Aller au contenu principal

Debugging assisté par IA

Trouver et corriger les bugs plus vite

Le debugging est un art : il faut comprendre le symptôme, remonter à la cause racine, et corriger sans casser autre chose. Codex accélère chaque étape de ce processus.

Débugger à partir d’une erreur

La manière la plus directe : donnez l’erreur à Codex.

"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."

Codex va :

  1. Lire le fichier du test pour comprendre le scénario
  2. Lire order.service.ts à la ligne 42
  3. Remonter le flux de données pour trouver où undefined est introduit
  4. Identifier la cause racine (paramètre manquant, erreur de typage, etc.)
  5. Proposer et appliquer le correctif
  6. Relancer le test pour vérifier

Débugger un comportement inattendu

Parfois il n’y a pas d’erreur, mais le comportement n’est pas celui attendu :

"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."

Codex trace le flux de données depuis la requête HTTP jusqu’à l’insertion en base de données, identifie l’endroit où le calcul est incorrect, et propose une correction.

Analyser des logs de production

Vous pouvez fournir des extraits de logs :

"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 comprend que les indices pointent vers une fuite de connexion à la base de données et cherche dans le code les endroits où une connexion est ouverte sans être correctement fermée.

Debugging par bisection

Pour les bugs difficiles à localiser, demandez à Codex d’investiguer méthodiquement :

"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."

Patterns de debugging efficaces

Symptôme Instruction Codex
Test qui échoue Donne le message d'erreur complet + le fichier du test
Erreur de type Donne la sortie de tsc --noEmit
Erreur runtime Donne la stack trace + les étapes pour reproduire
Comportement incorrect Décris le résultat attendu vs le résultat observé
Problème de performance Donne les métriques (temps de réponse, requêtes lentes)

Prévenir les bugs futurs

Après avoir corrigé un bug, demandez à Codex d’ajouter des protections :

"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."

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