Le temps non saisi est du chiffre d’affaires perdu
Sur une activité facturée au temps, la marge se joue à un endroit précis : l’écart entre le temps réellement passé et le temps qui finit sur la facture.
Cet écart a trois sources, et aucune n’est de la mauvaise volonté.
L’oubli. Vingt minutes au téléphone avec un client le mardi, un aller-retour de relecture le jeudi : ce sont des interruptions, pas des séances de travail. Elles ne s’inscrivent nulle part et disparaissent.
La reconstitution. Remplir son tableau le vendredi pour la semaine écoulée produit des chiffres ronds et pessimistes. Personne ne se surestime en reconstituant ; tout le monde se sous-estime.
L’autocensure. Une heure passée sur un point qu’on juge avoir mal anticipé ne se déclare pas. C’est humain, et c’est cher.
Le troisième point mérite d’être dit clairement : un système qui collecte le temps à partir de traces existantes ne supprime pas l’autocensure, mais il supprime les deux premières causes, qui sont les plus lourdes.
Ce qu’on automatise
La collecte. Depuis l’outil de tâches, l’agenda, le système de tickets, les canaux de projet — les endroits où le travail laisse déjà une trace.
Le rattachement. Quel client, quel dossier, quel poste. Avec une file de validation pour les traces ambiguës plutôt qu’une affectation par défaut.
L’application des règles. Taux, forfaits, catégories non facturables, arrondis, plafonds.
Le suivi de consommation. Budget consommé par mission, tendance, alerte aux seuils que vous définissez.
La préparation de la facture. Regroupement par livrable, rédaction des libellés, production de l’annexe détaillée.
La boucle de contrôle. Chaque personne reçoit, chaque semaine, un récapitulatif de ce qui a été attribué à son nom. Corriger sur la semaine écoulée est fiable ; corriger sur le mois écoulé ne l’est pas.
Comment ça marche techniquement — pour qui veut le détail
Les sources. Webhooks des outils de tâches (Jira, Linear, Notion, Trello) sur les changements d’état et les commentaires ; CalDAV ou API d’agenda pour les rendez-vous, avec filtrage sur les calendriers désignés — jamais l’agenda personnel ; historique des tickets de support ; Git pour les activités de développement, où l’horodatage des commits et la branche donnent un rattachement fiable au dossier. Chaque source produit des événements bruts conservés tels quels, jamais modifiés.
L’architecture en deux couches. Les événements bruts d’un côté, immuables et horodatés ; les entrées de temps dérivées de l’autre, recalculables. Cette séparation est ce qui permet de changer une règle d’attribution et de recalculer six mois d’historique sans avoir perdu l’information d’origine. Elle permet aussi de répondre à la question « d’où vient cette ligne de facture » en remontant à l’événement source.
L’inférence de durée. Un rendez-vous d’agenda donne une durée explicite. Un commentaire ou un changement d’état ne donne qu’un instant : on construit alors des sessions par regroupement temporel des événements d’une même personne sur un même dossier, avec un seuil d’inactivité au-delà duquel la session est close. Les paramètres — seuil de clôture, durée minimale, durée maximale d’une session sans confirmation — sont explicites et visibles, pas enfouis dans le code. Toute session inférée est marquée comme telle et distinguée d’une durée déclarée.
La détection de recouvrement. Deux sessions simultanées pour la même personne sont physiquement impossibles. Une contrainte d’exclusion GIST sur un tstzrange en PostgreSQL les rend impossibles en base, et le conflit remonte en file de validation. Sans ce garde-fou, un multi-sourçage produit de la surfacturation — ce qui est un problème bien plus grave que la sous-facturation qu’on cherchait à corriger.
L’attribution au dossier. Cascade de règles : identifiant de dossier explicite dans le titre ou le message ([ACME-42]) ; calendrier ou canal dédié à un client ; participant externe d’un rendez-vous dont le domaine de messagerie correspond à un client connu ; branche Git nommée selon la convention. Ce qui ne passe aucune règle va en file, jamais dans un dossier « divers » qui finirait non facturé.
Les arrondis. Règle unique, écrite : au quart d’heure supérieur, au dixième d’heure, à la minute. Appliquée au niveau choisi — par session, par jour ou par facture — et jamais deux fois. Un arrondi appliqué par session puis à nouveau au total produit un écart systématique en faveur de l’émetteur, ce qui se remarque et se conteste.
La rédaction des libellés. C’est le seul endroit où un modèle de langage a sa place : recevoir les libellés techniques des sessions d’un livrable et produire une ligne lisible par le client. Il reçoit les textes, jamais les durées, et la durée facturée est calculée en dehors de lui et injectée après. Cette séparation stricte est ce qui garantit qu’aucun chiffre facturé ne sort d’un modèle génératif.
Le suivi de budget. Vue matérialisée rafraîchie régulièrement : consommé, engagé, reste à faire, vitesse de consommation sur les quatre dernières semaines, date projetée d’épuisement. L’alerte porte sur la projection, pas sur le seuil atteint — savoir qu’on va dépasser dans trois semaines est actionnable, constater le dépassement ne l’est pas.
La clôture de période. Une fois la facture émise, les entrées de temps correspondantes sont verrouillées. Une correction ultérieure passe par une écriture d’ajustement visible, pas par une modification silencieuse de l’historique. C’est la même logique qu’en comptabilité, et pour les mêmes raisons.