Du volume à la sélection : le piège que les agents d'IA sont en train de forcer à résoudre
Il existe une croyance qui circule dans les couloirs de presque toutes les organisations ayant investi dans l'intelligence artificielle au cours des huit dernières années. La croyance selon laquelle le problème est toujours une question de quantité. Plus de données. Plus de tokens. Plus de couverture. Plus d'historique stocké. Comme si l'intelligence était proportionnelle au volume, et que la solution à n'importe quelle défaillance du système consistait simplement à en ajouter davantage.
Cette conviction n'est pas née de la naïveté. Elle est née à l'ère du big data, une époque où accumuler de l'information était techniquement difficile, coûteux et donc précieux en soi. Celui qui disposait de plus de données avait un avantage. Celui qui pouvait les traiter, encore davantage. Le modèle était simple et obéissait à une logique de marché claire.
Ce qui se passe aujourd'hui dans les organisations qui déploient des agents d'IA en production est en train de forcer une révision inconfortable de cette prémisse. Le problème n'est plus la pénurie de données. Les entreprises de taille moyenne dans des secteurs matures ont accumulé des billions de tokens entre leurs CRM, bases de données, documents, e-mails, tickets de support, fils de communication interne et systèmes hérités. Le problème, c'est que les agents ne savent pas quoi faire de ce volume. Non pas parce qu'ils sont incapables de le traiter, mais parce que personne ne leur a appris à filtrer. Et cette incapacité à sélectionner n'est pas un problème technique. C'est un problème de conception organisationnelle que les entreprises évitent depuis des années, sous prétexte qu'elles avaient d'abord besoin de plus de données.
L'illusion que davantage de contexte équivaut à un meilleur contexte
Il existe une différence structurelle entre alimenter un modèle avec tout ce qui est disponible et lui donner accès au fragment exact dont il a besoin pour agir correctement à ce moment précis. La première option semble plus sûre parce qu'elle donne une impression d'exhaustivité. La seconde exige d'avoir pris au préalable une décision difficile : savoir ce qui compte et ce qui ne compte pas.
Cette décision est coûteuse parce qu'elle oblige quelqu'un au sein de l'organisation à s'engager sur une hiérarchie de pertinence. Et s'engager sur une hiérarchie de pertinence, c'est accepter que certaines choses ne comptent pas autant qu'on le croyait, que certaines données que l'on collecte depuis des années ne changent pas le résultat, que certaines sources qu'un département défend comme critiques sont en pratique du bruit.
Peu d'organisations sont prêtes à avoir cette conversation. Non pas parce qu'elles en seraient incapables. Mais parce qu'elle a un coût politique interne que personne ne veut assumer. Le résultat, c'est que les agents reçoivent des contextes gonflés, avec des informations contradictoires, sans hiérarchie claire, et produisent des réponses qui sont techniquement plausibles mais opérationnellement inutiles. L'échec est attribué au modèle. La conversation qui n'a pas eu lieu reste intacte.
Ce qui émerge comme réponse à ce problème porte un nom technique : l'ingénierie de contexte. Ce n'est pas une pratique d'optimisation de prompts, même si cela peut y ressembler en surface. C'est la discipline qui consiste à décider, avec un discernement organisationnel, quelles informations reçoit un agent pour exécuter une tâche concrète. Cela implique une recherche structurée pour extraire des faits précis à partir de systèmes formels, une recherche sémantique pour récupérer du sens dans un contenu non structuré, et une indexation inversée pour localiser des identifiants exacts en temps réel. Trois couches de récupération distinctes, chacune avec une fonction différente. Aucune ne se substitue à l'autre. Ensemble, elles transforment la connaissance accumulée en contexte utilisable.
Le problème, c'est que mettre cela en œuvre correctement exige que quelqu'un au sein de l'organisation ait défini au préalable ce qui est pertinent pour quel type de tâche. Et ce n'est pas un problème d'ingénierie. C'est un problème de gouvernance de la connaissance que la majorité des organisations n'a jamais résolu de manière explicite.
Ce que les graphes de contexte révèlent sur la maturité organisationnelle
La prochaine frontière dans l'architecture des agents d'entreprise porte un autre nom : les graphes de contexte. La distinction par rapport aux graphes de connaissances conventionnels est précise et mérite qu'on s'y arrête.
Un graphe de connaissances modélise ce qui existe : entités, relations, taxonomies, ontologies. Il indique à l'agent comment est structuré le monde conceptuel de l'organisation. C'est utile, mais insuffisant. Un agent qui sait qu'il existe un processus d'approbation des exceptions ne sait pas pour autant comment ces exceptions sont résolues dans la pratique, qui a l'autorité réelle pour les approuver dans des situations ambiguës, quel fil de conversation informelle a généré la décision aujourd'hui codifiée en politique, ni quel contournement l'équipe des opérations utilise depuis deux ans parce que le processus formel ne fonctionne pas.
Les graphes de contexte capturent cette couche procédurale. Ils enregistrent des traces de décision : qui a approuvé quoi, dans quel ordre, en utilisant quels outils, avec quel résultat. Ils construisent une mémoire organisationnelle persistante qui inclut non seulement l'état actuel des choses, mais aussi le chemin qui y a conduit.
L'implication est significative pour ceux qui dirigent des organisations, et pas seulement pour ceux qui les conçoivent techniquement. Une organisation capable de construire des graphes de contexte utiles est une organisation qui a réussi à rendre visible son propre processus de prise de décision. Qui a nommé ses flux réels d'approbation, ses exceptions habituelles, ses schémas d'escalade. Qui a eu la conversation sur la façon dont les décisions sont réellement prises, et pas seulement sur la façon dont l'organigramme dit qu'elles devraient l'être.
De nombreuses organisations ne peuvent pas construire cette couche parce qu'elles ne l'ont pas articulée. Non pas parce que l'information n'existe pas, mais parce qu'elle existe, dispersée dans des conversations informelles, dans la mémoire de personnes spécifiques, dans des pratiques non documentées que personne n'a jamais eu intérêt à rendre explicites, car les rendre explicites impliquerait également de les rendre auditables. Et c'est là que réside une tension que les projets d'IA agentique sont en train de porter à la surface avec plus de clarté que n'importe quelle mission de conseil en processus antérieure.
L'agent d'IA ne peut pas opérer avec ce que l'organisation refuse de nommer. Et le refus de nommer n'est pas toujours technique. Il est souvent politique. C'est la protection d'espaces de discrétion que certains départements ou certaines personnes ne souhaitent pas voir formalisés, car ils y perdraient une part de pouvoir ou d'autonomie.
Pourquoi le rythme d'adoption prédit qui aura l'avantage, et non qui l'a aujourd'hui
Gartner projette que plus de 50 % des systèmes d'agents d'IA dans les environnements d'entreprise utiliseront des graphes de contexte avant 2028. C'est un chiffre qui mérite d'être lu avec attention, car il ne dit pas que toutes les organisations les utiliseront bien. Il dit que la majorité les utilisera d'une façon ou d'une autre.
La différence entre les utiliser d'une façon ou d'une autre et les utiliser correctement dépend de quelque chose qui ne se résout pas avec un budget technologique. Cela dépend de si l'organisation a été capable d'effectuer le travail préalable consistant à articuler comment elle prend ses décisions, de manière granulaire et honnête. Les organisations qui arriveront en 2028 avec des graphes de contexte construits sur des processus formels que personne ne suit réellement disposeront d'agents sophistiqués qui répliquent les dysfonctionnements avec une plus grande efficacité. Les organisations qui auront effectué le travail inconfortable de cartographier leurs flux réels — y compris les flux informels, ceux que personne ne documente parce qu'ils sont justement commodes en raison de leur opacité — disposeront de quelque chose de qualitativement différent : une mémoire institutionnelle capable d'apprendre.
L'avantage concurrentiel dans le domaine des agents d'IA n'appartiendra pas à celui qui a déployé le plus de modèles ou qui dispose du plus grand nombre de tokens stockés. Il appartiendra à celui qui a su filtrer en premier. À celui qui a construit des systèmes capables d'identifier le fragment exact de contexte qui change le résultat d'une décision concrète. Et cela, en pratique, est une capacité organisationnelle avant d'être technologique.
Il vaut la peine de considérer ce qui se passe dans le scénario opposé. Une organisation avec des centaines d'agents opérant en parallèle, chacun construisant sa propre vision fragmentée et incohérente du fonctionnement de l'entreprise, génère un type de chaos qui n'est pas immédiatement visible mais qui est structurellement corrosif. Les agents se contredisent mutuellement. Les décisions prises par l'un ne sont pas cohérentes avec celles prises par un autre. La mémoire institutionnelle ne s'accumule pas, elle se fragmente. Et lorsque quelque chose tourne mal, personne ne peut retracer clairement quel contexte a reçu quel agent et pourquoi il a agi comme il l'a fait. La gouvernance s'effondre exactement au moment où elle est le plus nécessaire.
La sélection est la discipline que les organisations n'ont pas encore apprise
Il y a quelque chose que l'évolution de ces huit dernières années dans l'IA en entreprise confirme avec une remarquable constance. Le problème n'a jamais été la pénurie de données. C'était la résistance à décider ce qui compte.
Décider ce qui compte a un coût. Cela signifie que certains départements reçoivent moins d'attention du système que d'autres. Cela signifie que certaines sources de données représentant des années de travail accumulé n'entrent pas dans le contexte opérationnel des agents. Cela signifie que quelqu'un doit s'engager sur une hiérarchie et la défendre face à ceux qui ne sont pas d'accord.
Cette conversation, dans la plupart des organisations que je connais, n'a jamais eu lieu de manière explicite dans le contexte de la stratégie d'IA. Elle a été évitée grâce à la promesse implicite que le système pourrait tout gérer si on lui accordait une capacité de calcul suffisante. Ce que les agents d'IA mettent en évidence aujourd'hui, c'est que cette promesse n'a jamais été viable. Non pas parce que la puissance de calcul est insuffisante, mais parce que l'intelligence qu'un agent peut déployer est limitée par la qualité du contexte qu'il reçoit, et la qualité du contexte n'est pas une fonction du volume. C'est une fonction de la clarté avec laquelle l'organisation a été capable d'articuler ce qu'elle sait et comment elle l'utilise.
Les organisations qui parviendront à construire cette clarté ne le feront pas parce qu'elles ont trouvé la bonne plateforme technologique. Elles le feront parce que quelqu'un en position de leadership aura eu la volonté de forcer la conversation que les autres évitaient, de nommer ce que le système préférait laisser sans nom, de s'engager sur une hiérarchie de pertinence qui a un coût politique réel et visible. C'est la capacité qui ne s'achète pas avec un budget d'infrastructure. Et c'est, pour l'instant, la plus rare.
