Pourquoi vos agents IA se trompent sur vos données

Un agent IA ne dit jamais qu'il hésite. Interrogé sur le chiffre d'affaires du mois, il donne un montant, précis, présenté avec assurance. Ce montant est exact au regard d'une définition. Rien ne garantit que ce soit celle du directeur financier.

L'erreur ne se situe presque jamais dans le modèle. Elle se loge dans les données que l'entreprise lui confie, et plus exactement dans les mots qui les décrivent.

Prenons l'exemple du chiffre d'affaires. La comptabilité le lit à la date de la facture, hors taxes. La direction commerciale le lit à la prise de commande. L'exploitation, dans un métier de chantiers ou de projets, le lit à l'avancement. La trésorerie ne le reconnaît qu'à l'encaissement. Aucune de ces lectures n'est fausse, chacune répond à un besoin. Le mot « client » connaît le même sort : une entité juridique pour la finance, un compte pour le commerce, un site de livraison pour la logistique.

Tant que des personnes font le lien entre les services, ces écarts se règlent par une conversation, ou par un « ah, tu parles du facturé ». Un agent IA ne converse pas avec le service voisin. Il interroge les tables qu'on lui indique et retient une lecture, sans savoir qu'il en existait d'autres.

Thomas Gruber la définissait, dès 1993, comme une spécification explicite d'une conceptualisation. Appliquée à l'entreprise, l'idée est concrète : décrire les concepts qui structurent l'activité (client, contrat, commande, facture, chantier, produit), leurs propriétés, les relations qui les lient et les règles qui s'y appliquent. Une facture se rattache à une commande, un client appartient à un groupe, une facture d'acompte ne constitue pas un chiffre d'affaires réalisé.

Un dictionnaire de données dit ce que contient chaque colonne. Une ontologie va plus loin, parce qu'elle rend explicites les liens et les règles, sous une forme qu'une machine peut exploiter. C'est ce qui permet à un agent de savoir de quel chiffre d'affaires on lui parle, et de le dire.

Une ontologie ne s'arrête d'ailleurs pas à des définitions isolées. Elle capture aussi les relations entre les concepts : un chantier dépend d'un client, s'appuie sur des sous-traitants, qui dépendent eux-mêmes de fournisseurs. Cette structure relationnelle permet à un agent de répondre à une question d'impact, pas seulement à une question de définition.

Cette structure ne suffit pourtant pas à elle seule. Il faut un mécanisme qui la relie aux données réelles de l'entreprise, à ses tables, à ses systèmes, aux flux qui alimentent le quotidien. C'est le rôle de la couche sémantique : un intermédiaire qui traduit une question posée en langage courant vers les bonnes définitions, les bonnes tables et les bons filtres.

Interrogé sur le chiffre d'affaires par produit du trimestre en Europe, un agent qui s'appuie sur une couche sémantique ne devine pas la réponse. Il consulte l'ontologie pour savoir ce que signifie « chiffre d'affaires » dans ce contexte, retrouve la donnée correspondante, et peut citer la définition qu'il a appliquée. Sans cette couche, la même question suppose que l'agent choisisse seul entre plusieurs tables, plusieurs filtres et plusieurs conventions, sans jamais le dire.

Un écart de définition passe inaperçu dans un reporting mensuel relu par des spécialistes. Il devient un problème dès qu'un agent répond, chaque jour, à des dizaines de questions posées par des personnes qui ne vérifient pas. L'automatisation ne crée pas l'incohérence, elle la diffuse.

Deux situations sont alors possibles. Dans la première, l'agent s'appuie sur un vocabulaire partagé et documenté, ses réponses citent la définition retenue et peuvent être contrôlées. Dans la seconde, il improvise à partir de définitions implicites, et personne ne peut dire laquelle il a appliquée. La différence ne tient pas à la puissance du modèle. Elle tient au travail réalisé sur les données avant de le brancher.

La facturation électronique en donne un exemple à grande échelle. La norme européenne EN 16931 décrit un modèle sémantique de la facture, avec des données définies et nommées de la même manière pour tous les émetteurs et tous les destinataires. C'est une forme d'ontologie imposée de l'extérieur, et c'est ce qui rend possible l'échange automatisé entre entreprises. Chaque entreprise gagne à faire le même effort pour ses propres concepts.

Il n'est pas nécessaire de modéliser toute l'entreprise. Une dizaine de concepts qui prêtent à débat suffisent pour démarrer, ceux dont les chiffres divergent d'un service à l'autre : chiffre d'affaires, marge, client, commande, chantier ou projet. Pour chacun, il convient de désigner un responsable, de rédiger une définition, d'indiquer la source de référence, puis de rendre ce référentiel accessible à l'agent.

Cet exercice réserve une surprise. Il révèle rapidement des désaccords que l'entreprise portait sans le savoir, et qu'aucun outil ne peut trancher à sa place. Quelqu'un doit décider de ce que signifie « client ». Ce travail est le plus long de la démarche, et il ne se délègue pas à un agent.