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 :
- Lire le fichier du test pour comprendre le scénario
- Lire
order.service.tsà la ligne 42 - Remonter le flux de données pour trouver où
undefinedest introduit - Identifier la cause racine (paramètre manquant, erreur de typage, etc.)
- Proposer et appliquer le correctif
- 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