Plan Mode : pourquoi je le déclenche avant toute tâche non triviale

Le mode par défaut de Claude Code alterne lecture, décision et action dans la même boucle : l'agent peut lire un fichier puis l'éditer dans la foulée, sans étape intermédiaire de validation. Ça convient très bien à une tâche petite et claire. Ça devient risqué dès que la tâche est assez grande pour que l'agent choisisse, sans le dire explicitement, une approche que je n'aurais pas retenue.

Ce que Plan Mode change concrètement#

En Plan Mode, l'agent perd l'accès aux outils d'écriture et d'exécution : il peut lire, chercher, explorer, mais pas modifier un fichier ni lancer une commande. Il doit construire sa compréhension du problème avec ces seuls outils, puis présenter un plan explicite avant que j'autorise le passage en exécution. Le point clé n'est pas la restriction elle-même, c'est le moment où elle intervient : avant la première modification, pas après.

Le vrai coût d'une mauvaise approche#

Sans Plan Mode, une approche bancale se découvre généralement au milieu de l'exécution, quand plusieurs fichiers ont déjà été modifiés dans une direction qu'il faut ensuite défaire. Le coût n'est pas seulement le temps perdu à revenir en arrière, c'est la difficulté à isoler ce qui, dans l'état actuel du repo, vient de la bonne approche et ce qui vient de la mauvaise. Avec Plan Mode, ce diagnostic se fait sur du texte, avant qu'un seul fichier ait bougé : corriger un plan coûte une relecture, corriger un refactor à moitié fait coûte un git diff entier à démêler.

Ce qu'un bon plan doit montrer, pas seulement dire#

Un plan qui se contente d'annoncer « je vais modifier X pour faire Y » ne vaut pas grand-chose : n'importe quel plan peut s'énoncer ainsi. Ce qui rend un plan vérifiable, c'est qu'il nomme les fichiers concernés, explique le choix retenu face aux alternatives écartées, et signale explicitement les points d'incertitude plutôt que de les lisser. Un plan qui ne mentionne aucune alternative écartée est souvent un plan qui n'a pas vraiment été comparé à d'autres options, juste rédigé après coup pour justifier la première idée venue.

La limite : Plan Mode ne remplace pas le jugement#

Un plan bien écrit reste un texte produit par un modèle probabiliste : il peut être cohérent, détaillé, et pourtant reposer sur une hypothèse fausse sur le code existant. Le lire vraiment, en vérifiant les affirmations factuelles qu'il contient (tel fichier existe-t-il vraiment à cet endroit, telle fonction a-t-elle vraiment cette signature), reste ma responsabilité, pas quelque chose que le mode garantit automatiquement.

Où ça se recoupe avec le TDD#

La logique de Plan Mode rejoint celle du TDD avec Claude Code : dans les deux cas, il s'agit de forcer un point d'arrêt explicite avant que le code ne parte dans une direction, plutôt que de découvrir le problème une fois le travail avancé. Le test rouge avant l'implémentation, le plan avant l'édition : même principe, appliqué à deux moments différents du cycle.

Ce que ça change au quotidien#

Je couvre Plan Mode dans le module dédié de Claude Expert, parce que c'est un des réflexes qui distingue le plus nettement une session productive d'une session qui part dans le mur sans qu'on s'en rende compte avant plusieurs fichiers modifiés. La règle que j'applique tient en une phrase : sur toute tâche où je ne suis pas certain à l'avance de l'approche que je choisirais moi-même, le plan passe avant le code, jamais l'inverse.