Claude Code Plan Mode : activation, phases et prompts

Des instructions supplémentaires figurent dans la documentation Ailoot.

Qu’est-ce que Plan Mode, et pourquoi ne suffit-il pas à lui seul ?#

En mode normal, Claude Code écrit immédiatement du code et, si vous ne suivez pas ce qu’il fait, vous pouvez obtenir un diff touchant de nombreux fichiers, sorti de nulle part. Plan Mode inverse les étapes : d’abord la recherche et la planification, puis l’approbation, puis les modifications.

Anthropic décrit ainsi Plan Mode dans sa documentation officielle :

Cela paraît simple, mais masque le principal changement. Plan Mode modifie le rythme du travail : se mettre d’accord d’abord, agir ensuite. C’est un changement de mode, pas un ajustement cosmétique. Le problème pour les vibe coders, c’est que les agents IA ont tendance à se précipiter. Si vous demandez « Ajoute l’authentification Google » en mode normal, Claude écrira le code en une minute, mais la moitié des fichiers ne seront pas les bons. Dans Plan Mode, la même demande devient un plan textuel que vous pouvez lire en deux minutes et corriger avant que le moindre code soit touché.

Voici un piège dont personne ne parle dans les guides internationaux. Plan Mode seul est un outil limité : le plan n’existe que dans la conversation en cours. Fermez la fenêtre, et le plan est perdu. Vous ne pouvez pas le transmettre à un autre agent. Il n’y a ni versions ni historique. Si la tâche est importante (refactorisation d’un module de 30 fichiers, migration vers une nouvelle base de données), le plan atteindra rapidement la limite de la fenêtre de contexte et commencera à se dégrader.

C’est pourquoi Plan Mode fonctionne bien avec un dossier plans/ dans le dépôt. Le plan est enregistré sous plans/2026-05-21-google-oauth.md, découpé en phases avec des cases à cocher, et tout agent qui intervient ensuite peut le reprendre. C’est ainsi que fonctionne l’ingénierie du contexte : gérer le contexte avant le prompt, pas pendant.

Comment activer Plan Mode dans Claude Code ?#

La méthode la plus rapide pendant une session consiste à utiliser le clavier :

Shift+Tab           # parcourt les modes : default → acceptEdits → plan

Après deux pressions, l’indicateur ⏸ plan mode on apparaît en bas du terminal. Une troisième pression ramène au mode normal. C’est la méthode la plus pratique : vous basculez à la volée lorsque vous voyez que la tâche prend de l’ampleur.

La deuxième méthode consiste à ajouter un préfixe avant un prompt unique :

/plan rédige un plan pour migrer la base de données de MySQL vers Postgres

Cette option est utile lorsque vous êtes en mode d’acceptation automatique et ne voulez pas le changer pour toute la session. Une seule demande en Plan Mode, puis le travail reprend comme avant.

La troisième méthode s’utilise au lancement de la session :

claude --permission-mode plan

Utilisez-la lorsque vous savez à l’avance qu’une tâche nécessite une planification, par exemple avant une refactorisation majeure ou une migration.

La quatrième méthode consiste à définir la valeur par défaut dans .claude/settings.json du projet :

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Dans quel cas est-ce utile ? Lorsqu’une équipe travaille sur un système complexe où chaque modification peut affecter les modules voisins. Le mode Plan activé par défaut protège alors tout le monde des modifications accidentelles.

Une cinquième astuce souvent oubliée : Ctrl+G ouvre le plan dans un éditeur de texte. Utilisez cette option lorsque le plan est presque bon, mais que vous devez reformuler 2-3 points ou ajouter une contrainte. Modifiez-le manuellement, enregistrez, et Claude poursuivra avec votre version.

Quelles sont les 4 phases canoniques d’Anthropic dans Plan Mode : Explore, Plan, Implement, Commit ?#

De nombreux guides décrivent 3 phases (Explore-Plan-Execute) ou seulement 2 (Plan-Implement). Ce sont des simplifications. Dans son guide officiel des bonnes pratiques, Anthropic décrit exactement 4 phases. La différence compte : la phase Commit séparée vous oblige à consigner le résultat au lieu d’en rester à « J’ai fait encore quelques ajustements, je ferai le commit plus tard », la source la plus fréquente de travail perdu.

