Claude a refait aujourd'hui une erreur que tu lui avais corrigée la semaine
dernière ? Voilà comment marche sa mémoire entre deux sessions, où elle est
rangée, comment la corriger, et ce qui va plutôt dans CLAUDE.md.
Le problème
Chaque nouvelle conversation avec Claude Code repart de zéro. Il relit le CLAUDE.md (tes conventions), mais sans mémoire il ne sait pas :
- Quelles décisions tu as prises hier et pourquoi
- Quelles corrections tu lui as déjà faites ("non, pas comme ça")
- Qui tu es, comment tu aimes bosser
- Où tu en es dans ta roadmap
Résultat : il te ressort une approche que tu as écartée la semaine dernière, ou refait l'erreur que tu viens de corriger.
Comment marche l'auto memory
Des notes que Claude écrit lui-même, pour lui-même, pendant que tu travailles : une correction que tu lui as faite, une décision, une info sur toi. Elles sont rangées hors de ton repo, une note par fichier, avec un sommaire relu au début de chaque session. Active par défaut en local, rien à configurer.
Claude ne note pas tout. Il saute ce qu'il peut retrouver en lisant le code ou l'historique git (l'architecture, les chemins de fichiers, le détail d'un fix), et ce que ton CLAUDE.md dit déjà. Il ne sauvegarde pas non plus à chaque session : seulement ce qui lui semble utile pour une prochaine conversation. Quand il le fait, tu vois passer "Saved 2 memories" ou "Recalled 2 memories".
Où c'est rangé
Pas dans ton projet. Dans ton dossier perso :
~/.claude/projects/<ton-projet>/memory/
├── MEMORY.md ← l'index, chargé à chaque session
├── feedback-pas-de-push-sans-accord.md
├── project-streak-hebdomadaire.md
└── reference-dashboard-supabase.md
Un dossier par repo git : tous les worktrees et sous-dossiers du même repo partagent la même mémoire. Elle reste sur ta machine, elle ne suit pas sur un autre ordi ni dans le cloud.
Deux niveaux :
MEMORY.mdest un sommaire : une ligne par souvenir, avec un lien vers son fichier. Claude Code le charge au début de chaque session, dans la limite des 200 premières lignes ou des 25 KB.- Un fichier par souvenir, avec un frontmatter (le bloc entre
---en haut du fichier). Claude ne l'ouvre que quand le sujet revient.
Voici le format que je retrouve dans mes propres fichiers :
---
name: feedback-pas-de-push-sans-accord
description: Ne jamais pousser sur main sans accord explicite
metadata:
type: feedback
modified: 2026-09-12T16:19:02.230Z
---
Correction du 12 septembre : Claude a poussé un fix directement sur main.
Règle : toujours demander avant un git push, même pour un fix d'une ligne.
La doc officielle ne fige pas tout ce format. Elle garantit deux choses : le type du souvenir est noté dans un champ type du frontmatter, et Claude Code ajoute un horodatage modified à chaque écriture (depuis la v2.1.214), pour que Claude sache si l'info est fraîche.
Et la ligne correspondante dans MEMORY.md :
- [Pas de push sans accord](feedback-pas-de-push-sans-accord.md) : toujours demander avant git push
Les 4 types de souvenirs
| Type | Ce qu'il contient | Exemple |
|---|---|---|
user | Qui tu es, ton niveau, tes préférences | "Solo founder, préfère des réponses courtes, stack Next.js" |
feedback | Les corrections que tu as faites, et les approches que tu valides | "Ne jamais mettre redirect() dans un try/catch" |
project | Les décisions et l'état d'un projet, ce que le code ne dit pas | "Streak hebdomadaire, pas quotidien : les freelances ne publient pas tous les jours" |
reference | Où trouver quoi hors du projet (dashboards, tickets) | "Les logs prod sont dans le dashboard Vercel du projet X" |
Piloter la mémoire
Demander une mise à jour
Claude sauvegarde de lui-même, mais tu peux forcer en fin de session :
"Mets à jour la mémoire projet avec les décisions et apprentissages de cette session."
Même logique au moment où tu corriges Claude : "Retiens ça pour la suite" suffit, il le range dans l'auto memory. Relis ce qu'il a écrit, surtout les premières semaines.
Relire et corriger avec /memory
/memory liste tes CLAUDE.md, active ou coupe l'auto memory, et ouvre le dossier de mémoire dans ton éditeur. À faire de temps en temps : un souvenir faux ou périmé est pire que pas de souvenir, parce que Claude va l'appliquer avec assurance.
Tu peux aussi ouvrir le dossier ~/.claude/projects/<ton-projet>/memory/ directement. Ce sont des fichiers markdown normaux, à éditer ou supprimer comme tu veux.
Couper la mémoire
L'interrupteur dans /memory enregistre le réglage autoMemoryEnabled dans ~/.claude/settings.json. Pour un seul projet, mets "autoMemoryEnabled": false dans les settings du projet. La variable d'environnement CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 la coupe aussi. Utile pour une démo ou un projet client où tu ne veux rien garder.
Mémoire, CLAUDE.md ou rules ?
Trois endroits où Claude trouve des consignes. Ils n'ont pas le même rôle.
| Où | Qui l'écrit | Ce qu'on y met | Chargé quand |
|---|---|---|---|
CLAUDE.md | Toi (ou Claude à ta demande) | Conventions stables : stack, structure, règles d'équipe | À chaque session |
.claude/rules/*.md | Toi | Règles d'un domaine précis, avec paths: pour cibler des dossiers | À chaque session, ou seulement sur les fichiers visés par paths: |
| Auto memory | Claude, surtout | Ce qui a été appris en route : corrections, décisions, état | L'index à chaque session, le détail à la demande |
Le test : une règle stable, valable pour toute l'équipe, va dans CLAUDE.md. Si elle ne concerne que les migrations SQL, fais-en une rule. Ce que Claude apprend en route reste en mémoire.
Une règle importante qui traîne dans la mémoire depuis des semaines mérite de remonter dans CLAUDE.md. Demande-le simplement à Claude : "Ajoute cette règle au CLAUDE.md du projet." Le fichier mémoire, lui, est perso et non versionné : tes collègues n'en profitent pas.
Les subagents ne chargent pas la mémoire de ta conversation principale. Seul un fork (une copie de ta conversation) en hérite.
Pas de CLAUDE.md mais un AGENTS.md ? Depuis la v2.1.277 (18 septembre
2026), Claude Code lit le fichier AGENTS.md (le format partagé par d'autres
outils de code IA) quand le projet n'a pas de CLAUDE.md. Voir le chapitre
3.
Ce qu'il ne faut pas mettre
- Les détails de session éphémères ("aujourd'hui j'ai fixé un bug dans...")
- Du code ou des extraits de fichiers : le code change, la mémoire doit rester stable
- Une opinion pas encore vérifiée. Attends d'avoir confirmé un pattern sur 2 ou 3 usages
- Jamais de secrets (clés API, mots de passe), la mémoire est un fichier texte en clair
Ce que ça coûte
MEMORY.md fait partie du contexte projet que Claude Code envoie avec chaque message, juste après le prompt système et à côté de CLAUDE.md. Grâce au cache, ce bloc est relu pour presque rien tant que tu ne fais pas de pause trop longue. Mais il est relu à chaque tour, et il occupe de la place dans ton contexte.
D'où la règle : un index court. Une ligne par souvenir, 20 à 50 lignes au total, le détail dans les fichiers. Au-delà de 200 lignes ou 25 KB, la fin n'est pas chargée. Claude Code prévient d'ailleurs Claude quand l'index approche de la limite, pour qu'il le raccourcisse. Fais le ménage avec /memory.
Le chapitre 19 détaille comment le contexte et le cache se traduisent sur ta facture.
Question
Ton MEMORY.md fait 320 lignes (moins de 25 KB). Que charge Claude Code au début d'une session ?
Choisis une réponse pour voir l'explication.
À retenir
- L'auto memory tourne par défaut, dans
~/.claude/projects/<ton-projet>/memory/, sans quitter ta machine. Tes collègues ne la voient pas : une règle d'équipe va dansCLAUDE.md. MEMORY.mdn'est qu'un index. Au-delà de 200 lignes ou 25 KB, la fin saute, alors vise 20 à 50 lignes.- En fin de session productive : "Mets à jour la mémoire projet". Et
/memoryde temps en temps pour relire et corriger.