Quatre flux de travail quotidiens : Exploration, correction de bugs, refactorisation, rédaction de tests

📚 Navigation de la série : L'article précédent 13 · Rédaction des prompts vous a appris comment vous exprimer — en découpant des besoins flous en instructions précises compréhensibles par Codex. Cet article aborde un autre angle d'application : 80 % de vos tâches quotidiennes se répartissent en quatre catégories. Pour chacune d'elles, je vous propose un flux de travail à appliquer directement. Le prochain article portera sur 15 · Autorisations, bac à sable et validations.

Commençons par une petite discussion. La semaine dernière, un collègue qui venait de passer à Codex m'a demandé dans un groupe :

« Je lui ai demandé de corriger un bug. Il a fait disparaître le message d'erreur en un rien de temps, et j'ai validé la modification. Mais le lendemain, le même problème est réapparu. D'où cela peut-il venir ? »

Je lui ai demandé : « Est-ce que tu lui as demandé d'identifier la cause réelle du problème d'abord ? Est-ce que tu as ajouté un test de non-régression ? »

Il m'a répondu : « ...Ah bon ? Corriger un bug, ce n'est pas juste faire disparaître le message d'erreur ? »

C'est exactement là que réside le problème. Il a confondu la « disparition du message d'erreur » avec la « résolution du problème », sans pour autant verrouiller le bug avec un test. Pourtant, l'exploration, la correction de bugs, la refactorisation et la rédaction de tests suivent des démarches bien précises. Si vous appliquez la bonne méthode, Codex travaille de manière rapide et fiable ; si vous vous y prenez mal, il résoudra le problème en apparence tout en introduisant des failles invisibles.

Le chapitre précédent traitait de la rédaction générale des prompts. Celui-ci applique ces principes à quatre scénarios très fréquents. Après plusieurs mois d'utilisation de Codex, j'ai formalisé ces quatre flux de travail, conçus pour s'adapté au fonctionnement propre de Codex — il s'appuie sur les fichiers ouverts dans l'IDE, alors qu'il nécessite que vous les désigniez explicitement avec @ dans la CLI ; il excelle dans les tâches qu'il peut valider de lui-même, vous devez donc lui donner les moyens de réaliser cette validation.

Après avoir lu cet article, vous obtiendrez :

• Quatre flux de travail applicables directement à vos tâches fréquentes (exploration, correction de bugs, refactorisation, rédaction de tests), détaillant les différences entre l'IDE et la CLI
• Les principes fondamentaux expliquant la logique de chaque démarche, pour éviter d'appliquer bêtement des modèles
• Un tableau récapitulatif synthétisant ces quatre démarches, disponible à la fin de l'article
• Un exercice pratique complet à suivre pas à pas pour corriger un bug réel en appliquant la démarche recommandée

⚠️ Dans la suite de cet article, toutes les commandes, options de commandes slash et comportements par défaut font référence à la documentation officielle de Codex ; les noms de modèles ou les libellés de l'interface dépendent de votre installation locale.

---

01 Comprendre les spécificités de chaque tâche

Avant de commencer, distinguons les caractéristiques de ces quatre types de travaux. Leurs exigences vis-à-vis de Codex diffèrent grandement. Si vous utilisez la mauvaise méthode, l'efficacité de l'outil s'en trouvera fortement réduite.

Analogie : Choisir le bon couteau de cuisine pour chaque ingrédient. On utilise un couteau à filet pour le poisson et un couperet pour les os. Tenter de couper des os avec un couteau à filet risquerait d'endommager la lame. L'exploration, la correction de bugs, la refactorisation et la rédaction de tests correspondent à ces outils différents — la clé de l'efficacité n'est pas seulement de savoir utiliser Codex, mais de savoir quelle démarche appliquer à la tâche en cours.

Leur principale différence réside dans un critère simple : la tâche implique-t-elle de modifier le code existant ?

Tâche	Modification du code	Rôle principal de Codex	Votre point de contrôle
Explorer le code	Non (lecture seule)	Lire les fichiers et expliquer leur rôle	La pertinence des explications fournies
Corriger un bug	Oui	Reproduire le bug, identifier la cause et corriger	La cause identifiée et la présence d'un test de non-régression
Refactoriser	Oui (sans changement de comportement)	Réécrire le code à fonctionnalité équivalente	S'assurer que le comportement reste identique
Rédiger des tests	Oui (ajout de fichiers)	Générer des tests et couvrir les cas limites	La couverture complète des cas limites et cas d'erreur

