Déboguer avec l'IA

La façon coûteuse d'apprendre cette leçon est de passer directement à un correctif. Un développeur tombe sur une trace de pile rouge, la colle dans l'assistant et tape « fix this ». L'assistant prédit un correctif plausible, le test qui était rouge devient vert, et le travail continue. Deux jours plus tard, la même défaillance refait surface en production avec une entrée légèrement différente, car le changement a atténué le symptôme sans jamais traiter la cause.

Cela se produit pour une raison précise. L'assistant prédit une sortie plausible à partir de motifs présents dans des millions de dépôts publics. Plausible est exactement le type dangereux, car l'explication semble confiante et complète même lorsqu'elle est erronée pour votre code. Faire correspondre des motifs à travers de nombreux codebases est une opération différente du raisonnement causal à l'intérieur d'un seul. Votre bogue vit dans votre état spécifique, vos versions et vos données, qu'aucun modèle ne peut voir à moins que vous ne les mettiez dans le contexte.

Considérez parseDate() dans un dépôt réel. Il génère une exception sur les entrées qui comportent un décalage horaire comme "2026-03-14T10:00+02:00". Demandez un correctif immédiat et l'assistant peut envelopper l'analyse dans un try/catch et retourner une date de secours. L'exception disparaît, le test évident passe, et une date erronée silencieuse s'écoule maintenant en aval dans les rapports. La trace s'est tue; le bogue s'est caché.

L'avantage de procéder méthodiquement est que la cause est confirmée avec des preuves avant qu'une seule ligne ne change, donc le correctif est le bon et un test de régression le maintient corrigé. La discipline est la même que celle que les bons débogueurs ont toujours utilisée, et l'assistant accélère chaque étape : il lit une trace plus rapidement, il énumère plus d'hypothèses, il écrit la sonde et le test pour vous. Le mécanisme qui transforme « fix this » en un cycle fiable est la boucle d'analyse d'abord, que la section suivante décompose.

Le débogage avec un assistant est une boucle avec des étapes distinctes, et sauter une étape est là où ça déraille. Le principe durable en 2026 est analyser d'abord, corriger ensuite : forcez le modèle à expliquer et à classer avant qu'il ne propose un changement.

• Comprendre. Demandez ce que signifie l'erreur et quelle ligne l'a déclenchée. Traduire une trace cryptique en langage clair est le point fort du modèle, et cela ne coûte presque rien.
• Reproduire. Identifiez l'entrée exacte, la commande et les conditions. Une reproduction est la plus petite recette fiable qui déclenche la défaillance. Sans elle, vous ne pouvez pas confirmer qu'un correctif a fonctionné.
• Émettre des hypothèses. Demandez au modèle de lister les causes probables, classées de la plus probable à la moins probable. Le classement le force à s'engager dans un ordre que vous pouvez tester plutôt que de couvrir toutes les possibilités.
• Confirmer. Choisissez une hypothèse et testez-la avec une seule vérification : une valeur imprimée, un point d'arrêt ou une entrée restreinte. Les preuves, et non la confiance dans le texte, décident quelle cause est réelle.
• Corriger et verrouiller. Apportez le plus petit changement qui traite la cause confirmée, relancez la reproduction, puis ajoutez un test de régression qui échoue sur l'ancien code et réussit sur le nouveau.

La distinction qui décide du succès est inspection versus preuves d'exécution. Lire le code suffit pour de nombreux bogues logiques. Pour le timing, l'état partagé, l'ordre asynchrone et les conditions de course, une valeur imprimée au moment de l'échec surpasse toute quantité de lecture, car le bogue n'existe que pendant l'exécution du programme. C'est pourquoi Cursor a livré Debug Mode en 2026 : l'agent ajoute des instructions de journalisation qui se diffusent vers un serveur de débogage local, vous reproduisez le bogue, et il lit les journaux capturés pour trouver la cause racine à partir de preuves d'exécution avant de faire un correctif ciblé, puis retire l'instrumentation. Claude Code atteint le même objectif différemment, avec un sous-agent debugger qui conserve les outils Edit et Bash pour qu'il puisse reproduire, corriger et retester dans une boucle serrée; sans Bash, il peut théoriser mais jamais confirmer.

