L'iceberg organisationnel : les données invisibles qui nuisent à vos agents d'IA

Le raisonnement derrière chaque décision, jamais consigné, fait échouer les agents d'IA ; seules les entreprises qui capturent ce jugement organisationnel en tireront de la valeur.

Lorsque nous concevons des plateformes de données pour de grandes organisations, nous prenons souvent des décisions en fonction de ce que nous pouvons voir, mais nous ignorons les données invisibles, qui peuvent s'avérer plus dangereuses que les données erronées. Ces données invisibles comprennent les exceptions, les approbations, le contexte, les connaissances institutionnelles non documentées, les synthèses inter-systèmes et les décisions relevant du jugement humain qui sont essentielles au bon fonctionnement de l'entreprise, mais qui sont rarement intégrées à un système.

Le phénomène n'est pas marginal : selon l'enquête de la BCE relayée par la Banque de France, les entreprises françaises citent les enjeux de données, de respect de la vie privée et d'éthique comme un frein majeur à l'adoption de l'IA.

Nous avons observé ce phénomène dans tous les secteurs, et notamment au sein d'une grande entreprise de réseaux sociaux, dans laquelle nous avons mené un audit des métadonnées qui a révélé que la plupart des jeux de données de production étaient orphelins, sans propriétaire ou redondants. Personne ne disposait d'un décompte fiable des API en cours d'exécution et les outils de catalogage traditionnels fournissaient des métadonnées obsolètes. Pour résoudre ce problème, nous avons développé des connecteurs basés sur des graphes, reconstitué la traçabilité des actifs et réalisé des économies chiffrées en centaines de millions d’euros. Mais même après avoir résolu le problème de visibilité des données structurées, nous nous sommes sans cesse heurtés au même obstacle : le raisonnement sous-jacent aux données était toujours introuvable dans le système.

Pendant des décennies, l'absence de ce raisonnement était jugée acceptable. Les équipes pouvaient le reconstituer grâce à l'expérience et à l'intégration de nouveaux collaborateurs. Les décisions devenaient incohérentes au fil du temps, mais cette incohérence demeurait invisible. Les agents d'IA, eux, la mettent en évidence.

L'obstacle rencontré par les agents

Prenons l'exemple d'un agent d'IA chargé du renouvellement d'un contrat client, qui doit décider s'il convient d'accorder une remise de 20 % alors que la politique plafonne les remises de renouvellement à 10 %. Un agent correctement configuré peut extraire le chiffre d'affaires du client depuis le CRM, consulter les tickets d'assistance ouverts, passer en revue les incidents récents et évaluer le document de politique applicable.

Cependant, ce dernier n'a pas accès au raisonnement des personnes qui exercent ce métier depuis suffisamment longtemps pour avoir accumulé la logique de l'historique des exceptions accordées au taux de remise et des changements non documentés dans la prise de décision à la suite d'une réorganisation.

Sans ce raisonnement, l'agent prend une mauvaise décision. Il transmet le dossier à un humain qui doit reconstituer la même logique à partir de zéro, ou applique rigoureusement la politique écrite dans des situations que l'organisation a toujours traitées au cas par cas. Ce scénario se solde par un échec, et ses effets s'accumulent à grande échelle.

Pourquoi les acteurs historiques ne peuvent-ils pas combler cet écart ?

La contrainte est d'ordre architectural : il ne s'agit pas d'un écart au niveau du produit qu'un éditeur pourrait combler par une simple mise à jour de sa roadmap.

Les systèmes d'enregistrement opérationnels (CRM, ERP et SIRH) ne stockent que l'état actuel. Lorsqu'une exception est approuvée, le contexte qui la justifiait disparaît. Vous pouvez constater que la remise a changé, mais vous ne pouvez ni rejouer l'état du monde au moment où cette décision a été prise, ni l'interroger, ni l'utiliser comme précédent pour un raisonnement futur.

Les plateformes de données sont confrontées à un problème différent. Elles reçoivent les données via des pipelines ETL (Extract, Transform, Load) une fois que les décisions ont déjà été prises. Au moment où un enregistrement arrive dans l'entrepôt de données, le contexte du raisonnement a déjà disparu. Ces plateformes peuvent vous montrer l'historique, mais pas la causalité, qui aurait déjà dû être présente dans le chemin d'exécution au moment du commit.

Aujourd'hui, tous les grands éditeurs de logiciels développent des capacités d'agents. Ces agents fonctionnent bien à l'intérieur des frontières de leur propre système, mais ils héritent des contraintes du système parent. Un agent CRM ne voit pas l'incident d'infrastructure enregistré dans le système de supervision et un agent de plateforme d'assistance ne voit pas le signal d'attrition dissimulé dans un fil de discussion interne. La synthèse inter-systèmes que les équipes expérimentées réalisent instinctivement reste invisible pour tout agent confiné au sein du périmètre d'un seul éditeur.