Vous constatez la logique ? L'exploration présente un risque nul (lecture seule), vous pouvez donc interroger Codex sans contrainte. La correction de bugs et la refactorisation modifient le code, vous devez donc demander à Codex de vous expliquer sa démarche avant d'appliquer les modifications. La rédaction de tests se situe entre les deux : elle ajoute de nouveaux fichiers sans impacter le code de production existant, mais vous devez vérifier que Codex ne se limite pas à tester les cas nominaux.

Le principe directeur de ces quatre démarches est décrit dans la documentation officielle de Codex :

Codex est beaucoup plus performant lorsqu'il est en mesure de valider son propre travail. Fournissez-lui les instructions pour reproduire le problème, les méthodes pour tester la fonctionnalité, ainsi que les commandes de lint et de test — cela lui donne des critères clairs sur lesquels s'appuyer, plutôt que de s'arrêter dès que le code « semble » correct.

Ce principe constitue la base de nos quatre flux de travail. Les sections suivantes détaillent, pour chaque tâche, comment fournir à Codex un moyen de valider son propre travail.

💡 En résumé : Classez les quatre tâches selon qu'elles modifient le code ou non. L'exploration s'effectue sans risque, tandis que les modifications imposent d'analyser la démarche avant codage. Pour chaque flux, assurez-vous de fournir un moyen de validation automatisé à Codex.

Ce schéma compare les quatre types de tâches : chaque case présente une tâche, sa nature vis-à-vis des modifications de code, sa démarche principale et le point de contrôle sur lequel vous devez vous concentrer. Les sections suivantes détaillent chacune de ces démarches.

---

02 Explorer un projet inconnu : une démarche progressive en trois niveaux

Voyons d'abord la situation la plus courante : vous découvrez un projet de code inconnu et devez en comprendre le fonctionnement.

Auparavant, vous deviez parcourir les dossiers, ouvrir de nombreux fichiers au hasard et tenter de reconstituer le puzzle, une tâche qui prenait de nombreuses heures. Désormais, Codex utilise votre projet comme espace de travail : il peut analyser l'ensemble du code et répondre à vos questions.

Analogie : Découvrir un centre commercial inconnu. On consulte le plan général, puis on localise le magasin recherché, et enfin on suit l'itinéraire pour s'y rendre. Vous ne commencez pas par fouiller chaque rayon au hasard. Vous analysez d'abord la répartition des étages (architecture globale), puis vous ciblez le rayon concerné (localisation du module), et enfin vous suivez le chemin d'accès (analyse du flux). Procéder du général au particulier, du plan global à l'itinéraire précis, c'est la méthode à appliquer pour explorer du code.

Il existe une différence importante à prendre en compte dans la formulation de vos questions — les extensions IDE de Codex et l'interface en ligne de commande (CLI) ne gèrent pas le contexte de la même manière, et cela diffère également de Claude Code : là où la CLI de Claude Code analyse automatiquement l'ensemble du projet via le fichier CLAUDE.md et l'espace de travail, la CLI de Codex nécessite que vous désigniez explicitement les fichiers concernés avec @ pour qu'il puisse les analyser.

L'extension IDE inclut automatiquement dans le contexte les fichiers ouverts et le code sélectionné. Dans la CLI de Codex, vous devez impérativement spécifier les chemins de fichiers avec @ (ou utiliser /mention pour associer un fichier).

En clair : dans l'IDE, ouvrez les fichiers concernés et sélectionnez le code cible avant de poser votre question ; dans la CLI, utilisez le préfixe @nom_de_fichier dans votre prompt. C'est une distinction essentielle pour que Codex dispose du contexte nécessaire.

Exploration dans l'IDE (la méthode la plus rapide en local)

Ouvrez les fichiers principaux du projet, sélectionnez le bloc de code qui vous intéresse (fortement recommandé), puis formulez votre demande sur ce modèle recommandé :

Explique-moi comment les requêtes traversent le code sélectionné.

Précise notamment :
- Le rôle de chaque module concerné, sous forme de résumé succinct
- Quelles données sont validées et à quel endroit
- Les points de vigilance ou pièges potentiels lors de la modification de ce bloc

