Reporting hebdomadaire automatisé : le cas d'une école de langue

Chaque lundi matin, la même séquence. Quelqu'un exporte les ventes du CRM, ouvre la console publicitaire pour récupérer les dépenses, colle tout dans un tableur, aligne les colonnes, rédige deux paragraphes de commentaire, et envoie l'ensemble avant la réunion d'équipe. Bout à bout, cela représentait environ six heures par semaine pour une école de langue avec laquelle nous avons travaillé.

Le problème n'était pas la durée. C'est que le résultat n'était jamais fiable. Les colonnes glissaient d'une semaine à l'autre, une offre se retrouvait comptée deux fois, et le chiffre de ventes affiché ne correspondait jamais tout à fait à celui que sortait le directeur commercial de son côté. En réunion, dix minutes partaient à trancher quel chiffre était le bon, avant même de parler de performance.

La demande initiale tenait en une phrase : automatiser le reporting du lundi. Ce que nous avons livré ressemble à cela de loin. De près, l'essentiel du travail n'avait rien à voir avec l'automatisation.

Le vrai problème n'était pas le temps, c'était la donnée

Avant d'écrire la moindre ligne d'agent, nous avons posé une question : qu'est-ce qu'une vente. La réponse changeait selon l'endroit où on la cherchait.

Le CRM comptait une vente quand le dossier passait à un certain statut. La console publicitaire attribuait des conversions selon sa propre fenêtre et sa propre logique d'attribution. Pour une même semaine, le nombre de ventes pouvait donc varier de plusieurs unités selon la source consultée. Personne n'avait tort : les deux outils mesuraient deux choses différentes en les appelant du même nom.

Ce désaccord silencieux était la racine du problème de confiance. Tant qu'il existait, aucun rapport, manuel ou automatisé, ne pouvait produire un chiffre défendable.

Nous avons donc passé l'essentiel des premiers jours à définir trois choses, par écrit, avec l'équipe :

• ce qui constitue une vente, et à quel moment elle est comptée ;
• comment elle se ventile par canal d'acquisition et par offre ;
• quelle source fait foi en cas de désaccord entre le CRM et la console.

Ce travail ne se montre pas en démo. Il est pourtant décisif : un agent qui automatise un calcul faux automatise une erreur, plus vite et plus souvent. La règle d'arbitrage, à elle seule, a réglé la moitié des discussions de réunion. Dès qu'une source est désignée comme référence, le débat ne porte plus sur le chiffre mais sur ce qu'il faut en faire.

Ce que fait l'agent

Une fois les définitions arrêtées, l'agent lui-même est presque modeste. Chaque lundi, avant 8 h, il exécute la même chaîne :

1. il interroge le CRM et l'API de la console publicitaire pour récupérer les agrégats de la semaine écoulée ;
2. il recoupe les deux sources et applique les règles de ventilation par canal et par offre validées en amont ;
3. il rédige un commentaire en langage clair, lisible par quelqu'un qui n'a pas le tableur sous les yeux ;
4. il livre le rapport, prêt à lire, sans intervention humaine.

Le rituel du lundi matin a disparu. Le rapport est là quand l'équipe arrive.

La règle non négociable : le calcul ne passe jamais par le modèle

Voici le point sur lequel nous ne transigeons pas, et que nous expliquons à chaque client. Les chiffres du rapport sortent d'un calcul déterministe, écrit en code. Jamais d'un modèle de langage.

Un modèle de langage est bon pour des tâches aux contours flous : lire un commentaire, reformuler, nettoyer une donnée mal saisie, repérer une catégorie mal orthographiée. Il est inadapté pour produire un total. Lui demander d'additionner des ventes, c'est accepter qu'un jour le résultat soit plausible mais faux, sans qu'aucune alerte ne se déclenche.

Dans ce système, le modèle a donc un rôle borné : il met en forme le commentaire et aide à nettoyer la donnée en entrée. Le total, l'écart à la semaine précédente, la ventilation, tout cela vient du code. Cette séparation n'est pas un détail d'implémentation : c'est ce qui rend le chiffre défendable face à un comptable ou un dirigeant.

Le tableau de bord : lisible en dix secondes

L'autre arbitrage portait sur ce que le rapport montre, et surtout sur ce qu'il ne montre pas.

