ouvrir guide/chapitre-05 --plan-mode
Chapitre 5 · Acte II · Le geste professionnel
Explorer, planifier,
coder
11 min · espace pour avancer, flèches pour revenir
Le réflexe
« Vas-y, code » est le plus naturel qui soit. Et le plus coûteux.
Son contexte contient votre phrase, et à peu près rien d'autre. Alors il comble les trous avec du vraisemblable : vous retrouvez le code plausible du chapitre 1.
En quinze ans, je n'ai jamais vu un bon développeur pousser du code dans l'heure. Il lit, il propose, et ensuite il écrit.
Exiger la même chose de Claude n'est pas de la méfiance, c'est du management.
Trois temps, trois gestes
- 01 · ExplorerFaire lire les fichiers concernés et restituer l'état des lieux. Puis la consigne qui change tout : « ne code rien ».
- 02 · PlanifierLe plan mode : Claude ne touche plus aux fichiers, il propose et attend votre validation.
- 03 · CoderEn dernier, avec les fichiers, les contraintes, le résultat attendu et les interdits.
Quelques minutes qui déplacent votre intervention là où elle vaut le plus cher : avant que le code n'existe.
Chez Talia · le remboursement des séances annulées
❯ claude ❯ Lis le module de paiement et explique-moi comment les ❯ remboursements sont gérés aujourd'hui. Ne code rien. · Claude explore le projet... Lu : payments/, 6 fichiers. Le remboursement passe par refund.ts. Remarque : le webhook Stripe n'est pas vérifié. ❯ Bien vu, note-le. Passe en plan mode : remboursement partiel. Plan : 1. montant validé côté serveur 2. webhook signé 3. un test par règle métier. J'attends votre relecture.
Le plan est court, lisible, et il attend. Regardez la route se tracer derrière, en pointillé : rien n'est encore écrit.
À vous
Le plan tient en trois lignes et attend votre validation. Que faites-vous ?
Choisissez : la scène vous répond.
La relecture, et ce qu'elle évite
❯ Point 2 : le motif de remboursement ne se stocke pas en ❯ clair. Et ajoute le cas du webhook reçu deux fois. Plan amendé : motif chiffré, webhook idempotent. ❯ Validé. Code, puis lance toute la suite de tests. · Claude implémente... 11 fichiers modifiés. Tests : 9 passés, 0 échec. Le webhook rejoué aurait doublé un remboursement en production. L'éviter a coûté une phrase de relecture.
Le webhook rejoué aurait doublé un remboursement en production. L'éviter a coûté une phrase.
Trois prompts, du réflexe au métier
Tels qu'ils arrivent
Devine ce que je veux
- « Ajoute un formulaire de contact »
- « Y a un bug à la connexion, corrige-le »
- « L’app est lente, améliore les performances »
Tels qu’ils repartent
Exécute ce que j’ai décidé
- « Validation serveur, réutilise Field. Done : le test passe »
- « Reproduis dans un test, corrige, ne touche à rien d’autre »
- « Mesure d’abord, dis-moi la cause, propose ensuite »
La colonne de gauche laisse Claude choisir le périmètre, l'outil et la définition du succès. Celle de droite garde ces trois décisions pour vous.
Un bon prompt de code
4ingrédients
Les fichiers concernés, les contraintes, le résultat attendu, et les interdits.
Rien d'un exploit : quelques secondes de réflexion en plus, qui transforment « devine » en « exécute ».
Donner la chose, pas sa description
- @fichier« Regarde @booking/rules.ts » vaut mieux que trois lignes pour dire où le code se trouve.
- Une captureElle se colle telle quelle : l'image de l'écran cassé remplace un paragraphe d'approximations.
- Une URLDonnée brute, à charge pour Claude de la lire. Autorisez le domaine une bonne fois.
- Le terminalcat erreur.log | claude pousse le fichier dans la demande, sans presse-papiers.
Une description approximative est une façon coûteuse de mettre du flou là où vous pouviez mettre du fait.
Au-delà d'une certaine taille
Un plan vit dans la session, et une grosse fonctionnalité déborde toujours d'une session. C'est le territoire du spec-driven.
- L'interview inversée→« pose-moi une par une toutes les questions nécessaires, puis rédige SPEC.md ».
- La relecture→vous amendez comme un plan : un cas limite ajouté, une priorité durcie.
- Git→la spec survit aux sessions, aux /clear et aux semaines. Elle arbitre les doutes.
GitHub en a fait un outillage complet avec Spec Kit. Le principe est partout le même : la spec d'abord, la validation ensuite, le code en dernier.
Et parfois : codez direct
Si vous pouvez décrire le diff attendu en une phrase, codez direct.
« Le bouton Annuler devient gris » n'a pas besoin d'un plan. « Refonds la gestion des erreurs » en a absolument besoin. Dans le doute, un plan court coûte une minute.
Fin du chapitre 5
Retenez surtout ceci : la vraie assurance ne vient pas du plan, elle vient de la preuve. Un plan parfait sans vérification ne rattrape rien.
La version article garde tout : la FAQ, les détails, les liens. Cette traversée en est la bande-annonce habitée.