Pour obtenir un récapitulatif facile à vérifier, vous pouvez enchaîner avec cette demande :

Résume le flux de traitement sous forme d'étapes numérotées, et liste les fichiers concernés.

Exploration dans la CLI (idéal pour conserver un historique textuel et lancer des commandes shell)

Lancez la session interactive :

codex

Spécifiez ensuite les fichiers avec @ (indispensable dans la CLI, contrairement à l'IDE) :

Je souhaite comprendre le protocole utilisé par ce service. Analyse les fichiers @foo.ts et @schema.ts.
Explique-moi la structure des données et le flux « requête / réponse », en précisant les champs obligatoires, facultatifs et les règles de compatibilité ascendante.

Une excellente habitude que j'applique systématiquement sur un nouveau projet : verrouiller les autorisations en mode lecture seule pendant toute la phase d'exploration. Comme vu au chapitre 12 · Commandes slash et raccourcis clavier, utilisez la commande /permissions pour passer en mode Read Only — cela garantit que Codex n'effectuera aucune modification accidentelle de vos fichiers alors que vous lui demandez simplement des explications. L'exploration doit rester sans risque.

L'année dernière, j'ai dû analyser un projet Go hérité de plus de 30 000 lignes. J'ai appliqué cette démarche : d'abord identifier les points d'entrée et demander une description de l'architecture globale via la CLI, puis cibler les fichiers du service concerné pour en comprendre le fonctionnement, et enfin demander un résumé étape par étape du traitement des requêtes. J'ai compris le fonctionnement du projet en une demi-journée, une tâche qui m'aurait pris plusieurs jours auparavant.

Voici la démarche d'exploration à suivre selon votre interface :

Étape	Flux dans l'IDE	Flux dans la CLI
1. Transmettre le contexte	Ouvrir les fichiers clés et sélectionner le code cible	Spécifier les fichiers avec @chemin/fichier ou /mention
2. Analyser l'architecture	« Présente-moi l'architecture globale et le rôle des modules clés »	Identique (fichiers spécifiés avec @)
3. Cibler les composants	« Quels fichiers gèrent la fonctionnalité [X] ? »	Identique
4. Tracer le flux	« Explique-moi le parcours complet du flux [Y] »	Identique
5. Synthétiser le résultat	« Résume les étapes sous forme de liste numérotée avec les fichiers associés »	Identique
Tout au long	Sécuriser le code	Utiliser /permissions pour passer en mode Read Only

💡 En résumé : L'exploration doit être progressive — de l'architecture globale aux fichiers cibles, puis au flux d'exécution. N'oubliez pas la spécificité de Codex : l'IDE analyse les fichiers ouverts, la CLI requiert l'usage du symbole @. Sécurisez la démarche en activant le mode lecture seule.

---

03 Corriger un bug : la méthode en 4 étapes (Reproduire → Identifier → Corriger → Valider)

La correction de bugs est une tâche fréquente mais particulièrement exposée aux erreurs — c'est le problème rencontré par le collègue de travail mentionné au début de l'article.

Pourquoi cette tâche est-elle sensible ? Parce que l'erreur classique consiste à fournir un message d'erreur et à demander « corrige cela », ce qui pousse Codex à proposer une modification qui fait simplement disparaître le message d'erreur. Supprimer le symptôme ne résout pas la cause réelle du bug : le problème est masqué mais la faille subsiste et se manifestera à nouveau sous une autre forme.

Analogie : Placer un seau sous une fuite d'eau ne répare pas le tuyau. Vider le seau régulièrement (faire disparaître l'erreur) masque le problème mais ne traite pas la cause — vous devez localiser la section de tuyau fissurée (identifier la cause), la remplacer (corriger le bug) et ouvrir l'eau à nouveau pour vérifier que la fuite a disparu (valider). Corriger un bug de développement suit exactement la même logique : ciblez la source du problème, ne masquez pas seulement les symptômes.

La démarche recommandée pour corriger un bug avec Codex consiste à lui fournir une méthode de reproduction précise plutôt qu'une simple description générale. La documentation officielle l'explique ainsi :

Les éléments que vous fournissez — comme les étapes de reproduction et les contraintes — sont bien plus importants qu'une description générale de haut niveau. Codex fournit en retour les résultats de commandes, les points d'appel identifiés et les traces d'erreur générées.

