Ce que tu vas obtenir
Un projet avec des priorités, des tâches vérifiables et un point d’avancement que tu peux reprendre dans une nouvelle conversation.
Avant de commencer
- Un projet local ouvert dans Codex.
- Une application existante, ou la version créée dans le premier guide.
- Un dépôt Git pour utiliser les worktrees et le panneau de revue.
Une conversation très longue peut mélanger les idées, les corrections et les décisions. Pour un projet qui dure, garde le cap dans quelques fichiers courts et utilise chaque conversation pour un résultat précis. Ici, on organise l’évolution d’une application de tâches déjà existante. La méthode est une proposition Brefgo ; les fonctionnalités citées sont reliées à la documentation officielle.
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.
Commencer par un état des lieux
Demande à Codex ce qui existe avant de lui faire écrire une feuille de route. Une liste d’idées ne suffit pas : « prévu », « codé » et « essayé » sont trois états différents.
Garde un README.md pour lancer le projet et un docs/suivi.md pour les décisions et l’avancement. Ces noms sont une convention proposée ici, pas des fichiers spéciaux que Codex découvre automatiquement. Indique leurs chemins dans tes demandes.
Dans la barre latérale, renomme les conversations par résultat : « Ajouter le filtre », « Corriger la sauvegarde ». Tu les retrouveras plus facilement.
Agrandir
Examine le projet. Résume ce qui fonctionne déjà, comment le lancer et les points encore incertains. Crée docs/suivi.md avec trois rubriques : vérifié, à faire, questions ouvertes. Ne présente pas une fonctionnalité comme vérifiée sans preuve. Ne modifie pas le comportement de l’application.
Le bon résultatLa note distingue les observations des suppositions. Elle contient la commande de lancement et un prochain objectif compréhensible.
Mettre les règles durables dans AGENTS.md
À la racine du dépôt, AGENTS.md contient les conventions que Codex doit retrouver au début de son travail. Pour cet exemple : langue de l’interface, commandes de vérification, organisation du code et limites d’action.
Garde ce fichier court. Mets les explications détaillées ailleurs et ajoute un lien vers elles quand elles deviennent nécessaires. Sur Reddit, plusieurs utilisateurs décrivent AGENTS.md comme une carte vers la documentation. Ce retour est cohérent avec les conseils récents d’OpenAI ; ce n’est pas une garantie de gain de temps ou de consommation.
La capture montre un autre fichier durable, design.md, utilisé dans l’atelier filmé pour conserver les choix visuels. Il ne remplace pas AGENTS.md : donne à Codex le chemin du document lorsqu’il est utile à la tâche.
Agrandir
# Règles du projet - Interface en français, lisible à 390 px. - Préserver les données et les fonctionnalités existantes. - Garder le code organisé en petits modules. - Lire docs/suivi.md pour reprendre le contexte d’une tâche. - Utiliser les commandes de vérification documentées dans README.md. - Rapporter les vérifications effectuées et leurs résultats. - Ne pas déployer ni envoyer de message sans ma demande.
Le bon résultatLes règles correspondent au projet actuel. Demande à Codex quels fichiers d’instructions il a chargés ; un fichier bien nommé à la bonne racine compte plus qu’un long texte copié dans chaque chat.
Écrire des tâches que tu peux vraiment valider
Remplace « améliorer l’application » par un résultat observable : « un filtre affiche seulement les tâches terminées ». Une tâche comporte un objectif, ce qu’elle inclut, ce qu’elle laisse pour plus tard et un critère de réussite.
Une petite liste Markdown suffit au départ. Par exemple :
- À faire : filtre Toutes / À faire / Terminées. Réussite : changer de filtre ne supprime aucune tâche.
- À faire : modifier un titre. Réussite : le nouveau titre reste après rechargement.
- Plus tard : synchronisation entre appareils.
Tu n’as pas besoin d’un outil de gestion supplémentaire pour commencer.
Agrandir
À partir de docs/suivi.md, propose trois tâches prioritaires. Pour chacune, donne l’objectif utilisateur, le périmètre et un parcours de validation. Choisis ensuite la première tâche à réaliser. Ne commence pas l’implémentation tant que nous n’avons pas choisi.
Le bon résultatChaque tâche peut être vérifiée dans l’interface. Tu peux comprendre ce que « fini » veut dire sans lire tout le code.
Une conversation par objectif, un worktree si nécessaire
Crée une nouvelle conversation pour la tâche choisie, dans le même projet. Les fichiers de suivi donnent le contexte durable ; la nouvelle conversation n’hérite pas magiquement de toutes les décisions des autres conversations.
Si deux tâches indépendantes doivent modifier le même dépôt en parallèle, le mode Worktree prépare une copie de travail Git séparée. Choisis Worktree sous la zone de saisie, puis la branche de départ. Vérifie que les dépendances et le serveur fonctionnent dans cette copie.
Pour une seule tâche, rester en Local est souvent suffisant. Un worktree isole les fichiers ; il ne rend pas les bases de données ni les services externes indépendants. Il faudra relire et intégrer les changements ensuite.
Lis AGENTS.md et docs/suivi.md. Réalise uniquement le filtre Toutes / À faire / Terminées. Préserve les tâches enregistrées. Vérifie que changer de filtre ne modifie pas les données. Termine par les fichiers changés et les résultats de vérification.
Le bon résultatLe travail porte sur une tâche. Si tu utilises un worktree, tu sais dans quelle copie tu regardes le résultat et sur quelle branche tu l’intégreras.
Relire, vérifier et mettre à jour le suivi
Ouvre le panneau de revue du dépôt et regarde les fichiers modifiés. Demande /review pour une revue des changements non commités ou par rapport à une branche de base, selon ton cas. Corrige les problèmes utiles puis rejoue le parcours de validation.
Mets ensuite à jour docs/suivi.md : ce qui a changé, ce qui a été essayé et ce qui reste ouvert. Une note courte et datée rend la reprise plus simple. Elle doit refléter les fichiers actuels.
Le retour de Pedro Piñera sur X raconte justement l’intérêt des contraintes et des vérifications dans une migration réelle. C’est un retour d’expérience sur son projet, pas une promesse de résultat sur le tien.
Fais une revue des changements et vérifie le parcours du filtre. Corrige les problèmes bloquants. Mets à jour docs/suivi.md avec le résultat, les vérifications effectuées et le prochain objectif. Propose un commit local. Ne pousse et ne déploie rien.
Le bon résultatLe critère de réussite est satisfait. Le suivi indique les faits observés, et une autre conversation peut reprendre le projet avec ces fichiers.
À toi de jouer.
Avant de passer à la suite, vérifie ces points :
- Les priorités tiennent dans une courte liste.
- AGENTS.md contient des règles actuelles, sans recopier toute la documentation.
- Chaque conversation poursuit un résultat précis.
- Les tâches terminées ont un parcours de validation et une note de reprise.
