claude-mem, la mémoire d'agent qui survit à la fermeture du terminal

Un assistant de code démarre chaque session de zéro. Il ne se souvient pas pourquoi tu as rejeté une approche hier, comment s'appelle la convention interne de ce dépôt, ni ce que tu as cherché pendant une heure. claude-mem enregistre le travail effectué, le compresse avec un modèle, et te restitue les parties pertinentes au lancement suivant.

Le problème que ça résout

Le contexte de la conversation avec un agent disparaît à la fermeture de la session. En pratique, ça se traduit par trois choses qui coûtent du temps chaque jour.

Tu répètes les présentations. Chaque matin, tu expliques à nouveau que le projet utilise un gestionnaire de paquets précis, que les tests se lancent avec une seule commande, et que les paiements vivent dans un service séparé.

Tu répètes les erreurs. L'agent propose une approche que tu as abandonnée hier après une demi-heure de tentatives, parce qu'aucune trace de cette décision n'a survécu.

Tu perds des conclusions. Les enseignements d'une longue session de débogage restent dans la fenêtre du terminal et disparaissent avec elle, même s'ils étaient le résultat le plus précieux de ce travail.

Un fichier d'instructions de projet résout une partie du premier problème, puisqu'il décrit un état durable. Il ne résout aucun des deux autres, parce que personne n'y ajoute les conclusions après chaque session.

Comment ça fonctionne

Le mécanisme comporte trois étapes, et ça vaut la peine de les comprendre, car elles déterminent si l'outil aide ou s'il gêne.

L'enregistrement de session couvre ce que l'agent a fait : fichiers lus, commandes exécutées, changements appliqués, décisions prises. L'enregistrement brut est trop volumineux pour être réinjecté en entier.

La compression par modèle transforme cet enregistrement en notes concises. C'est l'étape charnière, puisqu'elle décide ce qui survit. Le résultat n'est pas une transcription, mais un ensemble d'affirmations qui valent la peine d'être retenues.

L'injection de contexte fournit, au démarrage de la session suivante, les notes qui semblent liées au travail en cours. L'agent démarre donc à partir d'un état de connaissance plutôt que d'une page blanche.

La compression a une conséquence supplémentaire qu'on oublie facilement : c'est un modèle qui décide ce qui compte. L'enregistrement de la session passe par le jugement de quelqu'un d'autre, pas par un filtre que tu as toi-même réglé. En pratique, ça veut dire que certaines choses évidentes pour toi peuvent ne pas survivre, alors que des détails sans importance, eux, survivront. Il vaut donc mieux lire les notes de temps en temps plutôt que de supposer qu'elles reflètent fidèlement le travail effectué.

C'est cette dernière étape qui déterminera le ressenti global de l'outil. Un filtrage trop large encombre le contexte de notes inutiles et augmente le coût de chaque appel. Un filtrage trop étroit donne l'impression que l'outil ne fonctionne pas du tout.

Installation

Le plugin s'installe depuis l'intérieur d'une session, via le catalogue d'extensions intégré.

/plugin marketplace add thedotmack/claude-mem
/plugin install claude-mem

Après un redémarrage, le contexte des sessions précédentes apparaît automatiquement. Tu ne lances rien à la main, mais il est utile de savoir que le plugin maintient en arrière-plan un service de travail local tournant sur Bun. Ce service traite l'enregistrement de session et expose une API locale ainsi qu'un aperçu des notes dans le navigateur ; quand l'outil se comporte bizarrement, c'est par l'état de ce service que commence le diagnostic. Les notes elles-mêmes atterrissent dans une base SQLite sous ~/.claude-mem.

Le projet se développe sur trois branches : stable, développement et communautaire. Seule la branche stable arrive sur le registre de paquets, donc les deux autres se lancent depuis les sources. Avec un outil de ce genre, rester sur la branche stable est prudent, car la mémoire d'un agent tombe en panne de façons difficiles à repérer.

Mets à jour le plugin de façon délibérée plutôt qu'automatique. Un changement dans la couche de compression peut modifier ce qui arrive jusqu'aux notes, et tu n'en verras l'effet que plusieurs sessions plus tard.

/plugin list
/plugin update claude-mem

Copie le dossier des notes avant une mise à jour. Les reconstruire à partir de l'historique des sessions n'est pas possible, donc le fichier sur le disque est tout ce que tu as.

L'outil n'est pas lié à un seul assistant. Il prend en charge plusieurs environnements d'agents, donc les notes récoltées dans l'un sont disponibles dans l'autre, à condition de travailler sur le même projet.

Comment ça change le travail quotidien

La plus grande différence apparaît sur un travail étalé sur plusieurs jours. Une session après un week-end démarre par un rappel de là où les choses en étaient, plutôt que par une reconstruction de l'état à partir de l'historique git.

La deuxième différence concerne les décisions négatives. Savoir ce qu'il ne faut pas faire, et pourquoi, vaut généralement plus qu'une description de la solution, parce que la solution est visible dans le code alors que les variantes rejetées ne laissent aucune trace. Une note indiquant qu'une bibliothèque n'a pas fonctionné avec ta version du runtime économise une demi-journée à la tentative suivante.

