Mnemolith, une mémoire de code qui peut se périmer

NNoor

D’après GitHub, Mnemolith est un serveur MCP qui associe une mémoire au dépôt Git d’un projet. Claude Code, Cursor et Codex peuvent ainsi retrouver cette mémoire commune, au lieu de repartir chacun avec des repères séparés entre deux sessions. L’outil vise deux problèmes différents : un agent peut oublier une décision utile, mais il peut aussi conserver une information devenue fausse. Anish illustre ce risque avec un changement de base de données : après une migration de Postgres vers MySQL, un agent pourrait continuer à se référer à l’ancien choix. Mnemolith cherche donc à garder des informations sur le projet tout en signalant que certaines doivent être contrôlées quand le code évolue. Le lien avec le dépôt Git sert à organiser cette mémoire autour d’un projet, et non à présenter ces souvenirs comme des vérités définitives. C’est ce principe de mémoire révisable qui distingue la proposition : l’outil ne promet pas seulement de retenir davantage, il prévoit aussi de mettre à l’écart des éléments susceptibles de ne plus correspondre au code.

NNoor

Une mémoire peut être liée aux fichiers dont elle dépend. Mnemolith conserve alors l’empreinte Git de ces fichiers et, si leur contenu change, met le souvenir de côté et le signale pour vérification. Le changement peut être enregistré dans Git ou ne pas encore l’être : dans les deux cas, le souvenir concerné est signalé. Ce mécanisme indique qu’il faut réexaminer l’information, parce que le fichier associé a changé, mais il ne prouve pas à lui seul que le souvenir est faux. La vérification permet de décider s’il reste valable, s’il doit être corrigé ou s’il faut le retirer. L’outil fournit donc un indice lié au code, pas une garantie automatique de vérité. Pour l’utilisateur, l’enjeu est d’éviter qu’une consigne ancienne soit reprise sans examen après une modification qui pourrait en changer le sens.

NNoor

Le projet s’adresse aux personnes qui utilisent des agents de programmation comme Claude Code, Cursor ou Codex sur un dépôt. Un tableau de bord local permet de consulter les souvenirs, leur provenance et leur historique. L’utilisateur peut confirmer qu’un élément est toujours juste, ou le retirer et indiquer ce qui est vrai à sa place. Cette possibilité de contrôle est utile parce qu’une mémoire automatique peut contenir une information partielle, ancienne ou devenue inadaptée. Les éléments jugés à jour peuvent aussi être inscrits dans une section gérée d’AGENTS.md ou de CLAUDE.md. Ils peuvent alors être examinés dans les pull requests, avec les modifications proposées au projet. Ce partage par dépôt donne un point commun aux différents agents utilisés sur le projet, mais ne signifie pas que Mnemolith synchronise directement les souvenirs entre les membres d’une équipe. Le fonctionnement annoncé reste local : les données demeurent sur la machine de l’utilisateur. Le tableau de bord et les fichiers de consignes offrent donc des moyens de contrôle, sans remplacer la vérification humaine des éléments conservés.

NNoor

Dans sa présentation sur GitHub, Anish indique que l’agent est censé évaluer si une nouvelle information contredit un souvenir antérieur, plutôt que de s’appuyer uniquement sur un seuil de ressemblance. Il donne l’exemple d’un projet qui utilise Postgres puis migre vers MySQL : les deux formulations peuvent être peu proches, tout en décrivant des choix incompatibles pour le même projet. Pour cet exemple, il rapporte un score de similarité de 0,30 lors de sa calibration. Ce résultat explique pourquoi une mesure de proximité textuelle, prise seule, ne suffit pas à reconnaître une contradiction. Sur le plan technique, le projet est en version 0.2.1 et son moteur est écrit en Java. Il comprend un serveur compatible Redis et un index vectoriel HNSW ; les représentations utilisées sont calculées localement avec all-MiniLM-L6-v2. Les données restent sur la machine de l’utilisateur. Ces éléments décrivent l’architecture annoncée, sans faire oublier que le projet est encore à un stade précoce et que la manière de traiter les contradictions est présentée comme une fonction de l’agent.

NNoor

La limite la plus nette est l’absence, pour l’instant, d’une synchronisation d’équipe dédiée en dehors des fichiers AGENTS.md et CLAUDE.md. Ces fichiers permettent de faire examiner des mémoires à jour dans les pull requests, mais ils ne constituent pas une synchronisation générale entre les membres d’une équipe. Le projet est en version 0.2.1 et demande Java 11 ou une version ultérieure. Il faut aussi distinguer le signalement d’un fichier modifié d’une confirmation que le souvenir associé est devenu faux : Mnemolith met l’élément de côté pour qu’il soit vérifié. Le tableau de bord permet ensuite de le confirmer, de le corriger ou de le retirer. Alors, l’idée centrale est de rendre visibles les souvenirs des agents, leur provenance et les changements de code qui peuvent les rendre douteux. Pour une personne qui travaille avec plusieurs agents sur un même dépôt, la mémoire partagée et les contrôles locaux sont les fonctions mises en avant. Pour une équipe, l’absence de synchronisation dédiée reste un point concret à prendre en compte. Le projet propose donc une façon de gérer les informations persistantes liées au code, mais leur exactitude dépend toujours d’une vérification lorsqu’un changement les remet en question.