La démarche de correction de bug doit impérativement suivre ces quatre étapes :

1. Fournir les étapes de reproduction et les fichiers suspects : collez le message d'erreur complet, décrivez précisément les actions menées pour déclencher l'anomalie, et mentionnez les fichiers que vous suspectez.
2. Demander de reproduire le bug puis d'identifier la cause : la documentation conseille de demander explicitement à Codex de reproduire le bug en local. Une fois le bug reproduit, l'analyse de la cause sera fiable. Ne le laissez pas faire de suppositions à distance.
3. Proposer la correction : une fois la cause identifiée et validée, demandez à Codex d'écrire la correction en lui imposant d'effectuer des modifications minimales.
4. Valider la correction : Codex doit exécuter à nouveau les étapes de reproduction après modification. Si le projet dispose de tests ou de vérifications automatisées, demandez-lui d'exécuter le lint et les tests associés et de vous présenter les résultats.

Cette quatrième étape est essentielle et constitue la véritable valeur ajoutée du flux de travail. La documentation officielle propose cette formulation simple pour l'étape de validation :

Une fois la correction appliquée, lance la commande de lint et le jeu de tests associé. Indique-moi les commandes utilisées et les résultats obtenus.

Cette validation permet de verrouiller le bug — si un développeur modifie à nouveau ce bloc par erreur ultérieurement, le test de non-régression se lancera et signalera l'anomalie. Le bug résolu par mon collègue est réapparu simplement parce qu'aucun test n'avait été mis en place pour verrouiller le comportement attendu.

Correction de bug dans l'IDE

Ouvrez le fichier contenant le bug ainsi que les fichiers qui l'appellent (l'IDE les inclura au contexte), puis formulez votre demande :

Identifie la cause du bug provoquant le message « données enregistrées » alors qu'aucune écriture n'est faite en base de données.
Propose une correction et indique-moi comment vérifier visuellement sa résolution.

Correction de bug dans la CLI

Lancez Codex à la racine du projet et fournissez une fiche de reproduction structurée sur ce modèle recommandé par la documentation officielle :

codex

Bug : Lors du clic sur « Enregistrer » dans la page des paramètres, le message « Modifié » s'affiche mais les modifications ne sont pas persistées après rafraîchissement.

Reproduction :
1) Lancer l'application : npm run dev
2) Accéder à la page /settings
3) Activer l'interrupteur « Notifications »
4) Cliquer sur Enregistrer
5) Rafraîchir la page : l'interrupteur est revenu à son état initial

Contraintes :
- Ne pas modifier la signature de l'API.
- Proposer une correction minimale et ajouter un test de non-régression si possible.

Reproduis le bug en local, identifie la cause du problème, puis propose un correctif et exécute les vérifications.

Voici la structure type à utiliser pour corriger un bug :