Quand on a accès à toute la donnée, la tentation est de tout afficher. Nous avons fait l'inverse. Le tableau de bord se lit en une dizaine de secondes et tient sur l'essentiel :

• la tendance des ventes en ligne sur l'année, pour situer la semaine dans une trajectoire ;
• l'écart par rapport à la semaine précédente ;
• la ventilation par offre ;
• deux ou trois variations qui méritent une décision, mises en avant.

Le reste a été coupé. Un indicateur que personne ne regarde n'est pas neutre : il occupe de la place, dilue l'attention, et finit par décrédibiliser ceux qui comptent. La discipline consiste à résister à l'envie d'en ajouter au cas où. Si une donnée ne déclenche jamais de décision, elle n'a pas sa place sur la vue principale.

Ce que cela a changé

Les résultats tiennent en quelques points :

• environ six heures par semaine rendues à l'équipe, qui ne compile plus rien à la main ;
• un rapport prêt chaque lundi à 8 h, sans intervention ;
• un chiffre de ventes unique, désigné, que personne ne conteste plus en réunion ;
• des données hébergées en Europe, sans transit par une API tierce.

Aucun de ces résultats n'est une prouesse technique. Ce sont des gains opérationnels, vérifiables, qui tiennent semaine après semaine.

La leçon : le besoin n'était jamais "de l'IA"

Si on demandait à cette école ce qu'elle voulait, la réponse honnête n'était pas l'intelligence artificielle. C'était récupérer six heures et arrêter de se disputer sur un chiffre. L'agent n'est qu'un moyen, et la partie la plus utile du chantier, la définition de la donnée, ne contient pas une ligne de modèle.

C'est aussi pour cela que nous parlons d'un système opéré, pas d'une démo. Une démo impressionne une fois en réunion. Un système tient le lundi suivant, et celui d'après, quand une source change de format ou qu'une nouvelle offre apparaît au catalogue. La valeur n'est pas dans l'effet, elle est dans la régularité.

Questions fréquentes

Pourquoi ne pas laisser le modèle de langage calculer les totaux ?

Parce qu'un modèle de langage produit des sorties plausibles, pas garanties. Pour une reformulation, c'est acceptable. Pour un total de ventes, non : le jour où il se trompe, le chiffre reste crédible et rien ne signale l'erreur. Les agrégats viennent donc d'un calcul déterministe en code. Le modèle se limite à mettre en forme le commentaire et à nettoyer la donnée d'entrée.

Combien de temps pour déployer ce type de système ?

L'essentiel du temps ne va pas au code de l'agent, qui est court, mais au cadrage de la donnée : définir ce qu'est une vente, la ventilation, et la source qui arbitre. Cette phase détermine le délai, et c'est celle qu'il ne faut pas compresser. Une fois les définitions stabilisées et validées avec l'équipe, l'automatisation et le tableau de bord suivent vite.

Est-ce que nos données sortent de chez nous ?

Non. Dans ce cas, les données sont hébergées en Europe et ne transitent pas par une API tierce. Nous traitons ce paramètre au moment de l'architecture, avant l'implémentation, parce qu'il est difficile à corriger après coup. Selon les contraintes du client, le calcul et l'hébergement peuvent rester entièrement sous son contrôle.

Que se passe-t-il si une source de données tombe le lundi matin ?

Le système ne fait pas semblant. Si le CRM ou la console publicitaire ne répond pas, ou renvoie une donnée manifestement incohérente, l'agent le signale au lieu de livrer un rapport partiel présenté comme entier. Un chiffre faux qui passe inaperçu coûte plus cher qu'un rapport en retard et signalé comme tel. La règle d'arbitrage entre sources sert aussi à gérer ces cas de désaccord ou d'absence.

Et si nos définitions de KPI changent en cours de route ?

C'est prévu, et même attendu. Une nouvelle offre apparaît, un canal d'acquisition se réorganise, la direction décide de compter une vente autrement. Comme les règles de ventilation et d'arbitrage sont définies explicitement et séparées du code de calcul, les faire évoluer est une opération encadrée, pas une réécriture. C'est ce qui distingue un système opéré dans la durée d'une automatisation figée le jour de sa livraison.