Utilisez l'IA pour décortiquer un message d'erreur et construire une démarche de diagnostic, au lieu de quémander un correctif que vous ne comprendrez pas.
Ouvrir cette leçon dans KodokonFace à un bug, le réflexe dominant consiste à coller la stack trace dans un chat avec « corrige ça ». Ça fonctionne souvent - et c'est précisément le problème. Vous repartez avec un correctif que vous n'avez pas compris, et la classe de bugs dont il relève reviendra sous une autre forme le mois prochain. Un bug est une occasion d'apprentissage rare : il révèle un écart entre votre modèle mental et le comportement réel du système. Demander le correctif, c'est jeter cette information. Le bon usage : demander à l'IA d'expliquer le message d'erreur et de vous exposer une démarche de diagnostic - puis mener l'enquête vous-même.
Tu es un développeur senior qui m'aide à progresser en débogage. Ton rôle est de m'expliquer, pas de corriger à ma place.
Contexte : [langage + version, framework, ce que le code doit faire].
Message d'erreur complet, avec la pile d'appels :
[coller le message d'erreur]
Extrait de code concerné (10 à 30 lignes) :
[coller le code]
Ta mission :
1. Explique le message d'erreur partie par partie : que dit-il exactement, et que ne dit-il PAS ?
2. Liste les 2 ou 3 causes les plus probables dans MON contexte, de la plus probable à la moins probable.
3. Pour chaque cause, propose une vérification concrète que je peux faire moi-même (log ciblé, point d'arrêt, test isolé).
Contrainte absolue : ne me donne PAS le correctif. Si tu identifies la cause avec certitude, dis-moi seulement où regarder.Ce prompt a trois propriétés qui font toute la différence. D'abord, le contexte minimal mais complet : versions, intention du code, message d'erreur intégral - une IA qui devine votre contexte hallucine des causes. Ensuite, la demande de causes classées par probabilité : vous apprenez à raisonner en hypothèses, pas en certitudes. Enfin, l'interdiction explicite du correctif : sans elle, le modèle glisse presque toujours vers la solution, parce qu'il a été entraîné à être serviable. C'est à vous de verrouiller le cadre.
Tu es mon coach de débogage. Méthode socratique stricte : tu ne fournis jamais la réponse, tu poses des questions.
Mon bug : [symptôme observé] alors que j'attends [comportement attendu].
Ce que j'ai déjà vérifié : [liste].
Fonctionnement :
- Pose-moi UNE question à la fois pour m'aider à isoler la cause.
- Chaque question doit soit éliminer une hypothèse, soit en renforcer une.
- Quand je réponds, explique ce que ma réponse élimine comme piste avant de poser la question suivante.
- Si je formule une hypothèse, aide-moi à concevoir le test le plus rapide pour la confirmer ou la réfuter.
Interdiction : ne nomme jamais la cause directement, même si elle te paraît évidente.Ce second prompt couvre le cas le plus difficile : le bug silencieux, sans exception, où le programme fait juste autre chose que prévu. La démarche que l'IA doit vous faire pratiquer est celle de tout débogueur expérimenté : reproduire de façon fiable, isoler en réduisant le périmètre (dichotomie sur le code ou les données), formuler une hypothèse falsifiable, tester cette hypothèse par la vérification la moins coûteuse. L'IA joue ici le rôle d'un canard en plastique qui répond - et qui vous empêche de sauter des étapes.