Bug : [Description succincte de l'anomalie]
Reproduction :
[Étape 1, 2, 3... de la mise en route au déclenchement]
Contraintes :
[Limiter la portée des modifications, préserver les API...]
Fichiers suspects :
[Spécifier les fichiers avec @ si vous les avez identifiés]
Démarche attendue : Reproduis d'abord le bug → Identifie la cause (ne pas coder) → Propose une correction minimale → Exécute le lint et les tests associés.

💡 En résumé : Le flux de correction de bug comporte quatre étapes : détailler la reproduction, reproduire et identifier la cause, coder une correction minimale, et valider par des tests. Fournir une méthode de reproduction précise est indispensable pour éviter que Codex ne se contente de masquer le problème.

---

04 Refactoriser du code : planifier, modifier par étapes, assurer l'équivalence et tester

La refactorisation de code est l'opération la plus risquée, car elle intervient sur du code fonctionnel.

Contrairement à la correction de bug où la réussite se valide simplement (l'erreur disparaît, le test passe), la refactorisation exige que le comportement externe du code reste strictement identique, tout en améliorant sa structure et sa lisibilité. Si le comportement change, vous introduisez de nouveaux bugs sous couvert de nettoyage. Ces régressions sont complexes à détecter car on pense rarement à tester en détail du code que l'on a « simplement réorganisé ».

Analogie : Remplacer des composants sur un train à grande vitesse en marche. Le train doit continuer de rouler à la même vitesse et les passagers ne doivent ressentir aucune secousse pendant que vous remplacez un élément technique par un modèle plus moderne et plus simple à entretenir. La refactorisation suit ce principe : les services rendus (l'expérience utilisateur) doivent rester strictement inchangés.

Les deux erreurs classiques lors d'une refactorisation sont de vouloir tout réécrire d'un coup (rendant impossible toute validation progressive) et de travailler sans tests de couverture (rendant invisible tout changement de comportement). La démarche recommandée pour Codex répond à ces deux risques : concevoir un plan détaillé, puis l'implémenter par étapes successives.

Étape 1 : Demander un plan de refactorisation

La documentation officielle conseille de demander un plan d'action à Codex avant de modifier le code. Si vous disposez du skill $plan (planification), appelez-le explicitement (les skills s'appellent avec le symbole $, à ne pas confondre avec le mode plan /plan de la CLI). Ce skill est généralement disponible par défaut ; s'il n'est pas configuré, demandez simplement à Codex de « formuler un plan sans modifier le code ».

Voici comment formuler cette demande en définissant l'objectif et les contraintes :

$plan

Nous souhaitons refactoriser le module auth. Objectifs :
- Séparer les responsabilités (gestion des tokens / chargement des sessions / vérification des droits)
- Éliminer les dépendances cycliques
- Améliorer la testabilité du code

Contraintes :
- Le comportement fonctionnel externe doit rester strictement identique
- L'API publique du module ne doit pas être modifiée
- Propose un plan de migration étape par étape

Analysez le plan proposé et ajustez-le avec Codex si nécessaire — cette phase de cadrage est la clé de la réussite du projet :

Ajuste le plan d'action :
- Précise les fichiers impactés pour chaque étape
- Ajoute une stratégie de retour arrière (rollback) en cas d'erreur

Cette phase de planification répond au principe officiel : « diviser les tâches complexes en étapes simples et ciblées permet à Codex de mieux travailler et vous facilite la relecture ». En structurant le plan autour d'étapes associées à des fichiers précis, vous transformez un grand projet de refactorisation en une suite de modifications simples à valider.

Étape 2 : Implémenter par étapes et valider chaque modification

Une fois le plan validé, demandez à Codex d'implémenter les étapes l'une après l'autre, en exécutant les tests après chaque modification pour vérifier l'absence de régression. Appliquez cette règle stricte :

Ne lancez jamais de refactorisation sur du code qui ne dispose pas d'une couverture de tests. Si vous demandez à Codex de simplifier une fonction non testée, il risquera de supprimer une vérification qu'il juge inutile mais qui traite en réalité un cas limite rare. L'anomalie ne se manifestera qu'en production.

Si le code existant ne dispose pas de tests, la première étape de votre refactorisation ne doit pas être de modifier le code, mais d'écrire des tests. Ces tests serviront à figer le comportement actuel (créer un instantané). Après la refactorisation, vous vérifierez que les tests passent toujours pour confirmer l'absence de régression. Ce principe rejoint celui de la correction de bug : fournir un moyen de validation automatisé à Codex, pour éviter de valider des modifications sur sa seule déclaration de conformité.

J'ai commis cette erreur par le passé : j'ai laissé Codex simplifier une fonction de formatage de montants qui ne disposait d'aucun test. Il a supprimé une condition de traitement des nombres négatifs qu'il pensait inutile. L'anomalie est passée inaperçue lors de mes tests manuels et n'a été détectée que lors de la réconciliation des comptes en environnement de recette. Depuis, j'applique cette règle absolue : aucun code n'est refactorisé sans disposer d'une couverture de tests préalable.

Voici le flux de refactorisation recommandé :

Étape	Action	Point clé
1. Planifier	Demander un plan d'action (avec $plan ou textuellement)	Fixer l'objectif et les contraintes : comportement inchangé, API stables
2. Valider le plan	Préciser les fichiers impactés et le rollback pour chaque étape	Découper le projet en étapes simples à valider
3. Couvrir de tests	Si le code n'est pas testé, générer les tests décrivant le comportement actuel	Créer un instantané du comportement de référence
4. Modifier par étapes	Implémenter le plan étape par étape	Éviter les modifications globales en une seule fois
5. Tester à chaque étape	Lancer les tests après chaque modification et vérifier la conformité	Annuler la modification et revenir en arrière au moindre échec

ℹ️ Pour les projets de refactorisation importants, vous pouvez combiner cette démarche avec l'exécution à distance : définissez le plan et validez les étapes en local, puis confiez les modifications lourdes et les exécutions de tests à l'environnement cloud de Codex. Ce flux est décrit au chapitre 10 · Codex Cloud dans le Cloud. Concentrez-vous d'abord sur la maîtrise de la démarche en local.

💡 En résumé : L'enjeu de la refactorisation est de préserver le comportement existant. Demandez un plan d'action détaillé à Codex, découpez le travail en étapes simples, et exécutez les tests après chaque modification. Si le code n'est pas testé, commencez par écrire les tests avant de refactoriser.

---

05 Rédiger des tests : contraindre Codex à couvrir les cas limites

Le dernier flux de travail concerne la rédaction de tests pour votre code.

Codex est particulièrement performant pour générer des tests — la documentation officielle précise qu'il sait analyser et respecter les conventions des tests existants du projet. Il réutilisera les mêmes frameworks, syntaxes de mock et styles d'assertion que vos fichiers actuels, sans nécessiter de configuration de votre part. Cependant, vous devez anticiper une tendance naturelle de l'outil : sans consigne contraire, Codex a tendance à ne tester que les cas nominaux (happy path).

Qu'est-ce que cela signifie ? Si vous lui confiez une fonction de tri de liste, il écrira un test vérifiant que [1, 2, 3] est trié correctement. Le test passera, mais les cas limites (edge cases) — comme une liste vide, une liste contenant un seul élément, la présence de valeurs null ou une liste extrêmement volumineuse — seront ignorés. Pourtant, ce sont ces cas limites qui provoquent les plantages en production. Le but des tests est de valider ces cas limites.

Analogie : Tester la sécurité d'un véhicule en situation réelle. Vous ne testez pas la sécurité d'une voiture en la faisant rouler à vitesse modérée en ligne droite. Les tests utiles consistent à simuler un freinage d'urgence sur route mouillée, un évitement d'obstacle ou un choc frontal — c'est-à-dire des situations extrêmes. Les pannes surviennent aux limites, pas en conditions normales. Le but de la rédaction de tests est de contraindre Codex à tester ces situations limites.

Les guides officiels pour les deux interfaces insistent sur ce point : vous devez demander de couvrir à la fois les cas nominaux (happy path) et les cas limites (edge cases).

Rédaction de tests dans l'IDE (basée sur le code sélectionné)

Ouvrez le fichier contenant le code à tester, sélectionnez les lignes de la fonction, utilisez l'action « Add to Codex Thread » (Ajouter au fil Codex) de la palette de commandes pour l'ajouter au contexte, puis saisissez :

Génère les tests unitaires pour cette fonction. Respecte les conventions d'écriture des tests existants du projet.

L'action « Add to Codex Thread » est spécifique à l'IDE — elle transmet précisément le code sélectionné à Codex, ce qui est plus fiable que de lui décrire le nom de la fonction.

Rédaction de tests dans la CLI (en spécifiant les fonctions et fichiers)

Lancez Codex et désignez le fichier et la fonction avec @, en spécifiant explicitement les cas limites à tester :

codex

Écris les tests unitaires pour la fonction invert_list dans @transform.ts.
Couvre le cas nominal et intègre les cas limites.

La consigne essentielle de ce prompt officiel réside dans la mention « et intègre les cas limites ». Si vous l'omettez, Codex se limitera probablement au cas nominal. Comparez les deux approches :

❌ Formulation imprécise	✅ Formulation structurée
« Écris les tests pour cette fonction »	« Écris les tests unitaires pour la fonction invert_list de @transform.ts. Couvre le cas nominal et insiste sur les cas limites : liste vide, liste à un seul élément, présence de valeurs null et liste de grande taille »
Codex teste uniquement le cas nominal, donnant une fausse impression de couverture	Codex teste les cas qui risquent réellement de provoquer une panne

Vous pouvez également demander à Codex d'identifier des cas limites supplémentaires auxquels vous n'auriez pas pensé :

Identifie d'autres cas limites ou conditions d'erreur non mentionnés et ajoute les tests correspondants.

J'utilise cette formule systématiquement : Codex identifie fréquemment des cas d'erreur complexes auxquels je n'avais pas pensé. Pour une fonction de calcul d'intervalles de dates, alors que j'avais listé les cas limites classiques (dates vides, inversées), il a ajouté des tests pour la gestion du passage à l'heure d'été et pour des intervalles sur une même journée. Des cas complexes à formaliser de tête.

Voici la démarche pour rédiger des tests :

Étape	Démarche dans l'IDE	Démarche dans la CLI
1. Désigner le code	Sélectionner la fonction → « Add to Codex Thread »	Spécifier le fichier avec @chemin et nommer la fonction
2. Aligner le style	Demander de respecter les conventions de test existantes	Identique
3. Définir les cas limites	Demander de tester le cas nominal et les cas limites spécifiés	Identique
4. Compléter les tests	Demander d'identifier et de tester d'autres cas limites	Identique
5. Valider	Demander d'exécuter les tests et de corriger les éventuels échecs	Identique

💡 En résumé : Pour rédiger des tests, ne vous contentez pas d'une demande générale. Demandez explicitement de couvrir les cas limites (valeurs vides, null, limites de types), en vous appuyant sur la formule officielle « et intègre les cas limites ». Laissez Codex compléter avec ses propres suggestions de cas d'erreur.

---

06 Pratique : exécuter le flux complet de correction d'un bug

Mettons en pratique ces notions. Nous allons utiliser le flux de « correction de bug » — c'est le flux qui comporte le plus d'étapes, sa maîtrise vous permettra d'appliquer facilement les trois autres. Nous allons créer et corriger une anomalie réelle.

Différences de plateforme : les commandes mkdir et cd ci-dessous s'utilisent directement sous Mac / Linux. Sous Windows, exécutez-les dans PowerShell, et créez le fichier calc.py manuellement s'il le faut.

Étape 1 : Créer un projet contenant une anomalie

mkdir bug-demo
cd bug-demo

Sous Mac / Linux, créez le fichier avec echo :

echo 'def average(numbers):
    return sum(numbers) / len(numbers)' > calc.py

Sous Windows, créez le fichier calc.py et insérez-y ces deux lignes :

def average(numbers):
    return sum(numbers) / len(numbers)

Cette fonction average calcule la moyenne d'une liste de nombres. Elle semble correcte, mais si on lui passe une liste vide, la valeur de len(numbers) sera 0, provoquant une erreur de division par zéro. C'est ce bug que nous allons corriger.

Résultat attendu : le dossier bug-demo contient le fichier calc.py avec les deux lignes de la fonction average.

Étape 2 : Lancer Codex dans le dossier du projet

codex

Résultat attendu : l'interface TUI s'ouvre, avec la zone de discussion au centre et le champ de saisie en bas.

Étape 3 : Appliquer le flux de correction en fournissant la reproduction

Saisissez ce prompt structuré dans le champ de saisie (il reprend la structure présentée à la section 03 en précisant les étapes de reproduction, les contraintes et l'ordre des actions) :

Bug : L'appel à la fonction average dans calc.py provoque une erreur si on lui passe une liste vide average([]).

Reproduction :
1) Passer une liste vide [] à la fonction average
2) L'erreur ZeroDivisionError: division by zero est levée systématiquement

Contraintes :
- Modification minimale requise, ne pas modifier la signature de la fonction.

Démarche attendue : Reproduis d'abord le bug, identifie la cause (ne modifie rien), puis propose une correction minimale, et enfin écris un test de non-régression validant le comportement pour une liste vide et exécute-le.

Résultat attendu : Codex va reproduire l'anomalie et vous expliquer la cause — len(numbers) vaut 0 pour une liste vide, provoquant une division par zéro ; il vous présentera ensuite un diff de correction (par exemple, renvoyer 0 ou lever une exception explicite si la liste est vide) et attendra votre validation ; après validation, il créera un fichier de test (comme test_calc.py) contenant la validation pour la liste vide.

ℹ️ L'arrêt pour demande de validation dépend de la stratégie active de vos autorisations (le mode Auto autorise par défaut les écritures de fichiers dans l'espace de travail). Les mécanismes de validation et de bac à sable sont détaillés au chapitre 15 · Autorisations, bac à sable et validations.

