Pourquoi les rapports générés par l’IA échouent quand vos données opérationnelles restent dans Excel
Beaucoup se représentent le reporting par IA de façon très simple.
Vous prenez un dossier rempli de fichiers Excel, de PDF, de rapports quotidiens, de comptes rendus de terrain et de notes opérationnelles. Vous envoyez le tout à un modèle de langage. Puis vous demandez : « Fais-moi un rapport de direction. »
Sur un petit exemple, le résultat est étonnamment convaincant. Avec un ou deux fichiers, ou quelques jours de données, le modèle synthétise l’information, repère quelques tendances et produit quelque chose qui ressemble à un rapport.
Les ennuis commencent quand la situation devient réelle. Pas deux fichiers. Pas une semaine. Pas un tableur bien tenu. Mais des centaines de fichiers venus d’équipes différentes, sur des périodes différentes, dans des formats différents et pour des processus différents.
C’est là que l’approche « il suffit de tout donner au modèle » s’effondre. Le rapport sortira sans doute. Mais les chiffres deviennent difficiles à croire, les calculs difficiles à vérifier, et remonter d’une valeur jusqu’à sa source devient quasiment impossible.
C’est l’une des principales leçons que nous avons tirées en construisant Logsheet.ai.
Nous sommes partis d’une idée très simple : les journaux de production. L’entreprise décrit un journal une fois — journal d’évacuation de bois, rapport de poste, feuille d’arrêts machine ou tout autre journal opérationnel. Les équipes de terrain le remplissent chaque jour. Ligne après ligne. Poste après poste. Station après station.
Au départ, cela ressemble à un simple outil de collecte. Très vite, une nouvelle question apparaît : peut-on transformer tout cela en reporting de direction ?
Le vrai problème n’est pas la collecte
Beaucoup d’entreprises collectent déjà des données opérationnelles.
- Elles ont des tableurs.
- Elles ont des PDF.
- Elles ont des formulaires papier.
- Elles ont des photos prises sur le terrain.
- Elles ont des rapports de poste.
- Elles ont des synthèses quotidiennes.
- Elles ont des messages de chefs d’équipe.
Le problème n’est pas l’absence de données. Le problème, c’est qu’elles sont éparpillées, hétérogènes et pas préparées pour l’analyse.
Une équipe envoie un tableur. Une autre un PDF. Une troisième utilise un modèle légèrement différent. Une quatrième a renommé les colonnes. Certains fichiers contiennent plusieurs entités métier sur une même feuille. Certains ont des en-têtes à plusieurs niveaux. Certains ont des colonnes vides qui comptent quand même. Certains sont assez structurés pour un humain, pas assez pour un système.
Vus de loin, tous ces fichiers ressemblent à des rapports. Pour l’analyse de gestion, ce sont des matières premières. Et une matière première demande un traitement avant de devenir une information fiable.
Pourquoi envoyer des centaines de fichiers à un modèle ne fonctionne pas
Les modèles de langage comprennent bien le texte, reconnaissent les structures et aident à dialoguer avec l’information. Mais ce ne sont ni une base de données fiable, ni un moteur de calcul déterministe, ni une source de vérité transparente pour des centaines de fichiers opérationnels.
Sur un petit lot de documents, le modèle garde assez de contexte pour produire une synthèse utile. Dès que le volume grandit, plusieurs problèmes apparaissent.
- Le modèle perd des détails.
- Il fusionne parfois à tort des informations qui se ressemblent.
- Il produit des chiffres plausibles qui ne correspondent pas aux données sources.
- Il devient difficile d’expliquer d’où vient chaque valeur.
Pour un rapport de gestion, c’est dangereux. Un rapport n’est pas une simple synthèse textuelle. C’est un objet de décision. Si un directeur voit qu’un service est en retard, ou qu’une opération accumule des délais, le chiffre doit être traçable.
- D’où vient-il ?
- Quels fichiers y ont contribué ?
- Quelles lignes ont été retenues ?
- Quelle formule a été utilisée ?
- Qu’est-ce qui a été exclu ?
Si la réponse est « le modèle l’a dit », le système ne tient pas la route.
La base de données devient le socle
Le basculement le plus important a été de comprendre que l’IA ne doit pas être l’endroit où vivent les données opérationnelles. Les données doivent d’abord être extraites, normalisées et chargées dans une base. C’est seulement ensuite que l’IA devient utile.
Le flux devient bien plus fiable :
- L’utilisateur dépose ses fichiers opérationnels.
- Le système analyse leur structure.
- Les données sont réparties dans des journaux ou des tables.
- Les enregistrements sont sauvegardés en base.
- Les agrégats sont calculés de façon déterministe.
- Le modèle aide à concevoir et à expliquer le rapport.
- Le tableau de bord final peut être régénéré et vérifié.
Cela change le rôle de l’IA. Le modèle ne cherche plus à mémoriser le contenu des fichiers bruts. Il devient une interface et une couche de raisonnement posée sur des données structurées. Une place bien plus adaptée.
L’IA est utile à l’import — mais seulement avec des consignes strictes
L’import de fichiers paraît simple jusqu’à ce qu’on rencontre de vrais tableurs opérationnels.
- Un tableur peut contenir des cellules fusionnées.
- Un en-tête peut avoir trois niveaux.
- Une même feuille peut contenir plusieurs tables logiques.
- Certaines colonnes sont vides mais porteuses de sens.
- Certaines valeurs se comprennent par leur position, pas seulement par leur texte.
- Certains fichiers sont des versions différentes du même processus.
Si vous dites simplement au modèle « analyse ce fichier et charge-le dans des tables », il se trompera. La partie invisible du système devient donc décisive.
L’utilisateur voit une action simple : déposer un fichier. Derrière, le prompt système doit expliquer comment traiter les en-têtes, les colonnes vides, les entités multiples, les structures ambiguës, la création de journaux, les règles de correspondance et les exigences de validation.
La qualité du résultat dépend fortement de cette couche invisible. Sans elle, des données se perdent. Avec elle, le modèle devient bien plus utile.
Les rapports aussi ont besoin d’une structure invisible
Il en va de même pour la génération de rapports. Un utilisateur écrit : « Crée un rapport pour le directeur montrant tout ce qui est en retard. »
Cela paraît simple, mais le système doit le traduire en un plan de reporting bien plus précis.
- Qu’appelle-t-on le planning ?
- Où sont stockées les valeurs prévues ?
- Où sont stockées les valeurs réelles ?
- Comment calculer un retard ?
- Quels journaux contiennent l’information utile ?
- Quels champs définissent le statut ?
- Quels indicateurs mettre en avant ?
- Quels graphiques ont du sens ?
- Que souligner dans les conclusions ?
L’utilisateur n’a pas à décrire tout cela à la main. Le système, si. La tâche du modèle n’est donc pas seulement de rédiger un beau rapport : il doit raisonner sur la structure des données disponibles, préparer un plan et décider des requêtes et des sections nécessaires.
C’est là que les modèles de langage sont réellement utiles : ils transforment une demande humaine en spécification de reporting structurée.
Nous ne laissons pas le modèle calculer les chiffres
L’une des grandes inquiétudes autour du reporting par IA, ce sont les hallucinations. Elle est fondée. Si le modèle peut inventer, estimer ou calculer librement, le rapport n’est pas fiable.
Notre approche est différente. Le modèle peut décider de ce qu’il faut calculer. Il peut expliquer ce que signifie un chiffre. Il peut aider à structurer le rapport. Il peut rédiger les conclusions et mettre en avant des tendances.
Mais les calculs eux-mêmes se font en dehors du modèle. Sommes, moyennes, écarts, pourcentages et autres agrégats sont calculés de façon déterministe, généralement par des requêtes SQL ou une autre couche de calcul contrôlée.
Cela crée une frontière essentielle. Le modèle écrit le texte. La base fournit les chiffres.
C’est cette frontière qui rend le rapport auditable. Si un chiffre apparaît dans le tableau de bord, on peut remonter jusqu’à la requête et aux enregistrements sources. C’est toute la différence entre un système de reporting par IA utile et une hallucination bien présentée.
La vérification multi-agents améliore la fiabilité
Autre leçon : une seule étape d’IA ne suffit souvent pas. Pour les imports complexes et les structures de rapport, nous avons mis en place une auto-vérification.
- Un agent prépare une structure.
- Un deuxième la contrôle.
- Un troisième repasse sur le résultat.
- Si quelque chose cloche, le processus boucle jusqu’à un résultat acceptable.
Le système n’en devient pas parfait, mais il gagne en fiabilité. Dans nos essais internes, ce type de contrôle a amélioré la reconnaissance des fichiers d’environ 10 %. Cela peut sembler modeste, mais en traitement de données opérationnelles 10 % pèsent lourd — surtout quand l’alternative consiste à nettoyer les fichiers et à vérifier chaque table importée à la main.
Le cache de prompts compte plus qu’on ne le croit
Avec de gros contextes opérationnels, le coût en tokens grimpe vite. Un système réutilise en permanence la même structure de base, les mêmes définitions de journaux, les mêmes standards de reporting et les mêmes consignes d’import. Si tout est renvoyé à zéro à chaque appel, la facture s’envole.
Le cache de prompts réduit fortement ce coût. Sur une période de tests internes, nous avons dépensé environ 80 dollars pour des dizaines de millions de tokens traités, les économies de cache dépassant la dépense directe. Les chiffres exacts dépendent beaucoup du cas d’usage, mais la direction est claire : quand le contexte se répète, le cache compte.
Pour qui construit des systèmes comparables, le cache ne doit pas être une réflexion d’après-coup. Il pèse sur le coût, sur la latence et sur la viabilité économique du produit.
L’IA de bureau paraît plus simple que l’IA par API
Autre leçon pratique : tester avec des applications d’IA de bureau peut induire en erreur.
Quand nous déposions les fichiers à la main dans les versions bureau de ces produits, l’expérience paraissait très solide. Le contexte tenait, l’interface était confortable, les résultats faciles à inspecter.
Porter le même flux sur une API est une tout autre affaire. Contexte, limites, gestion des fichiers, prompts, reprises, mémoire, validation et coûts vous reviennent. L’API donne le contrôle, mais elle expose aussi toute la complexité d’ingénierie que le produit de bureau masque.
C’est là que beaucoup de prototypes cassent. Une démo peut fonctionner à la main. Un flux de production a besoin d’un système.
La question de la confidentialité ne disparaît pas
Dès que des données opérationnelles passent par des fournisseurs de modèles externes, la confidentialité devient un vrai sujet. Les données industrielles peuvent contenir des volumes de production, des problèmes d’équipement, des retards, des processus internes, des fournisseurs, des commandes clients et d’autres informations sensibles.
Plusieurs approches existent. La première : passer par les offres entreprise des fournisseurs, où les conditions d’usage des données sont plus claires et l’entraînement restreint. La deuxième : scinder le flux, en confiant l’interprétation des structures complexes à des modèles externes et en traitant les données sensibles dans un environnement plus maîtrisé. La troisième : basculer vers des modèles locaux pour certaines étapes.
Aucune de ces options n’est parfaite. Mais l’architecture doit prendre le sujet en compte dès le départ.
L’idée plus large : le journal devient une infrastructure de pilotage
Ce qui commence comme de simples journaux opérationnels peut devenir bien davantage. Dès lors que collecte, import, structure, validation, reporting et tableaux de bord sont reliés, le journal n’est plus un formulaire. Il devient un système de pilotage.
- Les équipes de terrain saisissent les données du jour.
- Les fichiers issus des processus existants peuvent être importés.
- La base de données devient la source de vérité.
- L’IA aide à interpréter la structure et à produire les rapports.
- SQL garde les chiffres déterministes.
- Les tableaux de bord donnent de la visibilité aux responsables.
- Les utilisateurs peuvent poser des questions et descendre dans le détail.
C’est la valeur concrète que nous voyons ici. Non pas « l’IA rédige un rapport à partir de fichiers en vrac », mais « l’IA aide à transformer des données opérationnelles en visibilité de gestion structurée ».
En conclusion
Vous pouvez envoyer 200 fichiers Excel à un modèle et demander un rapport. Vous obtiendrez peut-être quelque chose d’impressionnant. Mais si les chiffres ne sont pas vérifiables, si les données ne sont pas traçables et si le processus n’est pas reproductible, ce n’est pas un système de reporting de gestion. C’est une démonstration.
L’approche vraiment utile est moins magique et plus architecturale :
- extraire les données des fichiers ;
- les normaliser ;
- les stocker en base ;
- calculer les chiffres de façon déterministe ;
- utiliser l’IA pour la structure, l’interprétation, la logique du rapport et le texte ;
- valider le résultat ;
- mettre en cache le contexte répété ;
- garder la confidentialité en tête.
C’est ce qui sépare l’IA gadget de l’IA intégrée à un produit de reporting opérationnel.
La leçon est simple : les modèles de langage ne remplacent pas des données structurées. Mais posés au-dessus de données structurées, ils deviennent une interface puissante entre le travail quotidien sur le terrain et les décisions de direction.
