Transférer le travail d’ingénierie du contexte vers la plateforme d’IA

Au cours de l’année écoulée, le context engineering est devenu un élément central pour créer des agents IA performants — en façonnant la manière dont les modèles interprètent l’information et se coordonnent entre différents outils pour accomplir un travail réel. À mesure que les fenêtres de contexte s’élargissent et que les workflows agentiques gagnent en sophistication, le rôle du contexte n’a fait que croître. Bien le gérer est désormais déterminant pour savoir si les agents réussiront en entreprise.

Des frameworks comme le Model Context Protocol (MCP) ont accéléré ce changement en facilitant la connexion des outils et l’exposition de fonctionnalités. Ce faisant, ils ont également mis en lumière l’importance du contexte. L’accès seul ne garantit pas la compréhension, et sans couche unificatrice, la simple disponibilité des outils peut donner une fausse impression d’exhaustivité. En pratique, cela conduit souvent les équipes vers l’une de deux voies : orchestrer manuellement des outils MCP dans des workflows rigides et déterministes qui deviennent vite fragiles à mesure que les systèmes évoluent, ou s’appuyer sur des appels d’outils génériques qui héritent de la sémantique fragmentée et de la recherche peu efficace de chaque système. Dans les deux cas, la charge de gestion du contexte repose sur les ingénieurs, au lieu d’être résolue au niveau de la plateforme.

Notre point de vue : le contexte doit être une capacité fondamentale — unifiée, continuellement enrichie par l’apprentissage, et délivrée de façon cohérente — afin que les agents puissent fonctionner de manière fiable à grande échelle. Des agents efficaces s’appuient sur le contexte issu de systèmes conçus à cet effet comme la recherche, qui sait depuis longtemps que le contenu seul ne suffit pas. Des signaux tels que l’usage, la popularité et les liens améliorent la pertinence, tandis que des structures basées sur des graphes aident à cartographier les relations entre personnes, projets et équipes. En y superposant une mémoire d’entreprise qui apprend comment les outils et les processus s’articulent, on obtient non seulement l’accès à l’information, mais une véritable compréhension de la manière dont le travail s’accomplit.

Aujourd’hui, davantage de travail bascule vers des agents IA. Les employés demandent à l’IA de déboguer des problèmes d’ingénierie, de générer des plans de compte étayés, de se préparer à des rendez-vous clients et de piloter des initiatives complexes de bout en bout. Au cœur de tout cela : le contexte. Cette évolution — de la découverte, à la compréhension, puis à l’action — est ce qui fait du contexte l’épine dorsale de l’IA en entreprise. Dans cet article, nous passerons en revue nos choix de conception et les enseignements tirés de la création du contexte d’entreprise.

Méthodes pour comprendre le contexte d’entreprise

L’adoption croissante de MCP a aussi fait émerger certaines idées reçues sur la maturité et la fiabilité des outils. Si de nombreux outils MCP offrent une interface directe vers des API existantes — un point de départ précieux — ils manquent souvent d’une compréhension intégrée de la sémantique des données sous-jacentes ou de la manière dont ces données devraient être utilisées en pratique. Résultat : un contexte et une interprétation supplémentaires restent nécessaires, et sans couche de plateforme pour les prendre en charge, cette responsabilité peut retomber sur les ingénieurs.

Index

Pour réduire la charge cognitive, il faut construire des outils de qualité, suffisamment flexibles pour couvrir un large éventail de cas d’usage. Chez Glean, nous avons constaté que le socle de ces outils repose souvent sur des index : des index qui structurent et stockent les données de la meilleure façon possible pour répondre rapidement à une requête. Si vous voulez prendre en charge une grande diversité de cas d’usage d’IA en entreprise, il vous faudra différents types d’index pour la récupération. 

Par exemple, nous avons séparé les outils selon le job to be done : la recherche dans le calendrier indexe les événements par temps et par personnes (p. ex. after:now, before:DATE, « mon prochain rendez-vous avec John »), ce qui aide à répondre à des questions comme « quand ai-je vu Judy pour la dernière fois ? » ou « montre-moi mes rendez-vous à venir ». À l’inverse, la recherche Glean est plus adaptée pour retrouver des documents non structurés, des tickets et des e-mails, surtout quand j’ai besoin de contexte multi-applications, comme « quelles sont les dernières infos sur le projet falcon ? ». Pour les données structurées, si un utilisateur demande « Quel est notre ARR total ? », nous interrogeons un index des données de tableaux de bord Salesforce et utilisons des signaux tels que le créateur du tableau de bord et sa popularité pour identifier la métrique canonique de l’organisation. 

Connecteurs et modélisation des données

