Claude Code : le guide complet pour bien l'utiliser

Il existe des dizaines de tutoriels Claude Code qui t'accompagnent jusqu'à l'installation et s'arrêtent là où le vrai travail commence. Celui-ci fait l'inverse : chez Lasting Dynamics, nous utilisons Claude Code tous les jours sur des projets clients en production et nous enseignons l'agentic coding dans notre academy. Ce guide couvre donc la partie qui détermine réellement si l'outil te rend plus rapide — configuration, workflow, coûts, et les erreurs que presque tout le monde fait au début.

Ce qu'est Claude Code, et pourquoi c'est différent

Claude Code est l'outil d'agentic coding d'Anthropic. Au lieu de compléter des lignes pendant que tu tapes, il travaille comme un collègue à qui tu délègues : tu décris un résultat (« ajoute du rate limiting à cet endpoint et couvre-le de tests »), et un agent planifie, lit ton codebase, modifie les fichiers, exécute des commandes et des tests, puis itère jusqu'à avoir terminé. Toi, tu diriges et tu fais la review — comme avec un collègue.

Il est né comme CLI dans le terminal — et c'est là qu'il donne le meilleur — mais il existe aussi en extension VS Code et JetBrains, en app desktop et en version web. Dessous, les modèles Claude d'Anthropic ; dessus, un système d'extensions fait de serveurs MCP, de hooks, de skills et de subagents.

Le modèle mental à retenir tout de suite : Claude Code est puissant à proportion de ta propre précision. C'est un multiplicateur de ton jugement d'ingénieur, pas un remplaçant. Garde ça en tête pour tout le guide, parce que chaque section y revient.

Installation : dix minutes, honnêtement

npm install -g @anthropic-ai/claude-code
cd ton-projet
claude

(Anthropic propose aussi un installeur natif si tu préfères éviter npm.) Au premier lancement, tu t'authentifies avec un abonnement Claude (Pro, ou Max pour un usage intensif) ou avec une clé API. À partir de là, tu parles à l'agent en langage naturel — en français ou en anglais.

Les commandes que tu utiliseras dès le premier jour :

• /init — analyse le projet et génère un premier CLAUDE.md
• /help — la liste des commandes
• /clear — remet le contexte à zéro quand tu changes de sujet
• claude --continue / --resume — reprend une session précédente

C'est vraiment tout pour le setup. La partie intéressante, c'est la suite.

Étape 1 : écrire un CLAUDE.md qui vaut la peine d'être lu

Si tu ne retiens qu'une chose de ce guide, que ce soit celle-ci : ton projet doit avoir un CLAUDE.md soigné.

C'est un fichier markdown à la racine du repo que Claude Code charge au début de chaque session. C'est la différence entre onboarder une recrue talentueuse une seule fois et lui réexpliquer ton projet chaque matin.

Ce qui doit s'y trouver — exactement ce que tu dirais à un bon ingénieur le premier jour :

# Projet X

## Commandes
- build : `npm run build`
- test : `npm test`
- lint : `npm run lint`

## Conventions
- TypeScript strict, pas de `any`
- Les composants UI vivent dans src/components/ui
- Les changements de DB passent UNIQUEMENT par prisma/migrations
- Chaque correction de bug part d'un test qui reproduit le bug