Étape 4 : Valider la modification et observer la vérification

Validez la modification présentée dans le diff (sélectionnez « Oui » ou appuyez sur Entrée). Codex lancera alors l'exécution du test généré — ce qui correspond à l'étape finale de validation du flux.

Résultat attendu : les résultats d'exécution des tests s'affichent dans la console (le format dépend de votre environnement) :

test_calc.py::test_average_empty_list PASSED
test_calc.py::test_average_normal PASSED

Les tests passent au vert = le bug est corrigé et verrouillé par un test — toute régression ultérieure sera détectée par l'exécution de ce test.

Étape 5 : Quitter et valider les modifications de fichiers

Quittez Codex (saisissez /exit), puis vérifiez le fichier dans votre terminal :

cat calc.py

（Sous Windows PowerShell, utilisez type calc.py）

Résultat attendu : le fichier calc.py a été modifié et intègre le contrôle de la liste vide. Un fichier de test a également été créé dans le dossier. La structure du code est conforme aux modifications validées à l'étape 4, le flux est validé.

⚠️ Si Codex n'a pas généré de fichier de test à l'étape 3, vérifiez que vous avez bien inclus la consigne « écris un test de non-régression » dans votre prompt. Cette consigne est indispensable — la rédaction de tests de validation distingue les développeurs professionnels des débutants.