Construire des index centralisés était relativement simple pour des données internet homogènes par nature — on ne peut pas en dire autant des données d’entreprise, qui sont hétérogènes. Chaque application a sa propre structure et sa propre sémantique, et nécessite des modèles de données capables de capturer cette diversité tout en normalisant afin de renvoyer des résultats pertinents entre sources. Par exemple, dans Jira, un ticket représente un problème spécifique, mais ce problème se rattache à une epic plus large — et les documents liés dans la description ont tendance à être plus fiables et pérennes que ceux dans les commentaires. Lorsqu’on prend du recul et qu’on conçoit pour exploiter la richesse et la compréhension des données d’entreprise, les connecteurs et la modélisation des données comptent énormément. C’est souvent le début du chemin vers le contexte, mais son importance est souvent sous-estimée avec l’essor de MCP.

Des questions se posent sur la valeur d’outils de récupération comme la recherche d’entreprise face à une récupération basée sur MCP. Chez Glean, nous considérons MCP comme complémentaire : nous le combinons à notre système d’indexation via des connecteurs hybrides afin d’obtenir à la fois une fraîcheur en temps réel et une compréhension unifiée de l’entreprise. Comme toute source de données, les outils MCP bénéficient toujours de la modélisation des données, de l’extraction de signaux et de l’indexation pour créer de la valeur. C’est un travail de context engineering que la plateforme doit prendre en charge, et ce n’est pas une initiative ponctuelle — elle doit suivre le rythme des évolutions des applications d’entreprise (c.-à-d. nouveaux types de données, nouvelles fonctionnalités, etc.).

Graphes de connaissances

Les connecteurs et les outils aident à faire émerger le contenu, mais ils ne résolvent pas les relations et les correspondances canoniques entre différentes applications. C’est là qu’interviennent les graphes de connaissances. Même si le raisonnement des modèles progresse, les structures basées sur des graphes restent le substrat central du contexte en entreprise. En encodant des entités — personnes, projets et processus — et leurs relations, les graphes ancrent les agents, permettant un raisonnement en plusieurs sauts, la désambiguïsation du langage spécifique à l’entreprise et une compréhension de la manière dont le travail se déroule.

À la base, un graphe de connaissances représente l’information sous forme de relations liées, plutôt que comme des points de données isolés. Chaque relation relie une entité à une autre via une relation définie — par exemple, un ingénieur affecté à un ticket Jira ou un document lié à un projet. Ces relations forment collectivement un graphe d’entités connectées qui peut être parcouru pour répondre à des questions complexes, révéler des connexions cachées et produire des insights qui ne sont pas explicitement stockés dans une source unique.

Les modèles gèrent la simple restitution de faits lorsque les réponses sont explicites ou proches du contenu source, mais ils peinent face à des inférences complexes en plusieurs sauts, en particulier sur de grandes fenêtres de contexte (« Affiche tous les codebases des projets pilotés par X qui ont été livrés au T1 2025 »). De plus en plus, les agents en entreprise relèvent de cette deuxième catégorie — nécessitant un raisonnement en plusieurs étapes à travers des entités. C’est pourquoi les graphes sont essentiels : ils donnent aux agents accès à des insights complexes pour traiter avec précision des questions d’entreprise nuancées.

Utiliser le contexte pour passer à l’action

Nous voyons les modèles faire progresser leurs capacités de raisonnement, comprendre quand planifier de manière itérative et comment utiliser des outils, ce qui permet à l’IA de prendre en charge davantage de travail. Ce n’est pas parce qu’ils savent appeler des outils qu’ils savent en faire un usage scalable en entreprise. C’est un autre espace, récemment élargi, qui nécessite des optimisations et une mémoire d’entreprise.

Recherche d’outils

Lorsqu’il s’agit de passer à l’échelle avec des centaines d’outils en entreprise, la découverte d’outils et la désambiguïsation deviennent critiques. C’est là encore un problème de recherche — créer un index d’outils permettant de trouver le bon outil, ou la bonne combinaison, pour le travail à accomplir. Glean apprend quels outils fonctionnent le mieux pour votre entreprise en observant comment vos agents les plus performants accomplissent leur travail. Au fil du temps, il associe les workflows courants aux bons outils et utilise des signaux comme la popularité et la source de données pour sélectionner le meilleur outil suivant — afin que les agents agissent plus vite sans surcharger la fenêtre de contexte d’informations inutiles pouvant entraîner des hallucinations.

Optimisations des outils

