Cognee : une seule mémoire pour tous les agents IA de l'entreprise

Ce que valent les mémoires intégrées de ChatGPT, Claude et Copilot

Jusqu'à récemment, chacun de nos outils avait une connaissance parcellaire de nos projets. Claude Code avait ses consignes, Cursor ses règles, Codex les siennes, et aucun des trois ne savait ce que les deux autres avaient compris. Le plus visible, c'était d'une session à l'autre. Nos projets sont documentés, mais un agent ne garde rien d'une session sur l'autre. Il relisait donc à chaque ouverture la documentation, l'arborescence et les fichiers clés pour se remettre le projet en tête, et tout ce qu'il en avait tiré disparaissait avec la fenêtre. Une décision prise la veille dans un autre outil n'existait pas pour lui.

Cette relecture a un coût, et il se paie trois fois. En temps d'abord, puisque les premières minutes de chaque session servent à relire ce qu'on savait déjà. En qualité ensuite, parce que tout ce que l'agent relit occupe sa fenêtre de contexte, et qu'une fenêtre remplie de fichiers relus pour rien laisse moins de place au travail demandé. En argent enfin, parce que chaque relecture est facturée en tokens, à chaque session, sur chaque outil, et que ces tokens ne sont pas gratuits. C'est cette addition qui nous a poussés à chercher autre chose.

Cette perte de contexte ne touche pas que le développement, et chaque éditeur y répond par une mémoire intégrée à son outil, que tout utilisateur connaît. ChatGPT garde ce que vous lui dites d'une conversation à l'autre, Claude propose des projets où l'on dépose documents et consignes, Copilot lit les fichiers SharePoint et les mails auxquels l'utilisateur a accès. Pour une personne qui travaille seule avec un de ces outils, la relecture disparaît, le contexte reste d'un échange à l'autre, et c'est un vrai progrès.

Le problème, c'est que ce progrès s'arrête à la porte du compte. Dès qu'une entreprise déploie ces outils dans une équipe entière, chaque personne a sa mémoire, et ce que nous avons vécu avec nos trois outils se rejoue à l'échelle des services, où ce que le service commercial a appris à son ChatGPT n'existe ni pour le ChatGPT de la comptabilité, ni dans le Claude de l'équipe technique. On a déjà connu cette situation avec les fichiers Excel personnels, où chacun tenait sa version de la vérité dans un classeur que personne d'autre n'ouvrait.

La comparaison s'arrête là, et la différence compte davantage que l'éparpillement. Un classeur se copie sur un serveur partagé, et il reste la propriété de l'entreprise. Une mémoire de ChatGPT vit chez l'éditeur, dans un format que l'entreprise ne peut ni lire, ni exporter, ni brancher sur un autre outil. Au fil des mois, une part de ce que l'entreprise sait, ses procédures, ses décisions, ses façons de faire, se retrouve stockée dans des comptes qu'elle ne contrôle pas, et le jour où elle change d'outil, rien de tout cela ne la suit.

Rien de tout cela ne met en cause les agents eux-mêmes ; on a montré dans l'article sur eve de Vercel ce qu'ils apportent à un site e-commerce ou à un outil interne. Ce qui reste à décider, c'est où l'on range ce qu'ils savent, et à qui ça appartient. Nous avons répondu par une mémoire partagée entre les outils, possédée par l'entreprise, et gouvernée par elle. Les sections qui suivent reprennent ces trois mots dans l'ordre.

Une mémoire partagée entre tous les agents IA de l'entreprise

Partagée, d'abord. Aujourd'hui, quand on ouvre le code de notre propre site dans Claude Code et qu'on demande où sont stockés les médias, l'agent répond Vercel Blob avant toute lecture du code, précise qu'un premier cadrage prévoyait Cloudflare R2, et donne la date du changement et le fichier concerné. La même question posée depuis Cursor ou Codex donne la même réponse, parce que les trois outils interrogent le même endroit.

Cet endroit, c'est Cognee, un moteur de mémoire pour agents publié en open source sous licence Apache 2.0, que nous faisons tourner sur un serveur du studio. Les trois outils y sont branchés par un serveur MCP que nous avons adapté à notre installation, et chacun dispose des deux mêmes commandes, se souvenir et se rappeler, quelle que soit l'interface dans laquelle on travaille. La source de cette mémoire est un dossier de fichiers Markdown, dont l'historique est conservé avec Git, et qui contient les fiches de nos projets, les procédures que nous réutilisons et les leçons tirées de chaque chantier.

