← Contextes /
memoire-auto-claude-code.md 176 lignes · 6.6 KB
Personnaliser Télécharger
# CLAUDE.md — Mémoire persistante Claude Code

> Contexte spécialisé pour Claude Code. À utiliser pour gérer, alimenter et auditer la mémoire persistante d'un projet — ce qui traverse les sessions sans aller dans le CLAUDE.md.

---

## Quand utiliser ce contexte

- ✅ Début de projet : initialiser la mémoire avec ce qu'on sait déjà
- ✅ Après une longue session productive : capturer ce qui vaut la peine de traverser les sessions
- ✅ Mémoire qui a dérivé : audit et nettoyage
- ✅ Onboarding sur un projet existant : comprendre ce qui est déjà mémorisé
- ❌ Conserver le détail des sessions passées — le git log est plus fiable
- ❌ Dupliquer ce qui est déjà dans le CLAUDE.md

---

## Section 1 : Les 4 types de mémoire

### user — qui est la personne

Informations sur le rôle, le niveau technique, les domaines de connaissance. Permet d'ajuster le niveau d'explication sans re-présentation à chaque session.

Exemples :
- "Dev senior Go, découvre React pour ce projet — expliquer le frontend en analogies backend"
- "Data scientist, première fois sur ce codebase — pas besoin d'expliquer les bases de Python"

### feedback — comment aborder le travail

Guidance sur l'approche : ce qui a été corrigé, ce qui a été validé. S'applique aux sessions futures.

Structure : règle → **Why:** (raison donnée) → **How to apply:** (quand ça s'applique)

Exemples :
- "Ne pas résumer ce qu'on vient de faire en fin de message — l'utilisateur lit le diff"
- "Tests d'intégration sur vraie base de données, pas de mocks — incident en prod causé par divergence mock/réel"

### project — l'état en cours

Décisions actives, initiatives, contraintes temporelles. Vieillissent vite — à revoir régulièrement.

Structure : fait/décision → **Why:** (motivation) → **How to apply:** (comment ça influence les suggestions)

Exemples :
- "Freeze de merge à partir du 2026-03-05 — release mobile en cours"
- "Réécriture du middleware auth motivée par compliance légale, pas par dette technique"

### reference — où trouver l'information

Pointeurs vers des ressources externes utilisées régulièrement.

Exemples :
- "Bugs pipeline dans Linear project INGEST"
- "Board Grafana latency : grafana.internal/d/api-latency — surveiller si on touche les request handlers"

---

## Section 2 : Critères de tri

### Ce qui mérite d'être retenu

```
✅ Non déductible du code ou du CLAUDE.md
✅ Utile dans les prochaines sessions (pas juste aujourd'hui)
✅ Gotcha réel — contrainte invisible, comportement contre-intuitif
✅ Préférence confirmée ou corrigée en session
✅ Décision d'architecture pas encore dans le code
✅ Pointeur vers ressource externe régulièrement utile
```

### Ce qui n'a pas sa place

```
❌ Visible dans les fichiers — Claude le retrouvera en lisant
❌ Détail des sessions passées — git log est plus fiable
❌ Tâches en cours — appartiennent à la session, pas à la mémoire
❌ Convention déjà dans le CLAUDE.md — duplication inutile
❌ Cas limite qui ne se reproduira pas
```

### Le test en une question

> "Si je supprime ce fichier mémoire et que Claude relit le code, manquera-t-il quelque chose d'important ?"

Si non → la mémoire est inutile. Si oui → elle a sa place.

---

## Section 3 : Prompt d'audit

À lancer quand la mémoire a dérivé ou après une longue période sans révision.

```text
Audite les fichiers mémoire dans `.claude/projects/.../memory/`
(et `~/.claude/memory/` pour la mémoire globale si elle existe).

Pour chaque fichier mémoire :
1. Le contenu est-il encore exact ? (vérifier contre l'état actuel des fichiers/code 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 pour décider
   de la pertinence sans lire le corps ?

Cohérence globale :
- Doublons ou contradictions entre fichiers ?
- Mémoires "project" obsolètes (décisions résolues, états dépassés) ?
- MEMORY.md à jour avec tous les fichiers présents ?

Résultat en tableau : Fichier | Problème détecté | Action recommandée
Puis applique les corrections validées.
```

---

## Section 4 : Slash command /audit-memory

Pour ne pas avoir à retrouver le prompt d'audit, le sauvegarder comme commande slash.

**Mémoire projet uniquement :**
Créer `.claude/commands/audit-memory.md` à la racine du projet.

**Toutes sessions, tous projets :**
Créer `~/.claude/commands/audit-memory.md`.

Contenu du fichier :

```text
Audite les fichiers mémoire dans `.claude/projects/.../memory/`
(et `~/.claude/memory/` pour la mémoire globale si elle existe).

Pour chaque fichier mémoire :
1. Le contenu est-il encore exact ? (vérifier contre l'état actuel des fichiers/code 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.
```

Ensuite `/audit-memory` suffit pour lancer l'audit depuis n'importe quelle session.

---

## Section 5 : Mémoire projet vs mémoire globale

| | Mémoire projet | Mémoire globale |
|---|---|---|
| **Chemin** | `~/.claude/projects/<cwd>/memory/` | `~/.claude/memory/` |
| **Scope** | Un seul répertoire de travail | Toutes sessions, tous projets |
| **Types adaptés** | feedback projet, project, reference | user, feedback transversal |
| **Priorité** | Chargée après la globale | Chargée en premier |

**Règle pratique :** commencer en mémoire projet. Déplacer en global seulement si une préférence revient sur tous les projets. Ne jamais dupliquer les deux.

---

## Section 6 : Checklist d'initialisation

```
□ MEMORY.md créé (index des fichiers mémoire)
□ Au moins un fichier "user" — qui est la personne, niveau technique
□ Fichiers "feedback" pour les préférences déjà connues
□ Fichiers "project" pour les décisions actives (avec date absolue si deadline)
□ Fichiers "reference" pour les ressources externes régulières
□ Chaque fichier a un frontmatter complet (name, description, type)
□ La description de chaque fichier permet de juger la pertinence sans lire le corps
□ /audit-memory configuré (project ou global selon usage)
```

---

*Last updated: 2026-03 — Contexte associé à l'article [Mémoire persistante dans Claude Code](https://www.web-developpeur.com/blog/memoire-auto-claude-code).*