Démarrer en 5 minutes

La page la plus pratique du site. En une lecture, je pose les bases pour utiliser Claude Code sur n'importe quel projet. Pas de théorie, que du concret.

1. Prérequis 30 secondes

Quatre choses à vérifier avant de commencer :

1
Un repo git

N'importe quel projet versionne. Git est indispensable : Claude Code s'en sert pour le diff, les commits, et le suivi des modifications.

2
Un runtime installé

Node.js, Rust, Python, ou tout autre runtime pertinent pour mon projet. Claude Code a besoin de pouvoir lancer build et tests.

3
Claude CLI installé

npm install -g @anthropic-ai/claude-code et c'est tout. Documentation sur claude.ai/code.

4
Un terminal ouvert dans mon projet

Claude Code fonctionne dans le terminal, à la racine du projet. Je lance cd mon-projet et je suis prêt.

2. Le CLAUDE.md minimal 2 minutes

Le CLAUDE.md est le fichier le plus important. C'est le "prompt système" de Claude Code pour mon projet. Sans lui, Claude devine ma stack, mes conventions, et mes commandes. Et il se trompe souvent.

Template à copier-coller

Je crée un fichier CLAUDE.md à la racine de mon projet avec ce contenu, adapté à ma stack :

CLAUDE.md
# Mon Projet

## Stack
- Framework: [ex: NestJS 11]
- Language: [ex: TypeScript strict]
- Database: [ex: PostgreSQL 16]
- Tests: [ex: Vitest + Playwright]

## Commandes
- Dev: `npm run dev`
- Build: `npm run build`
- Test: `npm run test`
- Lint: `npm run lint`

## Conventions
- Commits conventionnels (feat/fix/docs/test/refactor)
- TypeScript strict, pas de `any`
- Tests obligatoires pour chaque feature

## Règles
- Toujours tester avant de considérer le code terminé
- Ne jamais commit sans vérifier que les tests passent
- Lire un fichier avant de le modifier

Pourquoi chaque section compte

Stack

Sans cette section, Claude génère du code générique. Avec elle, il produit du code idiomatique pour mon framework. Sur mes projets, j'observe 3x moins de corrections quand la stack est documentée.

Commandes

La section la plus impactante. Sans elle, Claude tente npm test alors que ma commande est npm run test:backend. Avec elle, il lance la bonne commande du premier coup.

Conventions

Claude a tendance à utiliser any et à nommer les fichiers selon ses propres conventions. Expliciter les miennes lui évite de deviner, et de se tromper.

Règles

Claude skippe les tests si on ne lui dit pas de les lancer. 3 règles impératives suffisent pour le cadrer : tester, vérifier, lire avant de modifier.

3. Première session 2 minutes

Je lance Claude Code et je lui donne un premier prompt très spécifique :

Terminal
cd mon-projet
claude
Mon premier prompt

Lis le CLAUDE.md et explore la structure du projet. Dis-moi ce que tu comprends.

Pourquoi ce premier prompt fonctionne

1
Il force la lecture du CLAUDE.md

Claude commence par lire ma configuration au lieu de deviner. Il découvre ma stack, mes commandes, mes règles.

2
Il explore avant d'agir

Claude parcourt l'arborescence, lit les fichiers clés, comprend l'architecture. Il ne modifie rien.

3
Il me montre ce qu'il a compris

Je peux corriger ses erreurs de compréhension avant qu'il touche au code. C'est une validation gratuite.

4. Les 3 commandes essentielles

Trois commandes couvrent 90% de mes besoins au quotidien :

/clear

Remet le contexte à zéro entre deux tâches indépendantes.

Quand : Je passe du bug #42 à la feature #18. Les deux n'ont rien à voir. /clear évite que Claude mélange les contextes.

/compact

Compresse le contexte quand il devient trop lourd.

Quand : Le contexte atteint 60-70%. Pas 95%. À 95% c'est trop tard, Claude perd en qualité. Je compacte tôt, quand les informations importantes sont encore fraîches.

claude --resume

Reprend la session précédente avec tout son contexte.

Quand : Je ferme mon terminal, je reviens le lendemain, je veux continuer où j'en étais. Claude retrouve le fil de la conversation.

5. Première feature avec Claude

Après l'exploration initiale, je passe à du concret. Un prompt simple et précis :

Mon prompt

Ajoute un endpoint GET /health qui retourne { status: "ok", timestamp: Date.now() }. Avec un test.

Ce que Claude fait, étape par étape

1
Lit le projet

Il repère le framework, le dossier des routes, la structure existante.

2
Crée le fichier

Il ajoute l'endpoint en suivant les conventions du projet, pas les siennes.

3
Écrit le test

Il utilise le framework de test déclaré dans le CLAUDE.md (Vitest, Jest, etc.).

4
Lance les tests

Il exécute la commande de test du CLAUDE.md et vérifie que tout passe.

6. Les 3 erreurs de débutant

1

Le prompt fourre-tout

Le piège : "Fais l'auth, les tests, le refactor et la doc."
La règle : 1 prompt = 1 tâche. Décomposer en étapes séquentielles. Claude est bien meilleur quand l'objectif est clair et unique.
2

Pas de CLAUDE.md

Le piège : Claude invente ses propres conventions. Il utilise Jest au lieu de Vitest, nomme les fichiers à sa façon, oublie le strict mode.
La règle : Toujours avoir un CLAUDE.md, même minimal. 20 lignes suffisent pour cadrer 80% du comportement.
3

Ignorer les tests

Le piège : Claude dit "build OK" et je passe à la suite. Mais build OK ne veut pas dire que ça marche. Ça veut dire que ça compile.
La règle : Exiger "avec un test" dans chaque prompt de feature. Et vérifier que le test passe réellement, pas juste que Claude le dit.

7. Étape suivante

Je n'ai pas besoin de tout faire d'un coup. Voici le chemin que je recommande :

Semaine 1
Ajouter session.md pour la persistance

Un fichier .claude/session.md lu au démarrage de chaque session. Claude retrouve le contexte au lieu de repartir de zéro. Gain immédiat : 15 minutes par session.

Semaine 2
Créer /autopilot et /test-sweep

Deux commandes personnalisées dans .claude/commands/. Le /autopilot traite le backlog en boucle. Le /test-sweep lance tous les tests, analyse les échecs, et corrige.

Mois 2
Agents spécialisés si 3+ domaines

Quand mon projet couvre backend + frontend + infra, ou plus, je crée des fichiers dans .claude/agents/ pour spécialiser le comportement par domaine.