💡 En résumé : Exécutez le flux complet de correction de bug en pratique — créez une anomalie, transmettez les étapes de reproduction, laissez Codex reproduire et corriger, puis vérifiez qu'il génère et exécute le test de non-régression. Maîtriser ce flux vous permettra de traiter les autres types de tâches.

---

07 Récapitulatif

Cet article a structuré 80 % de vos tâches de développement quotidiennes en quatre flux de travail précis :

Tâche	Flux recommandé	Point de contrôle clé
Explorer le code	Architecture générale → Cibles spécifiques → Flux d'exécution	Utiliser l'IDE pour les fichiers ouverts, et @ dans la CLI ; activer le mode Read Only
Corriger un bug	Détailler la reproduction → Reproduire et analyser → Corriger au plus juste → Valider par test	Fournir une méthode de reproduction précise, et écrire le test de non-régression
Refactoriser	Concevoir le plan → Valider et découper → Écrire les tests manquants → Modifier et valider par étape	Garantir que le comportement externe reste identique ; ne pas refactoriser sans tests
Rédiger des tests	Sélectionner la fonction → Aligner le style de test → Demander de couvrir cas nominaux et cas limites	Utiliser la formule officielle « et intègre les cas limites » (valeurs vides, null, etc.)

Le principe commun de ces quatre flux est de permettre à Codex de valider son propre travail : en fournissant des étapes sous forme de liste pour l'exploration, des tests pour la correction et la refactorisation, et en exigeant la couverture des cas limites pour les tests, vous donnez à Codex les critères de réussite indispensables pour travailler sans votre supervision constante.