Plus le plan est précis, moins l’implémentation nécessite d’itérations. Si vous consacrez 10 minutes au plan, un prompt suffira à l’implémentation. Si vous l’esquissez en une minute, l’implémentation vous demandera une heure de corrections.

Voici à quoi ressemblent les 4 phases pour ajouter Google OAuth (un exemple tiré d’Anthropic Docs) :

Les prompts diffèrent également selon la phase. Dans Explore : « lis /src/auth et comprends comment nous gérons les sessions et la connexion ». Dans Plan : « Je veux ajouter Google OAuth. Quels fichiers faut-il modifier ? Crée un plan ». Dans Implement : « mets en œuvre le flux OAuth de ton plan, écris des tests, exécute la suite et corrige les échecs ». Dans Commit : « crée un commit avec un message explicite et ouvre une PR ».

Une nuance importante : Plan Mode n’empêche pas Claude d’exécuter des commandes pour ses recherches. Read, LS, Glob, Grep, web fetch et les commandes shell d’exploration sont autorisés. Seuls Edit, Write et toute opération de système de fichiers qui modifie des données sont interdits. Claude peut donc lire la structure du projet, exécuter git log et examiner les tests, mais ne pourra rien modifier par accident.

Comment lire le plan de Claude et décider si vous devez l’approuver ?#

Lorsque Claude a terminé son plan, il propose plusieurs options pour la suite :

• Approuver et démarrer en mode automatique
• Approuver et accepter les modifications
• Approuver et examiner manuellement chaque modification
• Continuer la planification en donnant des commentaires
• Affiner avec Ultraplan (examen dans le navigateur)

Savoir s’il faut approuver un plan est la compétence clé dans Plan Mode. Il est facile d’appuyer automatiquement sur « Approuver », puis de devoir annuler des commits. L’IA complaisante veut donner une réponse rapide, et vous voulez passer plus vite au code. Vous avez tous les deux tort.

Un bon plan répond à 7 critères :

1. Des noms de fichiers précis. Pas « Je vais mettre à jour l’authentification », mais « Je vais modifier src/auth/login.ts:42-58, créer src/auth/oauth-callback.ts et mettre à jour src/auth/session.ts:103. »
2. La séquence est définie. Le plan est divisé en phases ou en étapes, et ne se contente pas de dire « Je ferai tout ça d’une manière ou d’une autre ».
3. Les dépendances externes sont nommées. Si la tâche nécessite une nouvelle bibliothèque, elle est indiquée. Si des variables d’environnement sont nécessaires, elles sont mentionnées.
4. Les risques sont listés. Un bon plan indique : « La migration pourrait perturber les sessions existantes ; il faut vérifier X. » Un mauvais plan ne dit rien des effets secondaires.
5. Des critères de réussite sont définis. « Les tests de test/auth réussissent, le linter ne signale rien et le serveur de développement démarre sans erreur. »
6. Aucune hypothèse n’est sortie de nulle part. Si Claude dit « Je vais utiliser la bibliothèque Z », vérifiez : l’avez-vous installée dans le projet ? Si l’IA l’a inventée, vous verrez qu’elle ne figure pas dans package.json.
7. Le plan tient à l’écran. Si le plan d’une fonctionnalité simple fait 200 lignes, la tâche est probablement trop grande pour un seul plan. Divisez-la.

Si un plan ne passe pas cette vérification, vous avez trois options :

• Continuer la planification avec des commentaires : donnez à Claude un commentaire précis sur ce qui ne vous convient pas, et il réécrira le plan.
• Ctrl+G : ouvrez le plan dans un éditeur, modifiez-le manuellement et enregistrez-le. Claude poursuivra avec votre version.
• Affiner avec Ultraplan : le plan passe en mode navigateur de Claude Code sur le Web, où vous examinez des sections et les commentez, puis vous l’exécutez localement ou dans le cloud.

Si quelque chose se passe mal au milieu de l’implémentation, ne forcez pas. Revenez à Plan Mode et réécrivez le plan. C’est 10 fois moins coûteux que d’annuler 40 commits plus tard.