## Limites
- Ne pas toucher src/legacy/** sans demander
- Pas de nouvelle dépendance sans justification

Dans notre équipe, le CLAUDE.md est maintenu comme du code : il passe en review, il est mis à jour quand les conventions changent, et quand l'agent se trompe de façon systématique, la première question est « est-ce qu'il manque une ligne au CLAUDE.md ? ».

Étape 2 : prendre les permissions au sérieux

Claude Code demande la permission avant les actions potentiellement risquées : exécuter certaines commandes, écrire en dehors du projet, appeler des outils externes. Au début, ces demandes ressemblent à de la friction — jusqu'au jour où l'une d'elles te sauve.

La discipline que nous enseignons :

1. Lis ce qu'il s'apprête à faire, pas seulement le nom de la commande.
2. N'autorise en permanence que ce qui est toujours sûr (le test runner, le linter, le build).
3. Laisse tout le reste sur demande. Chaque prompt de permission est un checkpoint de review gratuit sur le plan de l'agent : sers-t'en.

Sur un repo avec de vraies données, la discipline sur les permissions n'est pas de la paranoïa : c'est la raison pour laquelle tu peux confier des tâches sérieuses à l'agent en dormant tranquille.

Étape 3 : le workflow de production

Voici la boucle vers laquelle nos ingénieurs ont convergé après des mois de travail client quotidien :

1. Des briefs, pas des prompts. Une tâche bien posée a du contexte, des contraintes et une définition du terminé : « Ajoute la validation d'input à l'endpoint /apply. Utilise zod comme dans le reste du projet. Un input invalide renvoie 400 dans le format d'erreur standard. Ajoute les tests et fais-les passer. » Ce brief bat n'importe quel prompt « astucieux ».

2. Le plan avant le code. Sur toute tâche non triviale, demande à Claude Code de présenter son plan d'abord (le mode plan existe exactement pour ça) et relis-le comme tu relirais une approche en standup. Rejeter un mauvais plan coûte dix secondes ; rejeter un mauvais diff coûte un après-midi.

3. Des incréments à taille de commit. « Migre le module » devient « migre ce fichier, lance ses tests, arrête-toi ». Les petits objectifs convergent ; les gros objectifs dérivent.

4. Les tests sont la laisse. Un agent qui peut vérifier son travail itère vers le correct ; un agent qui ne peut pas devine avec assurance. Si ta suite de tests est faible, la première chose à déléguer, c'est écrire des tests — pas des features.

5. Git comme filet de sécurité. Des commits petits et fréquents ; chaque incrément vérifié atterrit. Claude Code est vraiment bon avec git — profites-en : revenir en arrière ne fait jamais peur.

6. Une review comme si le code était à toi — parce qu'il l'est. Chaque ligne assistée par IA part sous ton nom. « C'est l'IA qui l'a écrit » n'est pas une phrase qui existe dans une équipe sérieuse.

Étape 4 (plus tard, pas d'abord) : MCP, skills, hooks, subagents

Une fois que les fondamentaux fonctionnent, la couche d'extension est là où Claude Code prend l'avantage :

• Les serveurs MCP (Model Context Protocol) connectent l'agent à ton monde : bases de données, navigateurs, systèmes de tickets, API internes (claude mcp add).
• Les skills empaquettent des procédures répétables — runbook de déploiement, checklist de review — qui se chargent à la demande.
• Les hooks exécutent des commandes automatiquement sur des événements (lint après chaque modification), transformant les conventions en contraintes que l'agent ne peut pas oublier.
• Les subagents prennent en charge des tâches délimitées (explorer ce codebase, creuser cette question) en parallèle, sans polluer ton contexte principal.

Conseil honnête : ne commence pas par là. Quatre-vingt-dix pour cent de la valeur est dans un bon CLAUDE.md, des briefs précis et des tests fiables. Les extensions multiplient un workflow qui fonctionne ; elles ne réparent pas un workflow cassé.

Ce que ça coûte

Claude Code est inclus dans les abonnements Claude (Pro pour un usage régulier, Max pour un usage intensif) ou fonctionne à la consommation avec des tokens API. Les longues sessions agentiques sur de gros codebases consomment de vrais tokens : pour un usage professionnel quotidien, l'abonnement est presque toujours le choix rationnel.

Le coût que personne ne compte : ton temps de review. Un outil qui génère du code plus vite que tu ne peux le relire de façon responsable ne t'a pas rendu plus rapide — il a déplacé le goulot d'étranglement et l'a caché.

Les cinq erreurs que tout le monde fait

1. Des objectifs vagues sur de gros codebases — l'agent prend des décisions raisonnables que tu ne voulais pas, à grande échelle. Le remède, c'est la précision.
2. Des sessions marathon sans /clear — le contexte se remplit de bruit et la qualité chute. Nouveau sujet, nouveau contexte.
3. Approuver toutes les permissions pour aller plus vite — voir l'étape 2.
4. L'utiliser pour éviter de comprendre — le code que tu ne comprends pas aujourd'hui est le bug que tu ne sauras pas corriger dans trois mois. Si l'output n'est pas clair, demande à l'agent de te l'expliquer (il est excellent à ça) au lieu d'accepter et de passer à la suite.
5. Le juger sur un essai de cinq minutes — comme tout outil professionnel, la valeur arrive avec la pratique délibérée.

La meilleure façon d'apprendre Claude Code

Tu peux apprendre les commandes en un après-midi. Ce qui prend plus de temps, c'est le jugement qui rend l'outil puissant : reconnaître quand un diff plausible est faux, spécifier un travail avec précision, savoir quoi tester, savoir à quoi ressemble une bonne architecture. Les outils agentiques ont rendu plus facile que jamais de produire du code qu'on ne comprend pas — et ils ont rendu radicalement plus productifs les ingénieurs qui comprennent.

C'est le pari sur lequel la Lasting Dynamics Academy est construite : depuis dix ans, nous formons les ingénieurs que nous embauchons ensuite, et aujourd'hui le travail concret avec l'IA agentique fait partie du curriculum, enseigné par-dessus les fondamentaux — architecture, design patterns, tests — avec des tâches réelles relues chaque semaine par un mentor. C'est gratuit, entièrement à distance, sélectif, et tous ceux qui terminent reçoivent une offre d'emploi. Si ce guide correspond à ta façon de vouloir travailler, c'est exactement comme ça qu'est enseigné le programme d'agentic coding — et la prochaine cohorte est ouverte.

FAQ

Claude Code fonctionne-t-il en français ? Oui : tu peux lui donner des instructions en français et il répond en français. Le code, les commentaires et les conventions suivent ce que tu établis (ou ce que dit ton CLAUDE.md).

Claude Code ou Cursor — lequel choisir ? Des outils différents pour des tâches de forme différente ; beaucoup de nos ingénieurs utilisent les deux dans la même journée. La règle pratique : si tu sais décrire le résultat mais pas les modifications, Claude Code ; si tu vois déjà les modifications dans ta tête, l'éditeur IA. Comparaison complète tirée de notre expérience en production : Claude Code vs Cursor.

Faut-il savoir coder pour l'utiliser ? Pour jouer, non. Pour travailler, oui — et plus tu es bon, plus il vaut. Sans le jugement nécessaire pour relire l'output, tu accumules du code que tu ne sais pas maintenir. C'est la porte d'entrée du vibe coding — et de ses dégâts.

Ça marche sur un gros codebase legacy ? C'est l'un de ses points forts : exploration, longs refactorings, migrations. La règle des incréments à taille de commit y compte double, et il te faut une suite de tests en laquelle tu as confiance.

Combien de temps avant d'être productif ? Avec un CLAUDE.md solide et le workflow ci-dessus : quelques jours. La vraie maîtrise — celle qui multiplie — vient de la pratique délibérée et de la review de quelqu'un de plus expérimenté. C'est précisément la raison d'être de l'academy.