Comme beaucoup d’autres, nous avons constaté qu’avec des agents IA, minimiser les prompts système, donner aux agents un menu clair d’outils priorisés et permettre une exploration précoce conduit à des résultats de meilleure qualité. Nous nous sommes également concentrés sur la conception d’outils faciles à chaîner et évitant la désambiguïsation — en exposant des opérateurs, en rationalisant les entrées et sorties, et en rendant les noms et descriptions explicites. Les noms et descriptions des outils évoluent au fil du temps, de sorte qu’à mesure que les outils sont évalués et que de nouveaux sont ajoutés, ils continuent de fonctionner de manière optimale. Nous avons également observé que les agents utilisent efficacement les opérateurs, en les traitant comme des filtres qui indiquent quoi rechercher ensuite, quel chemin emprunter et où approfondir. Associés à de puissants outils de retrieval, les opérateurs permettent une extraction et une compréhension plus riches du contexte d’entreprise.

Mémoire

Si nous avons obtenu des gains incrémentaux grâce à une meilleure conception des outils et des gains plus importants grâce à la recherche d’outils, ces approches ne nous ont toujours pas permis d’optimiser la façon dont les actions fonctionnent ensemble. C’est en réalité une situation courante, en particulier pour les outils conçus pour des actions atomiques (des actions qui peuvent faire une seule chose, mais qui ne permettent pas réellement d’accomplir une tâche de bout en bout), qui sont populaires avec MCP.

Prenons la planification d’une réunion. D’abord, vous avez besoin de connaissances d’entreprise : qui fait partie de l’équipe, quels sont les points prioritaires de l’ordre du jour, quelle devrait être la durée de la réunion — comprendre comment les réunions sont organisées dans une entreprise. Ce sont des tâches de retrieval qui s’appuient sur des outils de recherche. Ensuite, il faut réellement planifier la réunion — ajouter des adresses e-mail, un lien de réunion, une salle et un horaire à une invitation. La planification n’est pas une action unique ce sont des données et des actions qui travaillent ensemble de manière coordonnée.

Pour atteindre l’objectif de façon fiable — planifier une réunion — l’agent doit apprendre quels outils utiliser et comment les paramétrer, en itérant souvent sur plusieurs tentatives avant de trouver le bon chemin. Mais quand une session se termine, ces enseignements durement acquis — chemins couronnés de succès, tentatives infructueuses, schémas de paramétrage d’outils — sont perdus au lieu d’être réutilisés de manière systématique. Chez Glean, dans une version antérieure de notre moteur agentique, nous utilisions la « recherche de workflows » pour faire remonter des agents passés similaires, mais cela ne mettait pas à jour la politique de l’agent pour choisir ou paramétrer des outils — c’était trop grossier. Nous l’avons remplacée par quelque chose de plus efficace : la mémoire d’entreprise.

Avec la mémoire d’entreprise dans Glean, nous stockons les traces des exécutions d’agents, y compris les outils utilisés, les paramètres transmis, les séquences tentées et les résultats. Hors ligne, et pour chaque entreprise, nous exécutons ensuite des permutations avec différents choix d’outils et d’arguments. Nous évaluons les résultats selon la justesse, l’exhaustivité et l’efficacité, puis réinjectons les apprentissages dans le système en langage naturel — le langage des LLMs. Ces apprentissages fournissent des indications sur les outils à utiliser et pourquoi, sur la manière de structurer les entrées d’outils et sur la façon d’enchaîner les actions. L’accent est entièrement mis sur les heuristiques d’utilisation des outils — et non sur les données d’entreprise elles-mêmes, afin de protéger la sécurité des données.

Lorsqu’une nouvelle tâche agentique similaire démarre, l’agent reçoit un indice ciblé issu de cette mémoire — ce qui l’aide à choisir de meilleures actions dès le départ. Au fil du temps, ces apprentissages, stockés au niveau de chaque entreprise, évoluent pour devenir la connaissance des processus agentiques de votre organisation. Le système se renforce de lui-même : à mesure que davantage de tâches sont réalisées, l’agent devient de plus en plus compétent, jusqu’à atteindre des performances de niveau expert. 

La planification d’une réunion n’est qu’un exemple nous avons également constaté chez Glean que la mémoire contribue aux cas d’usage suivants :

• Rédaction de notes de version : chez Glean, les notes de version sont réparties sur plusieurs champs Jira et se résument généralement à quelques phrases. La mémoire a appris à commencer par le ticket Jira et ses liens — docs de conception, docs d’exigences produit, docs de bêta — car c’est généralement là que se trouvent les détails faisant autorité, et elle utilise les bons outils de récupération pour rassembler ce contexte. 
• Indicateurs d’entreprise : elle peut aussi apprendre à trouver des indicateurs d’entreprise — comme une tendance de chiffre d’affaires — qui sont propres à chaque activité. Avec la mémoire d’entreprise, Glean apprend quel indicateur du data warehouse correspond à l’ARR, au lieu d’essayer de reconstruire le calcul depuis zéro.
• Recherche sur les comptes : ou bien, prenez des tâches de recherche ouvertes. Pour la recherche sur les comptes, elle détermine le format de référence du rapport final, ce qui aide à mettre en place des motions commerciales répétables et scalables. Ensuite, elle mène la recherche, collecte des informations et vérifie les faits au fil de l’eau en s’appuyant sur la mémoire des endroits où votre entreprise conserve ses données les plus fiables.

