Du suivi du temps à la facturation : des saisies aux PDF personnalisés

Ce que vous allez créer et pourquoi c’est important

Une application de suivi du temps vers facturation résout un désordre courant : les heures se retrouvent éparpillées dans des calendriers, des discussions et des notes. Puis arrive le jour de la facturation et quelqu'un doit reconstituer le mois à la main. C'est là que les erreurs apparaissent : temps facturable oublié, mauvais tarifs, lignes en double ou totaux qui ne correspondent pas.

Cette application s'adresse à toute personne qui facture à l'heure et qui veut un processus reproductible : freelances gérant plusieurs clients, agences avec plusieurs personnes enregistrant du temps sur le même projet, et équipes internes qui refacturent du temps à des clients ou services.

L'objectif est pratique : capturer des saisies de temps par projet, les regrouper dans un enregistrement de facture et générer un PDF de marque que le client peut comprendre. Quand ce flux est fiable, la facturation cesse d'être une course mensuelle.

Adopter le principe « simple d'abord » signifie généralement :

• Une seule façon d'enregistrer le temps (date, projet, heures, note)
• Une règle de tarif unique (par projet ou par personne)
• Une facture par client et par période
• Une mise en page PDF unique avec votre logo et les informations de l'entreprise
• Des statuts clairs (Draft, Sent, Paid)

Un petit scénario : un studio de deux personnes suit le temps pour « Client A - Mises à jour du site ». Chaque personne enregistre des saisies pendant la semaine. Le vendredi, vous créez une facture pour ce projet et cette plage de dates, l'application transforme les saisies en lignes de facture, et le PDF est prêt à être envoyé sans ressaisie.

Si vous utilisez une plateforme no-code comme AppMaster, assurez-vous d'avoir les données et le flux corrects avant d'ajouter des extras comme les reçus, la multi-devise, les remises ou les approbations. Ceux-ci sont plus faciles à ajouter une fois que le flux de base est rapide, précis et difficile à casser.

