Modèle de bug report pour Claude Code : transformer des erreurs vagues en correctifs reproductibles

Le debugging avec Claude Code dépend d’abord du bug report

Dire “ça ne marche pas” force Claude Code à deviner. Un bon bug report donne le symptôme, la reproduction, le résultat attendu, le résultat réel, les contraintes et la vérification.

Utilisez-le après le runbook de première tâche et avec le modèle de handoff si le contexte doit continuer.

Modèle à copier

Objectif:
- Bug à corriger:
- Hors périmètre:

Environnement:
- OS / browser / runtime:
- branch:
- commandes liées:

Reproduction:
1.
2.
3.

Résultat attendu:
-

Résultat réel:
-

Logs ou captures:
-

Contraintes:
- fichiers autorisés:
- fichiers interdits:
- pas d’envoi externe:

Vérification:
- build/test à lancer:
- URL à vérifier:

Demande à Claude Code:
Réduis d’abord la cause à 3 hypothèses, propose le correctif minimal,
les fichiers touchés et les étapes de vérification. N’édite pas avant accord.

Bon exemple

Bug:
Sur mobile, le CTA pricing déborde à droite.

Reproduction:
1. Ouvrir /en/products/ en largeur 390px
2. Aller jusqu’à la pricing card
3. Le bord droit du CTA dépasse le viewport

Vérification:
npm.cmd run build
Capture Playwright en 390px

Mauvais exemple

Le site est bizarre. Corrige-le.

Il manque le périmètre, le succès attendu et les contraintes.

Checklist avant envoi

• La reproduction prend-elle moins de 3 minutes
• Le succès se vérifie-t-il par commande ou capture
• Les fichiers interdits sont-ils clairs
• Y a-t-il logs, URL ou image

Étape suivante

Gardez les commandes dans le cheatsheet gratuit. Pour standardiser les prompts de debugging, utilisez 50 Prompt Templates. Pour le processus d’équipe, voyez la page de conseil.

En pratique, séparez enquête et correction

L’erreur courante consiste à demander un patch avant d’avoir réduit la cause. L’ordre stable est reproduction, hypothèses, puis correctif minimal. Chaque étape devient ainsi révisable.

À partir de ce bug report, enquête sans modifier.
1. confirme la reproduction
2. liste 3 hypothèses
3. indique la zone de code la plus probable
4. nomme les fichiers à lire avant correction
5. décide si un correctif minimal suffit ou si le design change

Si la réponse dit “non reproductible”, “logs insuffisants” ou “périmètre trop large”, ne corrigez pas encore. Un bon bug report construit un chemin d’enquête vérifiable.