.jpg)
Tout le monde parle soudainement des graphes de contexte, à la suite de l’article de Jaya Gupta et Ashu Garg sur la prochaine opportunité de mille milliards de dollars de l’IA. Chez Glean, nous sommes enthousiastes — parce que ça a enfin un nom. Des graphes de contexte qui comprennent non seulement vos données, mais aussi la façon dont votre entreprise fonctionne réellement.
Nous sommes à un stade où presque tout, dans l’entreprise, a été numérisé : les décisions et les données structurées sont consignées dans des systèmes d’enregistrement, tandis que le travail au quotidien se déroule dans des outils de communication, des systèmes de gestion de projet, des dépôts de code, et bien plus encore.
Les graphes de contexte éclairent la manière dont le travail s’effectue réellement dans l’entreprise, et rendent l’automatisation possible. Avec l’essor des agents et leur capacité à raisonner et à agir, une avancée majeure se profile pour l’automatisation, mais uniquement si ce raisonnement s’ancre 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 recherche performante est la base du contexte. Cela signifie comprendre le contenu : indexer les données non structurées pour que les employés puissent effectuer des recherches dans toute leur entreprise et trouver rapidement les informations les plus récentes et les plus pertinentes — comme la dernière documentation 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 travaux plus complexes, nous avons appris que cette base doit s’élargir. Comprendre les seules données d’entreprise ne suffit pas les systèmes doivent aussi disposer d’une connaissance des relations. La manière dont le travail s’effectue dans une entreprise repose fondamentalement sur 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 workflow ont cherché à automatiser les processus les mieux compris dans les organisations, mais la majeure partie du travail est distribuée — réalisée par des individus et de petites équipes, avec des processus documentés uniquement comme une « connaissance implicite ». Comment intégrer cette majorité de travail dans le champ de l’automatisation et permettre aux agents d’apprendre et d’automatiser ce travail ? C’est là que les graphes de contexte entrent en jeu.
Les graphes de contexte consistent vraiment à capturer la réalité des processus pour automatiser le travail
L’affinement de Glean sur les graphes de contexte : « On ne peut pas capturer de manière fiable le pourquoi on peut 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, il est suggéré dans une transcription de 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 : étapes récurrentes, mises à jour de données, validations, schémas de collaboration, champs qui évoluent, et comportements inter-systèmes au fil du temps. Sur de nombreux cycles, ces traces de processus se rapprochent du pourquoi : on peut déduire des rationalités à partir des schémas de la manière dont le travail est effectué à répétition — et non en essayant de stocker littéralement chaque pensée humaine.
Dans cette optique, l’objectif des graphes de contexte 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 les conditions dans lesquelles le travail se poursuit, s’interrompt ou s’escalade, de sorte que la prochaine fois qu’une situation se présente, l’agent puisse déterminer les actions appropriées à entreprendre.
Les graphes de contexte sont un investissement technique
Créer ce niveau de connaissance et de compréhension n’est pas simple. Construire des graphes de contexte est difficile :
- Observabilité (via des connecteurs et des applications) : Obtenir une compréhension complète de ce qui se passe dans une entreprise exige plus que des données de décision propres et structurées issues des systèmes d’enregistrement. Cela nécessite de l’observabilité à travers les connecteurs et les applications où le travail se fait 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 significatifs de chaque connecteur. Par exemple, un connecteur vers Salesforce peut exposer un changement d’étape d’un deal, mais la véritable observabilité vient aussi du fait de voir l’activité à travers des applications 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 — chacun capturé directement depuis le système sous-jacent via son connecteur.
- Compréhension des 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, réalisées dans les outils. Il s’agit notamment 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 la manière dont l’état change entre elles — fournit les données brutes d’activité.
- 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 à inférer des constructions de plus haut niveau. Les schémas, combiné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.
Distinguer les signaux du bruit est difficile, surtout en entreprise. Chez Glean, par exemple, notre compréhension des tâches atteint environ 80 % de précision — un indicateur de la solidité que doit avoir toute la technologie en amont pour rendre cela viable. C’est d’autant plus impressionnant que, dans le contexte de l’entreprise, les graphes de contexte 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 exige que les graphes soient inférés de manière algorithmique.
Les graphes de contexte font partie de la suite de technologies fondamentales qui formeront la prochaine plateforme de données
Alors que les graphes de contexte attirent le plus l’attention en ce moment, chez Glean nous savons que résoudre le contexte ne peut pas reposer sur une seule technologie. Parvenir à une véritable compréhension des processus nécessite une pile de technologies qui fonctionne de concert : 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 les agents exécutent réellement du travail. Cette pile permet aux systèmes de passer des données brutes d’entreprise à des agents capables d’agir.
À mesure que les agents commencent à opérer dans 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 en conditions réelles. Ces traces constituent la mémoire de l’entreprise, en capturant ce qui fonctionne réellement pour les agents au fil du temps. La compréhension des processus ne vient pas uniquement du graphe de contexte elle émerge de la combinaison entre compréhension structurelle et comportements appris.
Quand vous prenez du recul et regardez toutes ces couches ensemble — connecteurs, index, graphes, et mémoire personnelle et d’entreprise — vous vous rendez compte 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 pratique, et permet aux agents de faire avancer le travail de manière fiable à l’échelle de 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 véritable question derrière 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 vont prendre en charge davantage de travail, cette opportunité repose sur une base de contexte, qui comprend les données de votre entreprise, vos relations et vos processus.
