Claude Code Plan Mode — comment l'utiliser pour chaque tâche non triviale

La plupart des gens utilisent Claude Code comme un chat : décrire la tâche, regarder l'exécution. Ça marche pour les petites modifications. Pour tout ce qui touche plus de deux fichiers, il y a mieux.

Le Plan Mode.

Ce que fait le Plan Mode

Quand tu actives le Plan Mode, Claude lit ton codebase et produit un plan d'exécution étape par étape — sans modifier aucun fichier. Tu vois exactement ce qu'il a l'intention de faire avant qu'une seule ligne soit écrite.

C'est un point de contrôle : tu valides le plan, tu le réorientes, ou tu corriges une hypothèse incorrecte avant qu'elle ne se propage en 15 mauvaises modifications.

Comment l'activer

Deux façons :

Raccourci clavier : appuyer sur Shift+Tab avant d'envoyer ton message. L'input affiche un indicateur "Plan".

Préfixe dans le message : commencer ton message par Plan: (P majuscule). Claude détecte l'intention et passe en mode plan uniquement.

Plan: refactoriser le middleware auth pour utiliser le nouveau format de session

Claude va lister chaque fichier qu'il toucherait et pourquoi — puis s'arrêter.

À quoi ressemble un bon plan

## Plan : refactorer le middleware auth

1. Lire src/lib/auth.ts — comprendre la forme actuelle de la session
2. Lire src/middleware.ts — trouver tous les points d'accès à la session
3. Mettre à jour le type SessionData dans src/lib/auth.ts
4. Mettre à jour middleware.ts pour lire depuis la nouvelle forme
5. Trouver tous les appelants de getSession() dans le codebase
6. Mettre à jour chaque appelant pour utiliser les nouveaux noms de champs
7. Lancer tsc pour vérifier qu'il n'y a plus d'erreurs de type

Fichiers qui seront modifiés :
- src/lib/auth.ts
- src/middleware.ts
- src/app/dashboard/page.tsx
- src/app/api/user/route.ts

C'est actionnable. Tu vois immédiatement s'il a oublié un appelant, s'il touche quelque chose qu'il ne devrait pas, ou si l'ordre est incorrect.

Quand utiliser le Plan Mode

Pour tout ce qui touche 3+ fichiers. Les changements multi-fichiers ont un risque de coordination — un fichier change de forme et quatre autres doivent s'adapter. Un plan rend les dépendances explicites.

Quand tu ne sais pas où se trouvent les choses. "Ajouter du rate limiting à la route login" peut signifier trois endroits différents selon ta stack. Le Plan Mode force Claude à les localiser d'abord.

Avant les refactorings. Les refactorings touchent de nombreux fichiers par définition. Se tromper sur le pattern identifié à l'étape 1 gaspille toutes les étapes suivantes.

Passer outre pour les tâches sur un seul fichier. "Corriger cette erreur TypeScript à la ligne 42" n'a pas besoin d'un plan. L'overhead n'en vaut pas la peine.

Orienter le plan avant l'exécution

Tu peux pousser en arrière avant d'approuver :

Le plan semble correct mais l'étape 5 va rater les fichiers dans src/actions/.
Ne touche pas src/app/api/user/route.ts — ce fichier est remplacé la semaine prochaine.

Claude révise. Ensuite tu approuves et il exécute — avec tes corrections intégrées dès le départ.

Plan Mode + CLAUDE.md

Si ton CLAUDE.md contient une carte d'architecture, le Plan Mode devient beaucoup plus précis. Claude n'a pas à deviner où se trouvent les services, quelle couche gère quoi, ou quels patterns suivre.

## Architecture
actions/   — next-safe-action, côté client
services/  — logique métier, throw DomainError
queries/   — RSC uniquement, pas de safe-action

Un plan généré avec ce contexte identifiera correctement qu'une nouvelle feature nécessite une action, un service et une query — dans le bon ordre.

Le vrai bénéfice

Le Plan Mode ne ralentit pas. Il supprime les aller-retours "ce n'est pas tout à fait ça, réessaie" — qui sont toujours plus lents qu'une relecture de plan de 30 secondes. Sur les tâches complexes, ça m'économise régulièrement deux ou trois cycles de correction.

Pour tout ce qui a une vraie portée, c'est mon réflexe par défaut.