Agents IA sur les données ERP : pourquoi « rien trouvé » est la réponse la plus dangereuse

La réponse la plus dangereuse d’un agent IA sur des données ERP n’est pas un chiffre faux. C’est « rien trouvé ». Un résultat vide a exactement la même tête, que la donnée n’existe pas ou que l’agent ait cherché au mauvais endroit, et l’agent annonce les deux avec la même assurance. La règle est donc simple : chaque réponse négative et chaque total lu par un agent se vérifient par une seconde route, chaque requête est bornée par date, et l’agent montre ses preuves, pas seulement sa conclusion.

Nous l’avons appris sur notre propre système. Nous faisons tourner un agent IA sur notre propre Business Central pour des contrôles internes, comme les feuilles de temps, et il nous a déjà donné des réponses vides, sûres d’elles, et fausses. Les deux échecs sont racontés dans notre article sur les agents IA dans Business Central. Voici la méthode que nous avons construite autour.

Pourquoi « rien trouvé » est-il plus dangereux qu’un chiffre faux ?

Parce qu’un chiffre faux appelle une question, alors qu’une réponse vide en ferme une. Quand un agent annonce un total qui paraît bizarre, quelqu’un vérifie. Quand il annonce « aucune absence enregistrée » ou « aucune pièce ouverte sur ce mois », personne ne cherche plus loin. Il n’y a rien à regarder.

Un agent qui filtre le mauvais champ et un agent qui lit une table réellement vide rendent la même réponse, sur le même ton. Le modèle ne fait pas la différence, parce que de son côté il n’y en a pas : il a posé une question, le système a répondu zéro ligne, il rapporte zéro ligne.

C’est aussi pour ça que la crainte habituelle envers l’IA, qu’elle invente, n’est pas la bonne crainte sur des données ERP. Sur notre tenant, l’agent n’a jamais inventé une saisie de temps. Il a lu de vraies données, au mauvais endroit, et en a tiré une conclusion nette.

Comment un agent IA lit-il mal des données ERP sans rien inventer ?

Quatre schémas, tous constatés sur nos propres données.

• Le même fait enregistré de deux façons. Chez nous, les absences ne sont pas saisies de la même manière pour les salariés et pour les prestataires. Un agent qui cherche d’une seule façon en trouve la moitié et conclut que l’autre moitié n’existe pas. Dans un groupe, ce schéma se multiplie : deux entités qui enregistrent la même chose différemment, c’est le cas normal, pas l’exception.
• Une fenêtre tronquée. Certains champs ne sont pas filtrables sur certains points d’accès de l’API. Si l’agent récupère le premier lot de lignes puis filtre ensuite, il lit une fenêtre qui peut s’arrêter des mois avant la période demandée.
• Un vocabulaire qui ne correspond pas. Sur notre tenant, la valeur qu’une page d’import attend pour un champ n’est pas celle que la page de lecture renvoie pour ce même champ. Un filtre écrit avec la valeur d’import renvoie zéro ligne sur la page de lecture. Aucune erreur, aucun avertissement, juste une liste vide.
• Un fait que l’ERP ne connaît que si quelqu’un le déclare. Nous avons voulu repérer les jours fériés à partir des lignes saisies. C’est impossible : une personne qui travaille un jour férié saisit une journée normale, donc par construction il n’existe aucune ligne « férié » à trouver. Le contrôle était aveugle exactement là où il servait.

Aucun de ces cas n’est un problème de modèle. Chacun est un écart entre la façon dont la donnée est enregistrée et la façon dont la question est posée, et un modèle plus puissant pose la question de la même manière.

Concrètement, qu’est-ce qu’une seconde route ?

Une seconde route, c’est un autre chemin vers le même fait, qui ne partage pas l’angle mort du premier. Quand les deux concordent, on peut agir. Quand elles divergent, on a trouvé le problème avant qu’il n’atteigne une décision.

Sur nos propres contrôles, les secondes routes ressemblent à ceci :

• Deux tests, réunis. Pour trouver les absences, nous testons deux champs différents et prenons l’union. Tester l’un ou l’autre seul rate une population entière.
• Un document indépendant. Un total mensuel lu dans l’ERP est comparé à un document produit autrement. Une fois, le total d’un mois était faux, plausible, sans zéro suspect et sans aucune erreur. Seule la comparaison avec un document indépendant l’a attrapé.
• Une source extérieure pour les faits extérieurs. Les jours fériés viennent du calendrier public officiel, pas de ce que les gens ont saisi. L’ERP dit ce qui a été déclaré. Il ne peut pas dire ce qui aurait dû l’être.

