Nocturne Memory : un serveur MCP de mémoire longue durée, arborescent et réversible
A lightweight, rollbackable, and visual Long-Term Memory Server for MCP Agents. Say goodbye to Vector RAG and amnesia. Empower your AI with persistent, graph-like structured memory across any model, session, or tool. Drop-in replacement for OpenClaw.
En bref
- De quoi s’agit-il ?
- Nocturne Memory remplace le RAG vectoriel par un graphe de fichiers Markdown adressables et versionnés, exposé à tout client MCP. Le projet vise les utilisateurs qui veulent la même mémoire d'un modèle à l'autre, pas une mémoire par plateforme.
- À qui s’adresse-t-il ?
- À adopter si vous changez régulièrement de client MCP ou de modèle et que vous refusez de perdre l'historique à chaque bascule, ou si vous voulez relire et corriger les souvenirs de votre agent dans un dashboard plutôt que dans une base vectorielle opaque. À éviter si votre besoin se limite à retrouver des passages dans une documentation volumineuse : la recherche par mots-clés de search_memory ne fait pas de recherche sémantique.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 20 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : la mémoire qui appartient au client, pas à l'agent
La plupart des fonctions de mémoire intégrées vivent à l'intérieur d'un produit. Le README résume la situation ainsi : la mémoire de ChatGPT appartient à ChatGPT, celle de Claude à Claude, et changer de modèle remet le compteur à zéro. Nocturne Memory prend le problème par l'autre bout. La mémoire réside dans un serveur MCP séparé, sans dépendance à un LLM particulier. Le schéma du README montre un serveur unique relié à Claude, Gemini et GPT, avec la phrase qui accompagne le dessin : aujourd'hui Claude, demain Gemini, après-demain un modèle local, et c'est le même interlocuteur qui se réveille avec le même historique.
Le public visé n'est donc pas l'équipe qui veut un chatbot documentaire. C'est l'utilisateur individuel qui construit une présence continue sur plusieurs mois, garde plusieurs personnalités distinctes (le README mentionne une isolation par namespace pour un Alice et un Bob séparés), et veut pouvoir inspecter, éditer et annuler ce que l'agent a retenu. Le slogan du projet, « Alignment is for tools. Memories are for sovereign AI », annonce la couleur : il s'agit d'un projet avec une thèse, pas d'une brique d'infrastructure neutre.
Une arborescence de fichiers adressables plutôt qu'un index vectoriel
Le mécanisme central est visible dans les exemples de conversation du README. L'agent n'interroge pas un index de similarité : il appelle des fonctions nommées. read_memory("system://boot") charge un point d'entrée fixe. search_memory("jobstation") cherche par mot-clé. Puis read_memory("core://work_jobstation/strategic_position") descend dans une branche précise. Le schéma d'adressage est donc un chemin de type URI, avec un préfixe qui distingue la zone système de la zone de contenu.
Le README donne un chiffre pour justifier l'approche : dans une base réelle de 969 000 caractères, le premier message d'une nouvelle conversation ne charge que 7,2 K caractères, parce que seul le noyau défini par l'utilisateur est injecté au démarrage et que le reste est récupéré à la demande. C'est l'argument économique du projet : le coût en tokens d'une session ne dépend pas de la taille totale de la mémoire. Le même passage indique que 78 % de la base a été rappelée au moins une fois dans une conversation sur les trente derniers jours. Ces chiffres proviennent du README et n'ont pas été reproduits ici.
La différence avec un RAG vectoriel tient à la nature de l'objet stocké. Un vecteur est un fragment anonyme, retrouvé par proximité. Ici, chaque souvenir est un nœud nommé, avec un emplacement stable, que l'on peut citer dans un appel d'outil. Cela rend les récupérations traçables : on voit dans la réponse de l'agent quels chemins ont été lus. En contrepartie, la qualité du rappel dépend de la qualité de l'arborescence et des mots-clés, pas d'un modèle d'embedding. C'est un choix assumé, et il a un coût.
Versions, diff et confirmation humaine sur les suppressions
Le projet se présente comme rollbackable et visuel. Les captures listées dans le README documentent quatre écrans : Memory Explorer pour la navigation arborescente, Memory Detail pour l'édition en direct du contenu, des métadonnées et des conditions de déclenchement, Review & Audit pour un diff visuel avec acceptation ou retour arrière, et un écran décrit comme filet de sécurité de version, où chaque opération de l'IA déclenche une sauvegarde automatique et où le nettoyage exige une confirmation humaine.
C'est la partie la plus intéressante du design. Un agent qui écrit dans sa propre mémoire sans journal de versions est un agent dont on ne peut pas auditer les dérives. Le fait que la suppression soit placée derrière une validation humaine, alors que l'écriture ne l'est pas, indique une hiérarchie explicite entre les opérations réversibles et irréversibles. Le README ne détaille pas la granularité des sauvegardes, ni si elles sont stockées dans la même base que les souvenirs. C'est une zone où la documentation reste mince, et c'est précisément ce qu'il faut vérifier avant de confier des mois de contenu au système.
Le dashboard est servi par le serveur lui-même : Node.js est requis uniquement pour construire le frontend lors du premier démarrage, comme l'indique la section des prérequis. Une instance publique est accessible à l'adresse misaligned.top/memory, ce qui permet de voir l'interface sur des données réelles sans rien installer.
Installation : deux commandes, puis un fichier de configuration par client
Le README annonce une installation en deux étapes. La première tient en trois lignes :
git clone https://github.com/Dataojitori/nocturne_memory.git cd nocturne_memory pip install -r backend/requirements.txt
La seconde consiste à déclarer le serveur dans le client MCP. Le README ne montre pas de bloc de configuration complet pour cette étape, mais il donne un point de vigilance concret : le chemin à indiquer dans args dépend du client. Pour Antigravity, il doit pointer vers backend/mcp_wrapper.py, présenté comme la solution à un problème de fins de ligne CRLF sous Windows. Pour les autres clients, il pointe vers backend/mcp_server.py. Le README précise par ailleurs que le transport stdio et le transport SSE sont pris en charge.
Pour un essai sans installation, un serveur de démonstration est disponible. Côté OpenAI Codex, la configuration tient en deux lignes dans .codex/config.toml : une section [mcp_servers.nocturne_memory_demo] et une clé url valant https://misaligned.top/mcp. Côté Antigravity, le README donne un objet JSON avec la clé serverUrl et la même adresse. Attention : la démo est en lecture seule et n'expose que read_memory et search_memory. Elle ne permet donc pas de juger le cycle d'écriture, de version et de rollback, qui est justement la partie différenciante.
Deux bases de données, une licence permissive, et une maintenance à surveiller
Le projet est publié sous licence MIT, ce qui autorise la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver l'avis de licence. Aucun avis juridique ne s'impose ici : c'est la portée standard de cette licence. Le badge du README indique que le cœur s'appuie sur SQLite ou PostgreSQL, ce qui laisse le choix entre un fichier local et un serveur partagé. Le README ne décrit pas la procédure de migration entre les deux, ni les cas où PostgreSQL devient nécessaire. À vérifier si vous envisagez de faire évoluer un déploiement mono-utilisateur vers quelque chose de partagé.
La cadence de publication mérite d'être notée pour ce qu'elle est. La version 2.5.6, datée du 9 août 2026, est intitulée « MCP 2.0 Compatibility & Long-Form Improvements ». La 2.5.4, du 31 mai 2026, porte sur la commutation de presets au démarrage et la récupération de nœuds orphelins. La 2.5.2, du 23 mai 2026, est décrite comme une correction de bugs majeurs avec ajout du support du chinois. Le dépôt n'est pas archivé et le dernier push est daté du 27 août 2026. La migration vers une compatibilité MCP 2.0 dans une version mineure indique que l'interface avec les clients peut bouger. Si vous épinglez une version, prévoyez de relire les notes de version avant de sauter à la suivante.
Le coût de maintenance réel ne vient pas du code mais du contenu. Une mémoire de plusieurs centaines de milliers de caractères se dégrade si personne ne fusionne les nœuds redondants ni ne corrige les chemins mal nommés. Le dashboard Review & Audit existe pour cela, et le README en fait un élément de premier plan plutôt qu'un accessoire.
Quand Nocturne Memory n'est pas le bon outil
La limite la plus nette concerne la recherche. L'outil exposé s'appelle search_memory et, dans les exemples du README, il est appelé avec un terme simple : "jobstation", "身体". Rien dans la documentation fournie n'indique une recherche sémantique, une reformulation de requête ou un classement par pertinence. Si votre besoin est de retrouver un passage pertinent dans un corpus que vous n'avez pas structuré, un index vectoriel fait mieux le travail : il accepte une question en langage naturel et retrouve un fragment dont les mots diffèrent. Ici, c'est l'agent qui doit deviner le bon chemin ou le bon mot-clé, et un chemin mal nommé reste introuvable.
Deuxième cas défavorable : la mémoire partagée entre plusieurs utilisateurs ou plusieurs sessions concurrentes. Le projet est décrit comme un serveur personnel, avec une notion de namespace pour séparer des personnalités, pas pour cloisonner des locataires. Le README ne traite ni des droits d'accès, ni de la concurrence en écriture. Pour un déploiement en équipe, ces questions arriveront avant les fonctionnalités de rappel.
Troisième point, le contenu du README lui-même. Les exemples de conversation mis en avant incluent un échange à caractère sexuel explicite et des échanges de dépendance affective. Ce n'est pas un défaut technique, mais c'est une indication sur la communauté visée et sur le type de contenu que le projet est conçu pour héberger. Une équipe qui évalue l'outil pour un usage professionnel doit le savoir avant de le présenter à qui que ce soit.
Ce que change l'absence de couche d'embedding
La comparaison utile n'est pas avec un produit de mémoire d'assistant, mais avec une pile RAG classique : un découpage de documents, un modèle d'embedding, une base vectorielle, un réordonnanceur. Cette pile résout un problème de rappel dans un corpus non structuré et laisse le contenu en lecture seule. Nocturne Memory résout un problème d'écriture et de continuité : l'agent crée, modifie et supprime ses propres nœuds, et l'historique de ces opérations est conservé.
Les conséquences pratiques divergent. Un RAG vectoriel n'a pas besoin d'être organisé : on jette les documents dedans. Nocturne Memory exige une discipline d'arborescence, car un chemin comme core://work_jobstation/commercialization n'a de valeur que si quelqu'un, humain ou agent, a décidé de cette hiérarchie. En échange, la récupération est déterministe et citable : le README montre les appels d'outils avant chaque réponse, ce qui permet de savoir exactement ce que l'agent avait sous les yeux. Avec un RAG, on voit les fragments retrouvés, mais on ne peut pas les corriger à la source et rejouer.
Reste une question que la documentation ne tranche pas : comment l'agent choisit-il entre search_memory et la descente d'un chemin connu ? Les exemples suggèrent une combinaison des deux, mais rien n'indique de règle ni de garde-fou. C'est le genre de détail qui décide de la qualité du rappel en pratique, bien plus que le choix de la base de données.
Conclusion éditoriale
À adopter si vous changez régulièrement de client MCP ou de modèle et que vous refusez de perdre l'historique à chaque bascule, ou si vous voulez relire et corriger les souvenirs de votre agent dans un dashboard plutôt que dans une base vectorielle opaque. À éviter si votre besoin se limite à retrouver des passages dans une documentation volumineuse : la recherche par mots-clés de search_memory ne fait pas de recherche sémantique. Avant de vous engager, vérifiez deux points précis : le contenu réel de system://boot, puisque c'est lui qui fixe le coût en tokens de chaque nouvelle conversation, et la procédure de restauration d'une version depuis le dashboard, puisque rollbackable est la promesse centrale du projet.
Notes de la communauté