MemMachine : une couche mémoire pour agents, entre graphe et SQL

Le problème : un agent qui oublie tout entre deux sessions

Un agent LLM classique repart de zéro à chaque appel. L'historique tient dans la fenêtre de contexte, puis disparaît. Reconstruire cet historique à la main signifie réinjecter les mêmes tours de conversation, ce qui coûte des tokens et finit par saturer la fenêtre. MemMachine prend en charge cette persistance en dehors du modèle. Le projet se présente comme une couche mémoire à long terme pour agents et applications LLM, avec l'objectif affiché de transformer des chatbots sans état en assistants conscients du contexte. Le public visé est explicite dans le README : développeurs construisant des agents ou des workflows autonomes, chercheurs travaillant sur les architectures d'agents, et équipes ayant besoin d'une mémoire inter-sessions. Les cas d'usage listés vont du CRM à l'assistant d'écriture, en passant par un navigateur de santé et un conseiller financier. Ce dernier exemple mérite d'être noté : stocker des préférences de portefeuille et une tolérance au risque dans une base de données n'est pas un choix anodin, et le README ne dit rien sur le chiffrement au repos.

Trois mémoires, deux moteurs de stockage

MemMachine ne range pas tout au même endroit. Le README distingue trois types. La mémoire de travail couvre le contexte de la session en cours. La mémoire épisodique conserve le contexte conversationnel sous forme de graphe, et survit aux sessions. La mémoire de profil stocke les faits et préférences durables de l'utilisateur, dans SQL. L'architecture décrite en trois étapes est simple : l'agent passe par une couche API (REST, SDK Python ou serveur MCP), MemMachine traite l'interaction et la répartit entre épisodique et profil, puis persiste dans le graphe d'un côté et dans SQL de l'autre. La base graphe nommée est Neo4j. Cette séparation a une conséquence pratique : une question comme « quelles sont mes préférences de vol » peut être servie par le profil, tandis qu'une question sur le déroulé d'une conversation passée passe par le graphe. Le prix à payer est l'exploitation de deux systèmes de stockage aux modèles de sauvegarde, de supervision et de montée de version différents. Le README ne décrit pas de mécanisme de cohérence entre les deux, ni ce qui se passe si l'écriture dans Neo4j réussit et que celle dans SQL échoue.

Cinq lignes de code, à condition d'avoir un serveur

L'installation côté client tient en une commande : pip install memmachine-client. Le README précise une condition en amont, sous forme d'encadré : le code requiert un serveur MemMachine en fonctionnement, à démarrer localement ou via le service hébergé. Le client s'initialise avec MemMachineClient(base_url="http://localhost:8080"). On récupère ensuite un projet avec client.get_or_create_project(org_id="my_org", project_id="my_project"). L'instance mémoire se crée avec project.memory(group_id="default", agent_id="travel_agent", user_id="alice", session_id="session_001"). Ces quatre identifiants ne sont pas décoratifs : ils déterminent la portée de ce qui est écrit et relu. Une erreur sur user_id ou session_id cloisonne la mémoire au mauvais endroit, et le README n'indique pas de commande pour inspecter ou corriger des enregistrements mal rattachés. L'écriture se fait avec memory.add("I prefer aisle seats on flights", metadata={"category": "travel"}) et renvoie un AddMemoryResult avec un uid. La recherche utilise memory.search("What are my flight preferences?") et le résultat se lit en profondeur : results.content.episodic_memory.long_term_memory.episodes[0].content. Cette hiérarchie est révélatrice de l'architecture, mais elle expose aussi la structure interne à l'appelant : tout changement de forme dans cette arborescence casse le code client. Pour le reste, le README renvoie au guide de démarrage et à la référence API, sans détailler les paramètres de recherche ni les options de filtrage.

MCP, intégrations et surface d'API

