Claude Code : corriger un bug sans tout modifier

« Corrige ce bug » paraît être une demande précise. Pour un agent de développement, elle peut pourtant ouvrir un chantier beaucoup trop large. Une correction rentable rétablit le comportement attendu avec le minimum de changements nécessaires. Elle ne profite pas de l’incident pour réorganiser silencieusement toute l’application.

Décrire ce qui échoue réellement

Indiquez le parcours, les données utilisées, le résultat observé et le résultat attendu. Précisez si le problème apparaît toujours ou seulement dans certaines conditions. Une capture est utile, mais elle ne remplace pas les étapes permettant de reproduire le défaut.

Dans un exemple fictif, une recherche de blog ne conserve pas le mot saisi lorsque le lecteur change de page. Le besoin n’est pas de reconstruire le moteur de recherche : il est de conserver le filtre et d’afficher les résultats correspondants, y compris avec une catégorie sélectionnée.

Séparer le diagnostic de la modification

Demandez d’abord quels fichiers participent au comportement et quelle cause explique l’échec. L’agent doit distinguer les observations des hypothèses. Si plusieurs causes restent possibles, une vérification ciblée coûte moins cher qu’une série de changements exploratoires.

Les bonnes pratiques de Claude Code insistent notamment sur des tâches délimitées et des moyens de vérification. Cela ne garantit pas une correction parfaite, mais donne une structure pour éviter qu’une investigation locale dérive vers une lecture puis une réécriture générales.

Fixer le périmètre autorisé

Écrivez ce qui peut changer et ce qui doit rester intact : présentation validée, routes publiques, données existantes ou interface utilisée par d’autres outils. Demandez de signaler toute modification nécessaire en dehors de ce périmètre avant de l’entreprendre.

Un nettoyage de code intéressant peut attendre une tâche séparée. Mélanger correction urgente et refonte complique la relecture, rend le retour arrière plus risqué et empêche de savoir quel changement a résolu le problème. Une petite différence explicable vaut mieux qu’une grande amélioration difficile à attribuer.

Exiger une preuve avant et après

Conservez un test qui échoue avant la correction, lorsque c’est possible, puis vérifiez qu’il réussit ensuite. Ajoutez les cas voisins : absence de résultat, filtre vide, pagination suivante ou données incomplètes. Vérifiez aussi qu’une fonctionnalité déjà correcte reste correcte.

La démarche pour reprendre un projet avec Claude Code commence par comprendre l’existant. Pour un bug, cette compréhension doit rester proportionnée : suffisamment profonde pour expliquer le défaut, assez ciblée pour éviter de disperser la modification.

Livrer une correction lisible

Relisez les différences, les tests exécutés et les limites encore non vérifiées. Une compilation réussie ne prouve pas qu’un parcours utilisateur fonctionne sur mobile ou en production. Distinguez clairement ce qui a été testé localement de ce qui a été observé en ligne.

Gardez un point de retour et déployez selon le risque. Dans un développement orienté résultat, la valeur de l’IA ne se mesure pas à la quantité de code touchée. Elle se mesure à un problème résolu, sans régression inutile, avec une correction qu’une autre personne peut comprendre et maintenir.