Votre projet a maintenant sa mémoire : CLAUDE.md et les fichiers de cadrage du chapitre 3. La tentation, c'est de foncer : décrire la fonctionnalité, appuyer sur Entrée, regarder le code tomber. Parfois ça passe. Souvent, ça produit du code plausible : propre, commenté, convaincant, et à côté du besoin, parce que Claude a comblé les trous de votre demande avec ses propres hypothèses.
Ce chapitre installe le geste central du métier : explorer d'abord, planifier ensuite, coder en dernier. Trois temps qui coûtent quelques minutes et qui déplacent votre intervention là où elle vaut le plus cher : avant que le code n'existe. Et parce qu'aucune règle professionnelle ne survit au dogme, on verra aussi quand s'en passer.
« Vas-y, code », le réflexe qui coûte cher
Souvenez-vous du chapitre 2 : Claude travaille avec ce qui est dans son contexte, rien d'autre. Quand vous lancez « ajoute la gestion des remboursements » sans autre forme de procès, son contexte contient votre phrase, et c'est à peu près tout. Il ne sait pas encore comment votre projet encaisse les paiements, quelles conventions vous suivez, quels cas limites comptent pour vous.
Alors il fait ce qu'un modèle de langage fait le mieux : il comble les trous avec du vraisemblable. Le résultat compile, s'exécute, et repose sur une dizaine de décisions que personne n'a prises consciemment. Vous retrouvez le code plausible du chapitre 1, celui qui brille à la démo et qui casse dans les recoins.
En quinze ans de développement, je n'ai jamais vu un bon développeur arriver sur un projet et pousser du code dans l'heure. Il lit, il pose des questions, il propose, et seulement ensuite il écrit. Personne ne trouve ça lent : c'est ce qui distingue le professionnel du stagiaire pressé. Exiger la même chose de Claude n'est pas de la méfiance, c'est du management. Le workflow tient en trois mots, et chaque mot a son geste.
- ExplorerInterdire l'écriture, et terminer par la consigne qui change tout : « ne code rien ».
- PlanifierLe plan se relit et s'amende avant que le code n'existe.
- CoderSe joue en réalité dans la formulation de la demande.
Explorer : faire lire avant de faire écrire
Demandez à Claude de lire les fichiers concernés et de vous restituer un état des lieux : comment ça marche aujourd'hui, où sont les points d'entrée, qu'est-ce qui le surprend.
Ce temps de lecture a une double vertu. D'abord, il vous informe : la restitution révèle souvent un détail que vous aviez oublié, ou un problème existant que la nouvelle fonctionnalité aurait aggravé. Ensuite, il remplit le contexte avec les bonnes choses : au moment de coder, Claude s'appuiera sur ce qu'il vient réellement de lire dans votre projet, pas sur ses habitudes statistiques.
L'exploration est aussi le bon moment pour poser vos propres questions : « pourquoi ce module dépend-il de celui-là ? », « qu'est-ce qui casserait si on changeait ce schéma ? ».
Vous apprenez votre propre projet en le faisant expliquer.
Planifier : le plan mode, et le moment où vous valez cher
Le deuxième temps a son outil dédié : le plan mode. Activez-le et Claude ne touche plus aux fichiers. Il réfléchit, propose un plan d'attaque, et attend votre validation avant d'écrire la moindre ligne.
L'intérêt n'est pas le plan lui-même, c'est ce qu'il rend possible. Une ligne de plan douteuse se corrige en une phrase. La même erreur, découverte dans le code, se paie en une session de débogage.
C'est ici, très exactement, que l'humain apporte le plus de valeur dans tout le workflow : vous connaissez le métier, les contraintes réelles, les cas qui font mal. Le plan est l'endroit où cette connaissance s'injecte au meilleur prix. Voyons le cycle complet sur une vraie fonctionnalité du cabinet de Talia, la kiné du chapitre 1 : le remboursement des séances annulées à temps.
❯ 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. C'est le moment de le lire pour de vrai, pas de le survoler.
Chaque ligne que vous acceptez est une décision que vous prenez.
❯ 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.
Trois prompts, avant et après
Un bon prompt de code contient quatre ingrédients.
- 01 · Les fichiers concernésOù travailler.
- 02 · Les contraintesRègles métier, conventions.
- 03 · Le résultat attenduUn critère de done vérifiable.
- 04 · Les interditsCe qu'il ne faut pas toucher.
Regardez trois prompts réels passer du réflexe au métier.
Tels qu'ils arrivent
- « Ajoute un formulaire de contact au site »
- « Y a un bug à la connexion, corrige-le »
- « L'app est lente, améliore les performances »
Tels qu'ils repartent
- « Formulaire sur /contact : nom, email, message. Validation côté serveur, réutilise le composant Field. Aucune librairie en plus. Done : le test d'envoi passe »
- « À la connexion, un email avec une majuscule échoue. Regarde auth/login.ts. Reproduis dans un test, corrige, ne touche à rien d'autre »
- « La liste des commandes met plusieurs secondes à s'afficher. Mesure d'abord, dis-moi la cause, propose avant d'optimiser »
La version de droite n'a rien d'un exploit : quelques secondes de réflexion en plus. Mais elle transforme la tâche de « devine ce que je veux » en « exécute ce que j'ai décidé ». La colonne de gauche laisse Claude choisir le périmètre, l'outil et la définition du succès ; la colonne de droite garde ces trois décisions pour vous.
Donner de la matière, pas seulement des mots
Les quatre ingrédients disent quoi écrire. Reste la question de ce que vous posez dans la fenêtre à côté du texte, et c'est là que beaucoup se compliquent la vie sans le savoir.
Le préfixe @ référence un fichier directement dans votre phrase : « regarde @booking/rules.ts » vaut mieux que trois lignes pour expliquer où le code se trouve, et vous épargne le collage massif que le chapitre 10 vous apprendra à facturer. Une capture d'écran se colle telle quelle dans le prompt, et c'est le chemin le plus court pour faire comprendre un problème d'interface : l'image de l'écran cassé remplace un paragraphe d'approximations. Une URL de documentation se donne brute, à charge pour Claude d'aller la lire ; si vous revenez toujours aux mêmes sources, autorisez leur domaine une bonne fois plutôt que de valider à chaque consultation. Et le terminal reste le terminal : cat erreur.log | claude pousse le contenu d'un fichier dans la demande sans passer par le presse-papiers.
Ces quatre gestes remplacent votre description d'une chose par la chose elle-même.
Vous savez depuis le chapitre 2 pourquoi c'est décisif : ce qui n'est pas dans le contexte n'existe pas pour Claude. Une description approximative est une façon coûteuse de mettre du flou là où vous pouviez mettre du fait.
La spec d'abord, pour les grosses fonctionnalités
Au-delà d'une certaine taille, le plan mode ne suffit plus : un plan vit dans la session, et une grosse fonctionnalité déborde toujours d'une session. C'est le territoire du spec-driven : faire écrire une spécification versionnée, la valider, puis la dérouler.
Le geste le plus efficace pour l'obtenir est l'interview inversée, déjà croisée au chapitre 3 : ne rédigez pas la spec vous-même, faites-vous interroger. « Pose-moi une par une toutes les questions nécessaires pour écrire la spec de cette fonctionnalité, puis rédige SPEC.md. » Claude pose alors les questions qu'un product owner poserait : les cas limites, les priorités, ce qui est hors périmètre. Vous répondez, il rédige, vous relisez et amendez, exactement comme un plan.
Puis la spec entre dans git : elle se versionne, sert d'arbitre quand un doute surgit en cours d'implémentation, et survit aux sessions, aux /clear et aux semaines.
L'approche a dépassé le stade de l'astuce personnelle : GitHub en a fait un outillage complet avec Spec Kit, et des praticiens comme Harper Reed l'ont popularisée en la documentant sur leurs propres projets. Les variantes diffèrent, le principe est partout le même : la spec d'abord, la validation ensuite, le code en dernier.
Et parfois : codez direct
Ce serait mentir de terminer sans la nuance, car elle a grandi avec les modèles : tout ne mérite pas un plan. Corriger une coquille, renommer un champ, ajouter un log : imposer le cycle complet à ces tâches relève de la bureaucratie, pas de la méthode. Avec les modèles récents, la frontière s'est même déplacée : sur une petite tâche bien cadrée, le plan systématique est devenu du luxe, et c'est la vérification exécutable qui fait le vrai travail de filet de sécurité.
Retenez surtout ceci : la vraie assurance ne vient pas du plan, elle vient de la preuve. Un critère de done exécutable rattrape la plupart des raccourcis de cadrage ; un plan parfait sans vérification ne rattrape rien. C'est l'objet du chapitre suivant, et c'est le levier n°1 de tout le guide.
Questions fréquentes sur le workflow explorer, planifier, coder
Qu'est-ce que le plan mode de Claude Code ?
Le plan mode est un mode de travail où Claude explore et propose un plan d'action sans modifier aucun fichier. Il sert à séparer la réflexion de l'exécution : vous relisez le plan, l'amendez si besoin, puis validez, et seulement alors Claude passe au code. C'est le moment le plus rentable pour intervenir : corriger une ligne de plan coûte une phrase, corriger la même erreur une fois codée coûte une session de débogage.
Comment bien prompter pour générer du code ?
Un bon prompt de code contient quatre ingrédients : les fichiers concernés (où travailler), les contraintes (règles métier, conventions), le résultat attendu (un critère de done vérifiable) et les interdits (ce qu'il ne faut pas toucher). « Corrige le bug de connexion » laisse tout deviner ; « reproduis dans un test le bug de l'email en majuscules, corrige auth/login.ts, ne touche à rien d'autre » ne laisse rien deviner d'important.
Qu'est-ce que le spec-driven development ?
Le spec-driven development consiste à faire écrire par l'IA une spécification complète de la fonctionnalité (périmètre, règles, cas limites), à la valider humainement, puis à la faire implémenter en s'y référant. La spec est versionnée dans git : elle survit aux sessions et sert d'arbitre en cours de route. L'approche s'est outillée, notamment avec Spec Kit de GitHub, et s'adresse aux fonctionnalités trop grosses pour tenir dans un simple plan.
Faut-il planifier même les petites tâches ?
Non. Si le diff attendu se décrit en une phrase (« le bouton Annuler devient gris »), le plan est du luxe : codez direct, la vérification du chapitre 6 fera le filet de sécurité. Le plan s'impose dès que la tâche touche plusieurs fichiers, une règle métier sensible ou une zone du code que vous connaissez mal. Dans le doute, un plan court coûte une minute et se relit en trente secondes.
La suiteUn plan validé n'est encore qu'une intention. Au chapitre 6, on installe le levier le plus puissant de tout le guide : donner à Claude un moyen de prouver que son travail est juste, au lieu de vous demander de le croire.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe