Ce chapitre t'apprend à sauvegarder le contexte entre les sessions pour que Claude ne reparte jamais de zéro. C'est ce qui fait la différence entre un assistant qui oublie tout et un vrai partenaire de développement. Temps de lecture : 7 minutes.
Le problème
Chaque nouvelle conversation avec Claude Code repart de zéro. Il relit le CLAUDE.md (les conventions générales), mais il ne sait pas :
- Quelles décisions architecturales tu as prises hier
- Quels bugs tu as rencontrés et comment tu les as résolus
- Quels patterns fonctionnent bien dans ton projet spécifique
- Où tu en es dans ton roadmap
- Quels choix ont été écartés et pourquoi
Résultat concret : Claude peut refaire les mêmes erreurs, proposer des approches contradictoires avec les sessions précédentes, et perdre du temps à redécouvrir le contexte.
La solution : le fichier MEMORY.md
Claude Code peut maintenir un fichier de mémoire persistante qui survit entre les sessions. C'est différent du CLAUDE.md :
CLAUDE.md | MEMORY.md |
|---|---|
| Conventions générales et permanentes | Apprentissages spécifiques qui évoluent |
| "On utilise Supabase pour la BDD" | "Le bug de redirect() dans try/catch a été résolu le 28/02" |
| Change rarement | Mis à jour à chaque session productive |
| Tu le crées au début du projet | Claude le met à jour progressivement |
Comment ça fonctionne
Mémoire automatique (par défaut)
Claude Code gère désormais un système d'auto-memory natif. Il maintient automatiquement un fichier MEMORY.md dans ~/.claude/projects/ (pas à la racine du projet). Claude le met à jour de lui-même quand il juge pertinent de sauvegarder un apprentissage.
Tu n'as rien à configurer, c'est actif dès la première session.
Mise à jour manuelle
Tu peux aussi déclencher une mise à jour explicite en fin de session :
"Mets à jour la mémoire projet avec les décisions et apprentissages de cette session."
Claude ajoute les informations nouvelles sans dupliquer l'existant.
En pratique : Claude sauvegarde automatiquement les patterns confirmés, les erreurs résolues et les décisions importantes. Tu peux lui demander "mets à jour la mémoire" pour forcer une sauvegarde, mais il le fait aussi spontanément.
Ce que contient le MEMORY.md
1. Patterns confirmés
Les patterns techniques qui fonctionnent bien et doivent être réutilisés :
## Patterns confirmés
- Server Actions avec validation Zod : pattern standard pour toutes les mutations
- Formulaires : react-hook-form + zodResolver + composants shadcn/ui
- Streaming IA : useChat + api route POST avec sdk.messages.stream()
- Rate limiting : vérifier rateLimit() avant chaque appel IA
2. Décisions architecturales
Les choix faits et leur justification (pour ne pas les remettre en question) :
## Décisions
- Streak hebdomadaire (pas quotidien) : les freelances n'ont pas le temps de publier chaque jour
- Scoring sur 4 axes (pas 5) : réduit la complexité UX sans perdre de précision
- Pas de push notifications : trop coûteux à maintenir pour la taille du projet
3. Erreurs courantes et solutions
Les bugs rencontrés et leurs corrections (pour ne pas les refaire) :
## Erreurs résolues
- redirect() dans try/catch → Next.js throw un NEXT_REDIRECT, il faut le catch spécifiquement
- supabase db reset détruit toutes les données → toujours utiliser migration up
- cookies() doit être appelé avec await en Next.js 15+
4. État d'avancement
Où en est le projet et quelles sont les prochaines priorités :
## Avancement
- Authentification : ✅ terminé
- Dashboard : ✅ terminé
- Génération contenu : ✅ terminé
- Paiement Stripe : 🟡 en cours
- Analytics : ⏳ à faire
L'impact concret
Sans mémoire, chaque session : - Claude repart de zéro et perd 5-10 minutes à redécouvrir le contexte - Il peut proposer un streak quotidien alors que tu as décidé hebdomadaire hier - Il refait le même bug que tu as déjà corrigé (redirect dans try/catch) - Il ne sait pas quelles features sont terminées et lesquelles restent à faire
Avec mémoire, chaque session : - Claude sait exactement où tu en es : "Je vois que le paiement Stripe est en cours. On continue ?" - Il réutilise les patterns confirmés sans que tu aies à les re-spécifier - Il évite les erreurs déjà rencontrées proactivement - Il reste cohérent avec les décisions passées
Bonnes pratiques
Quand mettre à jour
- Après chaque session productive (2+ features livrées)
- Après un bug difficile résolu (pour ne pas le refaire)
- Après une décision architecturale importante (pour la justifier)
- Pas besoin si la session était juste un petit fix ou un ajustement cosmétique
Ce qu'il ne faut PAS mettre
- Détails de session temporaires ("aujourd'hui j'ai fixé un bug dans...") trop volatile
- Code ou extraits de fichiers, le code change, la mémoire doit rester stable
- Opinions non vérifiées, attends d'avoir confirmé un pattern sur 2-3 usages avant de l'écrire
Taille idéale et pattern "index"
Le MEMORY.md doit rester sous 200 lignes (au-delà, Claude tronque). L'idéal : 20-30 lignes en mode "index".
Le pattern index : au lieu de mettre tout le détail dans le MEMORY.md, tu le transformes en sommaire qui pointe vers des fichiers dédiés par projet :
memory/
├── MEMORY.md ← Index (~25 lignes)
├── mon-saas.md ← Détails projet SaaS
├── poc-client.md ← Détails POC client
└── side-project.md ← Détails side project
Le MEMORY.md devient un simple annuaire :
# Projets actifs
## Mon SaaS
- Path: /Users/moi/code/mon-saas
- Port: 3000
- Status: Phase 2 en cours
- Détails: voir mon-saas.md
## POC Client
- Path: /Users/moi/code/poc-client
- Port: 3001
- Status: Livré
- Détails: voir poc-client.md
Claude charge l'index à chaque session (léger, rapide) et ne lit les fichiers de détail que quand il en a besoin. C'est la même logique que .claude/rules/ pour le CLAUDE.md.
À retenir : "Mets à jour la mémoire projet" est la phrase à dire en fin de chaque session productive. 30 secondes qui garantissent que demain, Claude reprend exactement là où il s'est arrêté.