Effectuer des modifications

Modifier un projet existant n’a rien à voir avec créer à partir de zéro : le code est déjà là, il fonctionne à peu près, et l’enjeu n’est plus de produire des lignes mais de toucher les bonnes. Trois leviers font la différence, et cette leçon les couvre l’un après l’autre : montrer plutôt que décrire avec les captures d’écran, faire réfléchir en largeur avec le mode plan, faire réfléchir en profondeur avec le niveau d’effort.

Montrer avec des captures d’écran

Décrire une interface avec des mots coûte cher (« le bouton en haut à droite du panneau de filtres, celui qui se superpose au badge quand la fenêtre est étroite ») et laisse une ambiguïté que vous ne découvrirez qu’en voyant le résultat. Une capture supprime ce détour : Claude voit la zone dont vous parlez.

Collez l’image avec Ctrl+V dans le terminal, y compris sur macOS (Cmd+V ne fonctionne que dans iTerm2) ; sous Windows et WSL, Alt+V est aussi lié, au cas où le terminal intercepte Ctrl+V. Une puce [Image #1] apparaît dans votre prompt, que vous pouvez désigner dans la phrase : « Dans l’image 1, le badge déborde du conteneur ; corrige le CSS ». Vous pouvez aussi glisser un fichier image dans le terminal ou donner son chemin avec @ : l’outil Read sait lire les PNG, JPEG et PDF.

Le mode plan

Pour une tâche transverse, un assistant qui commence à écrire trop tôt s’engage sur une approche à partir d’une vision partielle, et vous découvrez le malentendu quand cinq fichiers ont déjà été modifiés. Le mode plan lui demande d’explorer d’abord : Claude lit des fichiers, lance des commandes pour comprendre, rédige un plan, et ne modifie aucune source tant que vous ne l’avez pas approuvé.

Trois façons d’y entrer :

• préfixez une demande par /plan : /plan migrer l'authentification vers des sessions côté serveur ;
• appuyez sur Maj+Tab jusqu’à ⏸ plan mode on ; depuis le mode Auto, il faut trois pressions (Manual, Accept edits, Plan) ;
• lancez la session avec claude --permission-mode plan.

Quand le plan est prêt, Claude le présente et demande comment continuer. Vous pouvez approuver et passer en mode Auto, approuver en validant chaque modification une par une, ou rester en mode plan et dire ce qu’il faut changer. Ctrl+G ouvre le plan dans votre éditeur de texte pour le corriger directement avant que Claude ne poursuive. Approuver fait sortir du mode plan, donne un titre à la session d’après le plan et lance l’implémentation ; Maj+Tab permet de ressortir du mode plan sans approuver.

Le plan vous est soumis au moment le moins coûteux de toute la session pour dire « non, pas comme ça ». Corriger une phrase de plan prend dix secondes ; revenir sur une implémentation qui a touché huit fichiers en prend infiniment plus.

Le niveau d’effort

Sur les modèles actuels, Claude décide à chaque étape combien réfléchir, et c’est le niveau d’effort qui calibre cette décision. Ce n’est ni un autre modèle ni une autre qualité de code, mais un budget de raisonnement : plus il est large, plus Claude envisage d’hypothèses, teste de cas limites et vérifie son travail avant de répondre.

Réglez-le avec /effort low, /effort high, etc., ou avec le curseur de /effort et du sélecteur /model. Valider avec Entrée enregistre le niveau comme défaut pour ce modèle ; la touche s l’applique à la session seulement. max ne s’applique jamais qu’à la session en cours. Au lancement, claude --effort high fait la même chose. L’échelle est calibrée par modèle : le même nom de niveau ne représente pas la même valeur d’un modèle à l’autre, et Opus 5.5 à medium fait aussi bien qu’Opus 5 à high dans les tests d’Anthropic.

Pour un seul tour plus poussé sans toucher au réglage, écrivez le mot ultrathink dans votre demande : Claude Code le reconnaît, l’affiche en couleurs arc-en-ciel et élève ce tour à xhigh (version 2.1.311 et au-delà). C’est le seul mot-clé reconnu ; « think », « think hard » ou « réfléchis bien » sont transmis comme des mots ordinaires. Sur Opus 5.5, Sonnet 5.5, Haiku 5.5 et les modèles Fable, la réflexion étendue est toujours active et ne se désactive pas ; Ctrl+O affiche le raisonnement en gris quand vous voulez le lire.

Plan ou effort ?

La confusion la plus fréquente consiste à traiter ces deux leviers comme deux intensités d’une même chose. Ils répondent à deux manques différents. Le mode plan adresse un manque de largeur : la tâche demande une compréhension étendue de la base de code, plusieurs étapes, des changements dans plusieurs fichiers. Migrer une bibliothèque d’authentification à travers toute l’application relève de ce cas : chaque remplacement est trivial, la difficulté est dans l’inventaire exhaustif de ce qui est touché.

Le niveau d’effort adresse un manque de profondeur : logique complexe, bug difficile, défi algorithmique. Une condition de concurrence qui ne se manifeste qu’en production tient parfois dans cinquante lignes d’un seul fichier ; aucune exploration ne la révélera, seule une analyse patiente des enchaînements possibles y parviendra. Rien ne vous oblige à choisir : une refonte de la gestion d’état demande les deux.

Donnez-lui une vérification à lancer

Le troisième levier n’est pas un réglage mais une habitude, que la page Best practices met en tête : dites à Claude ce qu’il ne peut pas voir, et donnez-lui un moyen de vérifier son travail. « Corrige le bug, puis lance npm test et ne t’arrête pas tant que la suite ne passe pas » produit un résultat d’une autre nature que « corrige le bug », parce que la boucle agentique a désormais un critère d’arrêt observable. Les skills intégrées /verify (lancer l’application et constater le résultat) et /code-review (relire les changements de la branche) industrialisent ce réflexe.

À vous de jouer

1. Prenez une évolution réelle de votre projet qui touche au moins trois fichiers. Lancez-la avec /plan …, lisez le plan, modifiez-en une étape avec Ctrl+G, puis approuvez en validation manuelle.
2. Sur un bug précis et localisé, comparez : une demande à /effort low, puis la même demande avec le mot ultrathink. Notez ce que la seconde réponse vérifie en plus.
3. Terminez par /code-review sur la branche et lisez les constats.

Sources officielles : Choose a permission mode · Model configuration · Interactive mode · Best practices · Review locally with /code-review

Points clés à retenir

• Une capture collée avec Ctrl+V (Alt+V sous Windows et WSL) vaut mieux qu’un paragraphe de description
• Le mode plan (/plan, Maj+Tab, --permission-mode plan) fait explorer avant de modifier ; vous approuvez, corrigez avec Ctrl+G ou renvoyez le plan
• L’effort (/effort low à max) règle la profondeur de raisonnement ; medium par défaut sur les modèles 5.5, high ailleurs ; ultrathink élève un seul tour
• Plan = largeur, effort = profondeur ; les deux se combinent
• Donnez toujours à Claude une vérification à lancer : un test, un build, /verify, /code-review