La troisième concerne la transmission du travail. Une personne qui rejoint le projet reçoit, avec le dépôt, un ensemble de notes des sessions précédentes, ce qui est souvent plus lisible que les messages de commit.

Fixe tes attentes correctement. Ça ne remplace ni la documentation ni un fichier de conventions du projet. C'est une couche complémentaire qui recueille ce qui se passe de toute façon pendant le travail, et que personne ne note à la main.

Confidentialité et sécurité

L'outil enregistre l'activité de la session, donc tu dois savoir exactement ce qui atterrit dans les notes et où ces notes vivent.

Par défaut, les données restent locales, tandis que les versions récentes ajoutent une synchronisation avec le service cloud de l'éditeur. C'est précisément le moment de s'arrêter : avec un dépôt client ou des données couvertes par un accord de confidentialité, synchroniser hors de ta propre machine mérite une décision délibérée, pas un réglage par défaut.

La deuxième chose concerne les secrets. Une session où l'agent a lu un fichier de variables d'environnement peut laisser ce fragment dans les notes. Avant de déployer l'outil dans une équipe, vérifie ce qui entre dans l'enregistrement et exclus les dossiers de configuration. L'outil offre ici une échappatoire explicite : le contenu entouré d'une balise <private> reste visible pour le modèle dans la session en cours, mais n'est jamais stocké comme observation. C'est la façon la plus simple de coller un extrait de logs de production sans le laisser en mémoire pour de bon.

sqlite3 ~/.claude-mem/claude-mem.db .dump 2>/dev/null \
  | grep -nE "(sk|pk)_(live|test)_[A-Za-z0-9]{10,}|PRIVATE KEY|AKIA[0-9A-Z]{16}" | head

Lance cette commande une fois après une semaine d'utilisation, avant que quiconque active la synchronisation. Si quelque chose apparaît, c'est la clé elle-même qu'il faut faire tourner, pas seulement les notes qu'il faut nettoyer : une valeur qui est entrée une fois dans l'enregistrement a peut-être déjà voyagé plus loin.

Vérifie séparément ce qui se passe à la suppression. Si les notes se synchronisent, les supprimer localement ne signifie pas forcément que la copie de l'autre côté a disparu, et face à une demande de suppression de données personnelles, cette différence est juridique, pas technique.

Le troisième point est le rangement. Les notes s'accumulent, et les anciennes peuvent induire en erreur, puisqu'elles décrivent le code tel qu'il était avant un refactor. Une révision trimestrielle qui supprime les entrées obsolètes est une tâche peu coûteuse qui maintient la qualité des suggestions.

Qu'est-ce qui vaut la peine d'être retenu, et qu'est-ce qui est du bruit

La qualité de cet outil se résume à la qualité de ses notes, et celles-ci dépendent de ce qui se passe dans une session, tout simplement. Quelques habitudes améliorent nettement le résultat.

Nomme les décisions explicitement. Une conclusion atteinte silencieusement au fil d'une série de commandes ne survit pas à la compression, parce qu'il n'y a rien à résumer.

Faible : passer la file d'attente à une table en base

Mieux : on garde une file d'attente en base plutôt qu'un broker, car à
        cent tâches par jour un broker est un service de plus à
        maintenir sans gain réel. On revient sur ce choix une fois les
        mille tâches par jour dépassées.

La seconde version porte la raison et la condition pour revenir sur la décision, donc un mois plus tard la note veut encore dire quelque chose. La première laisse un fait sans contexte, et c'est exactement le genre d'entrée qui trompe dans une session ultérieure.

Clos les sessions avec un résumé. Deux phrases sur ce qui a été fait et ce qui vient ensuite donnent au modèle une matière à enregistrer. Une session coupée en plein milieu laisse des notes décrivant un état transitoire qui trompe au lancement suivant.

Garde les projets séparés. Travailler sur deux dépôts dans une même session mélange les contextes, et les notes injectées plus tard concernent en partie le mauvais projet.

Ne compte pas sur l'outil pour se souvenir de ce que le code montre déjà. La structure des dossiers, les noms de fonctions et les dépendances sont visibles par l'agent sans aucune mémoire. Ce qui a de la valeur, c'est ce que le code ne montre pas : les raisons, les variantes rejetées, les contraintes externes.

Il est aussi utile de savoir que les compétences d'agent, décrites dans agent-skills, couvrent une partie de ce rôle. Une compétence contient les instructions pour traiter un type de tâche, la mémoire contient l'historique d'un projet précis. Ensemble, elles couvrent deux manques différents et ne se remplacent pas l'une l'autre.

Déployer ça dans une équipe

L'installer pour une personne prend une minute ; le déployer pour dix en demande trois, et il vaut mieux ne pas les reporter.

Le premier concerne le périmètre des données. Décidez si les notes restent locales ou se synchronisent, et si ça s'applique à tous les dépôts ou seulement aux dépôts internes. Sur les projets clients, ça finit généralement par désactiver la synchronisation pour certains dossiers choisis.

