Effectuer des modifications

Effectuer des modifications

Quand vous travaillez avec Claude dans votre environnement de développement, vous aurez souvent besoin de modifier des projets existants. Ce cas de figure n’a rien à voir avec la création à 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 techniques font la différence dans cet exercice, et cette leçon les couvre l’une après l’autre : la communication par capture d’écran, le mode planification et les modes de réflexion.

Utiliser des captures d’écran

L’une des manières les plus efficaces de communiquer avec Claude passe par les captures d’écran. Décrire une interface avec des mots coûte étonnamment cher — « le bouton en haut à droite du panneau de filtres, celui qui se superpose au badge quand la fenêtre est étroite » — et laisse toujours une part d’ambiguïté que vous ne découvrirez qu’en voyant le résultat. Une capture supprime ce détour : Claude voit exactement la zone dont vous parlez, et il ne vous reste qu’à formuler la modification voulue.

Pour coller une capture dans Claude, utilisez Ctrl+V, et non Cmd+V sur macOS. Le détail surprend les utilisateurs Mac, qui en concluent souvent à tort que le collage d’image n’est pas supporté et retournent décrire leur interface en trois paragraphes. Une fois l’image collée, demandez la modification qui vous intéresse sur cette zone de votre application.

Le mode planification

Pour des tâches plus complexes, activez le mode planification. Il pousse Claude à explorer votre projet en détail avant d’implémenter le moindre changement, ce qui répond à un problème très concret : sur 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.

Activez-le en appuyant sur Shift+Tab deux fois, ou une seule fois si vous acceptez déjà les modifications automatiquement. Le comportement de Claude change alors sur toute la première partie du travail : il lit davantage de fichiers dans votre projet, construit un plan d’implémentation détaillé, puis vous montre exactement ce qu’il a l’intention de faire et attend votre approbation avant de continuer.

C’est ce dernier point qui change tout dans la pratique. Le plan vous est soumis avant exécution, donc 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 terminée qui a touché huit fichiers en prend infiniment plus, et vous laisse en plus une conversation encombrée de travail à jeter.

Les modes de réflexion

Claude propose par ailleurs différents niveaux de raisonnement à travers les modes « thinking » :

Chaque mode donne à Claude progressivement plus de tokens pour travailler. Il ne s’agit ni d’un autre modèle, ni d’une autre qualité de code, mais d’un budget de réflexion : plus il est large, plus Claude peut envisager d’hypothèses, les comparer et revenir sur une piste avant de vous répondre. Sur un renommage de variable, ce budget est intégralement gaspillé ; sur une régression que vous traquez depuis deux heures et dont personne ne comprend le déclencheur, il est exactement ce qui manquait.

Quand utiliser planification vs réflexion

La confusion la plus fréquente consiste à traiter ces deux modes comme deux intensités d’une même chose. Ils répondent en réalité à deux manques différents. Le mode planification adresse un manque de largeur : vous l’activez quand la tâche nécessite une compréhension large de votre codebase, quand l’implémentation comporte plusieurs étapes, ou quand les changements affectent plusieurs fichiers ou composants. Migrer une bibliothèque d’authentification à travers une application entière relève typiquement de ce cas — la difficulté n’est pas dans le raisonnement, chaque remplacement est trivial ; elle est dans l’inventaire exhaustif de ce qui est touché.

Le mode réflexion adresse un manque de profondeur : vous l’activez quand le problème implique une logique complexe, quand vous déboguez un problème difficile, ou quand vous faites face à un défi algorithmique. Une race condition qui ne se manifeste qu’en production tient parfois dans cinquante lignes d’un seul fichier ; aucune exploration supplémentaire ne la révélera, seule une analyse patiente des enchaînements possibles y parviendra.

Rien ne vous oblige à choisir. Vous pouvez combiner les deux modes pour des tâches qui demandent à la fois de la largeur et de la profondeur, comme une refonte de la gestion d’état, où il faut cartographier tous les points d’appel et raisonner finement sur les effets de bord.