Claude Code Plan Mode : valider l’approche avant de coder

Tout se joue avant l’approbation : vous repérez un appelant oublié, préservez un contrat existant ou écartez une modification inutile de la base de données. Un plan détaillé se justifie s’il vous amène à revoir une décision.

À quoi sert Claude Code Plan Mode ?

Le mode Plan demande à Claude d’examiner votre base de code et de proposer des modifications. Il peut lire des fichiers, lancer des commandes d’exploration et rédiger le plan. En temps normal, les modifications du code source restent bloquées tant que vous n’avez pas donné votre accord. C’est l’équivalent d’une revue des plans de rénovation avant que l’artisan ne commence à déplacer les murs. Le workflow de planification d’Anthropic.

La documentation prévoit toutefois une exception importante : dans une session de terminal interactive où le contournement des permissions est disponible, les blocages du mode Plan ne s’appliquent pas. Claude reçoit toujours la consigne de planifier, mais une tentative de modification peut aboutir. C’est aussi le cas lorsque vous rendez ce contournement disponible avec --allow-dangerously-skip-permissions, même sans le sélectionner comme mode actif. Si vous voulez soumettre toute modification du code source à votre approbation, démarrez sans activer le contournement. Les règles des modes de permission selon Anthropic.

Le workflow de planification et le système de permissions se complètent. Le plan décrit ce que Claude compte modifier ; le mode de permission détermine quelles actions peuvent s’exécuter sans vous solliciter.

Comment activer et quitter le mode Plan ?

Dans un terminal, démarrez directement en mode Plan :

claude --permission-mode plan

Si une session est déjà ouverte, utilisez les commandes ci-dessous. Fiez-vous à l’indicateur de mode plutôt qu’à un nombre fixe de pressions sur les touches.

À partir de auto, le cycle passe par default (Manual), puis acceptEdits, puis plan. Les modes facultatifs disponibles viennent ensuite : d’abord le contournement des permissions, puis auto en dernier. Sous Windows, Anthropic indique que Alt+M sert de raccourci de remplacement lorsque l’environnement d’exécution Node ou Bun n’active pas le mode de saisie VT. Changement de mode, référence des raccourcis clavier, référence des commandes.

Lorsque Claude présente un plan, la demande d’approbation vous permet de :

• Choisir No, keep planning pour poursuivre la planification et préciser les corrections à apporter.
• Choisir Yes, manually approve edits pour valider l’approche tout en examinant chaque modification séparément.
• Choisir Yes, and use auto mode pour approuver le plan et continuer en mode auto, lorsque celui-ci est disponible.

Si le mode auto n’est pas disponible, l’option automatique accepte les modifications automatiquement. Si la session a démarré avec le contournement activé, cette option passe au contournement des permissions. Lisez le mode proposé avant de le sélectionner. L’approbation met fin au mode Plan et lance la mise en œuvre avec les permissions choisies. Changer de mode avec Shift+Tab permet aussi de quitter la planification, mais ne vaut pas approbation du plan proposé. Fonctionnement de l’approbation d’un plan.

Vous utilisez une interface graphique ? Dans VS Code, cliquez sur l’indicateur de mode sous le prompt et sélectionnez Plan. Dans l’onglet Code de Desktop, utilisez le sélecteur de mode à côté de Send. Dans JetBrains, les commandes de la CLI s’utilisent dans le terminal intégré. Le journal des modifications indique également que la saisie de /plan est prise en charge dans VS Code depuis la version v2.1.280. Commandes des interfaces, journal officiel des modifications.

Les réglages de Claude Code à connaître

Pour démarrer les sessions de terminal d’un projet en mode Plan, ajoutez cette configuration à .claude/settings.json en la fusionnant avec le contenu existant :

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

Utilisez plutôt ~/.claude/settings.json si vous voulez en faire le mode par défaut de vos sessions de terminal au niveau utilisateur. L’option de lancement prime sur les réglages, et les paramètres du projet ou les paramètres administrés peuvent prendre le pas sur vos préférences utilisateur. VS Code possède son propre réglage de démarrage : définissez "claudeCode.initialPermissionMode": "plan" dans les paramètres utilisateur de VS Code. L’extension ne consulte pas les paramètres du projet pour choisir son mode de permission initial. Configuration du mode au démarrage.

Les clés suivantes se placent à la racine des paramètres de Claude Code, en dehors de permissions :

Ces choix sont indépendants : l’emplacement de sauvegarde du plan, le contrôle des commandes pendant la planification et la présence d’une option d’approbation qui efface la conversation. Référence des paramètres, stockage des plans, option d’effacement du contexte.

Si vous choisissez d’effacer le contexte, consignez les contraintes, les décisions en suspens et les critères d’acceptation dans le plan lui-même. Sinon, vous comptez sur des échanges auxquels Claude n’aura plus accès pendant la mise en œuvre.