Le deuxième concerne le partage. Les notes d'une personne peuvent avoir de la valeur pour le reste de l'équipe, mais elles portent aussi sa façon de travailler et ses impasses. Un point de départ raisonnable est une mémoire individuelle, où les conclusions qui valent la peine d'être partagées sont déplacées délibérément vers un fichier du dépôt.

Le troisième concerne la révision. Choisissez un moment où quelqu'un parcourt les notes et retire celles qui sont obsolètes, par exemple à la clôture d'une étape importante. Sans ça, un trimestre plus tard, la moitié des entrées décrivent du code d'avant un refactor.

Pour des configurations d'agent plus importantes, garder l'ensemble des réglages dans le dépôt est payant, comme on le fait avec les modèles de claude-code-templates. Une personne qui rejoint le projet reçoit alors l'ensemble complet avec le projet, au lieu de configurer un environnement à partir de zéro.

claude-mem face aux alternatives

Ces approches ne s'excluent pas entre elles. Ce qui fonctionne le mieux, c'est un état durable dans un fichier du dépôt, avec la couche automatique qui recueille ce qui émerge pendant le travail.

Quand la mémoire d'agent est vraiment rentable

Toutes les façons de travailler ne profitent pas de cette couche, et l'installer par précaution finit par ajouter un coût sans retour visible.

Un travail continu sur un seul projet pendant des semaines en profite, surtout quand les sessions sont courtes et espacées dans le temps. Là, le coût de reconstruire l'état à chaque démarrage est réel et répété, donc le supprimer se voit immédiatement.

Le travail de débogage en profite aussi. Traquer un défaut qui apparaît une fois tous les quelques jours s'étire sur de nombreuses sessions, et les conclusions de chacune valent plus que le code produit en chemin.

Un travail en forme de tâche isolée n'en profite pas : une correction unique, la génération d'un composant, une migration de fichier ponctuelle. Là, une session commence et se termine dans le même contexte, donc la mémoire n'a rien à transporter.

Alterner entre de nombreux dépôts sans lien n'en profite pas non plus. Des notes d'un projet servies dans un autre sont du bruit qui occupe le contexte et coûte à chaque démarrage.

Un test simple avant de déployer l'outil : compte combien de minutes par jour partent à remettre l'assistant à niveau sur le projet. Si ça représente quelques minutes sur deux sessions, l'outil se rentabilise. Si ça ne représente que quelques secondes, parce que tu travailles dans une seule longue fenêtre, le bénéfice sera difficile à remarquer.

Erreurs courantes

La première est de traiter l'outil comme une documentation. Les notes enregistrent ce qui s'est passé, elles ne décrivent pas comment le système doit se comporter. Garde les conventions et l'architecture dans le dépôt.

La deuxième est d'activer la synchronisation sans vérifier ce qui est synchronisé. Sur un projet client, c'est une décision à prendre ensemble, pas un réglage à accepter en passant.

La troisième est de ne jamais réviser les notes. Après quelques mois, certaines décrivent du code qui n'existe plus, et l'agent les traite comme si elles étaient à jour.

La quatrième est d'installer une branche de développement sur une machine de travail. Un défaut dans la couche de mémoire se manifeste par un comportement bizarre de l'assistant plutôt que par un message d'erreur, donc le diagnostic prend un temps disproportionné.

FAQ

claude-mem est-il gratuit ?

Le code est ouvert et disponible dans le dépôt, et le plugin s'installe sans frais. Le coût arrive indirectement : compresser un enregistrement de session implique des appels à un modèle, donc la facture de ton fournisseur augmente avec le nombre de sessions. La synchronisation optionnelle avec le cloud de l'éditeur peut être facturée séparément.

Les données quittent-elles ma machine ?

Le mode par défaut est local, tandis que les versions plus récentes proposent une synchronisation avec un service cloud. Avant de déployer l'outil sur un projet soumis à une obligation de confidentialité, vérifie quelle option est active et décide en connaissance de cause.

Est-ce que ça remplace un fichier d'instructions de projet ?

Non. Ce fichier décrit un état durable : conventions, commandes, architecture. claude-mem recueille le déroulement du travail et les conclusions des sessions. Les deux couches se complètent, et remplacer l'une par l'autre donne un résultat moins bon que d'utiliser les deux.

Est-ce que ça fonctionne avec d'autres assistants que Claude ?

Oui, l'outil prend en charge plusieurs environnements d'agents, donc les notes récoltées dans l'un apparaissent dans l'autre quand tu travailles sur le même projet. Ça le distingue d'une mémoire intégrée à un outil précis, Cursor par exemple.

Est-ce que ça ralentit une session ?

L'enregistrement et la compression se font en arrière-plan, donc le travail ne s'arrête pas sur cette étape. Ce qui peut se remarquer, c'est la taille du contexte injecté : trop de notes au démarrage allongent la première réponse et augmentent le coût, ce qui explique pourquoi limiter le périmètre au projet en cours est payant.

Le code source et les instructions d'installation se trouvent dans le dépôt GitHub, et le paquet dans le registre npm.