Claude ne se souvient de rien. À chaque session, on repart de zéro — les préférences
expliquées la semaine dernière, les contraintes métier découvertes en travaillant sur le
code, les corrections demandées deux fois. Tout disparaît avec /clear.
Le CLAUDE.md compense en partie : on y encode les conventions du projet, la stack, les règles de déploiement. Mais il y a une catégorie d'information que le CLAUDE.md gère mal : ce qui évolue au fil du temps. Une décision d'architecture prise ce mois-ci, une préférence de style corrigée en cours de session, un gotcha découvert en production. Ces informations ont une durée de vie variable et n'ont pas toutes leur place dans un fichier versionné avec le projet.
Claude Code a un système de mémoire persistante pour ça.
Ce que la mémoire auto fait — et ne fait pas
La mémoire auto est un ensemble de fichiers Markdown dans un répertoire dédié par projet
(~/.claude/projects/<projet>/memory/) ou global
(~/.claude/memory/). Claude les lit au démarrage de chaque session via
un fichier index MEMORY.md, et peut les mettre à jour en cours de session.
Ce que ça ne fait pas : ce n'est pas un journal de session automatique. Claude ne note pas tout ce qui s'est passé. C'est un outil actif — il faut lui dire explicitement ce qui mérite d'être retenu, ou lui demander de faire l'audit lui-même.
La distinction avec le CLAUDE.md est importante. Le CLAUDE.md décrit le projet : stack, conventions, déploiement. La mémoire décrit la relation de travail : préférences, décisions en cours, contraintes non évidentes à un instant T.
Les 4 types de mémoire
Chaque fichier mémoire a un type déclaré dans son frontmatter. Ce n'est pas cosmétique — ça définit quand Claude va les utiliser.
- user — qui est la personne avec qui on travaille : rôle, niveau technique, domaines de connaissance. Permet d'ajuster le niveau d'explication sans avoir à se présenter à chaque session.
- feedback — comment aborder le travail : ce qui a été corrigé, ce qui a été validé. "Ne pas résumer ce qu'on vient de faire en fin de message" est un feedback. "Toujours utiliser une vraie base de données dans les tests, pas de mocks" aussi.
- project — l'état en cours du projet : décisions actives, initiatives, contraintes temporelles. Ces mémoires vieillissent vite — elles méritent une revue régulière.
- reference — où trouver l'information dans des systèmes externes : "les bugs pipeline sont dans Linear project INGEST", "le board Grafana pour la latence est à grafana.internal/d/api-latency".
Ce qui mérite d'y aller — et ce qui n'en vaut pas la peine
La mémoire n'est pas une archive. Ce qui va dans un fichier mémoire doit être non déductible du code ou du CLAUDE.md, et utile dans les prochaines sessions.
Ça mérite d'être retenu :
- Une préférence de style confirmée ou corrigée pendant la session ("pas de résumé en fin de réponse", "toujours passer par la fonction X pour modifier Y")
- Un gotcha découvert en travaillant — une contrainte invisible dans le code, un comportement contre-intuitif
- Une décision d'architecture en cours qui n'est pas encore dans le code
- Un pointeur vers une ressource externe qu'on utilise régulièrement
Ça n'a pas sa place dans la mémoire :
- Ce qui est visible dans les fichiers — Claude le retrouvera en lisant le code
- Le détail des sessions passées — le git log est plus fiable pour ça
- Les tâches en cours — elles appartiennent à la session, pas à la mémoire persistante
- Les conventions déjà dans le CLAUDE.md — duplication inutile
Mémoire projet vs mémoire globale
La mémoire projet (~/.claude/projects/<cwd-sanitisé>/memory/) est isolée
par répertoire de travail. Ouvrir Claude depuis un autre dossier, c'est une autre mémoire.
C'est la bonne option pour les préférences et décisions spécifiques à un projet.
La mémoire globale (~/.claude/memory/) s'applique à toutes les sessions,
tous projets confondus. C'est là que vont les préférences vraiment transversales : le style
de réponse attendu, le niveau technique de la personne, les conventions de communication.
Dans la pratique : commencer par la mémoire projet. Si une préférence revient dans tous les projets, la déplacer en global. Éviter de dupliquer les deux.
Alimentation automatique : la règle dans ~/.claude/CLAUDE.md
Plutôt que de demander à Claude de sauvegarder quelque chose à chaque fois qu'on y pense,
on peut lui donner la règle une fois pour toutes dans le CLAUDE.md utilisateur —
~/.claude/CLAUDE.md, chargé dans toutes les sessions, tous projets confondus.
# Règles globales
## Mémoire automatique
Dès qu'une session révèle une information persistante, la sauvegarder
immédiatement dans le bon fichier mémoire sans attendre que l'utilisateur
le demande :
- Préférence découverte ou corrigée → memory/user ou memory/feedback
- Correction d'approche → memory/feedback
- Décision projet durable → memory/project
- Pointeur vers ressource externe → memory/reference
Ne pas sauvegarder : état temporaire, travail en cours, ce qui est déjà
dans CLAUDE.md, ce qui est déductible du code.Le filtre est aussi important que le déclencheur. Sans lui, Claude va noter chaque détail de session et la mémoire grossit aussi vite que le CLAUDE.md qu'on venait de nettoyer.
Maintenir la mémoire : le prompt d'audit
La mémoire vieillit. Les mémoires de type project en particulier — une décision prise en janvier peut être résolue en mars, mais le fichier reste. Sans revue régulière, on accumule des informations obsolètes que Claude va lire et potentiellement appliquer à tort.
Un prompt d'audit à lancer en début de session quand la mémoire a dérivé :
Audite les fichiers mémoire dans `.claude/projects/.../memory/`.
Pour chaque fichier :
1. Le contenu est-il encore exact ? (vérifier contre l'état actuel des fichiers si nécessaire)
2. Est-il non déductible du code ou du CLAUDE.md ?
3. Le type est-il correct ? (user / feedback / project / reference)
4. La description dans le frontmatter est-elle assez précise ?
Cohérence globale : doublons, contradictions, mémoires project obsolètes, MEMORY.md à jour ?
Résultat en tableau : Fichier | Problème | Action recommandée
Puis applique les corrections.
Pour ne pas avoir à retrouver ce prompt, le sauvegarder comme commande slash dans
.claude/commands/audit-memory.md (projet) ou
~/.claude/commands/audit-memory.md (global). Ensuite /audit-memory
suffit.
Conclusion
La mémoire auto répond à un problème précis : l'information qui évolue trop vite pour le CLAUDE.md, mais qui mérite de traverser les sessions. Elle fonctionne bien quand on est sélectif — un fichier par sujet, un type bien choisi, une description précise dans le frontmatter.
Ce qui casse le système : vouloir tout y mettre. Une mémoire qui grossit sans critère finit par être aussi peu utile qu'un CLAUDE.md de 300 lignes — Claude charge tout, traite tout, et le signal se noie dans le bruit.