Les quatre tâches les plus courantes : Explorer, corriger un bug, refactoriser, écrire des tests
📚 Navigation dans la série : L'article précédent [15 Comment poser des questions et donner des instructions] vous a appris « l'art de parler » — transformer des besoins vagues en instructions précises. Cet article change d'angle : 80% des tâches quotidiennes se résument à quatre catégories, et pour chacune d'elles, je vous donne un modèle d'instruction prêt à l'emploi, il n'y a plus qu'à remplir les blancs.
Les amis, aujourd'hui, on passe aux choses pratiques.
Réfléchissez un peu, quand vous êtes devant votre code, que faites-vous exactement tous les jours ? En fin de compte, ça tourne toujours autour de quatre actions : prendre en main un projet qu'on ne comprend pas, corriger un bug incompréhensible, nettoyer un bout de code en le refactorisant, ou ajouter des tests à une fonction. Il y a d'autres besoins, bien sûr, mais ces quatre catégories représentent l'essentiel de notre temps.
L'article précédent portait sur les « techniques de communication » générales, celui-ci va s'attaquer à des scénarios bien spécifiques — ces quatre types de tâches ont chacune leur propre méthode standard, une routine établie. À force d'utiliser Claude Code, ce qui vous restera, ce sont quatre modèles, enregistrés dans vos notes, que vous pourrez dégainer et remplir en fonction de la situation.
Pour résumer : les techniques de communication générales sont les fondations de base, ces quatre modèles sont les techniques de combat. Vous maîtrisez maintenant les bases, place aujourd'hui aux techniques.
Après avoir lu cet article, vous obtiendrez :
- Quatre modèles d'instructions prêts à être copiés pour les quatre tâches les plus fréquentes (explorer / corriger un bug / refactoriser / écrire des tests).
- La logique clé de chaque modèle, expliquant « pourquoi on procède ainsi », afin de ne pas simplement les retenir par cœur.
- Un aide-mémoire de ces quatre types de tâches, à conserver et à utiliser en un instant.
- Un exercice pratique complet avec des résultats attendus (corriger un vrai bug du début à la fin).
01 La base : Quatre tâches, quatre outils différents
Avant de commencer, clarifions la « personnalité » de ces quatre tâches. Elles imposent des exigences totalement différentes à Claude. Si vous utilisez la mauvaise approche, les résultats en pâtiront grandement.
Analogie : Quatre outils dans une boîte à outils, identifiez leurs usages respectifs. On utilise un tournevis pour visser et une clé pour des écrous. Vous serez mal à l'aise si vous essayez de visser avec une clé. L'exploration, la correction de bugs, la refactorisation et les tests sont quatre outils différents — la question n'est pas « savez-vous utiliser Claude », mais « quel outil devez-vous sortir pour cette tâche spécifique ».
Leur différence fondamentale réside dans une seule question : cette tâche modifie-t-elle votre code ?
| Tâche | Modifie le code ? | Que fait Claude principalement ? | Ce que vous devez surveiller de plus près |
|---|---|---|---|
| Explorer la base de code | Non (Lecture seule) | Lit les fichiers, vous explique | Si ses explications sont correctes |
| Corriger un bug | Oui | Trouve la cause profonde + Modifie | S'il a bien identifié la cause, et s'il a ajouté un test de régression |
| Refactoriser | Oui (mais le comportement reste le même) | Réécrit à l'identique | Si le comportement a changé après modification |
| Écrire des tests | Ajoute des fichiers | Génère des tests + Couvre les cas limites | Si les cas limites (edge cases) sont tous couverts |
Vous le voyez ? L'exploration est sans aucun risque (elle lit sans écrire), vous pouvez donc y aller sans hésitation ; la correction de bugs et la refactorisation modifient le code, il faut donc lui demander d'expliquer avant d'agir ; l'écriture de tests se situe entre les deux, elle crée de nouveaux fichiers sans toucher à votre code original, mais vous devez veiller à ce qu'il ne se contente pas des cas « nominaux ».
Mémorisez la logique de ce tableau, et les quatre sections suivantes détailleront comment utiliser chaque outil.
💡 En résumé : Distinguez les quatre tâches selon si elles modifient ou non le code — l'exploration sans risque permet toutes les questions, tandis que pour les tâches qui modifient le code, faites-le d'abord parler avant d'agir.
02 Explorer une base de code inconnue : Du général au particulier, en trois étapes
Commençons par le scénario le plus courant : vous prenez en main un projet totalement inconnu et la première chose à faire est de le comprendre.
Comment faisiez-vous avant ? Vous ouvriez le dossier, regardiez quelques dizaines de répertoires d'un œil perdu, cliquiez sur l'un après l'autre, et après deux heures, vous étiez toujours dans le flou. C'est fini — Claude Code considère le répertoire courant comme son espace de travail, il peut analyser l'ensemble du projet de lui-même, il vous suffit de poser des questions.
Analogie : Arriver dans une nouvelle entreprise, on ne plonge pas immédiatement dans le code source d'un module, mais on s'adresse à un ancien en lui posant trois questions. 1) « Que fait exactement cette entreprise, à quoi ressemble l'architecture générale ? » ; 2) « Où se trouve le code gérant les paiements ? » ; 3) « Quel est le cheminement du code, depuis la commande jusqu'au prélèvement, pour un achat ? » Du général au particulier, de la surface aux détails, tel est le rythme standard de l'exploration.
Selon les exemples de la documentation officielle, ces trois étapes correspondent à trois types de questions :
Donne-moi un aperçu général de cette base de code, et explique ses principaux modèles d'architectureDans quels fichiers se trouve le code gérant l'authentification des utilisateurs ? Comment ces fichiers fonctionnent-ils ensemble ?Trace le parcours de connexion, depuis le front-end jusqu'à la base de donnéesUne bonne habitude consiste à poser les deux premières questions en Plan Mode (Mode Planification) — c'est-à-dire, appuyer deux fois sur Maj+Tab (la première fois vous passe en acceptEdits, la seconde en plan) avant de commencer. Pourquoi ? Parce que pendant la phase d'exploration, nous voulons seulement qu'il lise et explique, et non qu'il commence soudainement à modifier des fichiers avec zèle. En Plan Mode, il ne touchera pas à votre code source, même si vous posez de multiples questions.
Si vous reprenez un vieux projet en Go de 30 000 lignes, vous pourriez faire cela dès le premier jour : commencez par « aperçu général » pour comprendre en combien de services il est divisé, puis « où est le code gérant X » pour localiser les modules, et enfin choisissez une chaîne principale pour « tracer ce parcours ». Vous comprendrez l'essentiel en une demi-journée, alors qu'il aurait fallu deux ou trois jours auparavant.
Voici directement le modèle d'exploration, il suffit d'y insérer vos mots-clés :
Je viens de reprendre ce projet, aide-moi à le prendre en main rapidement. En trois étapes :
1. Donne-moi un aperçu de l'architecture globale, explique les principaux modules et leurs responsabilités
2. Où se trouvent les fichiers gérant [la fonctionnalité qui vous intéresse, ex. « le paiement de commande »]
3. Trace le cheminement complet de l'exécution pour [un flux essentiel, ex. « la création d'une commande jusqu'au paiement »]
Explique de manière simple pour un débutant, ne modifie aucun code pour l'instant.💡 En résumé : L'exploration se fait avec un seul rythme — de l'architecture globale aux fichiers spécifiques puis au chemin d'exécution, en posant des questions de la macro à la micro, et il est préférable de poser les deux premières en Plan Mode.
03 Corriger un bug : Coller l'erreur → Trouver la cause → Corriger → Ajouter un test de régression
La correction de bugs est l'autre tâche très fréquente, et c'est aussi la plus sujette aux erreurs.
Pourquoi est-il facile de se tromper ? Parce que l'erreur classique des débutants est de coller un message d'erreur en lançant un « Corrige-le », à la suite de quoi Claude proposera un correctif qui « fait disparaître le message ». Attention, « disparition de l'erreur » ne signifie pas « résolution du problème » — bien souvent, l'outil se contente de masquer les symptômes sans toucher à la racine, et l'erreur finira par ressurgir.
Analogie : Aller chez le médecin parce qu'on a mal. Vous n'entrez pas en disant simplement « donnez-moi un antidouleur ». Vous expliquez « où ça fait mal, depuis quand, quels mouvements aggravent la douleur », afin que le médecin établisse un diagnostic d'abord, puis propose un traitement. C'est exactement la même chose pour corriger un bug — demandez-lui d'abord d'identifier la cause profonde, et empêchez-le de se précipiter pour vous « calmer la douleur ».
La meilleure pratique de la documentation officielle insiste sur une règle d'or qu'il faut afficher au mur :
Corrigez le bug et vérifiez que le build réussit. Réglez la cause profonde, ne vous contentez pas de supprimer l'erreur.
Ainsi, la méthode correcte pour corriger un bug se déroule en quatre étapes indispensables :
- Collez l'erreur + les étapes de reproduction : le message d'erreur complet, la pile d'appels, ainsi que « ce que j'ai fait pour le déclencher ».
- Demandez d'identifier la cause profonde : ne le laissez pas modifier tout de suite, exigez qu'il explique « pourquoi ça a planté ».
- Fournissez le correctif : si la cause est bonne, autorisez-le à intervenir.
- Ajoutez un test de régression : ajoutez un test permettant de reproduire le bug, afin de garantir que cette erreur ne se reproduira pas à l'avenir.
La quatrième étape est celle que les débutants omettent le plus, et c'est pourtant la plus précieuse. L'approche de la documentation est excellente : demander à Claude « d'écrire un test échouant qui reproduit le problème, avant de le corriger » — ainsi, le correctif fera passer le test au vert, et si par malheur quelqu'un annule la modification à l'avenir, le test sonnera l'alarme immédiatement.
Beaucoup s'y sont fait prendre. Par exemple, la correction d'un bug de parsing de date : Claude avait tout réglé en un rien de temps, l'erreur avait disparu et c'était commité. Deux semaines plus tard, un autre développeur lors d'une refactorisation a rétabli l'ancienne ligne, ressuscitant le même bug sur place — parce qu'il n'y avait pas eu de test, personne ne savait que cette ligne ne devait pas être touchée. Donc, chaque correction de bug devrait s'accompagner de cette quatrième étape.
Voici directement le modèle pour corriger un bug :
Je rencontre un bug.
Message d'erreur : [Collez l'erreur complète et la pile d'appels]
Étapes de reproduction : [Ce que vous avez fait pour déclencher le bug, est-ce intermittent ou systématique]
Je te demande de :
1. Identifier d'abord la cause profonde, explique pourquoi l'erreur se produit, ne modifie pas le code pour le moment
2. Proposer une solution qui s'attaque à la cause profonde, ne te contente pas de cacher l'erreur
3. Après modification, ajouter un test de régression capable de reproduire ce bug, lance-le et confirme qu'il réussit💡 En résumé : Quatre étapes pour corriger un bug — Coller l'erreur et la reproduction, trouver la cause profonde, corriger, et enfin ajouter un test de régression ; sans le cadenas qu'est le test de régression, ce bug reviendra vous hanter.
04 Refactorisation : Expliquer l'état actuel → Définir l'objectif → Modifier par petites étapes → Tester avant et après
La refactorisation est la tâche la plus risquée, car elle touche du « code qui n'est pas cassé ».
La correction d'un bug a un critère clair de « réussite » — plus d'erreur, test au vert. La refactorisation n'en a pas. Son objectif est d'avoir « un code plus propre, mais dont le comportement reste rigoureusement identique ». Si le comportement change, vous avez furtivement introduit un bug sous couvert de refactorisation, et c'est le pire type de bug car personne ne teste un code qui a "juste été réorganisé".
Analogie : Refaire la décoration d'une maison habitée, sans obliger les habitants à déménager. Vous devez garantir que l'eau et l'électricité fonctionnent normalement et que les résidents puissent y vivre, en repeignant juste les murs et en organisant les fils. La refactorisation, c'est de la « rénovation en site occupé » — les fonctionnalités (la vie des résidents) ne doivent être perturbées à aucun moment.
C'est pourquoi la stratégie de refactorisation sûre comporte quatre étapes, et dont le cœur est : « vérouiller le comportement par des tests » :
- Demander d'expliquer d'abord l'état actuel : comprendre ce que fait vraiment ce code, y compris les cas limites cachés.
- Clarifier l'objectif de refactorisation : Voulez-vous « diviser la fonction », « utiliser des syntaxes modernes » ou « éliminer les redondances » ? Soyez précis.
- Modifier par petits pas : La documentation suggère explicitement de « refactoriser par de petits incréments testables ». Ne le laissez pas tout réécrire d'un coup.
- Vérifier les tests avant et après modification : Lancez les tests avant la refactorisation pour définir un point de référence, et relancez-les après, les résultats doivent correspondre parfaitement.
La quatrième étape est la bouée de sauvetage de la refactorisation. Si le code ne dispose pas de tests, la première étape de la refactorisation n'est pas de modifier, mais d'ajouter des tests — utiliser les tests comme une "photo" du « comportement actuel », afin de comparer après refactorisation pour prouver qu'il n'y a pas eu de changement. C'est exactement l'avis des bonnes pratiques officielles : donnez à Claude un moyen de vérifier son propre travail, sinon l'impression « ça a l'air bon » est son seul signal, et une refactorisation qui a juste l'air bonne est la plus susceptible de cacher une bombe.
Voici une règle de conduite stricte à adopter : Ne laissez pas Claude refactoriser directement du code non couvert par des tests. Imaginez le scénario : vous voulez refactoriser une fonction utilitaire sans tests, et Claude, dans son élan « d'optimisation », supprime un embranchement qui semblait inutile, mais qui en réalité gérait une entrée très rare. Vous ne le découvrirez que lorsque la production plantera. Toujours des tests d'abord, puis refactorisation ; c'est un peu plus long, mais ça sauve des nuits.
Voici directement le modèle pour la refactorisation :
Je veux refactoriser [Nom du fichier / de la fonction].
Objectif de la refactorisation : [Précisez, par ex. « diviser en fonctions plus petites », « utiliser une syntaxe moderne », « éliminer les répétitions »]
Exigences :
1. Explique d'abord le comportement actuel de ce code, y compris les cas limites (edge cases) faciles à négliger
2. S'il n'y a pas encore de tests, ajoute d'abord des tests couvrant le comportement actuel
3. Refactorise par petites étapes, en maintenant le comportement extérieur strictement identique
4. Lance les tests avant et après la refactorisation, et vérifie que les résultats sont cohérents💡 En résumé : La règle d'or de la refactorisation est : « le comportement ne doit pas changer » — expliquez l'existant, fixez l'objectif, progressez par petits pas, verrouillez le comportement avec des tests exécutés avant et après ; sans tests, commencez par les ajouter avant toute modification.
05 Écrire des tests : L'essentiel est de l'obliger à couvrir les cas limites
La dernière catégorie : Ajouter des tests au code.
Claude est en fait très doué pour cela — il consultera vos fichiers de test existants, adoptera votre framework de test et le style de vos assertions, s'alignant automatiquement sans que vous n'ayez besoin de lui apprendre. Mais il y a un piège que vous devez connaître : si vous ne lui précisez pas, il ne testera par défaut que les « cas normaux ».
Qu'est-ce qu'un cas normal ? Pour une fonction de division, il va tester que « 6 divisé par 2 donne 3 » — c'est correct, mais qu'en est-il d'une division par 0 ? d'un nombre négatif ? d'un paramètre null ? Ces « cas limites (edge cases) » sont ceux qui causent de véritables bugs, et ce sont ceux que les tests devraient prioritairement cibler.
Analogie : Embaucher quelqu'un pour le contrôle qualité, vous ne devez pas lui demander de ne tester que les « opérations normales ». Le vrai contrôle qualité consiste à essayer les cas « bizarres » : les entrées vides, trop longues, négatives, mal encodées. Les problèmes se situent toujours aux limites, pas sur les chemins habituels. Écrire des tests implique donc de contraindre Claude à tester ces cas extrêmes.
Le point clé du modèle pour écrire des tests se résume à une phrase : demander explicitement la couverture des cas limites. La meilleure pratique officielle fournit une indication pertinente — précisez clairement « quelle fonction tester, quels scénarios, utiliser des mocks ou pas » :
Écris des tests pour foo.py, couvrant les cas limites où les utilisateurs sont déconnectés. Évite les mocks.
Comparez ces deux requêtes, la différence saute aux yeux :
| ❌ Requête floue | ✅ Requête précise |
|---|---|
| « Écris des tests pour cette fonction » | « Écris des tests pour la fonction divide, en te concentrant sur les cas limites tels qu'un diviseur à 0, des nombres négatifs ou des entrées non numériques » |
| Il ne teste que le chemin normal, gonflant artificiellement la couverture | Il teste les cas qui feront vraiment planter le code |
Il y a aussi une petite astuce : utiliser @ pour lui indiquer directement le fichier ciblé (@src/utils/math.py). Ainsi, il lira le fichier en entier avant d'agir, ce qui est bien plus précis que de dire "cette fonction divide dans le fichier math". La façon d'utiliser @ a été abordée précédemment, c'est l'endroit parfait pour l'appliquer.
Voici directement le modèle pour écrire des tests :
Écris des tests pour la fonction [Nom de la fonction] dans le fichier @[Chemin du fichier].
Exigences :
1. Conserve le framework de test existant et le style d'assertion du projet
2. Couvre de manière prioritaire les cas limites : [listez ceux qui vous viennent à l'esprit, par ex. « entrée vide, zéro, nombres négatifs, très grandes valeurs, types erronés »]
3. Aide-moi également à identifier d'autres cas limites que je n'aurais pas listés, et inclus-les dans les tests
4. Exécute les tests une fois écrits, et corrige ceux qui échouent jusqu'à ce qu'ils passent tousLe 3ème point est une astuce en plus — lui demander de combler vos lacunes. La documentation officielle précise d'ailleurs que Claude peut analyser le code et identifier des cas limites que vous auriez pu oublier. Cette phrase est presque obligatoire pour l'écriture de tests, il découvre souvent des combinaisons d'entrées auxquelles vous n'aviez pas pensé, bien mieux que si vous étiez seul à y réfléchir.
💡 En résumé : Ne vous contentez pas de dire « écris des tests » — obligez-le explicitement à couvrir les cas limites (valeurs nulles, zéro, négatifs, erreurs de type), puis demandez-lui d'ajouter ceux auxquels vous n'avez pas pensé, le chemin normal est paradoxalement le moins important.
06 Pratique : Résoudre un vrai bug étape par étape
Il ne suffit pas de lire les modèles, il faut les mettre en pratique. Nous allons utiliser la catégorie « corriger un bug » pour cet exercice — elle comporte les quatre étapes essentielles, une fois maîtrisées, vous pourrez facilement adapter pour les autres. Et pour cela, j'ai préparé un véritable bug à corriger.
Première étape : Créer un petit projet avec un bug (Mac / Linux)
mkdir bug-demo
cd bug-demo
echo 'def average(numbers):
return sum(numbers) / len(numbers)' > calc.pyUtilisateurs Windows : exécutez mkdir et cd, puis créez calc.py dans le Bloc-notes, et collez les deux lignes Python ci-dessus.
Cette fonction average calcule une moyenne, et semble tout à fait correcte — mais si vous lui passez une liste vide, elle va planter à cause d'une division par zéro. C'est le bug que nous allons corriger.
Résultat attendu : Dans le dossier bug-demo, il y a un calc.py contenant les deux lignes de la fonction average.
Deuxième étape : Lancer Claude Code
claudeRésultat attendu : L'écran d'accueil s'affiche, avec la zone de saisie en bas.
Troisième étape : Appliquer le modèle de correction de bug, en collant l'erreur
Dans la zone de saisie, tapez ceci (c'est le modèle de la section 03, prérempli) :
Je rencontre un bug.
Message d'erreur : Lors de l'appel de average([]), il retourne ZeroDivisionError: division by zero
Étapes de reproduction : Il suffit de passer une liste vide à la fonction average dans calc.py pour déclencher le bug systématiquement
Je te demande de :
1. Identifier d'abord la cause profonde, explique pourquoi l'erreur se produit, ne modifie pas le code pour le moment
2. Proposer une solution qui s'attaque à la cause profonde, ne te contente pas de cacher l'erreur
3. Après modification, ajouter un test de régression capable de reproduire ce bug, lance-le et confirme qu'il réussitRésultat attendu : Claude va d'abord expliquer la cause — avec une liste vide, len(numbers) vaut 0, donc la division par zéro fait planter le code ; ensuite, il proposera un diff (comme renvoyer 0 pour une liste vide ou lever une exception plus claire), et il s'arrêtera pour attendre votre approbation ; une fois approuvé, il créera un fichier de test (comme test_calc.py), contenant un cas spécifique pour les listes vides.
Quatrième étape : Approuvez les modifications et regardez-le exécuter les tests
Après avoir examiné le diff, choisissez "Oui / Yes". Claude lancera alors le test qu'il vient de créer.
Résultat attendu : Dans le terminal, vous verrez les résultats des tests, ressemblant à ceci :
test_calc.py::test_average_empty_list PASSED
test_calc.py::test_average_normal PASSEDVoir tous les tests au vert signifie que ce bug a été corrigé et verrouillé — si à l'avenir quelqu'un rétablit cette ligne, le test s'allumera en rouge pour donner l'alerte.
Cinquième étape : Quittez et vérifiez les modifications des fichiers
Quittez Claude (tapez exit ou appuyez sur Ctrl+D), et regardez dans le terminal :
cat calc.py(Pour Windows PowerShell, utilisez type calc.py)
Résultat attendu : Le traitement des listes vides (par exemple if not nums: return 0) a bien été ajouté à la fonction average dans calc.py, et un nouveau fichier de test est présent dans le répertoire. Si tout correspond à ce que vous aviez approuvé = Le processus de correction de bug est validé, félicitations !
⚠️ Attention : Si lors de la troisième étape Claude n'écrit pas de test de lui-même, il est fort probable que vous ayez retiré le 3ème point de votre modèle. Ne faites pas l'économie de cette instruction — le verrou que représente le test de régression est ce qui différencie les débutants des professionnels.
💡 En résumé : Appliquez le processus de correction de bug par vous-même — insérez un vrai bug, utilisez le modèle pour trouver la cause profonde avant de corriger, puis vérifiez la présence et la réussite des tests ; une fois que vous aurez maîtrisées cette tâche, les trois autres suivront naturellement.
07 Résumé
Cet article a décomposé 80 % de vos tâches quotidiennes en quatre catégories, chacune accompagnée de son approche spécifique et d'un modèle que vous pouvez copier :
| Tâche | Cœur du modèle en une phrase | Point d'attention crucial |
|---|---|---|
| Explorer le code | « Architecture globale → Où est le code pour X → Tracer le processus » | Trois niveaux du général au particulier, les deux premiers en Plan Mode |
| Corriger un bug | « Coller l'erreur et la reproduction → Trouver la cause profonde → Corriger → Ajouter un test de régression » | Résoudre la racine, ne pas masquer les symptômes, ne jamais omettre le test de régression |
| Refactoriser | « Expliquer l'existant → Objectif → Modification par petites étapes → Tester avant et après » | Le comportement ne doit pas changer ; sans test, en ajouter un d'abord |
| Écrire des tests | « Tests, focus sur les valeurs vides/zéro/négatives/types erronés » | Le forcer à tester les limites, lui demander de combler les trous |
Maintenant, vous devriez pouvoir : Prendre en charge n'importe laquelle de ces tâches sans hésiter, simplement en appelant le modèle adapté et en remplissant les blancs, sachant exactement ce que Claude doit faire à chaque étape, et ce que vous devez surveiller. Ces quatre modèles seront votre charpente pour la grande majorité de votre travail à venir ; avec la pratique, vous découvrirez que les tâches même les plus complexes ne sont en fait que des combinaisons de ces quatre méthodes de base.
Ces quatre modèles résisteront à l'épreuve de l'utilisation quotidienne — même les tâches qui semblent complexes finiront par revenir à ces quatre logiques fondamentales.
Article suivant : 17 « Images et Multimodalité » — Jusqu'ici nous n'avons utilisé que des « instructions textuelles », mais certaines choses sont difficiles à expliquer par de simples mots : une capture d'écran d'un message d'erreur, une maquette de design, un schéma de structure de base de données. Le prochain article vous apprendra à fournir des images directement à Claude pour qu'il s'en serve pour travailler. Imaginez : cette erreur qui vous prend la tête, et si vous pouviez juste lui envoyer la capture d'écran ? Ce serait tellement plus simple !