Accueil / Gestes courants

Déboguer et corriger un bug

Une commande de reproduction précise et une trace de pile complète orientent le diagnostic vers la cause réelle d'un bug, et la correction ne se déclare close qu'après qu'un test de régression reproduisant le cas fautif a été exécuté et sa sortie lue.

Coller à Claude Code la seule dernière ligne d'un message d'erreur laisse la cause réelle du bug hors de vue. Le flux de travail documenté pour corriger un bug efficacement demande un geste plus complet : donner la commande qui reproduit le problème et la trace de pile complète, pas seulement son dernier appel affiché à l'écran.

Reproduire avant de diagnostiquer

Trois éléments font la différence entre une correction qui touche le symptôme et une correction qui touche la cause. La commande exacte qui déclenche le bug, la trace de pile entière depuis le point d'entrée jusqu'à l'erreur, et une précision sur son caractère intermittent ou constant. Un bug qui n'apparaît qu'une fois sur dix appels n'a pas la même cause qu'un bug qui échoue à chaque appel, et cette distinction oriente tout le diagnostic qui suit.

L'exemple suivant fabrique ses propres données pour rester valable à toute lecture, sans toucher à aucun fichier réel d'un projet. Une fonction qui partage un total entre un nombre de parts échoue quand ce nombre vaut zéro.

function partager(total, nombreDeParts) {
  return total / nombreDeParts; // aucune garde sur nombreDeParts
}

console.log(partager(90, 3));  // 30, cas normal
console.log(partager(90, 0));  // Infinity, le bug réel se cache ici

La trace de pile désignerait ici l'appel exact à partager(90, 0), la commande de reproduction serait cet appel isolé, et la nature du bug serait constante : zéro part produit toujours le même résultat invalide, jamais une erreur intermittente.

Le correctif ne se clôt pas sur le vert immédiat

Une fois la cause identifiée, la correction se limite au code responsable, sans retoucher ce qui fonctionnait déjà. Le geste final consiste à exiger un test de régression qui reproduit exactement le cas fautif observé, puis à lire sa sortie avant de considérer le bug clos.

function partager(total, nombreDeParts) {
  if (nombreDeParts === 0) throw new Error("nombre de parts invalide");
  return total / nombreDeParts;
}

try {
  partager(90, 0);
} catch (erreur) {
  console.log("test de régression : ", erreur.message);
}

Cette exigence rejoint directement l'écriture du test avant l'implémentation : dans les deux cas, la confiance vient d'une sortie exécutée et lue, pas d'une relecture du code corrigé.