Cognee : donner une mémoire durable à vos agents IA

Cognee : donner une mémoire durable à vos agents IA

Un agent IA oublie tout à la fin de chaque session. Il relit ses documents à chaque requête, mais il ne se souvient ni de vos échanges passés, ni des liens entre les informations qu’il a déjà vues. Cette amnésie est la limite la plus visible des assistants actuels. Cognee est une brique open source qui répond précisément à ce problème : elle construit une mémoire persistante pour vos agents, sous la forme d’un graphe de connaissances qui s’enrichit au fil du temps. (Nous avions revu Mem0 sur le même thème)

Cognee est publié sous licence Apache 2.0 par topoteretes. Le projet se distingue d’un simple pipeline RAG : là où le RAG va chercher des passages de documents à chaque question sans rien mémoriser, Cognee accumule, relie et fait évoluer une représentation structurée de ce que l’agent a appris. C’est la différence entre une bibliothèque que l’on consulte et une mémoire qui se construit.

RAG ou mémoire : ce qui change

La distinction mérite d’être posée clairement, car les deux approches sont complémentaires et non concurrentes.

Un pipeline RAG classique est sans état : il prend une question, retrouve des morceaux de texte pertinents par similarité vectorielle, puis les passe au modèle. À la requête suivante, tout recommence à zéro. Il n’y a aucune trace de l’historique, aucun lien explicite entre les faits.

Cognee ajoute une couche de mémoire qui combine trois ingrédients : les embeddings vectoriels pour la recherche par le sens, un graphe de connaissances pour relier les entités entre elles, et une ontologie qui structure ces relations. Résultat : l’agent peut non seulement retrouver une information, mais aussi suivre les liens qui la connectent au reste de ce qu’il sait, et tenir compte de ses interactions passées.

Le pipeline ECL : Extract, Cognify, Load

Cognee organise le traitement de la donnée autour d’un pipeline en trois temps, baptisé ECL pour Extract, Cognify, Load. Concrètement, l’API tient en trois opérations.

• add() : ingère et prépare la donnée brute, qu’il s’agisse de documents, de conversations passées ou de transcriptions audio.
• cognify() : c’est le cœur du système. Cette étape construit le graphe de connaissances, calcule les embeddings et dégage les entités et les relations qui structurent la mémoire.
• search() : interroge cette mémoire en combinant similarité vectorielle et parcours du graphe, pour répondre avec un contexte beaucoup plus riche qu’une simple recherche de passages.

Cette simplicité d’usage est revendiquée par le projet : une mémoire fonctionnelle se met en place en quelques lignes de code, ce qui en fait un point d’entrée accessible pour expérimenter avant d’industrialiser.

Une brique souveraine et 100 % auto-hébergeable

C’est le point qui nous intéresse le plus dans une logique de souveraineté. Par défaut, Cognee fonctionne entièrement en local, sans aucune dépendance externe, grâce à une pile sobre : SQLite pour les métadonnées relationnelles, LanceDB pour le stockage vectoriel, et Kuzu comme moteur de graphe embarqué. Rien ne sort de votre infrastructure.

L’architecture reste modulaire et permet de monter en charge en remplaçant chaque composant. Côté graphe : Kuzu, Neo4j, FalkorDB ou NetworkX. Côté vecteurs : Qdrant, Weaviate ou Redis. Côté relationnel : SQLite ou PostgreSQL. Pour le modèle de langage, Cognee se branche aussi bien sur des API distantes comme Anthropic Claude que sur un modèle ouvert servi localement via Ollama. Vous pouvez donc garder la totalité de la chaîne, donnée et inférence, sur vos propres serveurs.

Cognee expose par ailleurs un serveur MCP, ce qui permet de brancher cette mémoire directement sur un agent compatible Model Context Protocol, dans la continuité des sujets que nous avons déjà traités sur MCP et l’orchestration d’agents.

Où Cognee trouve sa place dans une stack IA

Cognee n’est pas un framework d’agents de plus. C’est une brique transversale qui vient compléter une stack existante. Elle se pose naturellement à côté d’un orchestrateur comme LangGraph, d’une base vectorielle comme Qdrant, et d’un moteur d’inférence local comme Ollama ou vLLM. Là où ces outils gèrent le raisonnement, le stockage et le calcul, Cognee gère ce qui leur manque : la continuité dans le temps.

Les cas d’usage les plus parlants sont l’assistant interne qui se souvient des décisions et du contexte d’un dossier d’une session à l’autre, l’agent de veille qui relie les informations collectées sur plusieurs semaines, ou encore le support technique qui capitalise sur l’historique des échanges plutôt que de repartir de zéro à chaque ticket.

Points de vigilance

La mémoire persistante n’est pas neutre. Trois précautions s’imposent avant un déploiement. D’abord la donnée personnelle : un graphe qui accumule les interactions doit respecter la minimisation et le droit à l’effacement, ce qui suppose de pouvoir purger des entités du graphe. Ensuite la qualité : une mémoire qui se construit automatiquement peut propager des erreurs ou des relations fausses, d’où l’intérêt de garder un humain dans la boucle sur les usages sensibles. Enfin le coût : l’étape de cognify sollicite le modèle de langage, ce qui plaide pour un modèle ouvert auto-hébergé sur les volumes importants.

Notre recommandation

Cognee est un bon candidat pour un POC ciblé : prenez un cas d’usage où la continuité dans le temps apporte une vraie valeur, montez la pile par défaut en local avec Ollama, mesurez le gain sur quelques dizaines de documents et conversations, puis décidez de l’industrialisation en remplaçant Kuzu et LanceDB par des composants plus robustes si besoin. Si vous souhaitez explorer comment doter vos agents IA d’une mémoire souveraine, écrivez-nous : nous accompagnons le cadrage, le POC et le déploiement.