Le cours complet sur Claude, du premier message à l'automatisation : Projects, mémoire, connecteurs, skills, Cowork, puis Claude Code avec CLAUDE.md, agents, MCP, hooks, plugins et mods.
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.
Le plus simple pour démarrer : lancer /init dans le projet. Claude parcourt le dépôt et rédige une première version, que vous corrigez ensuite. /memory ouvre les fichiers chargés pour les éditer.
Il y a trois niveaux de configuration, du plus général au plus local.
~/.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"Au lancement, Claude charge les CLAUDE.md du dossier courant et de ses parents. Ceux des sous-dossiers sont chargés à la demande, quand Claude lit un fichier qui s'y trouve.
CLAUDE.local.mdVos réglages propres à ce dépôt, que l'équipe n'a pas à subir : l'URL de votre base locale, vos données de test. Ajoutez-le au .gitignore.
Un CLAUDE.md peut en inclure un autre avec @chemin. Pratique pour réutiliser un document qui existe déjà au lieu de le recopier :
Voir @README.md pour la présentation du projet.
Les conventions Git sont dans @docs/git-workflow.md.## 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, et tout est relu à chaque message — 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. Une règle qui doit s'appliquer à coup sûr (« ne jamais commiter sur main ») a plus sa place dans un hook, vu au module 11, que dans une phrase que Claude peut oublier.
# 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 module 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.