Comment le mode Plan s’articule-t-il avec le mode auto ?

Le mode Plan soumet la décision de mise en œuvre à une revue. Le mode auto réduit les demandes de permission courantes en confiant l’évaluation des actions à un modèle de classification distinct. Ce modèle examine les questions de permission ; votre revue du plan vérifie que la conception proposée répond au bon problème.

Lorsque le mode auto est disponible et que useAutoModeDuringPlan reste activé, ce modèle de classification examine également les commandes shell pendant la planification. Les commandes approuvées s’exécutent ; les commandes rejetées sont bloquées. Si le mode auto n’est pas disponible ou si ce réglage est désactivé, les commandes qui sortent de l’ensemble intégré de commandes en lecture seule déclenchent une demande de confirmation. Les suppressions visant des chemins critiques font l’objet d’un traitement distinct, et l’exception liée au contournement dans le terminal interactif est prioritaire. Planifier ne signifie pas que toutes les commandes shell se limitent à la lecture. Les commandes pendant la planification.

Pendant la mise en œuvre, default correspond à une validation manuelle, acceptEdits autorise automatiquement les modifications dans le périmètre prévu et les commandes courantes du système de fichiers, avec les exceptions documentées, et auto ajoute une évaluation des actions en arrière-plan. Aucun de ces modes ne vous dit si l’architecture est pertinente. Notre guide du mode auto de Claude Code détaille ce choix de permissions.

La documentation actuelle indique que, depuis la version v2.1.283, auto est le mode de démarrage intégré pour les sessions de terminal interactives et VS Code, sous réserve des règles de configuration, d’organisation et de disponibilité. Configurer explicitement un démarrage en mode Plan garde donc son intérêt. Règles actuelles du mode de démarrage.

Les anciens guides peuvent passer à côté de changements significatifs. Le journal des modifications d’Anthropic signale l’ajout d’un argument de description à /plan en v2.1.72, le masquage par défaut de l’option d’effacement du contexte en v2.1.81 et, en v2.1.218, la prise en charge par le modèle de classification des commandes Bash dont le caractère strictement en lecture seule est incertain, pendant la planification avec auto. Journal officiel des modifications.

Cas pratique : mutualiser le calcul des prix sans modifier les montants facturés

Prenons une refactorisation concrète : une application calcule les prix à la commande dans son API et les prix au renouvellement dans un worker en arrière-plan. Vous voulez mutualiser les règles de tarification tout en conservant les arrondis et les remises propres à chaque appelant. Ce plan sert d’illustration : il ne décrit ni un dépôt testé ni un résultat garanti de Claude.

Activez le mode Plan et formulez la contrainte réelle :

Supposons que les fichiers concernés soient les suivants :

Une première ébauche plausible pourrait proposer d’extraire un calculateur commun, d’y faire passer les deux appelants, de supprimer les anciennes fonctions utilitaires et de mettre les tests à jour. L’ensemble paraît propre. Il reste pourtant incomplet : que se passe-t-il si l’arrondi n’intervient pas au même moment à la commande et au renouvellement ?

Modifiez le plan avant de l’accepter. Pendant la revue, appuyez sur Ctrl+G et remplacez la suppression prématurée par cette correction :

Enregistrez le plan et revenez à la session. Si la proposition doit encore être retravaillée, choisissez l’option permettant de poursuivre la planification et demandez à Claude de rendre l’ensemble du plan cohérent avec cette correction. Il s’agit de supprimer l’étape de suppression contradictoire, pas d’ajouter un avertissement en dessous. La modification directe et la poursuite de la planification font partie du workflow documenté. Les recommandations d’Anthropic pour explorer, planifier et coder.

Le plan révisé doit maintenant présenter une séquence réalisable :

1. Consigner le comportement existant. Ajoutez des cas couvrant les montants actuels à la commande et au renouvellement, notamment les seuils d’arrondi, les remises et les entrées invalides. Clarifiez tout résultat attendu encore incertain avant de poursuivre.
2. Introduire la politique commune derrière des adaptateurs. Préservez les entrées, les sorties et le comportement en cas d’erreur de chaque fonction existante. Rendez explicites les différences entre appelants.
3. Migrer les appelants par étapes distinctes. Mettez à jour le parcours de commande, vérifiez-le, puis passez au renouvellement. Laissez les nettoyages sans rapport en dehors de ces changements.
4. Vérifier le résultat. Exécutez les vérifications réelles du projet sur la tarification, l’API et le worker, puis ses contrôles habituels de types et d’intégration. Examinez le diff pour repérer toute modification des réponses publiques ou de la logique de facturation.
5. Préserver une possibilité de retour arrière. Conservez la couche de compatibilité jusqu’à la réussite des vérifications. Supprimez le code obsolète dans une étape distincte, qui puisse faire l’objet d’une revue.