Le projet fournit un serveur MCP natif, avec deux points d'entrée en ligne de commande : memmachine-mcp-stdio pour les clients de bureau comme Claude Desktop, et memmachine-mcp-http pour les clients web. C'est probablement l'argument le plus concret du dépôt : brancher une mémoire persistante sur un client compatible MCP ne demande pas d'écrire de code. Côté frameworks, le README liste des intégrations LangChain, LangGraph, CrewAI, LlamaIndex, AWS Strands, n8n, Dify et FastGPT, chacune dans son sous-dossier sous integrations/. La liste est large, et c'est aussi sa faiblesse : rien n'indique dans le matériel fourni à quel point ces intégrations sont maintenues, ni si elles suivent les ruptures d'API des frameworks concernés. Le SDK est disponible en Python et en TypeScript, avec une API REST en dessous. Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'avis de licence. Le README ne comporte aucune section sur les conditions du service hébergé, qui relèvent d'un contrat séparé et non de la licence du dépôt.

Ce que le dépôt ne dit pas

Le matériel fourni ne contient aucune mesure de latence, aucun coût de stockage par conversation, aucun schéma de données pour le graphe ou les tables SQL. Impossible donc de savoir combien de nœuds une conversation de mille tours génère dans Neo4j, ni comment la recherche épisodique est classée. Le README mentionne un point d'entrée REST et un serveur MCP, mais pas d'authentification, de quotas ni de modèle de permissions. Il ne décrit pas non plus de stratégie d'élagage : dans un système de mémoire à long terme, l'absence de mécanisme de suppression ou d'expiration documenté est une question ouverte, en particulier pour les cas d'usage santé et finance cités en exemple. Enfin, la compatibilité entre versions n'est pas traitée. Trois versions sont sorties entre le 1er et le 18 mai 2026 (v0.3.7, v0.3.8, v0.3.9), ce qui suggère un rythme de correction soutenu sur une API encore en 0.x. Un projet en version 0.x signifie par convention que des ruptures sont attendues ; prévoyez de lire les notes de version avant chaque montée, et de figer la version du serveur et du client ensemble.

Face à un vector store et à un historique maison

L'alternative la plus courante n'est pas un concurrent nommé, c'est une pile maison : une base vectorielle pour les embeddings plus une table pour les faits utilisateur. L'approche diffère sur un point précis. Un vector store retrouve des passages par similarité, sans notion de relation entre eux. MemMachine place la mémoire épisodique dans un graphe, ce qui permet en principe de relier des épisodes entre eux et de suivre une conversation dans le temps plutôt que de récupérer des fragments isolés. En contrepartie, il faut opérer Neo4j, ce qu'un vector store managé évite. Une seconde alternative est de garder l'historique brut dans sa propre base et de le réinjecter dans le prompt. C'est trivial à mettre en place et sans dépendance externe, mais le coût en tokens croît avec la longueur de l'historique et la fenêtre de contexte finit par être le facteur limitant. MemMachine déplace ce problème vers une couche de stockage et de recherche, au prix d'un serveur supplémentaire à maintenir.

Qui doit adopter, qui doit attendre

MemMachine est un bon candidat pour une équipe qui a déjà un agent en production, qui constate que la réinjection d'historique coûte cher, et qui dispose déjà d'une infrastructure Neo4j ou est prête à en exploiter une. Le serveur MCP est le chemin le plus court pour valider l'intérêt sur un client de bureau, sans écrire de code. À l'inverse, un projet qui veut une bibliothèque embarquée, sans processus serveur ni base graphe, se trompe d'outil : le README impose une instance MemMachine joignable. De même, une application qui doit garantir la suppression effective d'une donnée personnelle ne trouvera dans le matériel fourni aucune documentation sur l'effacement. Avant de vous engager, vérifiez trois points : la présence de l'image memmachine/memmachine dans votre registre, la procédure de migration entre v0.3.7 et v0.3.9, et le comportement de memory.search sur un user_id inexistant, cas que le README n'illustre pas.

Conclusion éditoriale

MemMachine convient aux équipes qui acceptent d'exploiter un Neo4j en plus d'une base SQL et qui veulent une mémoire épisodique interrogeable, pas un simple journal de conversation. Passez votre chemin si vous cherchez une bibliothèque embarquée sans serveur : memmachine-client exige une instance MemMachine joignable, et le README indique lui-même qu'un serveur doit tourner. Avant d'adopter, vérifiez deux choses concrètes : la disponibilité de l'image memmachine/memmachine sur votre registre et le schéma de migration entre v0.3.7 et v0.3.9, puisque trois versions se sont succédé en moins de trois semaines.

Sources officielles

1. License: Apache-2.0
2. MemMachine/MemMachine on GitHub
3. Project website
4. README
5. Releases