Memmy : un hub de mémoire locale partagé entre agents de codage

Le problème : chaque agent repart de zéro

Un développeur qui utilise Claude Code le matin, Codex l'après-midi et Cursor le soir redécrit trois fois la même architecture, les mêmes conventions de nommage et les mêmes décisions déjà tranchées. Les fichiers d'instructions par outil aident, mais ils ne se parlent pas. Memmy part de ce constat et propose un magasin de mémoire unique, local, que tous les agents interrogent. Le README résume la promesse par une phrase : « Let every AI remember the same you. » La cible est donc l'utilisateur individuel qui jongle entre plusieurs assistants, pas l'équipe qui veut centraliser la connaissance dans un serveur partagé. Le dépôt liste d'ailleurs une quinzaine de clients compatibles, de DeepSeek Harness à Hermes en passant par OpenClaw et WorkBuddy. Cette largeur est le point de départ du projet : sans elle, l'outil n'aurait aucune raison d'exister.

Deux services locaux et un fichier de configuration

L'architecture visible dans le README tient en deux démons. memmy-memory.service expose une API sur http://127.0.0.1:18960, c'est le magasin de mémoire. memmy-gateway.service sert de point d'entrée aux agents et aux modèles. Les deux sont des services systemd --user liés à localhost, et le README précise qu'ils restent actifs après la fermeture du terminal ou de la TUI, puis redémarrent aux connexions suivantes. L'installateur ne les marque pas linger, donc ils ne survivent pas à une déconnexion complète de la session. Le CLI memmy-memory parle directement au premier service, avec des sous-commandes add, get, search et health. L'option --source et l'option --user-id servent à nommer l'espace de travail : c'est ainsi qu'on cloisonne plusieurs projets ou plusieurs agents sur une même machine. Rien dans le matériel fourni ne décrit le format de stockage, l'algorithme de recherche ni la façon dont les souvenirs sont dédupliqués ou résumés. Cette zone reste opaque, et c'est une réserve légitime.

Installer Memmy, puis décider explicitement qui y accède

Sur Linux x64 ou arm64, avec Node.js 22 ou plus récent et une session systemd utilisateur disponible, l'installation tient en deux lignes :

curl -fsSL https://raw.githubusercontent.com/MemTensor/memmy-agent/main/scripts/install.sh | bash memmy

Le premier appel à memmy ouvre l'assistant de configuration du modèle si nécessaire, active memmy-gateway.service, attend qu'il soit prêt, puis lance la TUI. Point important : l'installateur initialise la mémoire sans toucher à Codex, Claude Code ni Cursor. Pour brancher un agent, il faut lancer explicitement memmy-memory init, ou memmy-memory init --agent <agent> pour n'en cibler qu'un. Cette séparation est saine, elle évite qu'une installation modifie silencieusement les configurations d'autres outils. Le reste de la prise en main passe par memmy onboard, memmy status, memmy agent --message "...", memmy serve pour exposer une API compatible OpenAI sur le port 18990, et la configuration minimale dans ~/.memmy/config.yaml :

agents: defaults: model: openai/gpt-4.1 provider: openai timezone: "+08:00" providers: openai: apiKey: ${OPENAI_API_KEY}

Le README signale aussi que memmy réécrit ~/.memmy/systemd/gateway.env en mode 0600 avant chaque connexion au Gateway, avec les variables d'environnement référencées, les identifiants des fournisseurs courants et le PATH du terminal. Si ces valeurs changent, l'appel suivant à memmy redémarre le service avec le nouvel environnement. C'est pratique, mais cela signifie que des secrets de fournisseurs transitent par un fichier que le projet gère lui-même.

L'application de bureau et les jetons d'essai