Sécuriser le contexte dans l’entreprise

Lorsque vous centralisez le contexte d’entreprise, la sécurité doit être intégrée dès la conception. On pense souvent à tort que l’accès fédéré est intrinsèquement plus sûr que l’indexation parce que les données ne sont pas copiées ailleurs. En pratique, la sécurité provient de plusieurs couches de protection, et non d’un choix de conception unique : gestion des autorisations, application du moindre privilège, détection des données sensibles et supervision continue. Fédération vs. indexation est un choix d’architecture la posture de risque réelle est définie par qui peut voir quoi, quand et pourquoi.

Une couche de contexte robuste s’appuie sur plusieurs contrôles de sécurité complémentaires qui se renforcent mutuellement. Cela implique généralement de s’exécuter dans le propre cloud du client, d’appliquer les autorisations à chaque requête, de cadrer ou d’exclure les sources sensibles lors de l’indexation, de respecter les labels de sensibilité existants et de détecter automatiquement les contenus trop largement partagés ou à haut risque. Chaque récupération et chaque action doivent respecter les ACL des systèmes sources et les politiques de l’entreprise.

À mesure que vous ajoutez des graphes et de la mémoire, vous introduisez aussi des données dérivées, qui exigent la même rigueur. Si l’accès à un document source est retiré, les entités, relations et signaux inférés à partir de celui-ci doivent également être supprimés ou invalidés. La même règle s’applique aux structures basées sur des graphes : les utilisateurs ne devraient pas voir des vues dérivées s’ils n’ont pas accès aux données sous-jacentes, avec une sémantique de droit à l’oubli intégrée.

Chez Glean, nous avons conçu la mémoire d’entreprise pour être sûre by design — limitée à chaque tenant, jamais partagée entre clients, et centrée sur l’apprentissage de la façon dont le travail est réalisé (utilisation des outils, séquences, schémas), plutôt que sur le stockage de contenus sensibles. Au final, l’architecture qui crée le contexte est ce qui permet à l’IA de bien fonctionner — mais c’est le modèle de sécurité autour d’elle qui protège ce contexte partout où il est utilisé.

Le contexte est aussi intelligent

Il n’existe pas de solution miracle unique pour l’ingénierie du contexte. Elle nécessite plusieurs technologies qui fonctionnent ensemble — intelligemment — pour organiser l’information et les outils afin que les agents puissent mener à bien du travail réel de manière fiable. Les connecteurs sont intelligents sur ce qu’il faut ingérer, comment interpréter les signaux et quand réexplorer les données à mesure qu’elles évoluent. La recherche applique de l’intelligence dans la façon dont elle classe les résultats, en s’appuyant sur la pertinence pour faire remonter la bonne information au bon moment. Les graphes infèrent des relations, en cartographiant de façon algorithmique les connexions entre personnes, projets, documents et systèmes. Et la mémoire apprend au fil du temps, en reconnaissant des schémas dans la manière dont le travail est effectué, quels outils sont utilisés ensemble et quelles actions conduisent à des résultats concluants. Ensemble, ces couches transforment les données brutes en un contexte vivant que les agents peuvent comprendre, raisonner et sur lequel ils peuvent agir.

Lorsque nous avons construit Glean au début, des entreprises venaient nous voir pour trouver des informations comme « Trouvez notre politique de réseaux sociaux », qui pouvait se trouver dans n’importe laquelle des centaines d’applications du site. Aujourd’hui, nous voyons des entreprises nous demander non seulement de trouver la politique, mais aussi de « rédiger une politique de réseaux sociaux pour notre entreprise qui soit conforme aux normes du secteur, ainsi qu’un processus pour qu’elle soit approuvée par les bonnes parties prenantes internes ». C’est une tâche agentique — elle doit non seulement savoir où rechercher vos données, mais aussi comprendre les normes de l’entreprise et les outils nécessaires pour faire approuver la politique. Cela représente beaucoup plus de contexte lorsqu’il s’agit de travail agentique.

Même si nous sommes enthousiastes à propos de l’interopérabilité des agents et de MCP, qui rend les outils largement accessibles, cela ne décharge pas une équipe d’ingénierie de la nécessité d’ajuster finement le contexte. Pour réellement libérer les ingénieurs de l’ingénierie du contexte, il faut une plateforme conçue pour le contexte.

Note de disponibilité : la mémoire d’entreprise Glean et la recherche d’outils arrivent bientôt.