Les agents IA savent déjà produire une réponse en quelques secondes. Leur faiblesse apparaît après la fermeture de la fenêtre de discussion : préférences oubliées, décisions perdues et contexte à reconstruire. En 2026, plusieurs projets open source s’attaquent directement à cette limite en ajoutant une mémoire persistante aux applications et aux agents.
Cognee, Graphiti, Mem0, OpenViking et OpenMemory ne répondent pas au même besoin. Les uns transforment les informations en graphes de connaissances, les autres privilégient la continuité entre sessions ou le partage du contexte entre plusieurs outils de développement. Voici les cinq solutions à connaître pour choisir une architecture adaptée à votre agent.
Les cinq solutions open source face à face
La différence principale tient à la manière dont chaque projet représente et récupère la mémoire : graphe de connaissances, état persistant, système de fichiers contextuel ou couche locale partagée.
| Solution | Approche principale | Licence | Cas d’usage mis en avant |
|---|---|---|---|
| Cognee | Graphe de connaissances et mémoire vectorielle | Apache-2.0 | Mémoire documentaire et multi-agent |
| Graphiti | Graphe de connaissances temporel | Apache-2.0 | Faits qui évoluent dans le temps |
| Mem0 | Couche de mémoire persistante pour agents | Apache-2.0 | Personnalisation et rappel entre sessions |
| OpenViking | Base de contexte pour connaissances, mémoire et compétences | AGPL-3.0 | Agents opérant sur de longues périodes |
| OpenMemory | Mémoire locale partagée entre outils de codage | Open source | Continuité entre Claude Code, Codex et OpenCode |
Ces projets sont tous destinés à conserver des informations au-delà d’une session, mais leur périmètre varie. Mem0 s’intègre comme une couche de mémoire, Graphiti modélise les changements de faits, tandis qu’OpenViking cherche à unifier les ressources dont un agent a besoin pour agir.
À retenir : Une mémoire efficace ne consiste pas à conserver toute l’historique. Elle doit extraire, structurer et retrouver les éléments utiles au moment opportun.
1. Cognee transforme les documents et conversations en graphe exploitable
Cognee se positionne comme une plateforme open source de mémoire pour les agents IA. Son principe consiste à transformer des documents, du code et des conversations en un graphe de connaissances que les agents peuvent ensuite interroger et réutiliser entre plusieurs sessions.
Le projet combine un graphe et une recherche vectorielle. Cette architecture permet de rapprocher deux besoins différents : retrouver un passage sémantiquement proche d’une requête et relier plusieurs entités ou faits entre eux.
Une mémoire adaptée aux bases documentaires
Cognee cible les applications qui doivent conserver une connaissance structurée d’un corpus. Un agent peut ainsi s’appuyer sur des documents internes, des échanges précédents ou des éléments de code sans reconstruire l’ensemble du contexte à chaque requête.
Le projet utilise notamment SQLite, LanceDB et Kùzu dans sa configuration décrite publiquement, avec la possibilité de remplacer certains composants par d’autres bases compatibles. Cette organisation favorise un déploiement autohébergé et laisse à l’équipe le choix de son infrastructure de stockage.
L’un des intérêts du graphe est de rendre les relations entre éléments plus explicites. Une information peut être reliée à une personne, un projet, une décision ou un document source, au lieu d’être conservée uniquement sous la forme d’un vecteur isolé.
Pour quels agents ?
Cognee convient particulièrement aux agents qui doivent exploiter une mémoire commune ou une base de connaissances évolutive :
- agents d’entreprise connectés à des documents internes ;
- assistants qui doivent conserver le contexte de projets sur plusieurs semaines ;
- systèmes multi-agents partageant des informations structurées ;
- applications qui combinent recherche sémantique et raisonnement sur les relations.
La licence Apache-2.0 facilite l’utilisation, la modification et l’intégration du projet dans une application. Comme pour toute architecture de mémoire, la qualité du résultat dépend toutefois de l’extraction des faits, du découpage des documents et de la stratégie de recherche choisie.
2. Graphiti ajoute la dimension temporelle aux souvenirs des agents
Graphiti est un moteur open source de graphe de connaissances temporel développé par Zep. Il est conçu pour représenter des faits qui changent, plutôt que de traiter la connaissance comme une photographie figée.
Cette dimension temporelle répond à un problème concret : une information peut être vraie aujourd’hui, puis devenir obsolète. Un outil de gestion de projet, par exemple, doit pouvoir distinguer une ancienne responsabilité d’une responsabilité actuelle au lieu de mélanger les deux.
Le graphe conserve l’évolution des faits
Graphiti organise les informations issues d’épisodes, comme des conversations ou des événements, dans un graphe. Les relations peuvent être associées à leur période de validité, ce qui permet de suivre l’apparition, la modification ou la fin d’un fait.
Le projet prend en charge des bases de graphes telles que Neo4j et FalkorDB. Cette dépendance le destine aux équipes qui acceptent d’administrer une infrastructure de graphe ou d’utiliser un service compatible.
La mémoire temporelle est utile lorsque l’agent doit répondre à des questions portant sur l’évolution d’une situation : qui était responsable d’un projet à une date donnée, quelle version d’une règle était active ou quand une préférence a changé.
À retenir : Graphiti est le choix le plus naturel lorsque la date de validité d’un fait compte autant que le fait lui-même.
Une approche différente de la simple mémoire vectorielle
Une base vectorielle peut retrouver des contenus proches d’une requête, mais elle ne représente pas nécessairement la succession des événements. Graphiti ajoute cette structure en reliant les faits et leur évolution dans le temps.
Cette méthode peut réduire les réponses qui confondent une information ancienne avec l’état actuel d’un projet. Elle ne dispense pas pour autant de contrôler la qualité des données injectées dans le graphe : une date erronée ou une extraction incorrecte peut produire une relation temporelle trompeuse.
Graphiti s’adresse donc aux applications où les connaissances évoluent régulièrement, notamment les assistants métier, les agents de suivi et les systèmes qui doivent conserver un historique exploitable.
3. Mem0 installe une couche de mémoire persistante entre les sessions
Mem0 se présente comme une couche de mémoire pour les agents et les applications d’IA. Son objectif est de permettre à un système de conserver des informations utiles sur un utilisateur, une tâche ou un agent, puis de les rappeler lors d’interactions ultérieures.
Son fonctionnement repose sur l’extraction de souvenirs à partir des échanges, leur stockage et leur récupération lors d’une nouvelle requête. L’agent ne reçoit donc pas nécessairement toute la conversation passée : il récupère les éléments jugés pertinents pour le contexte courant.
Une intégration pensée pour les applications
Mem0 propose des bibliothèques pour Python et JavaScript et peut être utilisé comme infrastructure autohébergée. Le projet est publié sous licence Apache-2.0, ce qui permet de l’intégrer dans une application et d’adapter son fonctionnement à l’architecture existante.
La solution met l’accent sur la personnalisation. Un assistant peut retenir des préférences, des habitudes ou des informations récurrentes afin d’éviter de demander plusieurs fois les mêmes précisions.
Cette approche est également adaptée aux agents qui doivent maintenir un état entre plusieurs tâches. Un agent de support peut conserver des éléments liés à un dossier, tandis qu’un assistant de productivité peut retrouver des préférences établies lors d’échanges précédents.
Une couche plutôt qu’un environnement complet
Mem0 se distingue de Cognee et d’OpenViking par son positionnement de couche de mémoire directement intégrable. Il ne cherche pas nécessairement à devenir le système qui organise toutes les ressources d’un agent.
Cette spécialisation peut simplifier un premier déploiement. Une équipe peut ajouter la mémoire à une application existante sans reconstruire l’ensemble de sa chaîne de récupération documentaire.
Les capacités de la version open source et celles des services commerciaux ne doivent toutefois pas être confondues. Les comparaisons publiées en 2026 indiquent notamment que certaines fonctions avancées de mémoire graphique, de décroissance ou de raisonnement temporel sont associées à la plateforme commerciale, tandis que la version open source fournit la couche de base sous Apache-2.0.
Mem0 est donc particulièrement pertinent pour les équipes qui recherchent une mémoire persistante généraliste, avec une intégration rapide dans un agent déjà développé.
4. OpenViking regroupe mémoire, connaissances et compétences dans un même contexte
OpenViking est une base de contexte open source pour agents IA, publiée par Volcengine. Le projet décrit un système de fichiers unifié destiné à regrouper trois catégories de ressources : les connaissances, la mémoire et les compétences.
Cette organisation part d’un constat pratique : un agent ne travaille pas seulement avec des souvenirs. Il doit aussi retrouver des documents, charger des compétences et accéder à des ressources opérationnelles. OpenViking cherche à réunir ces éléments dans une même couche de contexte.
Un système de fichiers virtuel pour l’agent
OpenViking utilise un système de fichiers virtuel identifié par le préfixe viking://. Cette abstraction permet de présenter les ressources de l’agent sous une structure commune, plutôt que de répartir les informations entre plusieurs mécanismes indépendants.
Le projet décrit également une organisation progressive du contenu :
- un niveau L0 pour les résumés ;
- un niveau L1 pour les aperçus ;
- un niveau L2 pour le contenu intégral.
Cette progression vise à limiter le chargement de contexte inutile. L’agent peut commencer par un résumé, approfondir avec une vue d’ensemble, puis consulter le contenu complet lorsqu’il est nécessaire à la tâche.
OpenViking s’appuie sur AGFS, son système de fichiers virtuel, avec des possibilités de stockage local et de stockage compatible avec S3. Le projet peut aussi utiliser des index vectoriels, notamment avec VikingDB.
Une architecture adaptée aux tâches longues
OpenViking vise les agents qui doivent travailler sur des missions prolongées et manipuler plusieurs types de ressources. Le même environnement peut réunir des souvenirs issus des sessions précédentes, des documents de référence et des compétences nécessaires à l’exécution.
Le projet décrit aussi des mécanismes d’extraction, de déduplication, de fusion et de suivi des changements de mémoire. Une logique de validation de type commit et un mécanisme de comparaison des évolutions permettent de contrôler les modifications apportées à la mémoire.
Sa licence AGPL-3.0 doit être prise en compte avant une intégration dans un produit distribué. Elle impose des obligations différentes de celles d’une licence permissive comme Apache-2.0, notamment lorsqu’un logiciel dérivé est distribué ou rendu accessible sur un réseau.
OpenViking se distingue ainsi par son ambition d’infrastructure de contexte complète. Il s’adresse moins à l’ajout minimal d’un souvenir dans une application qu’à la construction d’un environnement organisé pour agents autonomes.
5. OpenMemory porte le contexte de codage d’un outil à l’autre
OpenMemory est présenté comme une couche de mémoire locale destinée à conserver le contexte entre plusieurs outils d’intelligence artificielle pour le développement. Le fait établi par Brief IA indique qu’il peut porter le contexte de codage entre Claude Code, Codex et OpenCode.
Cette fonction répond à une difficulté croissante pour les développeurs : un même projet peut être traité successivement avec plusieurs agents de programmation, mais chacun dispose souvent de son propre historique et de ses propres fichiers de contexte.
Une continuité entre Claude Code, Codex et OpenCode
OpenMemory vise à centraliser les éléments utiles au travail de développement afin qu’ils restent accessibles d’un outil à l’autre. Les décisions d’architecture, les conventions du dépôt, les problèmes rencontrés et les solutions déjà testées peuvent ainsi être réutilisés par plusieurs agents.
Le projet est décrit comme local-first. Cette orientation place le stockage du contexte dans l’environnement contrôlé par l’utilisateur ou l’équipe, ce qui peut répondre aux contraintes de confidentialité liées au code source et aux discussions techniques.
OpenMemory cible donc un besoin plus spécialisé que Mem0. Mem0 fournit une couche générale de mémoire pour agents, tandis qu’OpenMemory se concentre sur la continuité du contexte de programmation entre différents clients.
Une mémoire utile dans les équipes de développement
Le partage du contexte devient particulièrement intéressant lorsqu’un projet combine plusieurs usages : génération de code, correction de bogues, revue, documentation et exécution de commandes. Un agent peut avoir besoin de connaître une décision prise lors d’une session précédente, même si cette session a eu lieu dans une autre interface.
Les cas d’usage incluent notamment :
- conserver les conventions propres à un dépôt ;
- transmettre les décisions techniques entre plusieurs agents ;
- éviter de réexpliquer l’architecture à chaque nouvel outil ;
- maintenir un contexte commun lors d’un travail en équipe.
OpenMemory est donc à considérer lorsque le problème principal n’est pas seulement l’oubli entre deux conversations, mais la fragmentation du contexte entre plusieurs environnements de développement.
Quelle solution choisir selon le problème à résoudre ?
Le bon choix dépend moins du volume de données que de la structure de la mémoire attendue. Une application qui doit retenir des préférences n’a pas les mêmes besoins qu’un agent chargé de suivre l’évolution d’un projet ou de partager un contexte de code.
| Besoin prioritaire | Solution la plus adaptée | Raisons principales |
|---|---|---|
| Ajouter une mémoire persistante à une application | Mem0 | Couche de mémoire intégrable pour agents |
| Relier documents, entités et conversations | Cognee | Graphe de connaissances combiné à la recherche vectorielle |
| Suivre les changements de faits | Graphiti | Graphe de connaissances temporel |
| Unifier mémoire, connaissances et compétences | OpenViking | Base de contexte organisée comme un système de fichiers |
| Partager le contexte de développement entre outils | OpenMemory | Continuité entre Claude Code, Codex et OpenCode |
Le choix de la licence peut également peser dans la décision. Cognee, Graphiti et Mem0 utilisent Apache-2.0, tandis qu’OpenViking utilise AGPL-3.0. OpenMemory est présenté comme open source, avec une orientation locale pour le stockage du contexte.
L’infrastructure existante est un autre critère. Graphiti nécessite une base de graphe adaptée à son modèle temporel, alors que Mem0 peut être ajouté comme couche à une application déjà équipée d’un stockage. OpenViking demande une réflexion plus large sur l’organisation des ressources et leur chargement progressif.
Les points techniques à vérifier avant un déploiement
Une mémoire persistante améliore la continuité d’un agent, mais elle ajoute aussi des décisions d’architecture. Le stockage n’est que la première étape : il faut déterminer quelles informations conserver, comment les mettre à jour et quand les injecter dans le contexte du modèle.
Extraction et qualité des souvenirs
Chaque solution doit transformer des entrées brutes en éléments réutilisables. Une conversation complète n’est pas toujours un bon souvenir. Les informations utiles doivent être séparées des formulations temporaires, des hypothèses et des détails sans valeur pour les sessions futures.
Les équipes doivent donc tester les règles d’extraction sur des conversations représentatives. Une mémoire trop permissive accumule du bruit ; une mémoire trop agressive supprime des détails importants.
Mise à jour et obsolescence
La mémoire d’un agent doit gérer les contradictions. Une préférence peut changer, une équipe peut adopter une nouvelle convention et un projet peut abandonner une décision précédente.
Graphiti est particulièrement conçu pour représenter l’évolution temporelle des faits. Les autres solutions peuvent également organiser une mémoire persistante, mais la stratégie de remplacement, d’ajout ou de suppression doit être vérifiée dans le comportement concret du système.
Recherche et injection dans le contexte
Un agent ne peut pas exploiter une mémoire qu’il ne retrouve pas au bon moment. Les tests doivent mesurer la capacité du système à rappeler une information précise, à éviter les souvenirs hors sujet et à fournir assez de contexte sans saturer la fenêtre du modèle.
L’approche progressive d’OpenViking, avec résumés, aperçus et contenu complet, répond directement à cette contrainte de chargement. Les systèmes fondés sur des graphes peuvent de leur côté exploiter les relations entre entités pour compléter une recherche sémantique.
Sécurité et gouvernance
Une mémoire persistante peut contenir des informations sensibles : code source, données clients, décisions internes ou préférences personnelles. Le choix d’un déploiement local ou autohébergé doit être associé à des règles de contrôle d’accès, de conservation et de suppression.
La licence ne constitue pas une garantie de confidentialité. Elle définit les conditions de réutilisation du logiciel, tandis que la protection des données dépend de l’infrastructure, des journaux, des fournisseurs de modèles et des politiques de l’équipe.
Notre avis : Mem0 pour commencer, Graphiti pour les faits qui changent
Pour une application qui doit simplement retenir des informations utiles entre plusieurs sessions, Mem0 est le point de départ le plus direct. Son positionnement de couche de mémoire, ses bibliothèques pour Python et JavaScript et sa licence Apache-2.0 réduisent la distance entre un prototype d’agent et une intégration fonctionnelle.
Cognee devient plus intéressant lorsque la mémoire doit relier documents, conversations et entités dans une structure commune. Graphiti prend l’avantage dès que l’historique et la validité temporelle des faits sont essentiels. OpenViking vise une architecture plus ambitieuse, dans laquelle la mémoire n’est qu’une partie d’un environnement de contexte comprenant aussi les connaissances et les compétences.
OpenMemory répond à un problème concret du développement assisté par IA : éviter que le contexte d’un projet reste enfermé dans un seul outil. Sa valeur dépendra directement de sa capacité à transmettre des informations pertinentes entre Claude Code, Codex et OpenCode sans augmenter le bruit ni exposer inutilement le code.
Dans les six prochains mois, le critère décisif ne sera probablement pas la quantité de souvenirs stockés, mais la précision avec laquelle les agents sauront les sélectionner, les actualiser et les relier à une tâche. Les équipes qui adopteront ces briques devront surtout mesurer une question : quelle solution permet à l’agent de se souvenir de la bonne chose, au bon moment, dans le bon outil ?