Le problème : les agents IA échouent quand le contexte est fragmenté

Pourquoi les agents se trompent-ils en entreprise ?

Dans une démonstration contrôlée, un agent dispose souvent d'un objectif clair, d'une documentation propre et d'un petit nombre d'outils. Dans une entreprise réelle, il rencontre l'inverse: des règles métier implicites, des acronymes locaux, des dashboards contradictoires, des tickets anciens, des exports ponctuels, des décisions prises en réunion et des exceptions que seules quelques personnes connaissent.

Ce décalage explique beaucoup d'échecs. L'agent ne se trompe pas toujours parce qu'il est mauvais. Il se trompe parce qu'il reconstruit une carte du terrain à partir de fragments incomplets. Si deux documents décrivent la même métrique différemment, si un playbook n'est plus à jour, ou si la source de vérité n'est pas indiquée, le modèle peut produire une réponse plausible mais opérationnellement dangereuse.

Google Cloud formule le problème de manière très directe dans son annonce d'OKF: les modèles progressent, mais leur capacité reste souvent limitée par le manque de contexte pertinent. Cette page part de ce constat pour détailler le problème avant d'expliquer pourquoi un format comme OKF devient utile.

Le contexte est partout, donc nulle part

La connaissance utile d'une organisation ne vit presque jamais dans un seul endroit. Elle est distribuée entre Notion, Google Drive, Confluence, Slack, Linear, Jira, HubSpot, Salesforce, dashboards BI, tables SQL, notebooks, commentaires de code, runbooks, mails, comptes rendus de réunion et mémoire des équipes senior.

Pour un humain expérimenté, cette fragmentation reste pénible mais gérable: il sait qui demander, quel dossier ouvrir, quelle définition ignorer, quel dashboard est obsolète. Pour un agent, cette même fragmentation devient un risque systémique. Il voit des morceaux de contexte, mais pas toujours leur statut, leur fraîcheur, leur niveau de confiance ni leur relation avec les autres morceaux.

Le problème devient encore plus visible quand on déploie plusieurs agents. Chaque agent doit réapprendre où se trouvent les règles, quelles sources sont fiables et comment interpréter les entités métier. Sans carte commune, chaque intégration recommence le même travail d'assemblage.

Les cinq symptômes d'un contexte non exploitable

Un contexte non exploitable se reconnaît rarement à un seul bug. Il produit plutôt une série de symptômes: réponses qui semblent bonnes mais ne passent pas la validation métier, définitions de métriques incohérentes, agents incapables de citer leurs sources, onboarding lent des nouveaux outils IA, et dépendance continue aux mêmes personnes senior.

Le symptôme le plus dangereux est la réponse plausible. L'agent ne dit pas nécessairement je ne sais pas. Il assemble ce qu'il trouve, comble les trous et donne une réponse fluide. Dans un contexte marketing, cela peut produire un brief hors positionnement. Dans un contexte data, une métrique mal calculée. Dans un contexte support, une promesse client impossible à tenir.

Pourquoi le RAG ne suffit pas toujours

Le RAG reste une approche importante: il permet à un modèle de récupérer des passages pertinents dans un corpus avant de répondre. Les outils de retrieval et de file search sont utiles pour connecter un agent à une base documentaire, réduire la dépendance à la mémoire interne du modèle et citer des sources.

Mais le RAG ne transforme pas automatiquement une connaissance désordonnée en contexte fiable. Si les documents sont contradictoires, mal nommés, périmés ou sans ownership, le retrieval peut simplement ramener les mauvais passages plus vite. Un chunk proche sémantiquement n'est pas forcément la source correcte. Une documentation longue n'indique pas toujours ce qui fait foi aujourd'hui.

C'est pour cela qu'il faut distinguer deux couches. Le RAG retrouve des éléments au moment de la question. Un format comme OKF structure la matière première avant la question: concepts, types, liens, citations, historique, index et conventions de bundle. Les deux approches sont complémentaires, mais elles ne résolvent pas le même problème.

Le vrai problème : l'absence de carte de connaissance

Une entreprise n'a pas seulement besoin de documents. Elle a besoin d'une carte: quels concepts existent, comment ils se relient, quelles sources les prouvent, qui en est responsable, quand ils ont changé et dans quel workflow ils doivent être utilisés.

Sans cette carte, l'agent doit reconstruire le contexte à chaque tâche. Il doit deviner le sens des termes métier, retrouver les dépendances, choisir entre plusieurs sources et déterminer si l'information est encore valable. Cette reconstruction permanente crée de la lenteur, de l'incertitude et des erreurs difficiles à diagnostiquer.

La carte de connaissance n'a pas besoin d'être parfaite dès le départ. Elle doit d'abord rendre explicite ce qui était implicite: les définitions importantes, les sources de vérité, les relations critiques, les décisions structurantes et les playbooks que les agents doivent suivre.

Ce que cela coûte aux équipes

Le coût du contexte fragmenté est rarement présenté comme une ligne budgétaire, mais il se voit partout. Les équipes data recalculent les mêmes métriques. Les équipes produit réexpliquent les mêmes décisions. Le support reformule les mêmes réponses. Le marketing reconstruit les mêmes preuves. Les équipes ops relisent les mêmes runbooks.

À mesure que les agents entrent dans ces workflows, ce coût change de nature. Ce n'est plus seulement un coût humain d'onboarding ou de documentation. C'est un coût d'automatisation: chaque agent mal contexté augmente la charge de vérification, réduit la confiance et ralentit l'adoption.

Anthropic parle de context engineering pour désigner cette discipline: concevoir ce que l'agent doit voir, à quel moment, sous quelle forme et avec quelles limites. OKF s'inscrit dans cette logique en proposant un support portable pour organiser une partie de ce contexte.

Pourquoi OKF devient pertinent ici

OKF ne promet pas de supprimer toutes les erreurs d'agents. Il ne remplace pas une bonne stratégie data, une gouvernance documentaire ou une validation humaine sur les décisions sensibles. Sa proposition est plus simple et plus crédible: donner une forme portable à la connaissance que les humains et les agents doivent partager.

Concrètement, OKF permet de représenter des concepts métier dans des fichiers Markdown avec un frontmatter YAML minimal, des liens, des citations et des conventions de bundle. Cela rend le contexte plus lisible, plus versionnable et plus facilement consommable par différents outils.

La valeur commence avant même l'automatisation complète. Une entreprise qui crée son premier bundle OKF clarifie déjà ses définitions, identifie ses sources, expose ses trous de connaissance et réduit la dépendance aux explications orales. Le format devient alors un prétexte utile pour remettre de l'ordre dans le contexte.

Lire ensuite

Cette page pose le diagnostic. Les chapitres suivants expliquent comment OKF répond à ce problème, comment il se compare au RAG et comment démarrer sans vouloir cartographier toute l'entreprise d'un coup.

Sources officielles et lectures utiles