Une réponse négative n’est acceptée que si deux routes indépendantes la confirment. Cette règle coûte une requête de plus. L’avoir sautée une fois a conduit l’agent à poser à notre fondateur une question à laquelle ses propres données répondaient déjà.

Pourquoi borner chaque requête par date d’abord ?

Parce que la date est le seul axe que l’on peut toujours vérifier après coup. Si l’agent récupère un nombre plafonné de lignes et les filtre ensuite, le résultat dépend des lignes qui sont arrivées en premier, et cela n’a rien à voir avec votre question.

Nous bornons donc d’abord la requête sur la période, puis nous regroupons et filtrons. Et nous demandons à l’agent d’indiquer la date la plus ancienne et la plus récente qu’il a réellement lues. Si vous avez demandé un mois et que la date la plus récente lue tombe des semaines avant le début de ce mois, la fenêtre était tronquée, et le zéro annoncé ne veut rien dire. La plage de dates réellement lue est un meilleur témoin que la réponse elle-même.

Que doit exiger une équipe finance d’un agent ?

Des preuves, pas de l’assurance. Avant que quiconque agisse sur la réponse d’un agent, celui-ci doit montrer quatre choses :

1. Le filtre utilisé, écrit en clair.
2. Le nombre de lignes lues.
3. La plage de dates couverte par ces lignes.
4. Les champs testés, et ceux sur lesquels il n’a pas pu filtrer.

Un « non » sans la requête derrière n’est pas une réponse, c’est une supposition prononcée sans sourciller. C’est la même discipline que pour les droits : nous ne croyons pas à un réglage en lecture seule parce qu’une case est cochée, nous le prouvons en cherchant des actions d’écriture et en n’en trouvant aucune.

Cela change aussi la façon de demander. « Y a-t-il des lignes non approuvées ? » appelle un oui ou un non. « Listez les lignes non approuvées du 1er au 31, avec le filtre utilisé et le nombre de lignes » appelle une réponse que l’on peut vérifier.

Où une personne doit-elle encore trancher ?

Partout où la correction demanderait de deviner. Notre règle : l’agent signale, il ne répare pas pour faire passer un contrôle.

Un exemple tiré de nos propres données. Certaines lignes portent un projet mais pas de tâche. Les corriger n’est jamais automatique : la ligne ne dit pas ce qui était voulu, et quand la référence du ticket manque aussi, seul l’auteur le sait. Un agent qui comble le trou avec la valeur la plus probable transforme un problème visible en problème invisible.

Il en va de même pour les écarts entre entités. Quand deux filiales enregistrent la même chose de deux façons, l’agent peut trouver chaque cas. Il ne peut pas décider quelle façon est la bonne pour le groupe. C’est une décision de gouvernance, et le conseil cause racine sert à la prendre avant de confier les données à un outil.

L’approche Asio Services

Nous mettons des agents sur les données ERP pour lire, recouper et préparer, et nous traitons chaque réponse comme une affirmation à vérifier, pas comme un fait à classer. Une seconde route pour chaque réponse négative, un bornage par date sur chaque requête, des preuves avant la confiance, et une personne qui tranche partout où il faudrait deviner. C’est le cœur de notre approche de l’IA pour les groupes multi-entités : la difficulté est dans les données en dessous, pas dans le modèle au-dessus.

Si vous testez un agent sur vos propres données ERP et voulez savoir à quelles réponses vous fier, commencez par une session de clarté.

FAQ

Les agents IA inventent-ils des chiffres sur les données ERP ?

Rarement, d’après notre expérience. L’échec courant est une mauvaise lecture : l’agent interroge le mauvais champ, ou un lot de lignes tronqué, et rend un résultat propre. C’est plus difficile à repérer qu’un chiffre inventé, parce que cela ressemble à une vraie réponse.

Comment savoir si le « rien trouvé » d’un agent est réel ?

Demandez le filtre, le nombre de lignes et la plage de dates lues, puis confirmez la réponse par une seconde route indépendante. Si la plage de dates ne couvre pas la période demandée, le résultat vide ne vous apprend rien.

Un meilleur modèle d’IA corrige-t-il ces erreurs ?

Non. Ces erreurs viennent de la façon dont la donnée est enregistrée et dont la question est posée. Un modèle plus puissant pose la même question de la même façon et obtient la même réponse vide. La solution se trouve du côté des données et de la vérification.

Un agent IA doit-il corriger les erreurs qu’il trouve ?

Pas quand la correction suppose de deviner. L’agent doit signaler la ligne et dire ce qui manque. Une personne qui connaît le contexte tranche, sinon un problème visible devient un problème caché.