Pour cet exemple, approuvez ensuite le plan en conservant une validation manuelle des modifications. Après la mise en œuvre, comparez les changements réels et les résultats des tests au plan. Un plan qui mentionne des tests reste une proposition tant que ces vérifications n’ont pas été exécutées.

Le gain économique est ici précis : détecter un changement de comportement avant de réécrire les deux appelants et leurs tests. Inutile d’y associer un pourcentage spéculatif d’économie de tokens.

Quand la planification apporte-t-elle le plus de valeur ?

Privilégiez les travaux où une erreur de conception initiale se propage. Par ordre de valeur probable, voici les situations que je ferais d’abord passer par une phase de planification :

Il s’agit de workflows proposés, pas de résultats mesurés. Ils suivent la recommandation d’Anthropic : planifier lorsque l’approche reste incertaine, que la modification touche plusieurs fichiers ou que le code est peu familier. Pour une faute de frappe, une instruction de journalisation déjà identifiée ou un renommage au périmètre clair, demandez directement la modification. Quand Anthropic recommande de planifier.

Pour estimer le budget, comparez les deux workflows. L’exécution directe consomme du temps de mise en œuvre et de revue avant que vous ne découvriez une mauvaise approche. La planification ajoute en amont du temps d’investigation et de revue du plan, avec la possibilité d’éviter ces reprises.

La planification est rentable lorsque son coût humain et le surcroît d’utilisation du modèle restent inférieurs au coût attendu des reprises qu’elle évite. C’est une règle de décision, pas un indicateur d’économies publié par Anthropic. Appuyez-vous sur vos propres coûts de développement et votre consommation réelle. Si le plan ne ferait que répéter une modification que vous savez déjà décrire précisément, passez-vous-en.

Quels produits créer autour de ce workflow ?

La piste la plus solide est un dossier de revue de refactorisation pour les équipes : transformer une modification proposée en un ensemble prêt à examiner, avec cartographie des fichiers, contrats à préserver, vérifications d’acceptation et notes de retour arrière. Un responsable technique pourrait payer pour rendre les pratiques plus cohérentes entre développeurs, en particulier sur la logique métier partagée.

Les estimations de mots-clés de DataForSEO pour les États-Unis, consultées le 12 octobre 2026, situent « code refactoring tools » à 170 recherches par mois. C’est un signal modeste d’intérêt pour ce besoin, pas la preuve que ces internautes achèteront un produit de revue de plans. Le plus petit produit utile pourrait accepter un plan exporté et une cartographie des fichiers du dépôt, rechercher les appelants manquants ou les hypothèses non étayées, puis produire une note de cadrage pour une pull request. La difficulté : la génération de plans génériques fait déjà partie de Claude Code. Pour justifier son existence, le produit doit proposer des contrôles propres à l’équipe et un livrable de revue utile.

Une piste plus ciblée serait un dossier de préparation aux migrations pour les agences : produire un inventaire des composants concernés, une checklist de déploiement par étapes et une liste des décisions en suspens avant de chiffrer une mise à niveau. La même consultation de DataForSEO estime à 20 le nombre de recherches mensuelles aux États-Unis pour « code migration tools ». Le faible volume de cette requête commerciale invite à valider le besoin auprès des clients existants avant de bâtir un produit généraliste.

Sa version minimale pourrait se concentrer sur une famille de migrations et exiger, pour chaque modification, des liens vers la documentation pertinente de l’éditeur. La difficulté tient à la maintenance : les règles de migration propres à une version vieillissent vite. Le mode Plan peut aider à mener l’investigation, mais ne fournit pas de référentiel vérifié des règles de migration. Ce sont des hypothèses de produits appuyées sur la demande exprimée dans les recherches, pas des prévisions de chiffre d’affaires.

Ultraplan n’est plus disponible

Anthropic a retiré la préversion de recherche Ultraplan, y compris /ultraplan, son déclenchement par mot-clé et l’option d’approbation permettant d’affiner un plan avec Ultraplan sur le Web. Sa page précise que les préversions de recherche sont expérimentales et peuvent évoluer ou être supprimées en fonction des retours. Elle renvoie vers le mode Plan local et les sessions cloud de Claude Code pour les workflows de planification. La page actuelle d’Ultraplan chez Anthropic.

Les questions à se poser avant la prochaine session

Lundi, prenez la prochaine refactorisation impliquant plusieurs appelants d’une même logique, activez le mode Plan et demandez de préciser le comportement à préserver, les fichiers concernés, les vérifications et le retour arrière. Corrigez l’hypothèse la plus fragile avant d’approuver. Complétez cette démarche avec les habitudes de revue présentées dans les bonnes pratiques de Claude Code.

Si votre équipe a besoin d’un workflow de planification et de revue reproductible, nous pouvons l’intégrer à votre processus de développement.