Plan Mode + un dossier plans/ : une combinaison pour les contextes longs#

Plan Mode est un mode de Claude Code. Le dossier plans/ est une méthode construite par-dessus. Si vous utilisez Plan Mode sans dossier, vous atteindrez la limite après une heure de travail.

Voici la logique. La fenêtre de contexte de Claude constitue la mémoire de la session. Elle peut contenir 1 million de tokens dans Opus 4.7, mais cela correspond au volume de toute votre conversation. Si vous planifiez une tâche complexe dans une conversation, lui demandez ensuite de l’implémenter, discutez d’un bug, puis d’autre chose, la fenêtre se « gonfle ». Claude commence à oublier les premières décisions, à confondre les contextes et à poser de nouveau les mêmes questions.

La solution tient en une règle d’or : une tâche, une conversation.

Voici comment procéder :

1. Conversation 1 — élaborer le plan. Activez Plan Mode, décrivez la tâche et Claude crée un plan. Enregistrez-le sous plans/2026-05-21-feature-name.md. Fermez la fenêtre.
2. Conversation 2 — le diviser en phases. Ouvrez un nouveau chat. Demandez : « prends plans/2026-05-21-feature-name.md et divise-le en phases ». Enregistrez le fichier mis à jour.
3. Conversation 3 — mettre en œuvre la phase 1. Ouvrez un nouveau chat. Demandez : « mets en œuvre la phase 1 de plans/2026-05-21-feature-name.md et coche les éléments au fur et à mesure que tu les termines ». Fermez la fenêtre.
4. Conversation 4 — mettre en œuvre la phase 2. Faites de même.

Qu’est-ce que cela vous apporte ? La fenêtre de contexte de chaque conversation reste fraîche. À la phase 3, Claude ne connaît pas les détails de la phase 1, mais il connaît le plan, puisque le fichier plans/ se trouve dans le dépôt. Tout agent qui intervient ensuite (qu’il s’agisse d’un sous-agent, d’une nouvelle session ou d’une exécution via /goal) peut reprendre le plan et continuer.

Comparaison des approches :

Chaque fonctionnalité a son propre fichier de plan. Si, trois mois plus tard, vous devez vous rappeler pourquoi vous avez choisi un fournisseur de paiement plutôt qu’un autre, vous pouvez ouvrir le plan correspondant et consulter l’historique des décisions : ce qui a été discuté, les options envisagées et les raisons de ce choix.

Ce sont des plans de travail évolutifs ; la documentation statique devient obsolète en quelques mois.

Comment faire travailler Claude pendant que vous dormez avec Plan Mode et /goal ?#

La principale limite des longues sessions d’IA n’est pas le modèle lui-même, mais la personne qui appuie sur Entrée. Chaque fois que Claude arrive à la fin d’un tour, il attend votre réponse. /goal supprime cette attente.

La syntaxe est simple :

/goal tous les tests de test/auth réussissent et lint ne signale rien, ou arrêter après 20 tours

La condition peut contenir jusqu’à 4000 caractères. Un seul objectif par session. Après chaque tour, le mini-modèle Haiku examine la transcription et décide : « condition remplie — terminer » ou « non remplie — tour suivant ». L’évaluateur n’appelle aucun outil ; il se contente de lire.

Alias pour effacer l’objectif : /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Voici comment combiner cette commande avec Plan Mode :

1. Activez Plan Mode (appuyez deux fois sur Shift+Tab).
2. Demandez : « crée un plan pour migrer la base de données de MySQL vers Postgres et enregistre-le sous plans/2026-05-21-postgres-migration.md, avec des phases et des critères ».
3. Examinez le plan, modifiez-le et approuvez-le.
4. Quittez Plan Mode (appuyez encore une fois sur Shift+Tab).
5. Définissez un objectif : « termine toutes les phases de plans/2026-05-21-postgres-migration.md, coche les cases, tous les tests doivent réussir, ou arrête-toi après 50 tours ».
6. Fermez votre ordinateur portable et allez dormir.

Le matin, vérifiez le résultat : soit « ✓ objectif atteint », soit « ◎ arrêté après 50 tours », avec l’historique du travail effectué.

Il existe trois règles essentielles pour /goal, sous peine de gaspiller des tokens :

