Le compte rendu mensuel ne devine jamais une ligne. Même le mois où il en manquait plus de la moitié.

Un rapport qui coûtait cher parce qu’il vivait hors de l’ERP

On vend nos programmes de transformation en jours, découpés par domaine fonctionnel à l’intérieur d’incréments pluriannuels. Chaque mois, un compte rendu chiffré part chez le client, avec le budget en jours par domaine, le consommé, le pourcentage, le restant, cumulé depuis le premier janvier.

Avant, ce document se fabriquait à la main, en dehors de l’ERP, à partir d’exports de feuilles de temps. Trois à quatre jours par mois, rien que pour recomposer un tableau que personne ne relisait vraiment tant qu’il n’y avait pas d’erreur dedans. Le document glissait. Il arrivait en retard plus souvent qu’à l’heure.

Le vrai coût n’était pas seulement les jours passés dessus. C’était la charge mentale de savoir que ce document traînait, tout le mois, tant qu’il n’était pas fait.

La même vérité, pas un rapport à part

La bascule a eu lieu en deux temps. D’abord un prototype, encore hors ERP, avec une ventilation au prorata des budgets faute de savoir rattacher un ticket à un domaine. Puis le modèle est entré dans Business Central : les domaines sont budgétés dans le projet, les tickets s’y rattachent, et le compte rendu se régénère depuis les mêmes écritures de temps que celles qui alimentent le journal de projet, donc la facture. Une seule vérité, deux usages.

Ça a un prix, et il ne se paie pas sur le rapport, il se paie sur la saisie. Une ligne facturable ne peut plus être soumise sans un numéro de ticket externe, sans un type de travail, ni avec une description qui recopie le libellé de la tâche, parce que cette description part telle quelle chez le client. On a rendu la saisie plus lente pour rendre le rapport plus vrai. C’est un arbitrage du même ordre que celui qu’on documente dans notre guide sur les personnalisations Business Central à éviter : le raccourci qui économise une minute aujourd’hui coûte une heure de doute plus tard.

La règle posée avant d’en avoir besoin

Une conséquence de ce montage : une tâche qui n’a jamais été découpée en domaines n’a rien à donner au rapport. Le temps passé dessus reste sans domaine, littéralement.

La tentation existe de rebasculer ce temps sur une tâche déjà découpée, pour que le rapport reste rond. La procédure de clôture l’interdit, et elle l’interdit depuis avant que le cas ne se présente : rattacher ces jours à une tâche découpée reviendrait à leur attribuer des domaines que personne, dans les faits, n’a revendiqués. La règle retenue tient en une phrase : montrer le trou, ne jamais le combler avec un libellé plausible.

Ce n’est pas une règle sur une tâche en particulier. C’est une règle sur ce que le rapport a le droit d’affirmer, point final.

Le mois où la règle a servi

Un mois, un contrôle a signalé avant l’envoi que 56 % du compte rendu partait sous l’intitulé brut d’une tâche jamais découpée. L’alerte n’était pas bloquante. Elle n’a pas arrêté la génération du rapport, elle l’a juste rendue impossible à ignorer.

Ce qui a suivi n’a rien d’un sursaut : c’est une procédure qui a fait ce pour quoi elle avait été écrite. Le raccourci qui aurait fait disparaître le chiffre est resté sur l’étagère. Le rapport montre cette ligne pour ce qu’elle est, du temps réel sans domaine revendiqué, plutôt que pour ce qu’une tâche découpée aurait pu laisser croire. Le trou est resté visible, et le correctif est allé là où il devait aller : sur la tâche qui n’avait jamais reçu son découpage.

Ce que ça vérifie, une fois par mois

Un rapport client automatisé n’est pas une preuve de fiabilité en soi ; un script fabrique un chiffre aussi vite qu’un humain fabrique une approximation. Ce qui rend celui-ci vérifiable, c’est qu’il n’a techniquement pas la place pour inventer : il ne sait dire que ce que les écritures de temps disent, et quand elles ne disent rien sur un point, il le montre.

Ça change aussi ce qu’un client peut faire du chiffre qu’il reçoit. Un rapport qui peut dire « je ne sais pas » sur une ligne peut aussi être cru sur toutes les autres, celles où il affirme un budget consommé sans réserve. C’est ce qui manque à un tableau reconstruit à la main : pas la compétence de qui le fait, la capacité du document lui-même à refuser d’affirmer ce qu’il ne sait pas.

C’est la même discipline qu’on tient sur une extension AL qui doit survivre à ses propres montées de version : le code qui triche avec ses propres données finit toujours par devoir choisir entre mentir au client ou casser en silence. On a préféré fermer cette option avant qu’elle ne se pose.

Si votre reporting client vit encore hors de votre ERP

La question à se poser n’est pas si le rapport sort à temps. Beaucoup sortent à temps, y compris ceux qui viennent d’un tableau reconstruit à la main.

La question est ce qu’il se passe le mois où une donnée manque. Est-ce que ça se voit, ou est-ce que ça se répartit discrètement pour que le total reste joli. La différence ne se lit pas sur un rapport qui va bien, elle se lit sur celui qui, un mois, ne devrait pas.

C’est une des choses qu’on regarde dans un bilan de clarté Business Central.