Pourquoi toutes les entreprises ont besoin d’un graphique de connaissances à l’ère de l’IA

L’IA a accéléré de manière fondamentale le développement de logiciels, mais elle n’a que peu changé la façon dont les organisations logicielles opèrent. Cette discordance devient tranquillement la plus grande contrainte sur l’IA d’entreprise.

Pendant des années, les équipes d’ingénieurs avaient besoin de plus de ressources pour suivre la demande. Aujourd’hui, de petites équipes utilisent l’IA pour générer du code, tester et accélérer le chemin de l’idée à la mise en œuvre. Les développeurs expédient clairement du code plus rapidement, mais si cela se traduit de manière cohérente par de meilleurs résultats reste flou.

Cette vitesse crée un nouveau goulet d’étranglement : la taxe de coordination. L’IA a accéléré l’exécution beaucoup plus rapidement qu’elle n’a amélioré la façon dont les organisations coordonnent leur travail. Le partage de contexte, la priorisation, la prise de décision opérationnelle, les rapports de statut et l’alignement interfonctionnel restent largement manuels, même si le développement s’accélère.

Atlassian estime que la déconnexion résultante coûte aux entreprises du Fortune 500 environ 161 milliards de dollars par an. La même étude a constaté que même si 89 % des dirigeants estiment que l’IA a accéléré le travail, seuls 6 % peuvent pointer des résultats mesurables à l’échelle de l’organisation.

Des sorties plus rapides ne créent pas automatiquement une organisation plus intelligente. Seuls 17 % des utilisateurs estiment que les agents ont amélioré la collaboration au sein de leur équipe, ce qui en fait l’impact le moins évalué, laissant la boucle de coordination déconnectée.

Reconstruire le contexte à chaque requête est un coût élevé

Alors qu’une démonstration prospère en utilisant des sources de données propres et ciblées, les environnements de production présentent un défi : des informations ambigües, obsolètes et contradictoires dispersées à travers des systèmes déconnectés. Lorsqu’il est confronté à ces lacunes, un grand modèle de langage fait ce pour quoi il a été conçu : il prédit la réponse la plus probable. Ce qui ressemblait à une raison dans une démonstration contrôlée devient rapidement une supposition confiante avec des données de production réelles.

L’industrie a commencé à donner un nom à ce problème. L'”ingénierie du contexte” est devenue la discipline qui se concentre sur la conception de l’information, des relations, de la gouvernance et de la qualité qui déterminent si l’IA d’entreprise réussit. Le facteur limitant est souvent non plus le modèle lui-même, mais la qualité du contexte qui l’entoure.

Chaque fois qu’un système d’IA reconstruit le contexte à partir de zéro, il paie un coût. Les réponses sont lentes, les coûts de jetons augmentent et la confiance s’érode car les réponses varient en fonction des pièces de connaissance organisationnelle récupérées. Deux agents d’IA peuvent répondre différemment à la même question car chacun assemble le contexte à partir d’une tranche différente de connaissance organisationnelle.

La plupart des organisations possèdent déjà les connaissances dont leurs systèmes d’IA ont besoin. Le problème est que ces connaissances sont fragmentées à travers les tickets, les référentiels, la documentation, les conversations et les outils de planification. Par conséquent, chaque interaction commence par reconstruire le contexte organisationnel avant que le modèle ne puisse commencer à raisonner, répétant le même processus coûteux avec chaque nouvelle question.

L’accès n’est pas la même chose que la connaissance

Une question courante est de savoir si des fenêtres de contexte plus grandes, une meilleure recherche ou une récupération améliorée résoudront ce problème.

Les protocoles de contexte de modèle traitent un véritable problème d’intégration en fournissant aux agents un moyen standardisé d’accéder aux systèmes où vit l’information d’entreprise. Mais l’accès n’est pas la même chose que la compréhension. Accorder à un agent l’accès à une douzaine de systèmes n’explique pas laquelle des décisions a supplanté une autre, pourquoi une exigence a changé, si un document est toujours autoritaire ou comment une conversation client a finalement influencé ce qui a été expédié. Sans une couche logique structurée et vérifiée, cela ne fournit que davantage d’occasions de rencontrer des détails contradictoires.

La plupart des systèmes d’IA d’entreprise supposent toujours que le contexte doit être assemblé à partir de zéro chaque fois que quelqu’un pose une question. Cette approche peut répondre à des questions isolées, mais elle peine à soutenir le raisonnement continu nécessaire pour faire fonctionner une entreprise. Les dirigeants passent encore des heures chaque semaine à reconstituer les réponses à des questions qui devraient déjà exister au sein de l’organisation :

• Qu’est-ce qui a changé ?
• Pourquoi cette priorité a-t-elle changé ?
• La feuille de route est-elle toujours précise ?
• Résolvons-nous toujours le bon problème ?

