La semaine dernière, j'ai écrit sur ma réaction au post viral de Jaya Gupta sur les graphes de contexte [1]. L'idée d'un « système d'enregistrement pour les décisions » a profondément résonné, encadrant l'évolution de l'infrastructure agentique des outils aux compétences à la mémoire. Mais depuis, la conversation a explosé, et il est devenu clair que le terme « graphe de contexte » lui-même est un peu un test de Rorschach. Chacun y voit quelque chose de différent.
\n\nAnimesh Koratana, fondateur de PlayerZero, a écrit une série de posts de suivi qui percent le bruit et vont au cœur de ce qu'est réellement un graphe de contexte, et pourquoi il est si structurellement difficile à construire [2] [3]. Ses idées sont essentielles pour quiconque est sérieux au sujet de la construction d'IA agentique dans l'entreprise. Il ne s'agit pas « d'ajouter de la mémoire à votre agent » ou de brancher une base de données graphe. Il s'agit de repenser nos hypothèses sur les données, le temps et la nature des connaissances organisationnelles.
\n\nL'idée la plus puissante de Koratana est ce qu'il appelle le problème des deux horloges. Nous avons construit une infrastructure de mille milliards de dollars pour l'horloge d'état : ce qui est vrai maintenant. Votre CRM stocke la valeur finale de l'affaire. Votre système de tickets stocke « résolu ». Votre base de code stocke l'état actuel.
\n\nMais nous n'avons presque aucune infrastructure pour l'horloge d'événements : ce qui s'est passé, dans quel ordre, et avec quel raisonnement. Le git blame montre qui a changé le timeout de 5s à 30s, mais le pourquoi a disparu. Le CRM dit « perdu », mais il ne dit pas que vous étiez le deuxième choix et que le gagnant avait une fonctionnalité que vous livrez le trimestre prochain. Comme le dit Koratana :
\n\n\n\n\n« Nous avons construit une infrastructure de mille milliards de dollars pour ce qui est vrai maintenant. Presque rien pour pourquoi c'est devenu vrai. »
\n
C'est le cœur du problème. Nous demandons aux agents d'exercer un jugement sans accès au précédent. Nous formons des avocats sur des verdicts sans jurisprudence. Le graphe de contexte est l'infrastructure pour l'horloge d'événements. C'est la jurisprudence de l'entreprise.
\n\nAlors pourquoi ne pouvons-nous pas simplement construire une meilleure base de données ? Parce qu'un graphe de contexte nécessite des jointures à travers cinq systèmes de coordonnées différents qui ne partagent pas de clés :
\n\nChacun de ces systèmes a une géométrie différente. Les chronologies sont linéaires. Les événements sont séquentiels. La sémantique vit dans l'espace vectoriel. L'attribution est structurée en graphe. Les résultats sont des DAG causaux. Et les clés sont fluides. « Jaya Gupta » dans un email, « J. Gupta » dans un contrat, et « @JayaGup10 » dans Slack sont la même entité sans identifiant partagé.
\n\nLes bases de données traditionnelles sont construites pour des jointures sur des clés stables au sein d'un seul système de coordonnées. Les graphes de contexte nécessitent des jointures probabilistes à travers les cinq simultanément. Ce n'est pas un problème de base de données ; c'est un problème de représentation.
\n\nSi l'ontologie de chaque organisation est différente et en constante évolution, comment pouvons-nous espérer la modéliser ? La réponse de Koratana est que nous n'avons pas à le faire. Les agents le font pour nous.
\n\nLorsqu'un agent travaille sur un problème, sa trajectoire est une trace à travers l'espace d'état de l'organisation. C'est une carte implicite de l'ontologie, découverte par l'utilisation plutôt que spécifiée à l'avance. C'est l'idée clé de l'apprentissage de représentation de graphe (node2vec) : vous n'avez pas besoin de connaître la structure d'un graphe pour en apprendre des représentations. Vous avez juste besoin de le parcourir.
\n\nLes agents sont des marcheurs informés. Leurs trajectoires ne sont pas aléatoires ; elles sont dirigées par le problème. En accumulant suffisamment de ces trajectoires, nous pouvons apprendre des embeddings qui encodent la structure de l'organisation. Nous pouvons apprendre que deux ingénieurs qui n'interagissent jamais sont structurellement équivalents parce qu'ils jouent le même rôle dans différents sous-graphes. Nous pouvons apprendre qu'une certaine séquence d'événements est un précurseur de désabonnement, même si ces événements n'ont jamais été explicitement liés.
\n\nAlors, qu'est-ce qu'un graphe de contexte, vraiment ? Ce n'est pas une base de données graphe. Ce n'est pas un magasin vectoriel. C'est une représentation apprise du raisonnement organisationnel, dérivée des trajectoires des agents résolvant des problèmes.
\n\nCela a des implications profondes sur la façon dont nous construisons des systèmes agentiques :
\n\nConstruire un graphe de contexte ne consiste pas à acheter un nouveau logiciel. Il s'agit d'un changement fondamental dans notre façon de penser les données, le temps et la nature du travail à l'ère agentique. Il s'agit de reconnaître que l'actif le plus précieux que nous ayons n'est pas nos données, mais la sagesse accumulée des décisions que nous prenons chaque jour. Et il s'agit de construire l'infrastructure pour enfin capturer cette sagesse et la mettre au travail.
\n\nRéférences :
\n\n[1] Gupta, J. (2025, 23 décembre). AI's trillion-dollar opportunity: Context graphs. X.
\n\n[2] Koratana, A. (2026, 1er janvier). Why context graphs are rare in the wild. LinkedIn.
\n\n[3] Koratana, A. (2025, 28 décembre). How to build a context graph. LinkedIn.
", "source_hash": "sha256:c9f8cb57d671053bc8f97aa3c11eeb86305f270ab5994d742a815877626e63fb", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T02:09:50.916539+00:00" }