Rapporté aux trois coûts du début, le changement se mesure en sessions. L'agent qui ouvre un site livré il y a deux mois sait déjà quel CMS a été retenu, pourquoi l'alternative a été écartée, et quel incident a conduit à la règle qu'on applique depuis sur les uploads clients. Il ne repart pas d'une interprétation nouvelle à chaque fois. Une leçon apprise sur un site animé sert au site suivant, parce qu'elle a été écrite une fois et qu'elle se retrouve depuis n'importe quel outil. Et quand une session dans Cursor aboutit à une décision, la session suivante dans Claude Code la connaît.

Pour une entreprise, il suffit de remplacer fiches projet par comptes clients, procédures par process internes, et leçons par décisions prises en réunion. La mécanique est la même. Ce qui la rend possible, c'est la façon dont Cognee range ce qu'on lui donne, et ça mérite un détour.

Graphe de connaissances ou recherche vectorielle : ce que ça change pour un agent

Voici ce que devient une fiche de décision ordinaire quand elle entre dans Cognee :

"Le 2026-06-03, Atelier Vasseur a retenu Colissimo
 pour les envois France. Chronopost a été écarté
 parce que le volume ne justifiait pas son tarif.
 La décision est revue chaque trimestre."

                  │
                  │  découpage, extraction
                  ▼

[Atelier Vasseur] ──a retenu (2026-06-03)──▶ [Colissimo]
        │                                         │
        │                                    [envois France]
        │
        └──a écarté──▶ [Chronopost]
                           │
                           └──parce que──▶ [volume insuffisant]

[Décision transporteur] ──revue──▶ [chaque trimestre]

Le moteur découpe le document, puis un modèle en extrait les entités, une entreprise, un transporteur, une date, et les relations entre elles. Chaque relation devient un lien, et l'ensemble forme un graphe de connaissances. Quand un agent demande ensuite « quel transporteur pour la France, et pourquoi », il suit les liens, d'Atelier Vasseur à Colissimo, puis à la raison, à l'alternative écartée et à la date de révision. Une autre question, « qu'est-ce qui est revu chaque trimestre », part d'un autre nœud et arrive à la même décision.

La plupart des outils qui donnent des documents à un LLM ne font pas ça. Ils fonctionnent par recherche vectorielle. Chaque passage est transformé en une série de nombres qui représente son sens, et l'agent reçoit les passages dont le sens est le plus proche de sa question. Pour retrouver un paragraphe qui parle du même sujet, c'est efficace. Pour répondre à « pourquoi a-t-on choisi ce fournisseur », ça l'est moins, parce que la réponse est souvent répartie entre trois documents et que la ressemblance avec la question ne suffit pas à les relier.

C'est cette différence qui rend une mémoire partageable entre plusieurs outils. Un agent de code, un assistant de support et un agent qui prépare une réunion ne posent pas les mêmes questions, et un graphe leur répond à partir des mêmes faits. Cognee conserve d'ailleurs la recherche vectorielle à côté du graphe, avec une base relationnelle, et combine les trois selon la question. Nous l'avons retenu pour cette combinaison, pour sa licence, et parce qu'il s'installe sur un serveur ordinaire. Il a aussi ses limites à ce jour, puisque l'ingestion d'un document prend plusieurs minutes et qu'un document modifié doit être retiré puis renvoyé, ce qui demande un peu d'outillage. La dernière de ces raisons est celle qui comptait le plus, parce qu'elle commande le deuxième mot de notre réponse. Une mémoire ne peut être possédée que si elle tourne chez celui qui la remplit.

La connaissance de l'entreprise reste sa propriété

Possédée, ensuite, et ça commence par un dossier de quarante-deux fichiers Markdown sur GitHub, qui contient toute notre mémoire. On peut les ouvrir avec n'importe quel éditeur de texte, les lire sans aucun outil, les copier sur une clé. Le graphe décrit plus haut n'est pas la source, il en est une projection, et si le serveur disparaît, on le reconstruit à partir des fichiers en une heure. Si l'on change de moteur de mémoire dans deux ans, les fichiers restent et se rebranchent sur le suivant. Aucun abonnement ne conditionne l'accès de l'entreprise à ce qu'elle sait, et aucun prestataire non plus, Nualt compris.

