Lorsqu'un agent IA donne une réponse erronée, le problème ne vient probablement pas du modèle. Il réside plutôt dans les données, qui n'ont jamais été conçues pour être harmonisées entre les différents systèmes.
Tout peut sembler parfait lors de la phase pilote. En effet, les projets pilotes aboutissent souvent parce que quelqu’un sélectionne les données manuellement et limite suffisamment le champ d’application pour que celui-ci reste gérable.
En production, ces conditions ne sont pas réunies.
Lorsqu’un agent doit traiter simultanément des données relatives aux fournisseurs, aux produits, aux finances et aux marchés, cinq points de défaillance spécifiques apparaissent.
Chacun d’entre eux est bien connu pris isolément. Mais ensemble, ils expliquent pourquoi tant de programmes d’IA s’enlisent après un départ prometteur. Examinons donc rapidement chacun d’entre eux et voyons comment y remédier pour permettre à votre IA agentique d’évoluer à grande échelle.
1. Fiches de référence obsolètes ou contradictoires
Commençons par l'erreur la plus élémentaire : l'agent se fie à un enregistrement qui est déjà obsolète.
Les données d'entreprise sont rarement centralisées. Un produit peut avoir cinq versions réparties entre différentes instances de progiciel de gestion intégré (ERP), un système de gestion des informations produit (PIM), une base de données régionale et un portail fournisseurs. Chacune d'entre elles est mise à jour selon son propre calendrier, par sa propre équipe.
Un agent ne sait pas quelle version est à jour. Il interroge le système auquel il est connecté et considère cette réponse comme une vérité absolue.
C’est ainsi qu’un agent chargé de la tarification peut finir par recommander une augmentation de 12 % dans une région et un prix inchangé dans une autre, pour le même produit, le même jour. Aucune de ces deux recommandations n’est erronée en soi. Chacune reflète simplement une version différente et obsolète de la même fiche produit.
Aucune des deux régions ne fait plus confiance au résultat dès lors que cette divergence apparaît.
2. Définitions contradictoires entre les domaines
La signification d'un « enregistrement » peut varier selon la personne à qui vous vous adressez au sein de l'organisation.
Les équipes chargées des achats, des finances et des ventes définissent souvent la même entité à leur manière. Un « produit » dans un système de gestion du cycle de vie des produits peut ne pas correspondre à un « produit » dans la tarification, et la classification des fournisseurs dans un système peut contredire une notation de risque dans un autre.
Un agent capable de raisonner de manière transversale n’a aucun moyen de résoudre ce problème par lui-même. Il se contente de choisir une définition et d’agir en conséquence.
Sans définitions communes à tous les domaines, un agent ne peut pas produire d'informations fiables. Il ne peut que formuler une hypothèse qui, par hasard, correspond à la vision d'un système donné.
3. Absence de traçabilité
Lorsqu'un résultat produit par un agent semble erroné, la question qui se pose alors est toujours la même : pourquoi a-t-il pris cette décision ?
Sans traçabilité, cette question reste sans réponse. Personne ne peut remonter à l’origine de la recommandation pour déterminer :
- Les enregistrements sources
- Les relations entre ces derniers
- Les règles métier appliquées tout au long du processus
La décision n'est pas accompagnée d'une traçabilité, ce qui rend impossible sa reproduction ou sa justification.
Cela a des conséquences bien au-delà de l'équipe chargée des données. La loi européenne sur l'IA exige que les systèmes d'IA à haut risque produisent des résultats pouvant être interprétés, documentés et tracés.
Pour les secteurs réglementés, l’absence de traçabilité transforme chaque décision inexplicable prise par un agent en un risque de non-conformité.
4. Absence de propriété des données ou de responsabilité clairement définie
Les données sur les produits appartiennent à une équipe. Les données sur les fournisseurs appartiennent à une autre, et dans la plupart des entreprises, personne n’est responsable de la relation entre les deux.
Cela fonctionne bien lorsque les humains prennent chaque décision au sein de leur propre domaine. Mais cela ne fonctionne plus dès lors qu’un agent a besoin de données cohérentes entre plusieurs domaines pour agir.
Personne n'a l'autorité nécessaire pour résoudre un conflit entre une fiche produit et une fiche fournisseur, car la responsabilité s'arrête aux limites de chaque système.
Sans une structure de responsabilité claire, la gouvernance inter-domaines ne fonctionne tout simplement pas.
5. Absence de seuils de confiance ou de procédure d’escalade pour les interventions des agents
Recommander une décision et la mettre en œuvre ne présentent pas le même niveau de risque. La plupart des cadres de gouvernance n’ont été conçus que pour le premier cas.
Un agent ne disposant pas d’un seuil de confiance défini applique le même niveau d’autonomie à chaque décision.
Peu importe le degré d’incertitude des données sous-jacentes. À aucun moment le système ne s’interrompt pour renvoyer la décision à une personne.
Cela signifie qu’une seule donnée erronée se transforme en erreur systémique. L’agent répète la même erreur sur tous les enregistrements qu’il traite, à la vitesse d’une machine, avant que quiconque ne s’en aperçoive.
Comment remédier à ces 5 défaillances liées aux données et rendre l'IA agentique fiable
Chacune de ces défaillances trouve son origine dans la même situation initiale : les données ont été gérées dans une optique de reporting plutôt que pour permettre aux machines d’agir rapidement.
Pour y remédier, procédez comme suit :
- Attribuez des responsabilités à travers les différents domaines, afin que quelqu’un ait l’autorité nécessaire pour résoudre un conflit entre une fiche produit et une fiche fournisseur. Ne laissez pas la situation dégénérer en un bras de fer entre les équipes.
- Intégrez les règles de gouvernance directement dans l’infrastructure de données, afin que les données erronées soient détectées avant d’atteindre un agent (et non plusieurs semaines plus tard lors d’un contrôle).
- Reliez les domaines entre eux via un modèle relationnel partagé, plutôt que de les gérer chacun de manière isolée. Un agent travaillant à la fois sur les données fournisseurs, produits et marchés doit disposer d’une vue d’ensemble cohérente.
- Considérez la traçabilité comme une caractéristique inhérente à chaque enregistrement par défaut, et non comme un élément que l’équipe de conformité doit reconstituer a posteriori.
Trop d’entreprises abordent cette question par étapes plutôt que d’un seul coup. Par exemple, elles commencent par la responsabilité, puis la gouvernance, avant de relier les domaines. La traçabilité découle naturellement d’une bonne exécution des autres étapes.
STEP, notre plateforme d’intelligence de confiance, gère l’ensemble de ces aspects au sein d’un système unique et interconnecté.
Comment Stibo Systems résout d’un seul coup toutes ces lacunes
STEP résout ces défaillances en considérant une base de données de référence multidomaine régie comme un système unique et interconnecté, plutôt que comme cinq problèmes distincts.
La question de la responsabilité est résolue grâce à un modèle de métadonnées partagé. Les données relatives aux produits, aux fournisseurs, aux clients et aux sites sont regroupées sur une seule plateforme régie par un cadre de gouvernance unique, de sorte qu’aucun domaine n’échappe au contrôle de quiconque.
Les règles de gouvernance sont intégrées aux données elles-mêmes. Le contrôle d’accès basé sur les rôles et les journaux d’audit s’appliquent à chaque enregistrement, que la modification soit effectuée par un responsable humain ou par un agent.
Les limites des agents sont définies par la couche agentique ancrée de la plateforme, qui fixe les seuils de confiance et les règles d’escalade auxquels un agent doit se conformer avant de pouvoir agir de manière autonome.
Et la traçabilité devient la norme. Chaque décision, qu’elle soit prise par un humain ou par une machine, fait l’objet d’un enregistrement de version et peut être retracée jusqu’à l’enregistrement, la relation et la règle qui l’ont générée.
En résumé
Corrigez les défaillances, et l’agent cesse de deviner. Il fonctionne à partir d’un enregistrement régulé, avec un responsable clairement identifié, un chemin décisionnel traçable et une limite définie quant à ce qu’il peut faire sans intervention humaine. Voilà à quoi ressemble une intelligence fiable au moment où un agent agit en conséquence.
Pour mieux comprendre pourquoi ces erreurs de données sont si courantes dans les programmes d’IA d’entreprise, téléchargez le livre blanc « AI at Scale », que nous avons co-rédigé avec Accenture. Ce livre blanc passe en revue les conditions relatives aux données qui font la différence entre un projet pilote et une IA déployée à grande échelle.
FAQ
Pourquoi mon IA donne-t-elle des réponses incohérentes sur le même produit ou client ?
L'agent est probablement en train de tirer de plus d'une version de cet enregistrement.
Différents systèmes, comme l'ERP, le PIM ou une base de données régionale, contiennent souvent des valeurs différentes pour le même produit ou client, et un agent n'a aucun moyen intégré de savoir lequel est à jour. Il répond simplement à partir de la source qu'il interroge par hasard.
Qu'est-ce qui pousse les agents IA à faire des erreurs même lorsque le modèle sous-jacent est bon ?
Un modèle capable peut encore agir sur de mauvaises entrées telles que :
- Dossiers obsolètes
- Définitions contradictoires entre les domaines
- Lignée manquante
- Propriété incertaine
Tous ces éléments produisent des erreurs qui ressemblent à des échecs du modèle en surface. Dans la plupart des cas, la cause profonde réside dans les données fournies à l'agent, et non dans la manière dont le modèle a raisonné à leur sujet.
Le réentraînement ou l'échange de modèles résout rarement un problème qui a commencé en amont dans la base de données elle-même.
En quoi l'IA agentique diffère-t-elle des recommandations d'IA en termes de risque de données ?
Une recommandation est vérifiée par un humain avant que quoi que ce soit ne se produise. Un agent saute cette étape, donc une mauvaise entrée se transforme immédiatement en une mauvaise action, et cela peut se répéter sur chaque enregistrement similaire avant que quelqu'un ne s'en aperçoive.
La gestion des données de référence est-elle toujours pertinente maintenant que la plupart des IA fonctionnent sur de grands modèles de langage ?
Plus pertinent, pas moins. Les grands modèles de langage (LLMs) gèrent bien la langue, mais ils dépendent toujours de données maîtresses gouvernées pour savoir :
- Quel enregistrement de fournisseur est à jour
- Comment un produit doit être classé
- Quel dossier client est autoritaire sur tous les marchés
Sans cette base, un LLM produit des réponses fluides construites sur de faux faits.
Qu'est-ce qu'une couche agentique ancrée ?
C'est une partie de l'architecture d'une plateforme qui définit ce qu'un agent peut décider de lui-même, et quand une décision doit être prise par une personne à la place.
Cela définit des seuils de confiance et des règles d'escalade directement dans l'infrastructure des données, de sorte qu'un agent travaillant sur des données incertaines ou de mauvaise qualité soit dirigé vers un humain plutôt que d'agir sur une supposition.
La correction de ces défaillances de données ralentit-elle la feuille de route de l'IA ?
Pas nécessairement. La propriété, la gouvernance et le travail de traçabilité peuvent se faire parallèlement au développement de l'IA au lieu d'être une phase distincte qui retarde tout le reste.
Les équipes qui sautent cette étape ont tendance à perdre plus de temps par la suite, à reconstruire la confiance dans un agent qui a commis une erreur visible en production. Réparer les fondations tôt est généralement le chemin le plus rapide.
