Claude Code : démarrer
Installation, première session, la boucle de travail réelle, les modes de permission et le mode plan. Ce qui distingue Claude Code d’un assistant dans l’éditeur.
À la fin de ce chapitre, vous saurez
- Installer Claude Code et lancer une première session utile
- Comprendre la boucle explorer / proposer / modifier / vérifier
- Choisir le mode de permission adapté à ce que vous faites
- Utiliser le mode plan pour ne pas laisser modifier avant d’avoir validé
Dans ce chapitre
Claude Code est Claude dans le terminal, avec accès à votre projet. Il lit vos fichiers, les modifie, exécute des commandes, lit le résultat, corrige, recommence.
La différence avec un assistant intégré à l’éditeur n’est pas la qualité du modèle — c’est le même. C’est qu’il agit au lieu de proposer du texte à copier. Il peut lancer vos tests et itérer jusqu’à ce qu’ils passent, ce qu’aucune complétion ne peut faire.
Installer et lancer
L’installation se fait par le gestionnaire de paquets de Node, ou par le script d’installation officiel :
npm install -g @anthropic-ai/claude-codePuis, depuis la racine de votre projet :
claudeLa première exécution demande une authentification, par votre abonnement Claude ou par une clé d’API. Un abonnement Pro ou Max couvre un usage individuel confortable ; l’API se facture à la consommation et convient mieux à l’automatisation.
Quelques commandes utiles dès le départ :
claude # session interactive dans le répertoire courant
claude "corrige le bug de pagination dans la liste des commandes"
claude -p "liste les endpoints exposés par ce projet" # non interactif, sortie sur stdout
claude --continue # reprend la dernière session
claude --resume # choisit parmi les sessions précédentesLe mode -p — pour print — est celui qui sert dans les scripts et l’intégration continue. Il est traité au chapitre 28.
La première chose à faire : /init
Sur un projet existant, la commande à lancer avant tout le reste :
/initClaude analyse le dépôt et produit un CLAUDE.md contenant ce qu’il a pu déduire : commandes de build et de test, conventions repérées, organisation des dossiers. Si un CLAUDE.md existe déjà, il propose des améliorations plutôt que de l’écraser.
Ce fichier est le socle de tout le reste. Le chapitre 24 lui est entièrement consacré.
La boucle de travail
Comprendre cette boucle est ce qui distingue un usage frustrant d’un usage productif. Elle a quatre temps.
Explorer. Claude lit les fichiers pertinents, cherche dans le code, comprend l’existant. Sur un gros projet, il délègue cette phase à un sous-agent pour que les résultats de recherche n’encombrent pas la conversation principale — voir le chapitre 26.
Proposer. Il annonce ce qu’il compte faire. En mode plan, il s’arrête ici.
Modifier. Il édite les fichiers. Chaque modification vous est montrée.
Vérifier. Il lance les tests, le linter, la compilation. S’il y a une erreur, il repart au début du cycle.
Le quatrième temps est le plus important, et c’est celui que l’on oublie de rendre possible. Un Claude Code qui ne peut pas vérifier son travail travaille à l’aveugle. La première question à se poser sur un projet n’est pas « que va-t-il savoir faire » mais « comment saura-t-il qu’il a réussi ».
Les modes de permission
Claude Code demande votre accord avant d’agir. Le niveau se règle, et le choix compte.
| Mode | Comportement | Quand |
|---|---|---|
| Défaut | Demande avant chaque modification et chaque commande | Découverte, code sensible |
| Plan | Lecture seule. Aucune écriture, aucune exécution | Avant toute tâche non triviale |
| Acceptation des éditions | Accepte les modifications de fichiers, demande pour les commandes | Travail courant sur un dépôt versionné |
| Sans garde-fous | N’demande plus rien | Environnement isolé uniquement |
On bascule entre les modes en cours de session — la touche de tabulation majuscule fait défiler les modes dans la plupart des configurations, et /permissions ouvre le réglage.
Le mode plan
C’est le geste qui change le plus la qualité du résultat sur les tâches non triviales.
En mode plan, l’écriture et l’exécution sont bloquées. Claude explore, comprend, et propose une approche. Vous lisez, vous corrigez, vous validez. Ensuite seulement il agit.
Pourquoi c’est décisif : une mauvaise compréhension du problème produit un patch qui compile, qui passe les tests, et qui ne fait pas ce qu’il faut. Le mode plan attrape l’erreur avant qu’elle ne soit écrite.
> passe en mode plan
Le paiement échoue quand la commande contient un article en rupture.
Explore le code concerné et propose une approche.
Contraintes :
- ne touche pas à la couche de persistance
- la correction doit être couverte par un test qui échoue avant et
passe après
- explique-moi d’abord la cause, ensuite seulement la solutionDeux choses à faire systématiquement avec un plan.
Exiger la cause avant la solution. Un plan qui commence par « je vais modifier tel fichier » n’a pas diagnostiqué : il a deviné.
Demander ce qu’il n’a pas regardé. « Quels fichiers as-tu lus, et lesquels aurais-tu voulu lire ? » Cette question révèle les angles morts.
Les commandes de session
Quelques commandes reviennent en permanence.
| Commande | Ce qu’elle fait |
|---|---|
/init | Génère ou améliore le CLAUDE.md du projet |
/context | Montre ce qui occupe la fenêtre de contexte, et les fichiers de mémoire chargés |
/memory | Ouvre et édite les fichiers de mémoire |
/clear | Vide le contexte et repart propre |
/compact | Condense la conversation pour continuer sans tout perdre |
/permissions | Ouvre le réglage des autorisations |
/status | Affiche la configuration chargée et les règles actives |
/doctor | Diagnostique la configuration |
/agents | Gère les sous-agents |
/context est celle qu’on sous-utilise le plus. Elle répond à la question « pourquoi devient-il bête » : presque toujours, le contexte est plein — le mécanisme du chapitre 3 s’applique ici aussi.
Ce qu’il faut lui donner pour qu’il soit bon
Trois choses, par ordre de rentabilité.
Une commande de vérification unique. Déjà dit, et c’est le point principal.
Un CLAUDE.md qui contient ce qu’il ne peut pas deviner. Pas l’arborescence — il la voit. Les décisions, les pièges, les raisons. Chapitre suivant.
Des messages précis. Toute la partie 2 s’applique, avec une exigence supplémentaire : ici, une demande floue produit du code écrit, pas seulement un texte à jeter.
> Le composant de liste re-rend trop souvent.
Diagnostique d’abord : montre-moi ce qui déclenche les rendus, avec
les fichiers et les lignes. Ne corrige rien.
Ensuite, propose deux approches : une minimale, une qui restructure.
Dis-moi ce que chacune coûte en risque de régression.Reprendre un projet qu’on ne connaît pas
La situation
On vous confie un service que personne n’a touché depuis huit mois. Aucune documentation à jour. Vous devez y corriger un bug dans la semaine.
Jour 1 — cartographier, sans rien modifier
> passe en mode plan
Explore ce projet et produis une note pour un développeur qui arrive :
- ce que fait ce service, en trois phrases
- les points d’entrée : commandes, routes, tâches planifiées
- les dépendances externes, et ce qui se passe si chacune tombe
- les zones du code qui semblent fragiles : peu de tests, forte
complexité, commentaires d’avertissement
- ce que tu n’as pas compris
Écris la note dans NOTES-REPRISE.md. Ne modifie rien d’autre.La dernière section est celle qui vaut le plus : elle liste exactement les endroits où vous devrez enquêter vous-même.
Jour 1, suite — la boucle de vérification
> Comment lance-t-on les tests, le linter et la compilation dans ce projet ?
Vérifie que ça marche réellement en les exécutant. Si une de ces
commandes échoue avant toute modification de ma part, dis-le-moi : je
veux savoir dans quel état je récupère le projet.
Puis propose-moi une commande unique « verify » qui enchaîne les trois,
et ajoute-la au CLAUDE.md.Découvrir que les tests étaient déjà cassés avant votre arrivée est une information précieuse — et cela arrive plus souvent qu’on ne croit.
Jour 2 — le bug, en mode plan
> passe en mode plan
[description précise du bug, avec les étapes de reproduction]
Trouve la cause. Ne propose pas de correction avant d’avoir montré :
- où le comportement diverge de l’attendu, fichier et ligne
- depuis quand, si l’historique git le dit
- ce qui, dans le code, rendait cette erreur possible
Ensuite seulement, l’approche de correction.Ce qui a changé
Deux jours pour être opérationnel sur un service inconnu, avec une note de reprise qui servira au suivant. Et la boucle de vérification en place, sans laquelle tout le reste de cette partie serait bancal.
Ce qu’il faut retenir
Vérifier que c’est passé
3 questions. Rien n’est enregistré, rien n’est envoyé : c’est pour vous.
Une première session utile, sans risque
Sur un dépôt réel dont vous connaissez bien un coin, lancez Claude Code en mode plan et demandez : « Explique-moi comment fonctionne [la partie que vous connaissez]. Ne modifie rien. » Comparez sa réponse avec ce que vous savez. Vous mesurerez immédiatement ce qu’il comprend, ce qu’il rate, et à quel point votre code est lisible pour un lecteur neuf.
Un indice, si vous bloquez
Les endroits où il se trompe sont presque toujours ceux où un nouveau développeur se tromperait aussi. C’est un excellent détecteur de dette de lisibilité.