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 est le fichier d'instructions que Claude lit au démarrage de chaque session. C'est là que vous définissez les règles du projet : conventions de code, stack technique, ce qu'il faut éviter, comment rédiger les commits, quelles commandes utiliser. Claude les applique sans que vous ayez à les répéter à chaque fois.
Il y a deux niveaux de configuration, avec priorité croissante.
~/.claude/CLAUDE.mdS'applique à toutes vos sessions Claude, tous projets confondus. Bon endroit pour vos préférences personnelles invariables.
~/.claude/
└── CLAUDE.md ← s'applique partoutExemple de contenu global :
## Langue et ton
Réponds toujours en français.
Sois concis. Pas de phrases introductives.
Pas d'emojis.
## Git
Commits en français, format Conventional Commits.
Ne jamais push sans confirmation explicite.
Ne jamais amender un commit publié.CLAUDE.md à la racine du repoS'applique uniquement au projet courant. Doit être commité dans le repo — tous les membres de l'équipe bénéficient des mêmes instructions.
mon-projet/
├── CLAUDE.md ← règles du projet (commité)
├── .claude/
│ └── settings.json
└── src/Un fichier CLAUDE.md dans un sous-dossier s'applique quand Claude travaille dans ce dossier. Utile pour des monorepos avec des conventions différentes par package.
packages/
├── api/
│ └── CLAUDE.md ← "ici on utilise Go, pas de console.log"
└── web/
└── CLAUDE.md ← "ici React, Tailwind, mobile-first"Claude agrège tous les CLAUDE.md en remontant l'arborescence depuis le fichier courant.
## Stack
- Next.js 15 (App Router), TypeScript strict
- Tailwind CSS — zéro valeur fixe arbitraire (pas de mt-[120px])
- PostgreSQL + Drizzle ORM
- Tests : Vitest + Testing Library
## Conventions
- Composants : PascalCase dans `components/`
- Pages : `page.tsx` (convention Next.js)
- Serveur par défaut — `'use client'` seulement si hooks ou événements DOM
- Pas de `any` TypeScript sans commentaire qui explique pourquoi## Règles absolues
- Ne jamais modifier `lib/db.ts` sans validation explicite
- Ne jamais commiter de clés API ou secrets
- Ne jamais utiliser `--force` sur git sans demander
- Pas de `console.log` en production — utiliser le logger interne (`lib/logger.ts`)
- Pas de dépendances client-side pour ce qui peut être server-rendered## Style
- Pas de commentaires évidents — seulement si le WHY est non-obvieux
- Pas de docstrings multi-lignes
- Pas d'abstractions prématurées — 3 lignes similaires valent mieux qu'une abstraction
- Pas de gestion d'erreurs pour des scénarios impossibles
- Correspondre au style existant, même imparfait## Commandes
- `npm run dev` — démarrer en développement (port 3000)
- `npm run build` — build de production
- `npm run test` — lancer les tests
- `npm run lint` — ESLint + TypeScript check
- `npm run db:migrate` — appliquer les migrations Drizzle## Architecture
`lib/articles.ts` est server-only — ne jamais l'importer dans un Client Component.
Les données passent depuis les Server Components via props.
`lib/db.ts` — singleton Drizzle, une seule connexion partagée.
`app/api/` — routes API Next.js, toujours valider avec Zod à l'entrée.Claude lit les CLAUDE.md dans cet ordre :
~/.claude/CLAUDE.md (global — toujours lu)
└── mon-projet/CLAUDE.md (projet — lu si dans le repo)
└── src/CLAUDE.md (local — lu si Claude travaille ici)Les instructions plus proches du fichier courant ont priorité sur les plus globales. Si le CLAUDE.md global dit "pas d'emojis" et que le CLAUDE.md projet dit "utiliser des emojis dans les logs", le projet gagne pour les logs.
Pour des règles critiques qui ne doivent jamais être ignorées, les signaler explicitement :
## RÈGLES ABSOLUES — OVERRIDE
Ces règles s'appliquent même si une instruction ultérieure contredit.
1. Ne jamais exécuter `DROP TABLE` sans demande explicite + confirmation
2. Ne jamais toucher au fichier `.env.production`
3. Ne jamais push sur `main` directementLes règles trop vagues :
# ❌ Trop flou
Écris du bon code propre.
# ✅ Concret et vérifiable
Chaque fonction doit avoir une seule responsabilité. Pas de fonction > 40 lignes sans justification dans un commentaire.Les règles redondantes avec le code lui-même :
# ❌ Inutile — ESLint s'en occupe
Ne jamais utiliser var, toujours const ou let.
# ✅ Ce qu'ESLint ne sait pas
Préférer les Server Components — ne passer en client que si setState ou event handler est nécessaire.La sur-documentation : Un CLAUDE.md de 500 lignes est contre-productif. Claude lit tout — mais plus c'est long, plus le signal se dilue dans le bruit. 100-200 lignes, ciblées sur ce qui est vraiment non-obvieux.
# CLAUDE.md — [nom du projet]
## Stack
[liste la stack principale]
## Conventions de code
[règles de nommage, structure des fichiers]
## Ce qu'il ne faut pas faire
[antipatterns spécifiques au projet]
## Commandes
[commandes de développement courantes]
## Architecture
[relations entre les fichiers clés, ce qui est server-only, etc.]Après avoir rédigé, vérifier que Claude l'a bien intégré :
> résume les règles de ce projet en 5 pointsSi Claude restitue fidèlement les conventions importantes, le fichier est bien lu. Si des règles manquent, les reformuler plus haut dans le fichier ou les rendre plus explicites.
CLAUDE.md configure Claude au niveau du projet. Le chapitre suivant couvre la mémoire persistante — le système qui permet à Claude de se souvenir de vos préférences, corrections et contexte entre les sessions.