Debugging assisté par IA

Trouver et corriger les bugs plus vite

Le debugging reste un art : comprendre le symptôme, remonter à la cause racine, corriger sans casser autre chose. Codex intervient sur ces trois étapes, mais très inégalement. Sur la première il ne vous apporte presque rien, puisque c’est vous qui observez le symptôme et qui savez ce que le système devrait faire. Sur la deuxième il excelle, parce que remonter un flux de données à travers dix fichiers est un travail de lecture systématique, exactement ce qu’une machine fait mieux qu’un humain fatigué. Sur la troisième il apporte la vérification immédiate par les tests.

Débugger à partir d’une erreur

Le cas le plus direct : vous transmettez l’erreur telle quelle, sans la reformuler ni la résumer.

"Le test src/api/routes/orders.test.ts échoue avec :
  TypeError: Cannot read properties of undefined 
  (reading 'id')
  at createOrder (src/services/order.service.ts:42)

Trouve la cause et corrige le bug."

L’agent enchaîne alors six opérations : il lit le fichier de test pour comprendre le scénario, ouvre order.service.ts à la ligne 42, remonte le flux de données pour trouver où undefined s’est introduit, identifie la cause racine — paramètre manquant, erreur de typage ou autre —, propose et applique le correctif, puis relance le test pour vérifier. La troisième opération est celle qui vous aurait coûté vingt minutes de lecture à voix basse.

Débugger un comportement inattendu

Souvent il n’y a aucune erreur : le programme fait tranquillement quelque chose de faux. Ce sont les bugs les plus coûteux, et ceux où la formulation de votre demande pèse le plus lourd.

"La route POST /api/orders crée bien la commande en base, 
mais le total est toujours 0. Le prix des produits est 
correct dans la table products. Trouve pourquoi le calcul 
du total échoue."

Cette instruction fonctionne parce qu’elle délimite le terrain : ce qui marche, ce qui ne marche pas, et une hypothèse déjà écartée puisque les prix en base sont corrects. Codex trace ensuite le flux depuis la requête HTTP jusqu’à l’insertion, isole l’endroit où le calcul dérape et propose une correction. Sans la phrase sur la table products, il aurait selon toute vraisemblance commencé par vérifier ce que vous veniez de vérifier vous-même.

Analyser des logs de production

Vous pouvez également partir de traces d’exploitation, en collant simplement l’extrait pertinent.

"Voici un extrait de logs de production. L'application 
retourne 500 de manière intermittente sur /api/checkout :

[2026-04-01 14:23:01] ERROR: Connection pool exhausted
[2026-04-01 14:23:01] WARN: Query timeout after 30s
[2026-04-01 14:23:02] ERROR: Transaction rollback

Analyse le code de la route checkout et identifie la fuite 
de connexion."

Codex relie les trois lignes entre elles — pool épuisé, requête en timeout, transaction annulée —, conclut à une fuite de connexion vers la base, puis cherche dans le code les endroits où une connexion est ouverte sans être correctement refermée. C’est typiquement un bug qu’aucun test ne révèle, puisqu’il ne se manifeste que sous charge et qu’il disparaît dès qu’on tente de le reproduire en local.

Debugging par bisection

Quand le problème est diffus plutôt que ponctuel, demandez une investigation méthodique plutôt qu’un correctif.

"Le build TypeScript échoue avec 23 erreurs de type depuis 
la dernière mise à jour de dépendances. Analyse chaque 
erreur, identifie si c'est un changement d'API dans une 
dépendance, et corrige le code pour être compatible avec 
les nouvelles versions."

L’intérêt de cette formulation est qu’elle impose un diagnostic erreur par erreur. Sans la consigne d’identifier l’origine, la tentation d’un agent — comme celle d’un développeur en fin de journée — est d’ajouter des any jusqu’à ce que le compilateur se taise, ce qui transforme vingt-trois erreurs visibles en vingt-trois bugs futurs.

Patterns de debugging efficaces

Le matériau que vous fournissez conditionne tout le reste du travail. À chaque type de symptôme correspond une preuve à joindre, et l’omettre revient à demander un diagnostic sans examen.

Prévenir les bugs futurs

Un bug corrigé n’est traité qu’à moitié tant que rien n’empêche sa réapparition ailleurs. Prolongez donc systématiquement la correction par une tâche de consolidation, formulée à partir de ce que vous venez d’apprendre.

"Le bug venait d'un userId null qui n'était pas vérifié. 
Ajoute des gardes de type dans toutes les fonctions de 
src/services/ qui reçoivent un userId. Ajoute aussi un 
test de régression pour ce cas."

Cette seconde tâche généralise la leçon là où le correctif restait local : les gardes couvrent l’ensemble des services, et le test de régression garantit que le cas précis restera surveillé après votre départ du projet. C’est le geste qui distingue une équipe qui corrige des bugs d’une équipe qui en réduit le stock.

Points clés à retenir

• Donnez à Codex le maximum de contexte : messages d’erreur, stack traces, logs
• Codex trace le flux de données pour remonter à la cause racine
• Il vérifie sa correction en relançant les tests automatiquement
• Après correction, demandez des protections et des tests de régression
• Plus vos instructions sont précises, plus le debugging est rapide