Maîtriser Claude Code de A à Z : CLAUDE.md, mémoire persistante, skills custom, agents parallèles, MCP et hooks — pour transformer Claude en collaborateur de développement sur mesure.
CLAUDE.md configure les règles du projet. La mémoire persistante, c'est différent : c'est ce que Claude apprend sur vous au fil des sessions — vos préférences, vos corrections, le contexte derrière vos choix techniques. Sans mémoire, chaque session repart de zéro. Avec, Claude devient progressivement un collaborateur qui vous connaît.
La mémoire est un ensemble de fichiers Markdown dans un répertoire dédié. Claude les lit au début de chaque session (via MEMORY.md, un index) et les écrit quand il détecte quelque chose à retenir.
~/.claude/projects/[nom-projet]/memory/
├── MEMORY.md ← index — chargé automatiquement
├── user_role.md ← profil utilisateur
├── feedback_commits.md ← préférences sur les commits
├── feedback_tests.md ← comment traiter les tests
└── project_auth.md ← contexte du module authChaque fichier mémoire a un frontmatter structuré et un corps en prose.
Ce que Claude sait sur vous : votre niveau, votre rôle, ce que vous connaissez déjà.
---
name: user-profile
description: Rôle et niveau technique de l'utilisateur
metadata:
type: user
---
Développeur fullstack senior. Expertise Go et PostgreSQL. Nouveau sur le frontend React de ce projet — préfère les analogies backend pour comprendre les concepts React. Travaille en solo, pas d'équipe.Claude adapte ses explications. Il n'explique pas ce qu'est un index en base de données, mais peut vulgariser pourquoi useEffect ressemble à un middleware.
Les corrections que vous avez données et les approches validées.
---
name: feedback-no-summary
description: Ne pas résumer à la fin des réponses
metadata:
type: feedback
---
Ne pas conclure les réponses par un résumé de ce qui vient d'être fait. L'utilisateur préfère des réponses directes sans récapitulatif final.
**Why:** l'utilisateur a dit "stop de résumer, je viens de lire le diff".
**How to apply:** terminer sur l'action ou le résultat, pas sur une phrase de conclusion.---
name: feedback-real-db
description: Toujours utiliser une vraie base en tests
metadata:
type: feedback
---
Ne jamais mocker la base de données dans les tests d'intégration.
**Why:** une migration cassée a passé les tests mockés et planté en production.
**How to apply:** toujours lancer les tests contre une base PostgreSQL réelle, même en CI.Ce qui se passe dans le projet : bugs connus, décisions prises, contraintes temporaires.
---
name: project-auth-rewrite
description: Réécriture du module auth en cours — deadline fin juin
metadata:
type: project
---
Réécriture du module d'authentification obligatoire. L'ancien système stocke les tokens en clair (flag légal/compliance).
**Why:** conformité RGPD imposée par le service juridique.
**How to apply:** toute modification dans `/lib/auth/` doit prioriser la compliance sur l'ergonomie. Ne pas proposer de shortcuts qui contournent le chiffrement.Où trouver les informations importantes hors du projet.
---
name: reference-linear
description: Tickets et bugs trackés dans Linear, projet "WEB"
metadata:
type: reference
---
Tous les bugs et features sont dans Linear, projet "WEB". Quand l'utilisateur mentionne un numéro de ticket (ex: WEB-142), chercher le contexte dans Linear.MEMORY.md est un fichier court qui liste toutes les mémoires avec un résumé d'une ligne. C'est ce que Claude charge en premier.
- [Profil utilisateur](user_profile.md) — dev fullstack senior, expert Go, nouveau React
- [Feedback: pas de résumé](feedback_no_summary.md) — réponses directes sans récapitulatif
- [Feedback: vraie DB en tests](feedback_real_db.md) — jamais mocker la base
- [Projet: réécriture auth](project_auth_rewrite.md) — compliance RGPD, deadline fin juin
- [Référence: Linear](reference_linear.md) — tickets dans projet "WEB"Règle : MEMORY.md ne doit pas dépasser 200 lignes. Au-delà, Claude ne voit pas la suite.
La façon la plus directe :
> souviens-toi que je préfère les tests d'intégration sans mocks
> retiens que les variables d'environnement sont dans Doppler, pas dans .env
> mémorise que le client veut toujours des messages d'erreur en anglais même si le site est en françaisClaude crée le fichier mémoire adapté et met à jour MEMORY.md.
> oublie ce que tu sais sur mes préférences de commit
> supprime la mémoire sur le bug d'authentificationClaude trouve le fichier correspondant et le supprime (ou met à jour MEMORY.md).
> qu'est-ce que tu sais sur moi ?
> liste tes mémoires sur ce projet
> lis ta mémoire sur les testsLa mémoire n'est pas un journal de bord ou un carnet de notes. Elle est réservée à ce qui reste vrai entre les sessions.
Ne pas mémoriser :
Mémoriser :
Les mémoires de type project deviennent rapidement obsolètes. Avant de recommander quelque chose basé sur une mémoire nommée, Claude devrait vérifier que c'est encore vrai :
> La mémoire dit que le module auth est en cours de réécriture
> → vérifier l'état actuel dans le code avant de l'appliquerSi une mémoire est contredite par ce que Claude voit dans le code, le code gagne. La mémoire est mise à jour ou supprimée.
# Mémoire globale (toutes sessions)
~/.claude/memory/
# Mémoire par projet (automatique selon le répertoire)
~/.claude/projects/[hash-du-chemin]/memory/Claude sait dans quel projet il se trouve et charge les mémoires correspondantes.
La mémoire rend chaque session plus efficace que la précédente. Le chapitre suivant couvre les skills — les slash commands personnalisées qui encapsulent des workflows répétitifs et les rendent invocables en un mot.