Le chemin recommandé par le projet est l'application de bureau, téléchargeable depuis memmy.bot ou depuis les releases GitHub, avec une version v1.1.4 publiée le 9 septembre 2026. Le README mentionne une inscription donnant des jetons d'essai pour les tâches de l'agent, avec un basculement vers un mode BYOK quand le crédit est épuisé. Cette mécanique mérite d'être lue avant d'adopter l'outil : la mémoire locale, elle, ne dépend pas du compte, mais la partie « Agent Runtime » oui. Un utilisateur qui veut rester entièrement hors ligne configure donc son propre fournisseur dans config.yaml et renonce aux crédits. Le README ne détaille ni la durée de validité des jetons, ni ce que le service distant reçoit pendant l'essai. C'est le principal angle mort de la documentation fournie.

Ce que Memmy ne fait pas

Le projet ne synchronise pas la mémoire entre plusieurs machines. Le service écoute sur 127.0.0.1:18960 et le README ne décrit aucune réplication ni aucun backend distant. Un développeur sur deux postes devra donc compter sur autre chose. Autre limite : l'initialisation reste manuelle par agent. Si vous ajoutez un nouvel outil à votre flux, il faut repasser par memmy-memory init --agent <agent> et vérifier que la Skill et le Hook correspondants existent. Le README cite Claude Code, Codex, Cursor, OpenClaw, Hermes et d'autres, mais la liste des agents réellement pris en charge par un Hook n'est pas donnée dans le matériel. Enfin, le dépôt ne fournit aucun chiffre sur la consommation disque ou sur le coût d'un search sur un historique volumineux. Pour un usage intensif, c'est une inconnue à mesurer soi-même avec memmy-memory health et des requêtes réelles.

Face à un simple fichier d'instructions partagé

L'alternative la plus évidente n'est pas un autre produit, c'est un fichier. Un AGENTS.md ou un CLAUDE.md versionné dans le dépôt, lu par plusieurs outils, couvre les conventions de projet et les décisions stables. La différence d'approche est nette : le fichier est déterministe, relu par l'humain, modifiable en revue de code, et il ne tourne aucun démon. Memmy vise autre chose, une mémoire qui se constitue à partir de l'historique de collaboration et s'interroge par recherche, donc du contenu qui évolue sans relecture explicite. Le fichier gagne pour les règles stables et partagées en équipe. Memmy gagne pour un contexte personnel qui change souvent et qu'on ne veut pas maintenir à la main. Les deux peuvent coexister, mais il faut choisir consciemment ce qui va dans le fichier versionné et ce qui va dans le magasin local, sinon la même information vivra à deux endroits avec deux versions.

Coût de maintenance et licence

Le rythme de publication est élevé : v1.1.2 le 4 septembre 2026, v1.1.3 le 8, v1.1.4 le 9. Trois correctifs en une semaine sur une version mineure, cela veut dire des mises à jour fréquentes à suivre, et un redémarrage des services systemd --user à chaque fois. Sur une machine de développement, ce n'est pas gratuit en attention. La licence MIT est permissive : usage commercial, modification et redistribution sont autorisés, avec conservation du texte de licence et de la mention de copyright. Elle n'impose aucune obligation de publication des modifications. Rien dans le matériel fourni ne mentionne de clause additionnelle, de marque déposée ni de conditions propres au service hébergé memmy.bot, qui relève d'un autre cadre que le code du dépôt. Pour un usage en entreprise, la question à trancher n'est pas la licence du code mais la politique interne sur l'envoi de contexte de projet à un service tiers pendant la phase d'essai.

Conclusion éditoriale

Memmy convient à qui fait tourner plusieurs agents de codage en parallèle et perd du temps à répéter le même contexte de projet. Il ne convient pas à qui refuse une inscription, un service systemd --user permanent ou une dépendance à un service local sur le port 18960. À vérifier avant de vous engager : la commande memmy-memory init sur un seul agent, le contenu réel de ~/.memmy/config.yaml après memmy onboard --defaults, et le comportement de memmy-memory search sur vos propres requêtes.

Sources officielles

1. License: MIT
2. MemTensor/memmy-agent on GitHub
3. Project website
4. README
5. Releases