Le cadre de décision : IA-first vs Cerveau-first
Tous les bugs ne se valent pas. Certains sont parfaits pour l'IA, d'autres nécessitent votre cerveau humain. Voici comment décider :
IA-first (demandez à l'IA)
- Erreurs de syntaxe
- Messages d'erreur connus
- Typos et fautes de frappe
- Problèmes de configuration
- Incompatibilités de versions
Cerveau-first (réfléchissez d'abord)
- Bugs d'architecture
- Race conditions
- Logique métier incorrecte
- Problèmes de performance
- Bugs intermittents
L'IA excelle sur les bugs déterministes : ceux qui ont un message d'erreur clair et une cause unique. Elle est moins fiable sur les bugs systémiques : ceux qui impliquent plusieurs composants ou une logique métier complexe.
Le rapport de bug structuré
Le plus grand piège du debugging IA : coller juste le message d'erreur. L'IA va "corriger" quelque chose, mais probablement pas la vraie cause.
Un bon rapport de bug pour l'IA contient 4 éléments :
1. Message d'erreur Le message exact, copié-collé
2. Comportement attendu "Le formulaire devrait envoyer un email"
3. Ce que j'ai essayé "J'ai vérifié les logs, changé le port..."
4. Code concerné La fonction ou le fichier qui pose problème
Comparez ces deux approches :
Approche A (mauvaise)
"TypeError: Cannot read property 'map' of undefined. Corrige."
Approche B (bonne)
"J'ai un TypeError: Cannot read property 'map' of undefined dans ma fonction displayUsers(). Elle reçoit les données d'une API fetch. L'erreur arrive quand l'API retourne une réponse vide. J'ai vérifié : le fetch fonctionne, response.ok est true, mais response.json() retourne parfois null. Voici le code : [code]"
La technique du rubber duck IA
Le rubber duck debugging est une technique classique : expliquer son bug à un canard en plastique force à structurer sa pensée. Avec l'IA, c'est encore mieux : le canard répond.
La technique :
- Expliquez le bug à l'IA comme si elle ne connaissait pas votre projet
- Décrivez ce que DEVRAIT faire le code
- Décrivez ce qu'il FAIT réellement
- Expliquez les hypothèses que vous avez déjà testées
Souvent, le simple fait de formuler le problème clairement suffit à trouver la solution vous-même. L'IA est un bonus.
Le piège : corriger le symptôme, pas la cause
Le plus grand danger du debugging IA : l'IA corrige le symptôme, pas la cause.
Exemple : votre application plante avec "out of memory". L'IA suggère d'augmenter la limite de mémoire PHP. Le vrai problème ? Une boucle infinie dans votre code qui charge des données sans pagination.
Augmenter la mémoire "corrige" l'erreur... temporairement. La boucle infinie, elle, est toujours là.
Règle : quand l'IA propose un fix, demandez-vous toujours : "Est-ce que ça corrige la cause ou le symptôme ?" Si c'est le symptôme, creusez plus.
The decision framework: AI-first vs Brain-first
Not all bugs are created equal. Some are perfect for AI, others require your human brain. Here is how to decide:
AI-first (ask the AI)
- Syntax errors
- Known error messages
- Typos and spelling mistakes
- Configuration issues
- Version incompatibilities
Brain-first (think first)
- Architecture bugs
- Race conditions
- Incorrect business logic
- Performance issues
- Intermittent bugs
AI excels at deterministic bugs — those with a clear error message and a single cause. It is less reliable with systemic bugs — those involving multiple components or complex business logic.
The structured bug report
The biggest debugging trap: just pasting the error message. The AI will "fix" something, but probably not the real cause.
A good bug report for the AI contains 4 elements:
1. Error message The exact message, copy-pasted
2. Expected behavior "The form should send an email"
3. What I tried "I checked the logs, changed the port..."
4. Relevant code The function or file causing the issue
Compare these two approaches:
Approach A (bad)
"TypeError: Cannot read property 'map' of undefined. Fix it."
Approach B (good)
"I have a TypeError: Cannot read property 'map' of undefined in my displayUsers() function. It receives data from a fetch API call. The error happens when the API returns an empty response. I checked: the fetch works, response.ok is true, but response.json() sometimes returns null. Here is the code: [code]"
The AI rubber duck technique
Rubber duck debugging is a classic technique: explaining your bug to a rubber duck forces you to structure your thinking. With AI, it is even better — the duck answers back.
The technique:
- Explain the bug to the AI as if it does not know your project
- Describe what the code SHOULD do
- Describe what it ACTUALLY does
- Explain the hypotheses you have already tested
Often, just formulating the problem clearly is enough to find the solution yourself. The AI is a bonus.
The trap: fixing the symptom, not the cause
The biggest danger of AI debugging: the AI fixes the symptom, not the cause.
Example: your application crashes with "out of memory". The AI suggests increasing the PHP memory limit. The real problem? An infinite loop in your code that loads data without pagination.
Increasing memory "fixes" the error... temporarily. The infinite loop is still there.
Rule: when the AI suggests a fix, always ask yourself: "Does this fix the cause or the symptom?" If it is the symptom, dig deeper.
Testez un rapport de bug structuré. Copiez ce prompt dans Claude :
J'ai un bug dans une fonction JavaScript. Erreur : TypeError: Cannot read property 'length' of undefined à la ligne 3. Comportement attendu : la fonction devrait retourner le nombre d'éléments d'un tableau. Ce que j'ai essayé : vérifier que le tableau est bien passé en argument. Code : function countItems(items) { console.log(items); return items.length; }. La fonction est appelée avec countItems(getData()) et getData() retourne parfois undefined. Quelle est la vraie cause et comment la corriger proprement ?
Sans relire la réponse de l'IA ci-dessus : avec tes mots, comment vérifies-tu qu'un fix proposé corrige la cause et pas seulement le symptôme ?
items.length, le vrai problème n'est pas la ligne 3 mais que getData() renvoie parfois undefined : un ?? [] sur l'appelant traite la cause, un try/catch autour de .length masque le symptôme. Demander « est-ce que ça revient si je change les données d'entrée ? » : si oui, c'est un patch de symptôme.Votre site PHP affiche une page blanche au lieu du formulaire de contact. Rédigez un prompt de debug structuré avec les 4 éléments : message d'erreur, comportement attendu, ce que vous avez essayé, code concerné.
Tu signales à l'IA un TypeError: Cannot read property 'length' of undefined dans countItems(getData()), où getData() renvoie parfois undefined. Elle répond « corrigé » avec ce diff. Tu l'acceptes tel quel ou tu le rejettes ?
function countItems(items) {
try {
return items.length;
} catch (e) {
return 0;
}
}try/catch avale l'erreur et renvoie 0, l'appli ne plante plus… mais elle ment. Un « 0 élément » et un « échec de chargement des données » sont deux situations différentes, et masquer l'undefined ici fera disparaître silencieusement de vrais bugs ailleurs. La cause est en amont : getData() ne devrait jamais renvoyer undefined (corrige-le là), ou l'appelant fait countItems(getData() ?? []). try/catch sert à gérer une erreur attendue, pas à étouffer un undefined qu'on n'a pas compris.Sans remonter dans la leçon : quels sont les 4 éléments d'un bon rapport de bug à l'IA, et quelle question te protège du fix de symptôme ?
Débugger après coup, c'est réparer ce qui aurait pu être évité. La prochaine leçon, le TDD piloté par l'IA, renverse la logique : faire écrire les tests d'abord, puis le code qui les fait passer, pour que l'IA construise juste du premier coup.
Leçon 6 : TDD piloté par l'IA →