Règle 1 : un état final mesurable. « Fais en sorte que ce soit joli » est mauvais. « npm test renvoie 0, npm run lint renvoie 0 et une entrée a été ajoutée à CHANGELOG.md » est bien mieux.

Règle 2 : une vérification explicite. La condition doit faire référence à quelque chose de vérifiable : une commande, un fichier ou un endpoint. Pas « tout fonctionne », mais « curl localhost:3000/api/users renvoie 200 ».

Règle 3 : limiter le nombre de tours. Ajoutez toujours « ou arrêter après N tours ». Anthropic le recommande explicitement dans sa documentation :

Si vous activez /goal sans ajouter « ou arrêter après », votre budget peut disparaître pendant la nuit.

Quel cycle en 4 étapes transforme Plan Mode en processus d’ingénierie ?#

Une erreur fréquente consiste à demander « comment régler ça ? » : Claude propose une solution, vous l’appliquez, mais rien ne fonctionne ou la situation empire. C’est l’« IA complaisante » : elle est entraînée à répondre rapidement, et vous voulez passer plus vite au code. Un cycle en 4 étapes permet d’y remédier.

Ce cycle en 4 étapes bloque ce comportement. Il s’utilise dans l’ordre au cours d’une même session Plan Mode :

Étape 1. Établir les faits sans proposer de solution.

Prompt : « Voici ce que je constate : [description du symptôme]. Ta tâche consiste maintenant à établir les faits. Toute solution, idée ou recommandation est interdite. Uniquement : ce que j’observe, les étapes reproductibles, les données disponibles et les données manquantes. Condition d’arrêt stricte : NE propose PAS de solution ; consigne uniquement le diagnostic. »

Cela bloque le premier réflexe de l’IA : « voici la solution ». Claude doit s’arrêter à « qu’est-ce qui est connu et qu’est-ce qui ne l’est pas ? ».

Étape 2. Élaborer des options à partir de précédents.

Prompt : « Maintenant que le diagnostic est établi, trouve en ligne des précédents pour résoudre des problèmes similaires. Au moins 3 approches différentes. Pour chacune : un lien vers la source primaire, une brève description, ainsi que ses avantages et inconvénients dans notre situation. »

Cela bloque le deuxième réflexe de l’IA : « inventer une solution de toutes pièces ». Nous lui demandons d’aller chercher dans le monde réel des approches qui peuvent être vérifiées.

Étape 3. Élaborer un plan détaillé avec les risques.

Prompt : « Prends la meilleure option de l’étape 2 et élabore un plan détaillé : quels fichiers précis modifier, quoi ajouter, quoi supprimer, quels tests écrire, ce qui pourrait casser et quels risques se profilent 2-3 étapes plus loin ? »

C’est la phase Plan habituelle, mais avec une différence : elle s’appuie sur les options vérifiées de l’étape 2, et non sur les suppositions de Claude.

Étape 4. Faire une auto-vérification du plan.

Prompt : « Effectue maintenant une auto-vérification obligatoire. Réexamine honnêtement ton plan : y a-t-il des éléments que tu as inventés sans les vérifier dans le code, la documentation ou un précédent de l’étape 2 ? Si oui, signale-les et révise le plan. »

C’est le filtre final. Claude doit examiner son propre raisonnement et reconnaître les endroits où il a halluciné. Cette étape conduit généralement à la révision d’au moins 2 éléments du plan.

Après ces 4 étapes, le plan est prêt à être approuvé. Vous pouvez passer à l’implémentation en sachant que la tâche est comprise, que les options ont été évaluées et que les risques ont été pris en compte.

Cette méthode sert à diagnostiquer des bugs difficiles et à prendre des décisions d’architecture, là où une erreur coûte cher. Appliquée à Plan Mode, elle élimine le principal problème des vibe coders : « l’IA m’a donné une solution, je l’ai appliquée, et tout a cassé ».

Quels sont les 5 prompts prêts à l’emploi qui fonctionnent dans Plan Mode pour les tâches courantes ?#

Modèle 1. Refactoriser un module.

J’active Plan Mode. Tâche : refactoriser le module {module-name}.

