Le flux explorer → planifier → coder → commiter

Pour une petite modification, une phrase suffit. Pour une tâche qui touche plusieurs fichiers ou une partie du code que vous connaissez mal, le cours officiel recommande un flux en quatre temps : explorer, planifier, coder, commiter. L’idée est simple : ne pas laisser Claude écrire du code avant que vous et lui sachiez ce qu’il faut écrire, et ne rien enregistrer qui n’ait été vérifié.

1. Explorer

Avant de modifier quoi que ce soit, laissez Claude comprendre le terrain. Sur un projet que vous découvrez, la documentation propose d’avancer du général au particulier :

give me an overview of this codebase
explain the main architecture patterns used here
what are the key data models?
how is authentication handled?

Sur une question précise, nommez la zone : « regarde comment src/auth/ gère le rafraîchissement des jetons ». Si l’exploration s’annonce longue, déléguez-la : « utilise un sous-agent pour étudier comment notre système d’authentification gère le rafraîchissement des jetons ». Le sous-agent lit les fichiers dans son propre contexte et ne vous rapporte que la synthèse, ce qui garde votre conversation lisible.

L’exploration sert aussi à dire à Claude ce qu’il ne peut pas voir. Il trouve tout seul l’organisation des fichiers, les conventions et le framework de test. Ce qu’il ne peut pas trouver, c’est ce qui n’est pas dans le dépôt : une décision prise en réunion, une préférence entre deux approches valables, la définition de « terminé ». C’est à vous de le lui donner.

2. Planifier

Le mode plan demande à Claude de chercher et de proposer des changements sans les faire. Il lit des fichiers, lance des commandes d’exploration et rédige un plan, mais ne touche pas à votre code source tant que vous n’avez pas approuvé ce plan. Pour y entrer :

• appuyez sur Maj+Tab jusqu’à ce que la barre d’état affiche ⏸ plan mode on ;
• ou préfixez une seule demande par /plan ;
• ou lancez directement claude --permission-mode plan.

Quand le plan est prêt, Claude vous le présente et vous demande comment continuer :

• Yes, and use auto mode : vous approuvez, et Claude commence en mode Auto ;
• Yes, manually approve edits : vous approuvez, mais validez chaque modification une à une ;
• No, keep planning : vous restez en mode plan et dites à Claude ce qu’il faut changer.

Ctrl+G ouvre le plan dans votre éditeur de texte pour le corriger vous-même avant que Claude ne s’y mette. Le plan vaut la peine d’être lu : c’est le moment le moins cher pour corriger un malentendu.

Quand vous ne savez pas encore exactement ce que vous voulez, une variante consiste à vous faire interviewer. Les bonnes pratiques officielles proposent ce prompt : « I want to add rate limiting to the public API but haven’t thought it through yet. Interview me until you could write the spec, then write it to SPEC.md. » Claude vous pose des questions à choix multiples sur ce qui n’est pas tranché, puis écrit la spécification. Ouvrez ensuite une nouvelle session pour construire à partir de SPEC.md : le travail démarre avec un contexte propre et une définition écrite de « terminé ».

3. Coder

Une demande précise fait gagner un aller-retour. Comparez :

Le point le plus important est de donner à Claude une vérification à lancer : un fichier de tests, le code de sortie d’un build, un linter, un script qui compare une sortie à une référence. Claude s’arrête quand le travail semble fini ; s’il a une commande qui répond « réussi » ou « échoué », il peut boucler seul : modifier, vérifier, lire l’erreur, corriger, revérifier. Sans elle, c’est vous qui devenez la suite de tests. Dites-le dans la demande (« lance les tests d’authentification après, et continue jusqu’à ce qu’ils passent »), et demandez des preuves : la commande lancée et sa sortie, plutôt qu’un « tous les tests passent ».

Pendant cette phase, le mode de permission règle votre niveau de contrôle. Auto (le mode de départ depuis la version 2.1.283, en terminal et dans VS Code) laisse un classifieur bloquer ce qui dépasse votre demande ; Manual vous fait tout approuver ; acceptEdits accepte les modifications de fichiers et les commandes courantes comme mkdir ou mv, mais demande pour le reste.

4. Commiter

Quand la vérification passe, demandez le commit :

commit my changes with a descriptive message

Claude prépare les fichiers, écrit le message et crée le commit ; il crée aussi les branches et ouvre les pull requests (« create a pr »). Avec la CLI gh installée et connectée, il ouvre la PR et lit les commentaires de revue sans autre explication de votre part. Pour retrouver plus tard la session qui a produit une PR, claude --from-pr 1234 (avec votre numéro de PR) ouvre la liste des sessions liées à cette PR.

Avant de commiter, une relecture par un regard neuf est une bonne habitude : c’est l’objet de la leçon sur la revue de code.

À vous de jouer

Une fonctionnalité en quatre temps. Choisissez une petite fonctionnalité dans un projet réel. Faites explorer le code par Claude sans rien modifier, passez en mode plan pour obtenir un plan que vous relisez et corrigez, laissez-le coder en vérifiant les tests, puis demandez-lui le commit. Notez l’étape où vous avez le plus corrigé sa trajectoire.

Sources officielles : The explore → plan → code → commit workflow (Claude Academy) · Best practices · Common workflows · Choose a permission mode

Points clés à retenir

• Explorer d’abord : vue d’ensemble, puis détails ; une exploration longue peut partir dans un sous-agent
• Planifier en mode plan (Maj+Tab, /plan ou --permission-mode plan) : Claude lit et propose, mais ne modifie rien avant votre accord
• Coder avec une demande précise et une vérification que Claude peut lancer lui-même ; exiger la sortie de la commande comme preuve
• Commiter quand la vérification passe ; Claude écrit le message, crée la branche et ouvre la PR