Fonctionnalités principales à inclure (et ce qu'il faut laisser de côté au début)

Une petite première version vous permet d'obtenir des « factures prêtes à envoyer » plus rapidement. Concentrez-vous sur trois choses : capturer le temps, transformer le temps en lignes de facture claires et produire un PDF lisible par le client sans questions supplémentaires.

Commencez avec quelques enregistrements clés (vous pouvez renommer plus tard, mais la structure compte) : Client, Project, Time Entry, Invoice et Invoice Line.

Gardez le flux de facturation simple avec un seul champ de statut sur l'enregistrement Invoice. Draft, Sent et Paid couvrent la plupart des équipes pendant longtemps.

Vos actions indispensables doivent correspondre à ce qui se passe chaque semaine :

• Enregistrer du temps (la saisie manuelle est généralement la plus rapide à construire et la plus simple à corriger)
• Approuver le temps (même si ce n'est qu'un statut « Approved »)
• Créer une facture à partir du temps approuvé
• Exporter en PDF

« De marque » ne veut pas dire sophistiqué. Cela signifie cohérent et digne de confiance : logo, informations de l'entreprise, numéro et dates de facture, totaux clairs et instructions de paiement.

Ce qu'il faut laisser de côté au début : taxes, remises, multi-devise et pièces jointes. Ils sont utiles, mais introduisent des cas limites (arrondis, règles de juridiction, taux de change, stockage de fichiers) qui ralentissent la première version.

Modèle de données : les enregistrements nécessaires et les champs importants

Une application de suivi du temps vers facturation vit ou meurt selon son modèle de données. Gardez-le petit et prévisible pour que les totaux correspondent toujours à ce que vous avez promis au client.

Un ensemble minimal de tables ressemble généralement à ceci :

• Client : nom, email de facturation, adresse de facturation, devise par défaut, conditions de paiement (comme Net 14)
• Project : client_id, nom du projet, tarif horaire par défaut (optionnel), indicateur actif
• Time entry : project_id, personne (nom ou user_id), date, durée (heures), description, rate_at_time, facturable (oui/non), invoiced_invoice_id (vide jusqu'à facturation)
• Invoice : client_id, project_id (optionnel), numéro de facture, date d'émission, date d'échéance, statut, sous-total, taxe, total

Les tarifs sont souvent la partie la plus compliquée. Choisissez une approche et tenez-vous-y : tarif par projet, tarif par personne ou tarif fixe par tâche/service.

Même si vous conservez un tarif par défaut sur le projet ou la personne, copiez le tarif réel dans chaque saisie de temps en tant que rate_at_time lors de la création (ou de l'approbation) de l'entrée. Cela évite les surprises quand les tarifs changent plus tard. Les factures doivent refléter ce qui était vrai au moment du travail.

Pour les saisies de temps, vous pouvez souvent vous passer d'un statut séparé et vous fier au fait que invoiced_invoice_id est vide ou non. Pour les factures, gardez des statuts serrés : Draft, Ready, Sent, Paid (et ajoutez Void si vous avez besoin d'un état d'annulation propre).

Dans AppMaster, le Data Designer se mappe proprement sur PostgreSQL et facilite la gestion des relations sans dupliquer les champs partout.

Capturer les saisies de temps par projet (UX simple)

La capture du temps détermine si l'application est fluide ou ignorée. Gardez la première version ennuyeuse et rapide : un écran, une action principale et le moins de choix possible.

Choisissez une méthode de capture pour commencer. La saisie manuelle gagne souvent car elle fonctionne pour tout le monde et est facile à réviser. Un minuteur peut venir plus tard une fois que vous aurez appris comment les gens suivent réellement leur journée. Si vous ajoutez un minuteur, autorisez toujours les modifications manuelles pour les arrêts manqués.

Rendez obligatoires les champs qui protègent la facturation de qualité :

• Projet (ou client + projet)
• Date
• Durée (heures et minutes)
• Courte description (quelque chose que le client reconnaîtra)
• Personne (si plusieurs coéquipiers saisissent du temps)

Décidez des règles d'arrondi tôt car elles affectent la confiance et les totaux. Une approche courante est des incréments de 6 minutes (0,1 heure). Soyez clair sur l'arrondi par saisie ou sur le total journalier. Arrondir chaque saisie est plus simple à expliquer et à auditer.

Si plusieurs personnes interviennent dans la facturation, ajoutez une étape d'approbation légère. Une règle pratique : une fois approuvées, les saisies sont verrouillées par défaut. Si un changement est nécessaire, exigez un rôle de manager pour rouvrir et enregistrez qui a modifié et pourquoi.

Transformer le temps en lignes de facture (règles de regroupement)

Le « roll-up » est l'étape où les logs bruts deviennent des lignes de facture qu'un client peut comprendre. Gardez les règles simples et reproductibles pour pouvoir faire confiance à chaque facture que vous générez.

Commencez par une action : choisissez un client et une plage de dates, puis récupérez uniquement les saisies non facturées correspondantes. Ce filtre empêche la double facturation. Si une saisie n'a pas de client ou de projet, considérez-la comme « pas prête à facturer » et laissez-la hors du roll-up jusqu'à correction.

Comment regrouper les saisies en lignes de facture

Le regroupement détermine combien de lignes vous créez et la facilité de lecture pour le client. Choisissez un comportement par défaut et ajoutez un commutateur optionnel si vous avez besoin de flexibilité.

Options courantes de regroupement :

• Par projet
• Par personne (utile quand les tarifs diffèrent)
• Par jour ou par semaine
• Par tâche/catégorie (Design vs Développement)

Quelle que soit l'approche, chaque ligne doit afficher : un libellé clair, le total d'heures, le tarif et le montant de la ligne. Si les tarifs peuvent changer, utilisez le rate_at_time enregistré sur chaque saisie (ou une table de tarifs avec des dates d'effet), pas un « tarif courant » unique.

Marquer comme facturé (sans se mettre dans une impasse)

Quand vous ajoutez des saisies à une facture, enregistrez l'ID de la facture sur chaque saisie de temps. Cela crée une piste d'audit et empêche la même saisie d'être récupérée à nouveau.

Des corrections surviennent. Si vous supprimez une ligne d'une facture, ne supprimez pas l'historique. Détachez les saisies concernées (effacez l'ID de la facture), recalculez les totaux et enregistrez une courte note comme « Retiré 2,0h, mauvais projet. »

Dans AppMaster, cela s'imbrique bien en tant que processus métier unique : requêter les saisies non facturées, les regrouper, créer les lignes de facture, puis mettre à jour chaque saisie avec la référence de facture.

Enregistrements de facture : totaux, numérotation et statut

L'enregistrement de la facture est le conteneur que vous pouvez envoyer, tracer et auditer plus tard. Il doit rester stable même si quelqu'un modifie le nom d'un projet ou change un tarif par défaut.

Un en-tête de facture pratique inclut :

• Numéro de facture (unique et lisible)
• Date d'émission et date d'échéance
• Coordonnées du destinataire (nom du client, adresse de facturation, identifiant fiscal si nécessaire)
• Notes (instructions de paiement, courte formule de remerciement)
• Devise (et en option un taux de change enregistré si vous facturez à l'international)

Gardez les totaux prévisibles. Le sous-total est la somme des lignes de facture. Appliquez ensuite la remise (montant fixe ou pourcentage), calculez la taxe (souvent sur le sous-total après remise) et enregistrez le total final. Sauvegardez le taux de taxe exact et les valeurs de remise utilisés pour pouvoir reproduire la facture ultérieurement.

La numérotation des factures n'a pas besoin d'être sophistiquée. Choisissez un modèle et tenez-vous-y : séquentiel (000123), par année (2026-00123) ou préfixe client + séquence (ACME-014). La cohérence compte plus que la perfection.

Le statut doit rester orienté communication et contrôle interne :

• Draft (modifiable, non envoyé)
• Ready (totaux verrouillés)
• Sent (partagé avec le client)
• Paid (paiement confirmé)
• Overdue (passé la date d'échéance)
• Void (annulé, conservé pour l'historique)

Générer un PDF de marque lisible par votre client

Un bon PDF de facture répond rapidement à deux questions : qu'est-ce qui est facturé, et comment payer. Générez le PDF à partir de l'enregistrement de la facture (pas des saisies brutes) pour que le document corresponde toujours au numéro de facture, aux totaux et au statut.

La plupart des clients s'attendent aux mêmes blocs à chaque fois :

• En-tête avec le nom de votre entreprise, le numéro de facture et la date
• Coordonnées du client (entreprise, personne de contact, adresse de facturation, identifiant fiscal si nécessaire)
• Lignes (description, quantité ou heures, tarif, total de la ligne)
• Totaux (sous-total, taxe, remise, total général)
• Conditions de paiement (date d'échéance, méthodes acceptées, note sur pénalités de retard si applicable)

Le branding compte, mais la lisibilité compte plus. Utilisez une seule couleur d'accent, une police claire et facilitez la lecture des totaux.

Les problèmes de mise en page apparaissent avec des données réelles. Testez avec des descriptions longues et plus de 30 lignes. Assurez-vous que les en-têtes de colonne se répètent sur les nouvelles pages et que le bloc des totaux reste regroupé.

Si vous générez des PDFs dans AppMaster, traitez le PDF comme un artefact de la facture : enregistrez le fichier (ou la référence de stockage) sur l'enregistrement de la facture avec un horodatage et une version générée. Cela facilite la réexpédition du document exact que le client a reçu.

Plan de construction pas à pas (workflow no-code)

Décidez ce qui est la « source de vérité ». Les saisies de temps sont des faits bruts. Les factures sont un instantané que vous pouvez envoyer et auditer plus tard.

1) Modélisez les données en premier

Créez les tables et relations, puis ajoutez quelques champs de qualité une fois les bases stables :

• Clients
• Projects
• Time Entries
• Invoices
• Invoice Lines

2) Construisez deux écrans simples

Gardez l'UI minimale :

• Formulaire de saisie de temps : projet, date, durée, notes, sauvegarder
• Revue de facture : client, période, lignes, totaux, statut

Une interface web suffit généralement pour l'administration et les revues. Ajoutez des écrans mobiles plus tard si les gens saisissent du temps en déplacement.

3) Automatisez la logique de roll-up

Construisez un flux tel que : sélectionner client + plage de dates, récupérer les saisies non facturées, les regrouper, créer les lignes de facture. Marquez les saisies comme facturées seulement après que la facture est approuvée ou passée en Ready.

4) Générez et stockez le PDF

Ajoutez une action « Generate PDF » qui récupère l'en-tête de facture, les coordonnées du client et les lignes dans un modèle, puis enregistre la sortie sur l'enregistrement de la facture.

Exemple : des logs hebdomadaires aux factures prêtes client

Une agence de 3 personnes a un client, Northstar Co, et facture deux projets sur deux semaines : Website Refresh et Monthly Support. L'équipe est Alex (design), Priya (dev) et Sam (PM). Tout le monde enregistre du temps quotidiennement en choisissant le client, le projet, la date et une courte note.

Chaque jour, les saisies sont sauvegardées en Draft. Le vendredi après-midi, Sam ouvre un écran de revue filtré sur « Cette semaine, Northstar Co ». Il corrige deux notes (« Homepage hero » au lieu de « Hero »), confirme facturable vs non-facturable, et verrouille la semaine.

Voici un exemple de saisies cette semaine :

Quand Sam clique sur « Create invoice », l'application regroupe les saisies en lignes de facture avec des règles simples : regrouper par projet et tarif applicable, sommer les heures et reprendre une description courte. La facture obtient 3 lignes :

Le système assigne un numéro de facture (comme NS-2026-014), calcule le sous-total et la taxe, et met le statut à Ready. Un clic supplémentaire génère un PDF de marque (logo, adresse du client, détails des lignes, totaux, notes de paiement). Après envoi, le statut passe à Sent et les saisies sous-jacentes sont marquées comme facturées pour qu'elles ne puissent plus être refacturées.

Erreurs courantes et comment les éviter

La plupart des problèmes ne sont pas des erreurs de calcul mais des problèmes de workflow.

Ne pas verrouiller les saisies facturées. Si les gens peuvent modifier ou reselectionner les mêmes saisies pour une nouvelle facture, la double facturation finit par arriver. Corrigez cela en ajoutant une référence de facture sur chaque saisie et en masquant les saisies facturées de la vue « ready to invoice ».

Réécrire l'historique quand les tarifs changent. Si vous calculez uniquement à partir d'un tarif « courant » projet ou utilisateur, changer ce tarif modifiera d'anciennes factures. Copiez le tarif effectif dans rate_at_time sur chaque saisie.

Modifier du temps approuvé sans piste d'audit. Ajoutez « Approved by », « Approved at » et une courte note de changement pour les modifications après approbation.

PDFs qui cassent avec des données réelles. Des descriptions longues, de nombreuses lignes et de grands nombres mettront à l'épreuve votre modèle.

Corrections rapides qui évitent la plupart des problèmes de mise en page :

• Fixez une longueur maximale pour la description et déplacez l'excédent dans une section notes
• Autorisez le retour à la ligne et testez avec 30+ lignes
• Gardez l'en-tête compact pour laisser de la place au tableau
• Utilisez des formats numériques cohérents (devise, décimales)

Un flux de statuts flou. Sans règles claires, les factures sont envoyées deux fois ou jamais.

Un flux simple et sûr : Draft -> Ready -> Sent -> Paid. Autorisez les roll-ups seulement en Draft et la génération de PDF seulement quand les totaux sont verrouillés.

Une courte checklist et étapes pratiques suivantes

Avant d'envoyer une facture, faites une revue rapide. Cela évite les erreurs les plus courantes : totaux incorrects, détails manquants et PDFs qui semblent corrects à l'écran mais cassent à l'impression.

Checklist avant envoi :

• Les coordonnées du client sont complètes (nom légal, adresse de facturation, bon contact)
• La période de facturation est correcte (les dates de début et de fin correspondent au travail)
• Les totaux sont cohérents (sous-total, taxe, total correspondent aux saisies, tarifs et arrondis)
• Aucun temps n'est manquant ou dupliqué (rien d'oublié, rien d'inclus deux fois)
• Les champs opérationnels sont propres (numéro de facture unique, statut correct, PDF enregistré sur la facture)

Puis prévisualisez le PDF avec un regard « prêt pour l'impression ». Vérifiez le placement du logo, les adresses longues, le retour à la ligne du tableau et les sauts de page. Testez à la fois une facture courte (1-2 lignes) et une longue (20+ lignes).

Étapes suivantes une fois les bases stables :

• Envoyer les factures par email avec un modèle cohérent
• Ajouter Stripe pour les paiements et marquer les factures Paid automatiquement
• Ajouter des permissions pour que seuls les rôles appropriés puissent modifier les tarifs, approuver le temps ou changer les statuts

Si vous voulez construire et itérer rapidement sans tout réécrire, AppMaster (appmaster.io) est une option pratique pour créer une application de facturation no-code avec une vraie base de données, une logique métier et génération de PDF, puis régénérer du code source propre au fur et à mesure que les besoins évoluent.

Si vous n'améliorez qu'une seule chose cette semaine, faites en sorte que le « temps non facturé » soit impossible à manquer. Cela seul vous fait gagner des heures et protège vos revenus.