Le piège intégré dans la boucle est ce qu'une équipe a nommé le piège de l'hypothèse plausible. La cause la mieux classée par le modèle semble autoritaire, alors vous l'implémentez et sautez l'étape de confirmation. Lorsque le symptôme disparaît par hasard, vous enregistrez un correctif que vous n'avez jamais prouvé. La garde est mécanique : n'appliquez jamais une hypothèse que vous n'avez pas confirmée avec une vérification qui aurait écarté les autres. La section suivante suit un bogue à travers toute la boucle pour que les étapes cessent d'être abstraites.

Une développeuse, Maya, possède un petit module utilitaire dans un service Node. Un utilisateur signale que les horodatages d'une API partenaire apparaissent avec une heure de décalage dans l'exportation quotidienne. L'appel défaillant est parseDate("2026-03-14T10:00+02:00") dans src/utils/date.ts, qui génère une exception sur les entrées avec un décalage horaire. Voici la boucle qu'elle exécute.

1. Rassembler le contexte. Maya colle l'erreur exacte, la trace de pile complète, le corps de parseDate(), le diff récent qui l'a touché, et l'environnement : Node 22, l'échec est constant, uniquement sur les entrées contenant un décalage +HH:MM.
2. Comprendre avant de corriger. Son premier prompt se termine par « Ne le corrigez pas encore. Expliquez ce que signifie l'erreur et quelle ligne la déclenche. » L'assistant identifie qu'une expression régulière de décalage retourne null, et la ligne suivante lit une propriété sur ce null.
3. Classer les hypothèses. Elle demande les trois causes les plus probables, de la plus probable à la moins probable. En tête : l'expression régulière correspond à Z et aux heures nues mais pas à la forme +HH:MM. Deuxième : le décalage est analysé mais appliqué avec le mauvais signe. Troisième : la chaîne d'entrée est mal tronquée en amont.
4. Confirmer avec une vérification. Elle demande la plus petite sonde possible. L'assistant suggère de journaliser offsetMinutes juste avant son utilisation. Elle reproduit avec la chaîne partenaire exacte et le journal imprime NaN, ce qui correspond à la première hypothèse et écarte la théorie du mauvais signe, car une erreur de signe produirait quand même un nombre.
5. Apporter le plus petit correctif. « Confirmé. Gérer la forme de décalage +HH:MM. Ne touchez pas aux autres branches. » Le diff est de quelques lignes qui étendent l'expression régulière et convertissent les heures et minutes en minutes signées.
6. Verrouiller et nettoyer. Elle demande à l'assistant d'écrire un test qui passe "2026-03-14T10:00+02:00" et affirme le résultat UTC. Il échoue sur l'ancien code, réussit sur le nouveau. Elle supprime la ligne de journalisation temporaire, puis valide le correctif et le test ensemble, notant la cause dans le message.

La session entière a pris quinze minutes et l'exportation est maintenant correcte pour les entrées avec décalage, avec un test qui attrapera toute régression. Le contraste est net : la version « juste corriger » aurait enveloppé l'analyse dans un try/catch, retourné une valeur de secours, et expédié une heure silencieusement erronée dans chaque exportation. Maya et son bogue de décalage se poursuivent dans les pièges ci-dessous, car la boucle a des bords tranchants que l'exécution propre a cachés.

Chaque piège ci-dessous semble être un progrès sur le moment tout en brisant silencieusement le travail, donc le correctif se trouve dans le même élément.

• Sauter la reproduction. Corriger un bogue que vous ne pouvez pas déclencher à la demande signifie que vous ne pouvez pas dire si votre changement a fonctionné ou si l'échec ne s'est simplement pas produit. Construisez d'abord la reproduction, même un script d'une ligne, et conservez-le comme test.
• Faire confiance à l'explication confiante. La cause la mieux classée se lit comme un fait. Traitez chaque hypothèse classée comme une affirmation qui nécessite une vérification qui aurait falsifié les alternatives, et écartez celles que les preuves réfutent.
• Le correctif à la mitraillette. Laisser un agent modifier cinq fichiers en poursuivant une théorie vous laisse incapable de dire quel changement a corrigé le bogue ou ce qu'il a cassé d'autre. Changez une chose, relancez la reproduction, puis décidez de la prochaine étape.
• Symptôme plutôt que cause. Un try/catch qui avale l'erreur, ou une valeur par défaut qui cache une mauvaise valeur, fait taire la trace sans traiter pourquoi la valeur était erronée. Corrigez la cause que les preuves ont indiquée, pas l'endroit où l'erreur est apparue.
• Laisser l'instrumentation derrière. Les lignes de journalisation et les serveurs de débogage ajoutés pendant la chasse sont du bruit dans le diff et peuvent divulguer des données. Retirez-les avant de valider, de la même manière que le Debug Mode de Cursor supprime ses propres journaux une fois le correctif vérifié.

