Déboguer avec l’IA sans perdre sa capacité à réfléchir

TL;DR

Copier une erreur dans un agent et accepter la première correction est rapide. Cela ne t’apprend pas forcément à déboguer. La bonne boucle consiste à lire le symptôme, reproduire le problème, formuler une hypothèse, observer ce qui permet de la confirmer ou de l’écarter, puis demander à l’IA de challenger ton diagnostic.

Faire disparaître une erreur n’est pas toujours la résoudre

Une erreur apparaît dans le terminal ou dans le navigateur. Le réflexe est devenu presque mécanique : copier le message dans Claude Code ou Codex, demander une correction, accepter la modification proposée et passer à la suite.

L’erreur disparaît. On a l’impression d’avoir débogué.

Parfois, c’est vrai. Souvent, on a seulement déplacé le problème ou masqué son symptôme.

Le débogage n’est pas une collection de correctifs. C’est une manière de réduire l’incertitude jusqu’à comprendre pourquoi le système se comporte ainsi. Cette méthode paraît plus lente quand on regarde uniquement le temps passé sur la première erreur. Elle devient beaucoup plus rapide lorsqu’une erreur voisine arrive la semaine suivante et que tu reconnais déjà sa famille.

Prenons une situation réaliste dans notre mini-dashboard. L’API renvoie une réponse où la métrique CPU vaut null. Le composant, lui, suppose qu’il reçoit toujours un nombre et tente de le formater. La page casse.

La correction la plus rapide pourrait être de remplacer la valeur manquante par zéro. L’écran ne plante plus. Mais le dashboard annonce maintenant une charge CPU à 0 %, alors que la donnée est inconnue. Techniquement, le crash a disparu. Fonctionnellement, on vient peut-être de créer une information fausse.

Le problème n’est donc pas seulement la ligne qui échoue. Il peut se situer dans le contrat de l’API, dans la validation de la réponse, dans le type utilisé ou dans la manière d’afficher un état indisponible. C’est précisément là que le raisonnement humain doit rester présent.

Commencer par une hypothèse, pas par une demande de correction

Avant de solliciter l’agent, prends quelques minutes pour lire l’erreur en entier. Regarde le fichier, la ligne, la stack trace et les étapes exactes qui permettent de la reproduire. Ensuite, essaie de dire ce que tu crois comprendre.

Dans notre exemple, l’hypothèse peut être simple : « La réponse externe n’est pas validée avant d’arriver dans le composant, donc cpu peut être nul alors que le rendu attend un nombre. »

Cette phrase n’a pas besoin d’être correcte. Elle doit pouvoir être vérifiée.

Une hypothèse transforme une erreur vague en enquête. Tu sais alors quelle observation chercher : la réponse brute de l’API, la valeur après validation, puis la valeur reçue par le composant. Chaque observation élimine une partie des causes possibles. Tu n’as plus besoin d’ajouter des logs partout, ni de demander à l’IA de deviner toute l’architecture depuis une stack trace isolée.

Le prompt change complètement :

Voici l’erreur, les étapes de reproduction et mon hypothèse.

Ne modifie aucun fichier.
Évalue d’abord mon hypothèse. Indique l’observation la plus utile pour la confirmer ou l’écarter.
Propose au maximum deux causes alternatives, classées par probabilité.
Distingue les faits observés de tes déductions.

L’agent n’est plus un bouton « corriger ». Il devient un second regard. Il peut repérer une piste oubliée, suggérer une observation plus discriminante ou t’éviter de perdre une heure sur une cause peu probable. Mais il travaille sur ton raisonnement, pas à sa place.

Les logs ne sont pas une stratégie

Lorsqu’on bloque, on voit souvent apparaître une pluie de console.log. C’est compréhensible. Un log donne l’impression d’agir. Pourtant, un log n’est utile que s’il répond à une question.

« Quelle valeur sort de la validation ? » est une question utile. « Est-ce que l’appel API répond avant le rendu ? » en est une autre. « Mettons des logs dans tous les fichiers » ne réduit rien. Cela ajoute simplement du bruit dans lequel on risque de rater l’information importante.

Un agent peut t’aider à instrumenter le code, mais demande-lui toujours la question que chaque ajout est censé éclairer. Demande-lui aussi de signaler les données sensibles : un token, une adresse e-mail, une réponse complète d’API ou une information client n’a rien à faire dans des logs de production.

Quand le contexte s’y prête, un point d’arrêt dans un débogueur est souvent plus précis. Il te permet d’observer une valeur au moment exact où elle change, au lieu de reconstituer le déroulé après coup. L’outil importe moins que la discipline : observer une frontière à la fois.

Une correction doit respecter le contrat, pas seulement le symptôme

Revenons à notre métrique CPU absente. L’agent peut suggérer ceci :

const cpu = metrics.cpu ?? 0

Ce code est court. Il peut même sembler prudent. Mais il prend une décision métier silencieuse : il confond une donnée indisponible avec une charge inexistante.

La bonne correction dépend de ce que le système promet réellement. Si null est une réponse attendue, l’interface doit afficher clairement que la mesure est indisponible. Si cette valeur ne devrait jamais arriver, la réponse doit être rejetée à la frontière et l’incident rendu visible. Si elle vient d’une API instable, il faut peut-être préserver la dernière valeur connue, mais uniquement si cette règle est explicitement définie.

Ce sont des décisions de produit et d’architecture avant d’être des décisions de syntaxe. L’IA peut proposer plusieurs traitements. Elle ne peut pas choisir discrètement celui qui change la signification de la donnée.

Après la correction, ajoute un test qui reproduit le scénario. Pas parce qu’il faut cocher une case « couverture », mais parce que tu veux empêcher cette même erreur de revenir sous une autre forme. Puis note, en quelques lignes, ton hypothèse de départ, l’observation qui a tranché et le garde-fou ajouté. Cette trace devient une bibliothèque mentale. Avec le temps, tu reconnais plus vite les erreurs de validation, d’état asynchrone, de cache, de configuration ou de permissions.

Garder quelques moments sans assistance

Se priver d’IA pendant une courte session n’est pas un exercice nostalgique. C’est un test de résilience.

Une ou deux fois par semaine, prends une petite erreur et essaie de la diagnostiquer seul pendant vingt minutes. Tu peux consulter la documentation, utiliser le débogueur, écrire un test ou examiner le diff. Ensuite seulement, demande à l’agent une revue de ton approche ou une piste si tu restes bloqué.

L’objectif n’est pas de prouver que tu peux tout faire sans outil. Aucun développeur sérieux ne travaille ainsi. L’objectif est de conserver la capacité d’agir quand l’agent manque de contexte, produit une réponse très assurée mais fausse, ou n’est tout simplement pas disponible.

Plus ton diagnostic est précis, plus l’IA devient efficace. Tu lui donnes un périmètre, des faits, une hypothèse et une question. Elle n’a plus à inventer le reste du système. Voilà le vrai gain : moins de hasard, moins de corrections décoratives et une compréhension qui reste avec toi après la conversation.

Dans le dernier article, nous allons transformer cette méthode en progression concrète sur trente jours.