.webp)
Tout le monde parle soudainement des context graphs, suite à l’article de Jaya Gupta et Ashu Garg sur la prochaine opportunité à mille milliards de dollars de l’IA. Chez Glean, nous sommes enthousiastes — parce que, enfin, cela a un nom. Des context graphs qui comprennent non seulement vos données, mais aussi la façon dont votre entreprise fonctionne réellement.
Nous en sommes à un stade où presque tout, dans l’entreprise, a été numérisé : les décisions et les données structurées sont enregistrées dans des systèmes de référence, tandis que le travail au quotidien se déroule à travers des outils de communication, des systèmes de gestion de projet, des dépôts de code, et bien plus encore.
Les context graphs éclairent la manière dont le travail se fait réellement dans l’entreprise, rendant l’automatisation possible. Avec l’essor des agents et leur capacité à raisonner et à agir, une avancée majeure s’annonce pour l’automatisation — mais seulement si ce raisonnement est ancré dans le bon contexte d’entreprise.
Le contexte doit évoluer à mesure que l’IA progresse
Glean a été fondée avec la conviction qu’une excellente recherche est la base du contexte. Cela signifie comprendre le contenu : indexer les données non structurées afin que les employés puissent effectuer des recherches à l’échelle de leur entreprise et trouver rapidement les informations les plus récentes et les plus pertinentes — comme le dernier document de conception, une mise à jour de politique, ou une note client — nécessaires pour répondre à une question ou débloquer une tâche.
Mais à mesure que l’IA a commencé à prendre en charge des tâches plus complexes, nous avons appris que cette base doit s’élargir. Il ne suffit pas de comprendre les seules données de l’entreprise les systèmes ont aussi besoin de connaissances relationnelles. La façon dont le travail s’effectue dans une entreprise est fondamentalement guidée par les relations — savoir qui est responsable d’un compte, qui approuve un contrat, quel ingénieur est d’astreinte, ou quelles équipes collaborent lorsqu’un incident s’aggrave.
Les outils de RPA et de workflows ont cherché à automatiser les processus les mieux compris des organisations, mais la majorité du travail est distribuée - réalisée par des individus et de petites équipes, avec des processus documentés uniquement sous forme de « connaissance tribale ». Comment intégrer cette majorité du travail dans le champ de l’automatisation, et permettre aux Agents d’apprendre et d’automatiser ce travail ? C’est là que les context graphs entrent en jeu.
Les context graphs visent surtout à capturer la réalité des processus pour automatiser le travail
L’affinement de Glean concernant les context graphs : « Vous ne pouvez pas capturer de manière fiable le pourquoi vous pouvez capturer le comment. »
Le pourquoi est souvent une étape de réflexion qui se trouve généralement dans la tête de quelqu’un - on ne peut pas vraiment le modéliser. Parfois, on en retrouve des indices dans la transcription d’une réunion ou un fil Slack, mais une grande partie n’est jamais consignée de manière claire ou durable.
Le comment, en revanche, laisse une riche trace numérique : des étapes récurrentes, des mises à jour de données, des validations, des schémas de collaboration, des champs qui changent, et des comportements inter-systèmes au fil du temps. Sur de nombreux cycles, ces traces de processus se rapprochent du pourquoi : vous pouvez déduire des justifications à partir de schémas observés dans la manière dont le travail est réalisé de façon répétée — plutôt que d’essayer de stocker littéralement chaque pensée humaine.
Dans cette optique, l’objectif des context graphs devient de capturer le « comment » (le processus) dès maintenant, et d’apprendre le « pourquoi » (l’intention) au fil du temps. Si les agents sont censés automatiser le travail réel dans l’entreprise, la voie consiste à modéliser les processus en profondeur afin de comprendre à la fois les conditions dans lesquelles le travail progresse, se met en pause ou s’intensifie, pour que, la prochaine fois qu’une situation se présente, l’agent puisse déterminer les bonnes actions à entreprendre.
Les context graphs sont un investissement technique
Créer ce niveau de connaissance et de compréhension n’est pas simple. Construire des context graphs est difficile :
- Observabilité (via des connecteurs et des apps) : Obtenir une compréhension complète de ce qui se passe dans une entreprise nécessite plus que des données de décision propres et structurées provenant des systèmes de référence. Cela requiert de l’observabilité à travers les connecteurs et les applications où le travail se déroule réellement — à la fois l’étendue pour capturer l’activité dans les nombreux outils utilisés par les employés, et la profondeur pour extraire des signaux pertinents de chaque connecteur. Par exemple, un connecteur vers Salesforce peut exposer un changement d’étape d’une opportunité, mais la véritable observabilité vient aussi du fait de voir l’activité à travers les apps connectées : un document modifié dans Google Docs, un message envoyé dans Slack, une réunion créée dans Calendar, ou un enregistrement mis à jour dans Salesforce — chaque élément étant capturé directement depuis le système sous-jacent via son connecteur.
- Comprendre les données d’activité : Au-delà de l’indexation du contenu, les systèmes doivent capturer des signaux d’activité de bas niveau : des actions discrètes horodatées effectuées dans les outils. Il s’agit d’événements comme la modification d’un document, la mise à jour d’un champ, l’ajout d’un commentaire, l’envoi d’un message Slack, ou le téléversement d’un fichier. Capturer ces actions dans l’ordre chronologique — et suivre l’évolution de l’état entre elles — fournit les données d’activité brutes.
- Dériver une compréhension de plus haut niveau des tâches, projets et initiatives : Ce n’est qu’après avoir collecté ces données d’activité atomiques que les systèmes peuvent commencer à déduire des constructions de plus haut niveau. Des schémas, associés à une compréhension sémantique à travers de nombreuses actions de bas niveau — modifications répétées de documents, messages Slack coordonnés, et mises à jour fréquentes des mêmes enregistrements — peuvent être agrégés pour indiquer une tâche, un projet, ou une initiative plus large. Par exemple, une séquence de création de document, de modifications, de messages Slack et de mises à jour d’enregistrements sur plusieurs jours peut représenter collectivement un effort d’onboarding client ou un lancement de produit, même si ce travail n’a jamais été explicitement étiqueté comme tel dans un système unique.
Séparer les signaux du bruit est difficile, surtout dans une entreprise. Chez Glean, par exemple, notre compréhension des tâches atteint ~80% de précision — un indicateur de la robustesse nécessaire de toute la technologie en amont pour rendre cela viable. Cela est d’autant plus impressionnant que, dans le contexte de l’entreprise, les context graphs ne sont pas construits à l’échelle d’internet. Les données ne peuvent pas être agrégées entre clients, et les jeux de données qui en résultent sont à la fois plus petits et inaccessibles aux humains en raison des contraintes de confidentialité — ce qui impose d’inférer les graphes de manière algorithmique.
Les context graphs font partie de la suite de technologies fondamentales qui forment la prochaine plateforme de données
Alors que les context graphs concentrent le plus l’attention en ce moment, chez Glean nous savons que résoudre la question du contexte ne peut pas reposer sur une seule technologie. Parvenir à une véritable compréhension des processus exige une pile de technologies qui fonctionnent ensemble : des connecteurs pour observer l’activité à travers les outils, des index pour permettre une récupération rapide, des graphes pour modéliser la structure et les relations de l’entreprise, et de la mémoire pour capturer ce qui se passe lorsque des agents exécutent réellement du travail. Cette pile permet aux systèmes de passer des données brutes de l’entreprise à des agents capables d’agir.
À mesure que les agents commencent à opérer au sein de l’entreprise, l’apprentissage devient essentiel. Ce qui fonctionne pour les humains ne se transpose pas toujours directement aux agents. En capturant des traces d’exécution — comment les agents utilisent les outils, dans quels enchaînements et avec quels résultats — les systèmes peuvent apprendre du travail agentique tel qu’il se déroule en pratique. Ces traces constituent la mémoire d’entreprise, en capturant ce qui fonctionne réellement pour les agents au fil du temps. La compréhension des processus ne provient pas uniquement du graphe de contexte elle émerge de la combinaison entre une compréhension structurelle et des comportements appris.
Quand vous prenez du recul et regardez l’ensemble de ces couches — connecteurs, index, graphes, et mémoire personnelle et d’entreprise — vous réalisez que vous avez, de fait, construit une toute nouvelle plateforme de données. Une plateforme conçue non pas pour le reporting ou l’analytique, mais comme l’épine dorsale de l’automatisation agentique : un système qui observe comment le travail se déroule, apprend de l’exécution en conditions réelles et permet aux agents de faire avancer le travail de manière fiable dans toute l’entreprise. Chez Glean, nous disposons désormais de cette plateforme de contexte — y compris le graphe — après six ans d’investissement technique.
Le contexte est fondamental pour le travail agentique
La vraie question qui sous-tend le post de Jaya et Ashu est la suivante : comment permettre aux agents de mener à bien le travail dans l’entreprise ? Comment peuvent-ils apprendre, comprendre et opérer comme votre entreprise ? Si les agents doivent prendre en charge davantage de travail, cette opportunité repose sur une fondation de contexte, capable de comprendre vos données d’entreprise, vos relations et vos processus.
