Ce que tu vas obtenir
Une correction ciblée, un parcours qui reproduit le bug et une vérification qui prouve que le comportement a changé.
Avant de commencer
- Une application que tu peux lancer dans un projet Codex.
- Les étapes du problème et, si possible, le message d’erreur exact.
- Un dépôt Git pour utiliser le panneau de revue.
Le bouton affiche « Enregistré », mais la modification disparaît quand tu recharges la page. C’est notre exemple. Pour obtenir une correction utile, donne à Codex une recette du problème, puis rejoue cette recette après son intervention. Tu peux appliquer cette méthode à un bouton qui déborde, une liste vide ou une action qui échoue.
Captures réelles de Codex pendant les ateliers filmés d’OpenAI (avril et juillet 2026). Chaque image indique son moment dans la vidéo. Les projets montrés diffèrent de nos exemples ; l’interface peut varier selon la version.
Décrire ce que tu fais, ce que tu vois, ce que tu attends
Une bonne demande de correction contient trois éléments : les étapes, le résultat actuel et le résultat attendu. Ajoute la page concernée et précise si le problème arrive toujours ou seulement parfois.
Pour notre exemple : ouvrir la liste, modifier un titre, enregistrer puis recharger. La disparition du nouveau titre est le symptôme ; la cause peut se trouver dans le stockage, la requête ou l’affichage. Laisse Codex examiner cette chaîne plutôt que de lui imposer une cause devinée.
La capture réelle montre un autre exemple : un problème d’espacement signalé avec une image et un retour précis, pendant que la page reste ouverte à droite.
Agrandir
Bug sur la liste de tâches : je change le titre d’une tâche, je clique sur Enregistrer, puis je recharge la page. Le titre ancien revient alors que l’interface a affiché Enregistré. Attendu : le nouveau titre reste. Reproduis le problème et identifie la cause avant de modifier le code. Si tu ne peux pas le reproduire, explique ce qui manque.
Le bon résultatCodex rapporte une observation ou un manque d’information précis. « J’ai trouvé le bug » sans recette ni résultat ne suffit pas.
Joindre une capture qui apporte une information
Pour un problème visuel, joins une capture du mauvais état. Dans le navigateur intégré, Annotate permet de sélectionner un élément ou une zone et d’écrire un commentaire. Ajoute ensuite un message dans la conversation pour demander la correction de ce retour.
Pour une perte de données, une seule image ne montre pas la séquence : accompagne-la des étapes de rechargement et du texte d’erreur. Recadre dès la capture sur ce qui est utile et retire les informations privées avant de la joindre.
Dans l’enregistrement ci-dessous, le titre « ADM courses » est sélectionné et le champ de commentaire est ouvert. La capture montre l’annotation en cours dans le logiciel ; les libellés peuvent varier selon la version.
Agrandir
J’ai joint une capture du formulaire après l’enregistrement. Le message confirme une réussite, mais les données disparaissent au rechargement. Utilise les étapes de reproduction du message précédent. Ne te limite pas à modifier le texte du message.
Le bon résultatLe retour permet de repérer la page et l’état concernés. Il décrit aussi le comportement invisible sur l’image.
Demander une réparation limitée au problème
Une fois la cause identifiée, demande la plus petite correction qui résout le comportement. Le but est de conserver les autres actions, les données et l’apparence.
Quand c’est possible, demande un test de régression : un test qui échoue avec le bug et réussit après la réparation. Ce test doit vérifier ce que l’utilisateur attend, pas simplement recopier la nouvelle fonction. Si le projet n’a pas encore de tests, un parcours manuel précis reste utile ; Codex doit expliquer ce qu’il a pu exécuter.
Corrige la cause de la perte du titre après rechargement. Préserve les données existantes et les autres actions. Si l’infrastructure de tests le permet, ajoute un test de régression qui reproduit ce problème. Lance les vérifications pertinentes et indique les commandes, les résultats et les limites.
Le bon résultatLa correction agit sur la sauvegarde réelle. Un message de réussite doit correspondre à une opération réussie, et une erreur doit rester visible.
Utiliser la revue pour comprendre les changements
Dans un projet Git, ouvre le panneau de revue. Le diff montre les lignes ajoutées et supprimées. Choisis le bon périmètre : les changements non commités ou la comparaison avec ta branche de base. Le panneau reflète aussi les changements que tu as faits toi-même dans ce dépôt.
Tape /review dans la zone de saisie et sélectionne la portée adaptée. Pour donner un retour précis sur le diff, ajoute un commentaire sur la ligne concernée puis demande à Codex d’y répondre. La revue peut repérer des problèmes ; elle ne prouve pas que l’application fonctionne.
Relis cette correction en priorité sur trois points : données conservées après rechargement, message de réussite fidèle au résultat, autres actions préservées. Signale les problèmes avec le fichier concerné et explique leur effet. N’élargis pas la tâche à une refonte.
Le bon résultatTu comprends les fichiers modifiés et l’effet du changement. Les problèmes de revue retenus ont été corrigés, avec une nouvelle vérification ciblée.
Rejouer exactement le scénario initial
Reprends le parcours du début : change le titre, enregistre, recharge. Vérifie ensuite qu’ajouter, terminer et supprimer une tâche fonctionne encore. Pour une correction mobile, teste le même écran et le même état que dans la capture initiale.
Si le problème revient, précise le navigateur, l’état de départ et la séquence. Garde le correctif en cours pour l’examiner au lieu de demander une reconstruction complète.
Quand le parcours passe, conserve une version et écris la cause ainsi que la validation dans le suivi du projet. Ces quelques lignes seront utiles si le bug réapparaît.
Rejoue le scénario initial après correction, puis vérifie l’ajout, la complétion et la suppression d’une tâche. Résume la cause, la correction et les observations. Distingue les tests exécutés des vérifications restant à faire. Prépare un commit local de la correction vérifiée.
Le bon résultatLe nouveau titre reste après rechargement. Les autres actions fonctionnent. La note finale décrit ce qui a effectivement été essayé.
À toi de jouer.
Avant de passer à la suite, vérifie ces points :
- Le bug a une recette de reproduction claire.
- La correction préserve les autres comportements et les données.
- J’ai lu le diff et traité les remarques utiles.
- Le scénario initial réussit après réparation, avec une preuve adaptée.
