Avec les chapitres 1 et 2, vous devriez avoir saisi ce qu'est Claude Code et comment il fonctionne. Ce que ce chapitre construit, c'est un rythme que vous pouvez rejouer à l'identique chaque jour : les quatre temps explorer, planifier, implémenter, committer.
La raison d'avoir une forme est claire. Les jours où cela ne marche pas, la cause est presque toujours « un temps sauté ». Faire écrire sans faire lire, déléguer sans donner de moyen de vérifier, laisser courir sans poser de jalon : les symptômes diffèrent, mais l'endroit où l'on revient est le même.
La forme d'une journée : quatre temps
Lui faire lire les fichiers concernés et mettre en mots l'état actuel. Sans encore le faire écrire.
Lui faire sortir la marche à suivre d'abord, et la corriger vous-même. Le seul point de correction bon marché.
Le faire écrire et lancer la vérification dans la foulée. Le laisser boucler la boucle du chapitre 1.
Dès que c'est vert, planter un point de retour. La prochaine exploration part de là.
Le repère pour un tour complet : « s'il devient impossible de se rappeler ce qui s'est passé en route, c'est trop gros ». Quatre tours d'une heure sont presque toujours plus stables qu'un tour d'une demi-journée.
Cela ne veut pas dire « tout faire à chaque fois ». Corriger une faute de frappe n'appelle pas de plan. Ce qu'il faut décider, c'est quel temps vous pouvez sauter, et le réglage de départ est « on fait tout ».
Avant de commencer, donnez-lui un moyen de vérifier
Avant d'entrer dans les quatre temps, il y a une chose à faire une fois pour toutes : donner d'emblée à Claude un moyen de se contrôler lui-même.
Comme on l'a vu au chapitre 1, l'intérieur est une boucle collecter, agir, vérifier. Sa force vient de l'existence du STEP 3, qui lui permet de corriger tout seul jusqu'à ce que les tests passent. À l'inverse, sans moyen de vérifier, la boucle s'arrête au premier tour : il écrit, c'est probablement bon, fin. Exactement comme un outil de chat.
« Fais passer les tests » suffit. La sortie de l'échec devient l'entrée suivante, et la boucle tourne même quand vous ne regardez pas.
C'est vous qui exécutez, qui rapportez le résultat, puis qui faites réécrire. Vous devenez le goulot d'étranglement. Vous avez seulement l'impression d'avoir délégué.
Ce que vous donnez n'a pas à être grandiose. Une ligne du genre « tape cette commande et tu sauras si c'est correct » suffit. Et c'est plus sûr de l'écrire dans un fichier que de le dire de vive voix : le CLAUDE.md à la racine du projet est relu depuis le disque même après une compression.
Ce qui fait effet une fois écrit dans CLAUDE.md (exemples)
- Commandes à passer après modification : tests / types / linter
- Ne pas annoncer « c'est fait » tant que ça ne passe pas
- Endroits à ne pas toucher : fichiers générés, config de production, etc.
Écrit ainsi, il se met à vérifier de lui-même à chaque modification, sans que vous disiez « teste » à chaque fois. Ce n'est pas le nombre d'instructions qui baisse, ce sont les situations qui en réclament : voilà comment une forme fait son effet (la façon de l'écrire est au chapitre 6). Si les tâches classées « mauvais terrain » au chapitre 1 tombent ici, c'est justement parce qu'il n'y a aucun moyen de vérifier à donner.
Explorer : le faire lire avant de le faire écrire
Premier temps. Une seule chose à faire : lui faire lire les fichiers concernés et expliquer l'état actuel. Sans encore le faire écrire. Si vous sautez ce temps, Claude comble par des suppositions ce qu'il n'a pas lu. Il rend du code plausible, subtilement décalé par rapport aux conventions existantes, et vous découvrez l'écart à la relecture ou en production.
Mauvaise exploration : « Corrige l'authentification »
→ l'édition démarre aussitôt. on ne voit jamais sur quoi il s'est fondé
Bonne exploration : « Cherche et lis les fichiers liés à l'authentification.
Explique-moi comment la connexion est traitée aujourd'hui,
avec la liste des fichiers concernés.
Ne change rien pour l'instant. »
→ les hypothèses arrivent à l'écran. si elles dérapent, on corrige ici
L'explication qui revient, lisez-la. C'est le point d'intervention le moins cher de tous. Le coût d'un « ce fichier n'est plus utilisé » se compte en dizaines de fois moins que le coût de trouver une mauvaise implémentation à la relecture.
Autre chose : l'exploration a un prix. Les fichiers lus se chargent dans le contexte, donc plus vous explorez large, moins il reste de marge ensuite. Le « quand elle se remplit, il devient poussif et perd le début » du chapitre 1 commence ici. Trois façons de contenir cela.
- Découper le périmètre : « pour l'instant, seulement l'authentification ». Il faut une vue d'ensemble, pas tous les fichiers
- Faire lire les fichiers énormes par morceaux : en entier, ils remplissent tout d'un coup. Une plage de lignes ou une fonction suffit souvent
- Isoler les enquêtes à grosse sortie : analyse de journaux, recherches massives, à confier à un sous-agent. Il a son propre contexte et ne renvoie qu'un résumé, donc le contexte principal ne gonfle pas (chapitre 6)
Planifier : quand le mode plan paie, et quand il pèse
Deuxième temps. Faites-lui sortir quoi changer et dans quel ordre, avant qu'il commence à écrire. Claude Code dispose d'un mode plan dédié à ce temps : il enquête, présente un plan, s'arrête là, et ne passe à l'écriture qu'une fois que vous avez approuvé. La façon d'y basculer change selon les versions, alors vérifiez dans l'aide de la version que vous avez.
Le fond de l'affaire, c'est de déplacer la barrière des permissions de « à chaque édition » vers « à l'entrée du travail ». Par défaut, une confirmation arrive à chaque appel d'outil ; le mode plan les regroupe en une seule, placée en amont. Ce que vous approuvez n'est plus « cette ligne » mais « l'orientation de ce travail ».
Cela traverse plusieurs fichiers / il y a au moins deux façons de faire / il faut s'aligner sur une conception existante / le retour en arrière serait pénible en cas d'erreur / vous-même n'avez pas encore arrêté le meilleur coup
Il n'y a qu'une seule chose à faire / la marche à suivre est déjà fixée / en cas d'échec on revient en arrière instantanément / lire le plan prend plus de temps que l'implémentation
Le côté droit, sautez-le sans hésiter. Un plan n'est pas gratuit : il consomme du temps de production, du temps de lecture et du contexte. Quand vous en recevez un, ne regardez que trois choses. 1. Les hypothèses sont-elles justes (si le premier temps a dérapé, le plan dérape en entier). 2. La vérification y est-elle (s'il n'y a pas de « faire passer les tests », ajoutez-le). 3. Le découpage est-il assez fin (un plan qui fait tout en un coup ne permet pas d'identifier la cause en cas d'échec).
Pour un travail long, posez le plan dans un fichier. Un plan qui n'existe que dans la conversation finit écrasé par le résumé quand la session s'allonge. Faites-le écrire dans un endroit comme PLAN.md : vous pourrez le relire même après avoir replié le contexte, et il servira de point de reprise quand vous revenez après vous être absenté.
Implémenter : par petits pas, corrigés en cours de route
Troisième temps. C'est enfin le moment de le faire écrire. Deux principes.
Un : lancez la vérification à chaque pas. Si vous regroupez cinq modifications avant de tester, l'échec vous crée un travail supplémentaire, celui d'isoler laquelle est en cause. Un pas écrit, un pas validé : la cause, c'est le pas d'avant. Un usage qui sert moins à Claude qu'à vous.
Deux : transmettez la sortie de l'échec telle quelle. Inutile de la résumer avant de la lui rendre. Le STEP 3 consiste à « lire la sortie et revenir au STEP 1 », donc la sortie brute est l'entrée la plus riche en information. En la mâchant, vous réduisez les indices.
Un tour pendant l'implémentation (à répéter par petits pas)
[ÉDITION] modifier exactement un point du plan
↓
[EXÉCUTION] lancer les tests / la vérification de types
↓
vert → au point suivant (ou commit)
rouge → lire la sortie, retour à [ÉDITION]
Trois rouges d'affilée au même endroit : arrêtez de demander des corrections
→ posez les mains et passez au diagnostic (chapitre 4)
La dernière ligne est une règle empirique. Quand le même échec se répète, c'est le plus souvent le signe non pas d'un « presque corrigé » mais d'une hypothèse fausse.
Quand la vérification prend du temps (longue compilation, attente de l'intégration continue), vous pouvez déléguer plutôt que de rester scotché. Claude Code sait répéter une instruction à intervalle fixe, et si vous omettez l'intervalle, Claude décide lui-même quand revenir regarder, et arrête la boucle dès qu'il juge le travail terminé. Le fonctionnement et les limites sont dans Qu'est-ce que la commande /loop. Attention : fermer la session l'arrête.
Committer : c'est vous qui posez les jalons
Quatrième temps. Dès que les tests passent, committez à cet instant. Pas « une fois arrivé à un point propre » : l'instant où c'est vert est le point propre.
- Cela devient un point de retour : même si le pas suivant échoue, vous pouvez revenir à un endroit dont vous savez qu'il était vert
- Le diff garde une taille lisible : une demi-journée de modifications ne se lit pas. Un diff illisible n'est pas relu en pratique
- La conversation devient jetable : une fois le résultat rangé, abandonner la session ne fait plus peur
Vous pouvez aussi lui faire écrire le message de commit, mais n'approuvez pas sans regarder le diff. Décidez de chercher non pas « ce que j'ai changé » mais « s'il ne s'est pas glissé là quelque chose que je ne voulais pas changer », et votre regard cessera de glisser.
Notez que committer et pousser sont deux décisions distinctes. Jusqu'où déléguer les opérations difficiles à annuler, comme un déploiement, c'est le chapitre 5.
Replier une session, et revenir en arrière
Après quelques tours des quatre temps, vous butez immanquablement sur le contexte qui se remplit. Quand les deux symptômes du chapitre 1 apparaissent (réponses poussives, début oublié), il est temps de replier. Deux moyens, compresser ou repartir de zéro, et un seul critère les sépare.
Si la suite est « la suite », compressez : vous transmettez le parcours sous forme de résumé, et pouvoir indiquer quoi garder est précisément ce qui distingue le geste manuel du déclenchement automatique. Si la suite est « autre chose », repartez de zéro : si même le résumé est inutile, le coût de le produire l'est aussi. Et comme vous ne traînez pas un travail sans rapport, la précision y gagne.
Le moment aussi a sa forme. Appuyez à une coupure du travail, pas selon l'horloge ni selon un pourcentage : quand un tour s'achève, juste avant d'entamer un long chantier. Si vous appuyez en plein milieu, les détails que vous alliez utiliser sont écrasés par le résumé. Le raisonnement est développé dans Faut-il lancer /compact régulièrement ?.
Avant de replier, sortez dans un fichier ce qui ne doit pas disparaître. Le CLAUDE.md à la racine du projet et la mémoire automatique sont relus depuis le disque, donc ils survivent à autant de repliages que vous voulez ; mais les décisions qui n'existent que dans la conversation se diluent dans le résumé.
Il existe un autre dispositif, qui change la façon même de déléguer. Claude Code crée automatiquement un point de retour à chaque invite, et si les choses tournent mal, vous pouvez y revenir. Vous choisissez la cible entre le code seul, la conversation seule, ou les deux, et celle qui sert le plus est « annuler le code, garder la conversation » : les modifications sont effacées, et vous reformulez en gardant en mémoire ce qui n'allait pas.
Ce qui compte ici est moins la commodité du geste que la façon de prendre des risques. Si vous vous croyez sans retour possible, vous validez pas à pas, et l'intérêt d'un agent s'évapore. Si vous savez que vous pouvez revenir, vous déléguez en gros morceaux, et essayer puis jeter devient une option.
Cela dit, ce qui revient, ce sont uniquement « les fichiers que Claude a modifiés avec un outil d'édition ». Les fichiers créés ou supprimés par une commande shell, vos propres modifications et l'état d'une base de données ne reviennent pas. Ce n'est pas un substitut à Git, et cela suppose que vous committiez aussi aux étapes clés. La ligne se trace ainsi : un travail qui tient entièrement dans des éditions de fichiers, déléguez-le en gros morceaux ; un travail qui change l'état via un shell, committez avant de le déléguer. Les détails sont dans Points de contrôle et retour en arrière.
Le faire relire : séparer celui qui écrit de celui qui lit
Un code dont les tests passent n'est pas forcément un bon code. Les tests garantissent « que rien n'est cassé », mais ils ne répondent pas à « était-ce la bonne façon de l'écrire ».
Un seul principe : séparer le contexte d'écriture du contexte de lecture. Dire « relis ça » dans la conversation même où l'implémentation vient d'être écrite mène surtout à entériner ses propres décisions. Un état où toutes les raisons du choix sont visibles ne se prête pas à la recherche de failles. Concrètement, trois gestes.
- Faire lire dans une autre session : committez pour produire un diff, et donnez le diff seul à une conversation vierge. Un regard qui ignore le parcours
- Indiquer les angles : pas « améliore », mais des axes précis, « les cas limites », « la cohérence avec les conventions existantes ». Une demande floue produit des remarques floues
- Ne pas prendre les remarques pour argent comptant : leur justesse se contrôle sur le code réel. Lisez d'abord, faites corriger ensuite
Le troisième point rejoint le reste de ce chapitre. La relecture est le cas typique de la « tâche sans moyen de vérifier » : comme rien ne tranche automatiquement le vrai du faux, Claude énonce aussi des remarques à côté de la plaque, sur un ton assuré. Les enchaîner directement en consignes de correction casse du code qui était juste. Traitez les remarques comme des candidates et jugez-les une par une. Quand vous avez envie de repasser toujours les mêmes angles, c'est le signal qu'il faut en faire un dispositif (chapitre 6).
Plusieurs sessions : jusqu'où c'est rentable
Avancer sur autre chose pendant qu'un côté fait tourner un long test : l'idée vient naturellement. Claude Code sait lancer plusieurs sessions indépendantes en arrière-plan et les gérer sur un seul écran. Le cœur du mécanisme, c'est l'isolement : une session en arrière-plan se déplace dans son propre répertoire de travail avant de modifier le moindre fichier. Les lectures sont partagées, les écritures séparées, donc deux sessions qui s'écrasent mutuellement le même fichier deviennent structurellement impossibles. Les détails sont dans La vue agents et la répartition.
Les tâches sont indépendantes entre elles / vous n'avez pas besoin de voir le déroulé / juger au moment de recevoir le résultat suffit / un des côtés attend longtemps
Elles dépendent de la même décision de conception / il faut réorienter en cours de route / cela comprend des opérations irréversibles / le nombre dépasse ce que vous pouvez contrôler
Le dernier point de droite est la contrainte la plus mordante. Le parallélisme augmente le volume total de relecture. Si vous lancez trois choses, ce sont trois « est-ce bien vrai » qui reviennent, et l'effort de contrôle, lui, ne se parallélise pas. Le plafond de ce que vous pouvez lancer, c'est le nombre de résultats que vous êtes capable de vérifier. Le coût augmente aussi : ce n'est pas parce que c'est en arrière-plan que c'est moins cher (chapitre 7).
Avant de vous mettre au parallèle, revoyez vos réglages de permissions. Les sessions qui tournent en arrière-plan héritent des permissions définies dans les réglages, elles ne les choisissent pas sur le moment. Plus vous êtes du genre à travailler avec des réglages permissifs, plus vous fabriquez de « sessions à permissions larges que personne ne surveille », autant que vous en lancez. Le chapitre 5 vient d'abord.
Discret mais source de bien des accidents : le rangement. L'espace de travail créé par une session d'arrière-plan disparaît avec elle quand vous supprimez la session. « Terminé » et « intégré » sont deux choses différentes : committez avant de supprimer.
Résumé
- Le rythme d'une journée, ce sont les quatre temps explorer, planifier, implémenter, committer. Quand ça coince, la cause est presque toujours un temps sauté
- Avant de commencer, donnez un moyen de vérifier. Sans lui, la boucle collecter, agir, vérifier s'arrête au premier tour
- Explorer, c'est faire lire avant de faire écrire. Mais tout ce qui est lu réduit la marge, alors découpez le périmètre
- Planifier est le dispositif qui regroupe la barrière des permissions à l'entrée du travail. C'est lourd pour un travail d'un seul geste
- Implémenter, c'est vérifier à chaque pas et, après trois échecs, passer au diagnostic. Le commit se pose à l'instant où c'est vert
- Compresser ou repartir de zéro se décide sur « la suite est-elle la suite, ou autre chose ». Juste avant de replier, écrivez dans un fichier
- Le retour en arrière ne rend que les éditions de fichiers. Les changements passés par un shell ne reviennent pas, donc combinez-le avec les commits
- La relecture se détache du contexte d'écriture, et les remarques se traitent comme des candidates. Le plafond du parallèle est le nombre que vous pouvez vérifier
Même avec une forme, on se bloque parfois. Que le chapitre suivant vous donne un ordre de marche pour le diagnostic. Passez au chapitre 4, « Se sortir d'un blocage ».