Étape 1 : Étudie la structure actuelle du module {module-path}. Décris :
- quels fichiers font partie du module
- quelles dépendances externes il a
- quelles parties sont dupliquées
- quelles fonctions sont trop complexes

Étape 2 : Trouve en ligne 2-3 exemples de refactorisation de modules similaires.
Au moins 1 source doit être une documentation officielle d’Anthropic ou du framework concerné.

Étape 3 : Crée un plan de refactorisation dans plans/YYYY-MM-DD-refactor-{module}.md :
- quels fichiers renommer
- quelles fonctions extraire dans des modules séparés
- quels tests conserver et lesquels réécrire
- risques : qu’est-ce qui pourrait ne plus fonctionner pour les utilisateurs ?

Étape 4 : Auto-vérification. Le plan contient-il des hypothèses « sorties de nulle part » ?
Réécris-les ou supprime-les.

Modèle 2. Migration de base de données.

J’active Plan Mode. Tâche : migrer la base de données de {old} vers {new}.

Étape 1 : Étudie le schéma actuel de la base de données à l’aide de {schema-reading-command}. Décris :
- quelles tables existent et leur taille
- quelles relations, quels index et quelles contraintes sont présents
- où les migrations sont stockées
- quelles données sont critiques

Étape 2 : Trouve des précédents de migrations de {old → new} dans des projets en production.
Au moins 3 approches différentes : pg_dump, dual-write, blue-green.
Pour chacune, indique les avantages et les risques compte tenu du volume de nos données.

Étape 3 : Crée un plan de migration dans plans/YYYY-MM-DD-db-migration.md :
- phases (sauvegarde, migration, vérification, bascule)
- critères de réussite pour chaque phase
- plan de rollback en cas de problème
- avec ou sans temps d’arrêt

Étape 4 : Auto-vérification. Tous les chiffres sont-ils étayés par la documentation ?
Toutes les étapes ont-elles été vérifiées mentalement par rapport à l’environnement de développement ?

Modèle 3. Ajouter une nouvelle fonctionnalité.

J’active Plan Mode. Tâche : ajouter la fonctionnalité {description} au projet.

Étape 1 : Étudie le fonctionnement actuel des fonctionnalités similaires dans le projet.
Examine en particulier :
- {file-1}
- {file-2}
- les modèles d’architecture utilisés
- les tests écrits pour des fonctionnalités similaires

Étape 2 : Trouve comment cette fonctionnalité est implémentée dans des projets open source
avec une architecture similaire. Au moins 2 approches différentes.

Étape 3 : Crée un plan dans plans/YYYY-MM-DD-feature-{name}.md :
- liste des nouveaux fichiers
- liste des fichiers modifiés avec les lignes précises
- séquence d’implémentation
- tests à ajouter
- règle à ajouter à CLAUDE.md pour les sessions futures

Étape 4 : Auto-vérification. Le plan respecte-t-il l’architecture du projet ?
Suppose-t-il l’existence de bibliothèques qui n’ont pas encore été installées ?

Modèle 4. Écrire des tests.

J’active Plan Mode. Tâche : couvrir le module {name} avec des tests.

Étape 1 : Étudie le module {path}. Repère :
- les fonctions publiques et leurs signatures
- les fonctions internes que nous NE testerons PAS (détails d’implémentation)
- les cas limites : entrée vide, erreurs, accès simultané

Étape 2 : Trouve des exemples de tests pour une catégorie de tâches similaire
dans des projets open source populaires utilisant le même framework.

Étape 3 : Crée un plan de tests dans plans/YYYY-MM-DD-tests-{module}.md :
- pour chaque fonction publique, une liste de tests
- les mocks nécessaires
- les fixtures nécessaires
- l’approche de vérification à utiliser (style d’assertion)

Étape 4 : Auto-vérification. Tous les tests vérifient-ils le comportement plutôt que l’implémentation ?
La couverture inclut-elle les cas limites ?

Modèle 5. Déboguer une erreur complexe.

J’active Plan Mode. Tâche : comprendre la cause de l’erreur {symptom-description}.

Étape 1 : ÉTABLIS LES FAITS. Les solutions et les idées sont interdites. Uniquement :
- ce que j’observe (formulation exacte de l’erreur)
- les étapes reproductibles
- les données disponibles (journaux, traces, versions des bibliothèques)
- les données manquantes (ce qu’il faut recueillir en plus)