C’est là que le graphique de connaissances gagne sa place. Un graphique stocke des entités et leurs relations, fournissant une base pour préserver la mémoire organisationnelle.

Au lieu de récupérer une collection de passages qui contiennent des mots similaires, un agent peut suivre les connexions à partir d’une décision jusqu’à l’exigence qui l’a déclenchée, le ticket qui l’a mis en œuvre, la demande de tirage qui l’a modifiée et les commentaires clients qui l’ont plus tard remis en question.

Les graphiques de connaissances vont au-delà d’être simplement une autre façon d’organiser les données. Au lieu de reconstruire à nouveau le contexte à partir de systèmes déconnectés, l’IA peut raisonner à partir d’une compréhension continue de la façon dont l’organisation fonctionne réellement.

Le résultat est un IA qui peut raisonner à partir des décisions, des conversations et des preuves, plutôt que de reconstruire cette compréhension à partir de zéro avec chaque invite.

La structure seule ne suffit pas

Construire le graphique une fois est difficile, et le garder précis est encore plus difficile. Dans une organisation en mouvement rapide, les tickets changent, les plans changent, le code est expédié, les responsabilités changent et les commentaires des clients modifient les priorités. Cela signifie que la mémoire organisationnelle doit être mise à jour à mesure que la réalité change et relier chaque changement à sa source.

Alors que 82 % des développeurs rapportent que l’IA les aide à coder plus rapidement et que 71 % disent qu’elle améliore leur capacité à résoudre des problèmes complexes, cette vitesse vient avec un piège : 96 % des développeurs manquent de confiance totale que le code résultant soit fonctionnellement correct.

Chaque fait qu’un agent vous donne devrait remonter à sa source : le commit, le ticket, le fil. Si un système d’IA dit à un dirigeant qu’une version est sur la bonne voie mais ne peut pas montrer les signaux derrière cette conclusion, un dirigeant expérimenté devrait hésiter à agir.

J’ai vu des équipes abandonner des outils qui produisaient des réponses raisonnables parce que les utilisateurs ne pouvaient pas vérifier comment ces réponses avaient été atteintes. J’ai également vu des équipes continuer à utiliser des systèmes moins sophistiqués parce que ces systèmes montraient leur travail. Un résumé confiant sans reçus n’est qu’un moyen plus rapide d’être faux, et une fois qu’un outil brûle un dirigeant avec une réponse non sourcée, la confiance ne revient pas. Connecter chaque affirmation à sa source transforme “faites-moi confiance” en “voici pourquoi”.

La précision compte pour la même raison. Lorsqu’un système suit en continu la relation entre le plan et le réel, l’écart entre ce qu’une équipe a décidé et ce qui a réellement été expédié devient un dérive visible plutôt que d’être silencieusement absorbé dans une réponse confiante mais obsolète. Ce n’est pas une préoccupation marginale. Thoughtworks a signalé le dérive de code comme un danger spécifique pour les agents d’IA. Cela souligne la nécessité de boucles de vérification et de mécanismes de rétroaction qui aident les systèmes à détecter et à corriger les déviations à mesure que le travail évolue. Le dérive qu’une organisation peut voir est une information utile. Le dérive qui reste caché est comment un système d’IA commence à tromper les personnes qui lui ont fait confiance.

Que demander avant votre prochain projet d’agent

Lors de l’évaluation d’une initiative d’agent d’entreprise, je commencerais par quatre questions :

• Le système conserve-t-il sa propre représentation optimisée du contexte au fil du temps, ou fournit-il simplement à l’IA l’accès aux sources de données existantes ?
• Chaque réponse est-elle retracée jusqu’à une source spécifique, telle qu’un ticket ou un document ?
• Le système met-il à jour automatiquement à mesure que les informations de l’organisation changent ?
• L’agent comprend-il les relations entre les points de données plutôt que d’avoir simplement accès à eux ?

Les modèles de base continueront de s’améliorer. Les capacités de raisonnement deviendront plus fortes, les fenêtres de contexte grandiront et ces avancées seront de plus en plus disponibles à tous. Ce qui ne sera pas banalisé, c’est la compréhension organisationnelle.

Plus de la moitié des PDG rapportent voir peu ou pas de bénéfices en termes de revenus ou de coûts provenant de l’IA au cours de la dernière année. Je parierais que la plupart manquent de la couche de contexte qui permet à ces modèles de raisonner sur ce que l’organisation sait déjà.

Alors que le logiciel devient dramatiquement plus facile à créer, la compréhension devient la ressource rare. Ceux qui créent la plus grande valeur à partir de l’IA sont meilleurs pour préserver, se connecter et apprendre en continu de la connaissance organisationnelle. C’est la différence entre l’IA qui devine et l’IA qui sait.