Deux véritables cas limites étirent la boucle simple. Le bogue non déterministe. Les conditions de course et les échecs de timing ne se reproduisent pas à la demande, donc une seule exécution ne prouve rien. Ici, l'instrumentation d'exécution est le seul outil honnête : ajoutez une journalisation qui capture l'ordre des événements et l'état partagé, puis reproduisez plusieurs fois jusqu'à ce que le mauvais entrelacement apparaisse dans les données capturées. Un correctif que vous avez « confirmé » sur une seule exécution chanceuse n'est pas confirmé du tout.

Le correctif halluciné. Une particularité de 2026 est que l'assistant peut proposer d'importer un package pour résoudre le bogue, et le package n'existe pas. L'étude USENIX Security 2025 de 2,23 millions d'échantillons générés a trouvé que 19,7 % faisaient référence à au moins un package halluciné, et les attaquants enregistrent ces noms pour attaquer les personnes qui copient la suggestion. Confirmez que toute nouvelle dépendance se résout en un package réel et prévu sur le registre avant de l'installer. Ces cas limites deviennent plus difficiles une fois que plus d'une personne possède le code, ce qui est là où la section suivante se dirige.

Une personne peut garder une session de débogage en tête. Dès qu'un coéquipier doit reproduire le bogue, revoir le correctif ou reprendre là où vous vous êtes arrêté, la session a besoin d'un enregistrement durable, sinon les connaissances s'évaporent dès que la trace défile.

L'artéfact durable le moins cher est une courte note de débogage attachée au problème ou à la PR : le symptôme, la reproduction exacte, les hypothèses considérées, celle que les preuves ont confirmée et comment, et le correctif. Une responsable, Priya, en fait une partie de la définition de fait de l'équipe pour un correctif de bogue, afin que la prochaine personne qui voit une trace similaire trouve le raisonnement plutôt que juste le correctif. La même note appartient à la description de la PR, qui devrait enregistrer qu'un assistant a proposé le correctif et le prompt qui a trouvé la cause, afin qu'un réviseur humain puisse répéter la vérification plutôt que de faire confiance au diff.

L'échelle façonne également la mesure dans laquelle vous laissez un agent fonctionner sans surveillance. Le sous-agent debugger de Claude Code fonctionne dans son propre contexte et ne peut pas afficher une invite de permission, donc les sous-agents en arrière-plan refusent automatiquement les nouveaux outils; le modèle sûr est de garder l'exploration en lecture seule et de différer les changements Edit et Bash à la session parente où un humain peut les voir. Le Bugbot de Cursor passe en revue les pull requests automatiquement, et Cursor rapporte qu'à son effort par défaut, environ 80 % des bogues qu'il identifie sont résolus au moment de la fusion en 2026, ce qui en fait un premier passage utile. Le propre cadrage de Cursor garde l'humain dans la boucle ici, puisque l'équipe suit un taux d'acceptation (la part des découvertes de Bugbot qu'un réviseur approuve), et la directive largement répétée autour de ces outils est de laisser la révision humaine prendre la décision. Traitez tout débogueur automatisé, celui du modèle ou un bot de révision, comme un brouillon qui classe les suspects, puis faites confirmer la cause par une personne et décidez ce qui passe en production.

Gardez les correctifs petits pour la même raison que vous gardez les hypothèses uniques. Un correctif de bogue qui arrive sous la forme d'un diff ciblé de quelques dizaines de lignes est un correctif qu'un réviseur peut réellement lire et raisonner; un changement tentaculaire enterre la véritable correction parmi des modifications accessoires et submerge la révision qui est censée attraper la prochaine erreur.

Le principe durable à garder, quelle que soit la taille de l'équipe : confirmez la cause avec des preuves avant de changer le code, et verrouillez le correctif avec un test qui a échoué il y a un instant. Commencez par une petite chose sur votre prochain bogue. Avant de demander un correctif, demandez ce que signifie l'erreur et quelle ligne l'a déclenchée, et ne laissez pas l'assistant toucher au code tant que vous ne pouvez pas nommer la cause vous-même.