Étape 2 : Trouve des précédents pour cette erreur.
Au moins 3 sources : documentation officielle et autres sources utiles.
Pour chacune, donne un lien et un bref résumé de la solution.

Étape 3 : Crée un plan de diagnostic dans plans/YYYY-MM-DD-bug-{name}.md :
- les hypothèses à vérifier (classées par probabilité)
- les commandes/scripts à exécuter pour vérifier chacune
- le résultat attendu de chaque vérification

Étape 4 : Auto-vérification. Y a-t-il dans le plan des hypothèses « sorties de nulle part » ?
Toutes les hypothèses sont-elles liées aux faits de l’étape 1 ?

Copiez chaque modèle, remplacez {parameters} par vos propres valeurs et collez-le dans Claude Code en Plan Mode. Vous obtiendrez un plan de travail dans plans/, que vous pourrez approuver et utiliser pour l’implémentation.

Plan Mode ou mode normal : lequel choisir ?#

Anthropic l’indique directement dans sa documentation :

Les bonnes pratiques de Claude Code invitent à adapter la planification au périmètre et à l’incertitude. Un petit changement compris et peu risqué peut être direct ; une phrase courte ne suffit pas à éliminer les risques d’une migration ou de l’authentification.

Ne sautez le plan séparé que pour un diff réellement petit, compris et peu risqué. Planifiez pour découvrir l’approche ou coordonner des changements risqués entre composants. Connaître les noms de fichiers ou résumer l’objectif en une phrase ne supprime pas les risques de migration, d’authentification ou d’intégrité.

Tableau de décision :

Avant de choisir le mode, vérifiez si approche, effets secondaires et validation sont compris. Travaillez directement pour un petit changement localisé à faible risque et au contrôle évident. Planifiez en cas d’incertitude, de code inconnu, migration, authentification ou coordination, même si vous connaissez déjà les 3 à 5 fichiers concernés.

Comment combiner Plan Mode + CLAUDE.md + des subagents pour travailler de manière fiable ?#

CLAUDE.md est un fichier que Claude lit au début de chaque session, y compris en Plan Mode. Si CLAUDE.md indique « ne jamais coder les dates en dur ; toujours les récupérer dans la base de données », le plan ne suggérera jamais de coder une date en dur. En l’absence d’une telle règle, le plan peut proposer n’importe quoi.

Voici comment fonctionne cette combinaison :

Niveau 1. CLAUDE.md définit les règles.

Le fichier précise la stack du projet, ses principes d’architecture, ses interdictions (« ne pas utiliser d’API obsolètes ») et ses exigences (« tous les e-mails passent par une mise en page commune »). Guide détaillé : Comment configurer CLAUDE.md.

Niveau 2. Plan Mode applique les règles à la tâche.

Lorsque vous activez Plan Mode et demandez « ajoute OAuth », Claude lit CLAUDE.md, voit les règles (« stocker les tokens dans Redis, pas dans la base de données ») et en tient immédiatement compte dans le plan. Celui-ci respecte l’architecture du projet.

Niveau 3. Les subagents se répartissent le travail.

Si le plan est divisé en phases, chacune peut être confiée à un subagent distinct. Chaque subagent travaille dans sa propre fenêtre de contexte sans encombrer la fenêtre principale. Le plan dans plans/ reste la source de référence centrale : les subagents le lisent, exécutent leur phase et mettent à jour les cases à cocher.

Quelles sont les 7 erreurs qui font échouer Plan Mode ?#

Erreur 1. Le plan n’existe que dans le chat.

Symptôme : vous avez écrit un plan, fermé la fenêtre et devez y revenir le lendemain, mais il n’y a plus rien ; le contexte a disparu. Solution : enregistrez toujours le plan dans plans/YYYY-MM-DD-feature-name.md, dans le dépôt. Le chat est un bureau ; le fichier est une archive.

Erreur 2. Toutes les tâches sont dans un seul chat.