Vous êtes désormais capable de : aborder n'importe quelle tâche de développement courante avec une démarche structurée ; identifier les différences d'utilisation entre l'IDE et la CLI ; appliquer la méthode de correction de bug en 4 étapes ; structurer une refactorisation complexe ; et contraindre Codex à tester les cas limites de votre code.

Ces quatre flux de travail constituent la base de vos développements quotidiens avec Codex. En les appliquant systématiquement, vous gagnerez en rigueur et en efficacité.

---

Le chapitre suivant, 15 · Autorisations, bac à sable et validations, détaille les mécanismes de sécurité de Codex : vous avez observé que Codex demande parfois votre validation avant de modifier un fichier ou d'exécuter une commande. Nous allons voir comment configurer ces niveaux d'autorisation, comprendre le fonctionnement du bac à sable (sandbox) et régler le niveau d'autonomie de l'agent. Une question en guise de réflexion : lors de l'exercice pratique de correction de bug, Codex a demandé votre validation avant d'écrire le fichier. Si vous souhaitez qu'il applique les modifications dans l'espace de travail sans vous solliciter, mais qu'il demande votre validation pour les actions en dehors du projet, comment devez-vous configurer l'outil ?

---

Lectures recommandées

• Définir des Skills pour automatiser des tâches complexes
• Automatisation et intégration continue (CI/CD) : exécuter Codex en autonomie
• Codex Cloud : déléguer les exécutions longues dans le cloud