C'est le point qui nous paraît le plus important, au-delà de la technique. La connaissance d'une entreprise, ses procédures, ses décisions et leurs raisons, l'historique de ses clients, est une part de sa valeur. Quand cette connaissance se déverse dans les mémoires d'outils tiers, elle devient une fonctionnalité de quelqu'un d'autre. Quand elle vit dans des fichiers que l'entreprise possède, sur une infrastructure qu'elle contrôle, elle reste un actif qu'elle peut lire, transmettre, auditer et faire évoluer sans demander la permission à personne.

Garder la connaissance dans des fichiers demande en contrepartie de les écrire en sachant comment un graphe les lit, et trois règles suffisent pour l'essentiel. On donne à chaque chose un seul nom et on s'y tient, parce qu'un projet qui s'appelle « Atelier Vasseur » dans un fichier et « le client Vasseur » dans un autre devient deux nœuds. Chaque section d'un fichier se suffit à elle-même et nomme son sujet dès la première phrase, parce que le découpage peut tomber n'importe où. Et les relations s'écrivent en phrases courtes, sujet, verbe, complément, parce que c'est cette phrase qui devient un lien.

Droits d'accès : qui alimente la mémoire, qui la consulte

Gouvernée, enfin. Chez nous, la question ne se pose pas encore, parce qu'une seule personne alimente la mémoire et que tous les outils qui l'interrogent le font en son nom. Dans une entreprise de trente personnes, elle se pose dès le premier jour. L'agent RH ne doit pas voir la grille de salaires de la direction, et un stagiaire qui pose une question au même agent ne doit pas recevoir la même réponse que le DRH.

Cognee gère ces droits au niveau de ses ensembles de documents. Chaque service a le sien, chaque utilisateur reçoit des droits de lecture ou d'écriture sur chacun d'eux, et une recherche ne parcourt que ce que la personne qui la lance a le droit de voir. Le même agent, interrogé par deux personnes, ne consulte donc pas les mêmes ensembles et ne donne pas la même réponse. Pour une PME, le modèle le plus simple consiste à laisser les responsables de service alimenter leur périmètre pendant que tout le monde lit ce qui le concerne. Ça se règle dans une configuration, sans développement, et comme la mémoire est chez l'entreprise, c'est elle qui tient ces règles.

Ce qui vient ensuite demande davantage. Faire valider un document par un responsable avant qu'il entre dans la mémoire, donner à chaque service son propre agent avec ses propres outils, mesurer ce que les agents retrouvent et ce qu'ils ratent, tout cela suppose une couche de plus. Ce sont les sujets des prochains articles de cette série.

Un dépôt open source pour démarrer sa base de connaissances

Les trois règles d'écriture données plus haut sont réunies dans agent-memory-starter, un dépôt public sous licence MIT. Il contient trois modèles de fiches, pour un projet, pour une décision et pour une procédure, les conventions de rédaction qui permettent à un graphe de les lire correctement, et un script qui vérifie chaque fichier avant ingestion. Il ne dépend pas de Cognee, et les fichiers qu'il produit se lisent avec n'importe quel moteur de mémoire, ou sans moteur du tout, ce qui est cohérent avec l'idée qu'ils appartiennent à l'entreprise et non à un outil.

C'est un travail issu d'un seul studio, avec ses propres projets comme matière. Les modèles sont pensés pour une entreprise ordinaire, un choix de fournisseur, une procédure d'accueil, un compte client, et ils ont d'abord servi chez nous. Les retours de ceux qui les appliqueront à d'autres métiers sont bienvenus, comme ils l'ont été pour notre méthode sur les sites animés.

Chez Nualt, la mémoire fait partie du projet

La mémoire décrite ici tourne pour nos propres agents, sur un serveur du studio, avec nos projets dedans. Rien de ce qu'elle contient n'est propre à un studio de développement. Une entreprise qui a des procédures, des décisions et des clients peut avoir la même chose, sur son serveur ou chez son hébergeur, avec les outils IA qu'elle utilise déjà, et en rester propriétaire de bout en bout.

Ce que ça demande, c'est de structurer la connaissance avant de brancher les agents, de décider qui alimente et qui consulte, et de donner aux responsables un moyen simple d'écrire dedans. C'est un projet avec un début et une fin, comme un site ou une boutique, et c'est ainsi que nous l'abordons. Nous partons de ce que l'entreprise sait déjà, nous l'écrivons sous une forme qu'un agent retrouve, nous branchons les outils ensuite, et à la fin l'entreprise possède le résultat, le comprend et peut le faire évoluer avec ou sans nous. Comme pour la brique d'authentification de Medusa, ce que nous construisons pour nous sert de base à ce que nous construisons pour les autres.