Un exemple concret. Chez Crédit Agricole CIB, les équipes de développement de Paris, Londres et Singapour travaillaient sur des outils cloisonnés, sans intégration native ni gestion standardisée, ce qui rendait invisible une large part de l'activité et de son contexte. En consolidant ces chaînes d'outils sur une plateforme unique et traçable, la banque a réduit ses délais de livraison de 50 à 75 % et ramené l'intégration d'une nouvelle équipe de cinq à dix jours à moins d’une journée.

La dimension manquante

La plupart des systèmes de gestion des connaissances d'entreprise recensent les entités existantes, la façon dont elles sont reliées et l'évolution de leur état au fil du temps.

Une autre dimension fait presque toujours défaut : les événements décisionnels, c'est-à-dire les enregistrements structurés des moments où le jugement organisationnel transforme le contexte en action. La plupart des équipes ne consignent pas les éléments qui ont motivé une décision, la version de la politique appliquée, ni les conditions posées par la personne qui a approuvé la décision.

Ce raisonnement se perd dans les fils de discussion Slack, au cours d'appels et dans les conversations d'intégration avec des personnes qui finissent par quitter l'entreprise. Avant l'arrivée des agents, cette perte restait gérable : un employé expérimenté pouvait reconstituer le raisonnement en faisant appel à sa mémoire et à ses relations.

Dans un environnement piloté par des agents, cet écart devient critique. Les agents doivent comprendre non seulement ce que dit la politique, mais aussi la manière dont l'organisation l'a historiquement mise en œuvre. Cette approche est rendue possible grâce à un registre vivant et interrogeable du jugement organisationnel, capturé au moment même où les décisions sont prises.

Chaque décision prise par l'organisation renforce l'argument en faveur de la mise en place de cette couche. Chaque trace de décision capturée devient un précédent consultable. Chaque exception affine le traitement des futures exceptions. Les connaissances organisationnelles qui disparaissaient auparavant avec le départ des employés deviennent une ressource durable qui survit aux réorganisations et aux acquisitions.

Comment agir

Nul besoin d'attendre qu'un éditeur résolve cette contrainte architecturale. Les cinq pratiques ci-dessous aident à construire cette couche manquante de façon progressive, sans remplacer l'infrastructure existante.

• Auditez votre surface d'exceptions. Recensez les décisions prises par votre organisation que les politiques consignées n'expliquent pas entièrement : exceptions tarifaires, dérogations d'approbation, exemptions de conformité. Ce sont ces lacunes qui entraîneront les premiers échecs des agents. Priorisez les éléments essentiels à cartographier au lieu d'essayer de capturer l'ensemble d'emblée.
• Orchestrez le chemin d'exécution, pas seulement le résultat. La plupart des systèmes de journalisation se contentent d'enregistrer les événements. La capture des décisions exige également d'enregistrer les motifs à l'origine de ces décisions : les données prises en compte, la version de la politique appliquée, la personne ayant donné son accord et les conditions qu'elle a posées. Ajoutez l'émission d'événements structurés aux workflows concernés avant d'y déployer des agents.
• Évaluez les éditeurs en fonction de leur capacité de raisonnement inter-systèmes. Lors de l'évaluation de plateformes d'agents, demandez précisément comment celles-ci gérent les décisions qui nécessitent du contexte provenant de plusieurs systèmes. Si la réponse repose entièrement sur des intégrations prêtes à l'emploi ou sur un modèle de données unique, l'écart structurel finira par se manifester sous la forme d'un échec en production.
• Commencez par les workflows fréquents et à fort enjeu. Les renouvellements clients, les revues d'exceptions de sécurité, les escalades d'incidents et les approbations fournisseurs sont d'excellents points de départ. Ils se produisent suffisamment souvent pour constituer rapidement un corpus de précédents pertinent, et les erreurs des agents dans ces domaines y ont un coût réel.
• Concevez pour le rejeu, pas seulement pour la récupération. Un historique de décisions utile est un artefact structuré que les équipes peuvent interroger, comparer à des décisions précédentes et utiliser pour vérifier si une action proposée est cohérente avec le comportement réel de l'organisation.

Ce que cette démarche implique vraiment

Les agents raisonnent à partir des données disponibles explicitement au moment de l'exécution, à une échelle et à une vitesse qu'aucun mécanisme humain de transfert de connaissances ne peut égaler.

Les entreprises qui tireront une valeur durable de leurs agents d'IA ne seront pas celles qui disposent des modèles les plus sophistiqués. Ce seront celles qui auront réussi à rendre leur jugement organisationnel interrogeable, en capturant non seulement ce que disent leurs données, mais aussi la manière dont leur organisation a choisi d'agir en fonction de celles-ci au fil du temps.

L'iceberg est bien réel, et les agents sont déjà à l'œuvre. Chaque décision que votre organisation prend sans en capturer le raisonnement représente une connaissance institutionnelle que vous ne pourrez plus jamais récupérer.