Symptôme : au cours d’une session, vous discutez d’authentification, puis d’une migration, de conception UI, puis d’un bug. La fenêtre de contexte se « gonfle » et Claude oublie les sujets précédents. Solution : une tâche, une conversation. Le plan est terminé ? Fermez la fenêtre. Vous commencez l’implémentation ? Ouvrez-en une nouvelle.

Erreur 3. Un plan de 3000 lignes sans phases.

Symptôme : il y a un plan, mais sans cases à cocher ni divisions. Impossible de savoir ce qui est fait et ce qui ne l’est pas. Impossible de déléguer. Solution : divisez chaque plan en 3-7 phases. Chaque phase est une liste de cases à cocher correspondant à des actions précises.

Erreur 4. Pas de recherche approfondie avant le plan.

Symptôme : Claude propose une solution de son cru parce que vous ne lui avez pas demandé de chercher des précédents. Une semaine plus tard, vous découvrez qu’une meilleure approche existe depuis longtemps dans l’open source. Solution : l’étape 2 du cycle en 4 étapes — demandez à Claude de trouver 2-3 précédents en ligne avant de créer un plan.

Erreur 5. L’IA complaisante propose une solution sans diagnostic.

Symptôme : vous demandez « comment corriger l’erreur X ? », Claude propose une solution, vous l’appliquez et rien ne fonctionne ou la situation empire. Solution : commencez toujours par « établis les faits ; les solutions sont interdites ». Passez aux options uniquement après le diagnostic.

Erreur 6. Sauter l’auto-vérification.

Symptôme : le plan semble plausible, mais contient 2-3 hypothèses « sorties de nulle part » (une bibliothèque inventée, une API inexistante ou une version incorrecte). L’implémentation échoue à cause de ces points. Solution : étape 4 du cycle en 4 étapes — demandez à Claude de revérifier honnêtement son plan et de signaler les hypothèses.

Erreur 7. Des conditions vagues dans /goal.

Symptôme : vous définissez /goal fais en sorte que ce soit joli, le laissez tourner pendant la nuit et découvrez au matin que $200 de quota ont été consommés. Solution : utilisez uniquement des conditions mesurables avec une commande de vérification et la mention obligatoire or stop after N turns. Pas de « fais ça bien » ni de « peaufine ».

La huitième erreur, la plus fréquente chez les vibe coders, consiste à ignorer complètement le concept du dossier plans/. Plan Mode sans dossier plans/ n’est pas une méthode, c’est un jouet. Si vous utilisez Plan Mode sans créer de fichiers, vous n’exploitez que 10 % de ses capacités.

Que faire ensuite après votre première expérience avec Plan Mode ?#

Trois étapes concrètes, par ordre croissant de difficulté :

Étape 1. Configurez CLAUDE.md si vous n’en avez pas encore.

Sans CLAUDE.md, Plan Mode fonctionne « dans le vide » : Claude ne connaît pas les règles du projet et propose des plans qui enfreignent l’architecture. Guide complet : Comment configurer CLAUDE.md. Un CLAUDE.md minimal compte 50-80 lignes et décrit la stack, les règles et les interdictions. La longueur est secondaire. C’est la précision qui compte.

Étape 2. Créez un dossier plans/ dans le dépôt.

Ajoutez un dossier plans/ à la racine du projet. Convenez d’un format de nommage : YYYY-MM-DD-feature-name.md. Chaque plan a son propre fichier. Au bout d’un mois, vous en aurez 20-30 ; au bout de six mois, 100+. C’est un historique vivant des décisions du projet.

Étape 3. Essayez /goal sur une tâche.

Choisissez une tâche que vous effectuez habituellement à la main pendant 30-40 minutes. Activez Plan Mode, créez un plan et enregistrez-le dans plans/. Quittez Plan Mode. Définissez /goal terminer toutes les phases de plans/file.md, faire réussir tous les tests, ou arrêter après 30 tours. Fermez votre ordinateur portable pendant une heure et faites autre chose. Revenez vérifier le résultat.

Ces trois étapes constituent le minimum. Cela se construit progressivement ; n’essayez pas de tout mettre en place en une soirée. Commencez par CLAUDE.md, ajoutez plans/ après une semaine et essayez /goal pendant la nuit au bout d’un mois.

Quand vous serez prêt, découvrez Ailoot.