Rédaction des prompts : exprimer ses besoins de manière percutante pour Codex
📚 Navigation de la série : L'article précédent 12 · Commandes slash et raccourcis clavier vous a appris à placer vos doigts au bon endroit dans la session — le
/pour changer de mode, vider le contexte et afficher l'état. Les raccourcis clavier vous sont désormais familiers. Cet article aborde un autre niveau : maintenant que vous savez où appuyer, vous devez savoir comment vous exprimer. Pour un même besoin, selon que vos exigences sont bien formulées ou non, le travail fourni par Codex peut être radicalement différent.
On dit souvent que la puissance d'un outil de programmation IA dépend de son modèle — je ne suis pas d'accord.
Pour dire les choses franchement : avec un même GPT-5 et sur un même dépôt de code, celui qui sait exprimer ses besoins résout le problème en trois phrases, tandis que celui qui ne sait pas s'y prendre enchaîne cinq aller-retours infructueux et finit frustré. Les modèles sont déjà bien assez puissants, et la plupart du temps, ce qui bloque n'est pas leur intelligence, mais les instructions que vous leur fournissez. Si vous envoyez une consigne vide d'informations comme « corrige ce bug », le modèle doit deviner : quel fichier, quelle erreur, quel résultat attendu... Tout repose sur des suppositions. S'il se trompe et que vous vous plaignez devant un diff erroné en vous disant « cette IA n'est pas au niveau », le problème ne vient pourtant pas d'elle.
C'est exactement ce qui m'est arrivé l'année dernière. Un service Node renvoyait une erreur 500. J'ai tapé à la va-vite « l'API de connexion est plantée, corrige-la », sans même joindre les journaux d'activité. Codex a cherché un moment, a sélectionné ce qu'il pensait être le bug et a modifié trois fichiers, sans pour autant traiter la véritable cause du problème — l'erreur venait d'une variable d'environnement que je n'avais pas mentionnée et dont il ignorait l'existence. C'est à ce moment-là que j'ai compris : les limites de Codex sont en grande partie fixées par ma propre façon de formuler les questions.
Cet article ne cherche donc pas à vous faire apprendre des modèles de prompts par cœur, mais à vous faire comprendre une chose essentielle : de quelles informations Codex a-t-il réellement besoin pour ne pas s'égarer ? Une fois ce principe assimilé, rédiger vos prompts deviendra naturel.
Après avoir lu cet article, vous obtiendrez :
- Un tableau comparatif « mauvais prompt vs bon prompt » à appliquer pour réduire immédiatement le taux de retours inutiles
- Le cadre en « quatre points » pour structurer vos demandes : Objectif, Portée, Contraintes, Validation — si l'un de ces points manque, Codex devra le deviner
- Comment diviser une tâche volumineuse en étapes faciles à traiter pour Codex et simples à relire pour vous
- Comment utiliser la commande
/goal(mode objectif) pour fixer les critères de réussite sous la forme « ne pas s'arrêter tant que le résultat n'est pas atteint » (nécessite l'activation préalable defeatures.goals, détails à la section 05) - Un exercice pratique comparant deux formulations pour un même besoin afin de constater la différence par vous-même
⚠️ Dans la suite de cet article, toutes les commandes, paramètres et comportements par défaut font référence à la documentation officielle de Codex ; les noms de modèles ou les éléments d'interface dépendent de votre configuration locale.
01 Qu'est-ce qui caractérise un mauvais prompt ?
Analysons en détail mon échec mentionné au début. L'instruction « l'API de connexion est plantée, corrige-la » manquait cruellement d'informations pour Codex :
- De quelle API de connexion s'agit-il ? Il doit chercher dans tout le projet.
- Comment se manifeste la panne ? Quelle est l'erreur, et dans quelles conditions se produit-elle ? Il n'en sait rien.
- Quel est le comportement attendu ? Il doit le deviner en se basant sur le fonctionnement classique d'une connexion.
Comme expliqué au chapitre 06 · Exécuter sa première tâche, le travail de Codex repose sur une boucle d'agent (agent loop) : interroger le modèle, lire les fichiers, modifier les fichiers, exécuter des commandes (« réfléchir → agir → observer »). La documentation officielle indique qu'il « exécute des commandes de terminal dans une boucle pour modifier le code, lancer des vérifications et tenter de valider son travail ». Mais même si cette boucle est intelligente, si l'étape initiale de réflexion est alimentée par des instructions imprécises, l'ensemble du cycle tournera à vide dans la mauvaise direction.
Analogie : Renseigner l'adresse de livraison d'une commande. Si vous indiquez simplement « livrer dans cette résidence », le livreur devra tourner entre les bâtiments au hasard, risque de se tromper et finira par vous appeler. Si vous écrivez « Résidence XX, Bâtiment 8, Entrée 2, Appartement 1503, meuble à chaussures vert devant la porte », il trouvera sans hésiter. Plus l'adresse is précise, moins le livreur fait de détours ; plus l'instruction est floue, plus il doit deviner, augmentant le risque d'erreur. Pour formuler une demande à Codex, c'est la même chose — la précision de l'« adresse » que vous fournissez détermine s'il va droit au but ou non.
Voici un tableau comparatif basé sur les recommandations de la documentation officielle :
| Scénario | ❌ Mauvais prompt | ✅ Bon prompt |
|---|---|---|
| Corriger un bug | « L'API de connexion est plantée, corrige-la » | « Les utilisateurs signalent qu'après l'expiration de la session, l'appel à POST /api/login renvoie une erreur 500. Écris d'abord un test d'échec pour reproduire le bug, localise la logique de rafraîchissement des tokens dans src/auth/, corrige-la, puis lance les tests pour vérifier qu'ils passent au vert » |
| Écrire des tests | « Ajoute des tests pour parser.py » | « Écris des tests pour la fonction parse_date de parser.py en couvrant les cas limites d'une chaîne vide et d'un format invalide, n'utilise pas de mocks, et lance pytest pour vérifier que tout passe » |
| Ajouter une fonctionnalité | « Ajoute une fonction d'exportation » | « Analyse le fonctionnement de export_csv dans report.py et ajoute une fonction export_json sur le même modèle, sans ajouter de nouvelles dépendances en dehors des bibliothèques déjà installées » |
| Comprendre du code | « Pourquoi ce module a-t-il été écrit ainsi ? » | « Analyse l'historique Git du module transform et résume comment son interface a évolué jusqu'à sa forme actuelle » |
Vous constatez la différence ? Un bon prompt consiste simplement à fournir à Codex les éléments qu'il aurait autrement dû deviner. N'ayant plus à faire de suppositions, il ne risque pas de s'égarer.
💡 En résumé : Un mauvais prompt oblige Codex à deviner les informations manquantes. Un bon prompt consiste à clarifier à l'avance ce qu'il doit accomplir.
02 Le cadre en « quatre points » : Objectif / Portée / Contraintes / Validation
Pour savoir précisément quelles informations fournir à Codex, vous pouvez vous appuyer sur une structure simple : l'Objectif, la Portée, les Contraintes et la Validation. Considérez-le comme une liste de contrôle à valider mentalement avant chaque demande : chaque point manquant sera un point que Codex devra deviner.
Analogie : La fiche de travaux transmise à un artisan. Un artisan sérieux validera quatre points avec vous avant de commencer : le résultat attendu (l'objectif), les pièces concernées et celles à ne pas toucher (la portée), les contraintes techniques comme les murs porteurs à préserver (les contraintes), et les critères de réception des travaux (la validation). Si ces quatre points sont définis, il travaillera de manière autonome et efficace ; s'il en manque un, il devra faire des choix qui risquent de ne pas vous convenir. Formuler une demande à Codex revient à lui transmettre cette fiche de travaux.
Détaillons ces quatre points et les conséquences de leur absence :
| Point | Question clé | Comment le formuler | Conséquence de son absence |
|---|---|---|---|
| Objectif (Goal) | Que faut-il accomplir ? | « Renvoyer 0 si la liste est vide », « Modifier le format d'exportation en JSON » | Il devine le but attendu, le résultat dépend de la chance |
| Portée (Scope) | Où intervenir et où ne pas toucher ? | Désigner les fichiers ou fonctions : « Modifier uniquement average dans stats.py » | Il cherche au hasard dans tout le projet et risque de modifier d'autres parties |
| Contraintes (Constraint) | Quelles sont les règles à respecter ? | « Ne pas ajouter de bibliothèque », « Assurer la compatibilité ascendante », « Ne pas toucher à migrations/ » | Il applique ses propres préférences qui peuvent ne pas convenir |
| Validation (Verification) | Comment confirmer la réussite ? | « Écrire deux cas de test et les exécuter », « Vérifier que le build renvoie le code 0 » | Il s'arrête dès que le code « semble » correct, vous laissant le soin de détecter les bugs |
Parmi ces éléments, la « Validation » est le point le plus souvent oublié par les débutants, et pourtant le plus important — la documentation officielle insiste particulièrement sur ce point :
Codex est beaucoup plus performant lorsqu'il est en mesure de valider son propre travail. Fournissez-lui les étapes pour reproduire le problème, les méthodes pour tester la fonctionnalité, ainsi que les commandes de lint ou de vérification pré-commit à lancer.
Pourquoi la validation est-elle si importante ? Parce que sans tests ou vérifications à lancer, le simple fait que le code « semble correct » constitue pour Codex le signal de fin de tâche. Si vous ne définissez pas de critères, il s'arrête selon son propre jugement, et c'est à vous de vérifier manuellement chaque modification pour détecter les failles. Mais si vous lui fournissez une vérification qui renvoie un résultat « Succès / Échec » — comme un jeu de tests, une commande de lint ou un code de retour de compilation — la boucle se ferme d'elle-même : il implémente la modification, lance la vérification, analyse le résultat et corrige le code si nécessaire, sans que vous ayez besoin de superviser chaque étape.
Pour mes projets, j'applique désormais systématiquement ce cadre. Le mois dernier, pour ajouter une validation d'adresse e-mail dans un projet Python, j'ai formulé ma demande ainsi :
Ajoute une fonction validate_email dans src/validators.py (objectif).
Modifie uniquement ce fichier, ne touche pas au reste (portée).
Utilise le module standard re, n'ajoute aucune bibliothèque tierce (contraintes).
Écris trois tests pour valider le comportement : user@example.com doit renvoyer True, invalid doit renvoyer False, user@.com doit renvoyer False. Lance pytest pour vérifier que tous les tests passent (validation).Grâce à ces instructions claires, Codex a exécuté la tâche parfaitement du premier coup : il a localisé le fichier, écrit la fonction, ajouté les trois cas de test, lancé l'exécution et présenté le résultat vert. Il n'a eu aucune supposition à faire, car l'ensemble des règles de sa tâche était défini.
💡 En résumé : Avant chaque demande, passez en revue les quatre points « Objectif / Portée / Contraintes / Validation ». Tout point non défini sera interprété par Codex selon ses propres critères. La validation est essentielle : en fournissant une commande de vérification, vous permettez à Codex de valider son travail de manière autonome.
03 Portée et contraintes : privilégiez la transmission directe de contenu
Pour définir la « Portée » et les « Contraintes », il est souvent inutile de rédiger de longues descriptions. Il est plus simple et plus efficace de fournir directement le contenu ou les fichiers concernés.
Le principe est simple : dès que vous le pouvez, transmettez directement le contenu plutôt que de le décrire. Codex analysera toujours plus précisément un document source qu'une description approximative de ce document.
Premièrement, intégrez directement les fichiers concernés dans le contexte. La documentation officielle de Codex précise : lors de la formulation d'une demande, incluez tout le contexte utile à Codex, comme des références vers des fichiers ou des images. Indiquez clairement le chemin du fichier dans votre prompt :
En te basant sur les définitions de types dans src/types/user.ts, ajoute les annotations de type dans UserServiceCette approche est infiniment plus fiable que de dire « il y a un fichier de types utilisateur dans le projet, cherche-le ». L'extension IDE propose d'ailleurs une fonctionnalité très pratique documentée officiellement : elle inclut automatiquement dans le contexte la liste des fichiers actuellement ouverts ainsi que le code sélectionné. Ainsi, dans VS Code, il vous suffit de sélectionner les lignes concernées pour que Codex sache exactement sur quoi travailler, sans description textuelle nécessaire.
Analogie : Connecter une clé USB vs indiquer un emplacement approximatif. Spécifier un fichier ou laisser l'IDE transmettre le code sélectionné revient à connecter une clé USB contenant les données directement sur la console de Codex — les informations sont immédiatement accessibles et exploitables. Lui donner une indication floue revient à lui demander de chercher un document dans une armoire d'archives, au risque qu'il se trompe de dossier. (Le chapitre 02 comparait les serveurs MCP à des clés USB pour connecter des fonctionnalités ; ce principe s'applique ici pour transmettre des données.)
Deuxièmement, copiez-collez l'intégralité d'un message d'erreur au lieu de le résumer. Prenez l'habitude de copier l'ensemble de la trace d'erreur (traceback) sans la simplifier :
L'exécution des tests renvoie cette erreur, aide-moi à en identifier la cause :
TypeError: Cannot read properties of null (reading 'userId')
at getUserProfile (src/services/user.ts:42:18)
at async ProfileController.getProfile (src/controllers/profile.ts:15:20)Pourquoi coller la trace complète ? Parce qu'elle contient le nom du fichier, le numéro de ligne précis et la chaîne d'appels, permettant à Codex de cibler directement user.ts:42. Si vous résumez en disant « j'ai une erreur undefined », vous supprimez ces coordonnées indispensables, obligeant Codex à chercher la source du problème par lui-même.
Troisièmement, transmettez des captures d'écran pour les problèmes d'interface (UI). Codex prend en charge l'analyse d'images — vous pouvez copier-coller ou glisser-déposer une image dans la zone de discussion de l'application de bureau, ou utiliser les options de la CLI (se référer à la documentation officielle). Qu'il s'agisse d'une maquette, d'une capture d'écran d'un bug visuel ou d'un schéma d'architecture, une image sera toujours plus précise qu'une description textuelle pour expliquer un décalage de bouton.
Voici un tableau récapitulatif pour transmettre vos éléments :
| Élément à transmettre | ❌ Description textuelle | ✅ Transmission directe |
|---|---|---|
| Le contenu d'un fichier | « Il y a un fichier qui gère les sessions dans le projet » | Indiquer le chemin exact src/auth/session.ts dans le prompt |
| Le code en cours d'analyse | « Dans la logique principale... » | Sélectionner le code dans l'IDE pour que l'extension l'intègre au contexte |
| Un message d'erreur | « J'ai une erreur undefined » | Copier et coller l'intégralité de la trace d'erreur (traceback) |
| Un problème d'interface (UI) | « Le bouton n'est pas aligné » | Joindre une capture d'écran ou la maquette associée |
💡 En résumé : Définissez la portée et les contraintes en fournissant directement les éléments bruts — chemins de fichiers, code sélectionné, traces d'erreur complètes ou captures d'écran. Privilégiez la transmission directe de contenu au lieu de le décrire, Codex analysera le document source avec beaucoup plus de précision.
04 Comment diviser une tâche importante : pour simplifier le travail de Codex et votre relecture
Le cadre en quatre points convient parfaitement pour structurer une demande simple. Cependant, certaines tâches sont naturellement complexes — comme « implémenter un système d'authentification complet » ou « migrer l'ensemble du projet de JavaScript vers TypeScript ». Si vous soumettez une telle demande en une seule fois, Codex tentera de tout réaliser d'un coup, risquant de faire des choix erronés que vous ne détecterez qu'après la modification de nombreux fichiers.
La documentation officielle de Codex est très claire sur ce point :
Codex est beaucoup plus efficace lorsque vous divisez les tâches complexes en étapes plus simples et ciblées. Les tâches de taille réduite sont plus faciles à tester pour Codex et plus simples à relire pour vous. Si vous ne savez pas comment découper une tâche, demandez d'abord à Codex de vous proposer un plan.
Cette recommandation comporte deux aspects essentiels. D'une part, le découpage facilite votre propre travail de relecture — il est plus simple de valider un diff de quelques dizaines de lignes que d'analyser une modification de plusieurs centaines de lignes répartie sur de nombreux fichiers (ce qui m'aurait évité de valider aveuglément les modifications lors de mon erreur du début). D'autre part, si le découpage est complexe, laissez Codex concevoir le plan de travail — comme mentionné au chapitre 06, demandez d'abord un plan d'action avant de le laisser modifier le code.
Analogie : Découper une tâche comme on prépare un plat complexe. Vous ne pouvez pas réaliser toutes les étapes d'une recette en même temps. Vous préparez d'abord les ingrédients, puis vous cuisez les différents éléments un par un, en vérifiant l'assaisonnement à chaque étape pour corriger le tir si nécessaire. Si vous mélangez tout dès le départ, vous ne pourrez plus corriger une erreur de cuisson. Découper une tâche de développement suit la même logique : chaque étape doit être suffisamment simple pour qu'une erreur soit immédiatement visible et corrigeable.
Voici un exemple de découpage pour implémenter un système d'authentification :
Tâche globale : Implémenter un système d'authentification complet
Découpage en étapes simples avec livraison progressive :
Étape 1 : Concevoir la structure des données (tables utilisateurs et tokens) — me proposer le schéma pour validation
Étape 2 : Implémenter la fonctionnalité d'inscription (chiffrement des mots de passe avec bcrypt) et écrire les tests associés
Étape 3 : Implémenter la fonctionnalité de connexion (génération de tokens JWT) et écrire les tests associés
Étape 4 : Implémenter le middleware de validation des tokens et écrire les tests associés
Étape 5 : Implémenter la fonctionnalité de déconnexion et écrire les tests associésCe découpage présente deux avantages : chaque étape intègre sa propre validation (les tests associés), appliquant le cadre de la section 02 à chaque sous-tâche ; et l'étape 1 commence par une proposition de schéma — pour une structure de données qui influencera tout le reste du développement, il est essentiel de valider la conception avant d'écrire le code, car modifier un schéma validé est beaucoup moins coûteux que de refactoriser du code déjà écrit.
Si vous ne savez pas comment découper une tâche, Codex propose deux fonctionnalités d'assistance présentées au chapitre 07 :
- La commande
/plan(mode planification) : demande à Codex d'analyser le projet et de proposer un plan d'exécution détaillé avant de commencer à coder. C'est l'approche idéale si vous ne savez pas par où commencer — validez d'abord le plan proposé avant de lancer les modifications. - Une consigne d'attente expliquée : sans changer de mode, vous pouvez ajouter une contrainte simple dans votre discussion : « Indique-moi d'abord les fichiers à modifier et ta démarche, mais ne modifie aucun code pour le moment ».
Voici comment choisir la méthode de traitement selon la complexité de la tâche :
| Type de tâche | Méthode recommandée |
|---|---|
| Corriger une faute d'orthographe, ajouter une ligne de log, renommer une variable | Directement — si le résultat attendu se résume en une ligne, lancez la modification sans étape intermédiaire |
| Ajouter une validation sur une fonction, écrire un cas de test simple | Une demande structurée avec le cadre en quatre points, en une seule étape |
| Modification touchant plusieurs fichiers, sur du code complexe ou peu familier | Lancer d'abord la commande /plan pour valider la démarche avant codage |
| Créer un module complet, effectuer une migration ou une refactorisation d'envergure | Diviser la tâche en 5 à 8 étapes simples intégrant chacune leur validation, et les exécuter l'une après l'autre |
Une règle simple à appliquer : « Suis-je capable de visualiser précisément les modifications du code avant qu'elles ne soient faites ? » Si oui, vous pouvez lancer la tâche directement ; si ce n'est pas le cas, la tâche est trop complexe — divisez-la ou demandez un plan.
💡 En résumé : Ne traisez pas les tâches complexes en une seule fois. Divisez-les en étapes simples, mesurables et faciles à relire. Utilisez
/planpour demander à Codex de concevoir le plan d'action si vous hésitez sur le découpage ; à l'inverse, lancez directement les modifications simples qui ne nécessitent pas de planification.
05 Définir un critère d'arrêt strict : la commande /goal (mode objectif)
Intégrer une étape de validation dans vos prompts est une excellente pratique. Cependant, dans une demande classique, cette validation a une limite : elle ne s'applique qu'au cycle en cours — Codex effectue les modifications, lance la vérification et, si elle échoue, il vous rend le contrôle en attendant vos instructions pour la suite. Si vous souhaitez qu'il travaille de manière autonome en corrigeant le code cycle après cycle jusqu'à ce que la vérification passe, vous devez utiliser le mode objectif (Goal mode).
La différence avec une demande classique est majeure : en mode objectif, le critère de réussite devient le but ultime de la tâche. La documentation officielle l'explique ainsi :
Lorsque vous définissez un objectif, le texte de l'objectif sert à la fois de prompt initial et de critère d'arrêt. Codex l'utilise pour déterminer l'action suivante à mener et pour savoir si la tâche est finalisée.
En clair, la description de l'objectif définit ce qu'il faut faire et quand s'arrêter — Codex analyse le résultat après chaque modification et poursuit le travail de correction de manière autonome jusqu'à ce que le critère de réussite soit validé. Ce mode est particulièrement adapté pour les tâches longues nécessitant plusieurs étapes et disposant d'un critère de validation automatisable.
Pour l'utiliser, tapez /goal dans votre session, suivi de la description de l'objectif. Cet objectif doit être formulé de manière à ce que Codex puisse en évaluer la réussite de façon binaire (Succès / Échec) — la documentation officielle précise qu'un bon objectif doit inclure un livrable précis, une mesure quantifiable ou un critère de test vérifiable. En voici deux exemples issus de la documentation :
/goal Migrer ce projet de JavaScript vers TypeScript, le projet doit compiler correctement en mode strict sans aucun type any explicite dans le code/goal Réduire le temps d'interaction (TTI) de la page d'accueil sous la barre de 1 secondeDans ces exemples, « compiler en mode strict sans type any » ou « TTI inférieur à 1 seconde » sont des critères évaluables de manière objective (Vrai / Faux). Si vous indiquez des critères flous comme « améliorer la qualité du code » ou « rendre l'interface plus agréable », Codex ne disposera d'aucun moyen technique pour valider la réussite, et le mode objectif ne pourra pas fonctionner correctement.
Quelques conseils pratiques pour utiliser la commande /goal :
- La commande
/goalne s'affiche pas dans la liste ? Ce mode nécessite l'activation d'un paramètre. Ajoutez l'optiongoals = truedans la section[features]de votre fichier~/.codex/config.toml, ou exécutez la commandecodex features enable goals(vous pouvez également demander à Codex de l'exécuter pour vous) :
# ~/.codex/config.toml
[features]
goals = true- Vous hésitez sur la formulation de l'objectif ? La documentation conseille : si vous n'arrivez pas à définir précisément l'objectif initial, utilisez d'abord
/planpour structurer la démarche ; vous pouvez également demander à Codex de vous poser des questions pour vous aider à formaliser un objectif avec des critères de réussite clairs. - Vous pouvez réorienter l'objectif en cours de route. L'objectif n'est pas figé après son lancement — vous pouvez ajouter des contraintes ou des précisions en cours d'exécution (« utilise plutôt telle bibliothèque », « évite cette approche »). Si vous souhaitez suivre la progression sans interrompre le traitement, utilisez une discussion secondaire (side chat) pour lui demander un état d'avancement.
- Le traitement est interrompu par une déconnexion ? La documentation conseille : pour les objectifs longs, mettez le traitement en pause avant de vous déconnecter d'un réseau instable, puis relancez ou modifiez-le une fois la connexion rétablie.
Voici un comparatif entre la validation classique et le mode /goal :
| Caractéristique | Validation dans un prompt classique | Mode objectif /goal |
|---|---|---|
| Durée d'action | Limité au cycle en cours, s'arrête en cas d'échec | S'exécute sur l'ensemble de la tâche, ne s'arrête qu'une fois le but atteint |
| Cas d'usage idéal | Tâches simples en une ou deux étapes | Tâches complexes et longues nécessitant des critères d'arrêt automatisés |
| Formulation du critère | « Lancer les tests pour vérifier » | Un critère quantifiable et vérifiable de manière binaire (Vrai / Faux) |
| Configuration requise | Aucune | Nécessite features.goals = true dans la configuration |
💡 En résumé : Pour laisser Codex travailler en autonomie et corriger son code jusqu'à la validation complète de la tâche, utilisez le mode objectif avec
/goal. L'objectif doit être associé à un critère de réussite évaluable de manière binaire. Si besoin, utilisez/planau préalable pour structurer l'objectif, et assurez-vous que l'optionfeatures.goalsest bien activée.
06 Pratique : comparer l'impact de deux formulations pour un même besoin
Pour observer concrètement la différence d'efficacité, réalisons un exercice pratique. Nous allons créer un fichier minimal de trois lignes, sans impacter vos projets existants.
Différences de plateforme : la commande
mkdirci-dessous fonctionne sous Mac / Linux. Sous Windows, utilisez PowerShell pour créer le dossier et adapter les commandes, ou utilisez l'Explorateur de fichiers. Le fichierstats.pydoit contenir les deux lignes indiquées ci-dessous. Assurez-vous d'avoir installé Codex (voir chapitre 03).
Étape 1 : Créer un fichier de démonstration contenant une anomalie
mkdir prompt-demo
cd prompt-demo
echo 'def average(nums):
return sum(nums) / len(nums)' > stats.pyL'anomalie de ce code : si la fonction reçoit une liste vide [], la valeur de len(nums) sera 0, provoquant une division par zéro et le plantage du script. C'est ce problème que nous allons corriger.
Étape 2 : Lancer Codex dans le dossier du projet
codexRésultat attendu : l'interface interactive de Codex s'ouvre avec le champ de saisie en bas de l'écran. (Si l'application ne se lance pas, reportez-vous au chapitre 03 Installation.)
⚠️ Vous devez impérativement exécuter la commande
codexdepuis le répertoireprompt-demoafin que Codex l'identifie comme son espace de travail actif.
Étape 3 : Soumettre une demande imprécise (mauvais prompt)
@stats.py Modifie cette fonctionRésultat attendu : Codex va tenter de deviner votre besoin. Il choisira peut-être d'ajouter des annotations de type ou de documenter la fonction, mais il y a peu de chances qu'il identifie spontanément le bug de la division par zéro, le résultat dépendra de son analyse globale. C'est la conséquence d'une demande manquant d'objectif et de validation : vous le laissez décider à votre place.
Étape 4 : Soumettre une demande structurée (bon prompt)
La fonction average dans @stats.py présente une anomalie : si on lui passe une liste vide, elle plante en raison d'une division par zéro.
Le comportement attendu est de renvoyer 0 si la liste est vide (objectif).
Modifie uniquement cette fonction sans toucher au reste du fichier (portée), et utilise du code Python standard sans ajouter de bibliothèque (contraintes).
Corrige l'anomalie et écris deux tests pour valider le comportement : average([]) doit renvoyer 0, et average([2, 4]) doit renvoyer 3. Exécute les tests pour confirmer le résultat (validation).Résultat attendu : cette fois, la démarche de Codex est précise : il cible l'anomalie de la division par zéro, ajoute la condition de contournement (renvoyer 0 si la liste est vide), rédige les deux cas de test demandés, les exécute et affiche la validation. Toutes les étapes ont été réalisées sans aucune supposition, car vous avez défini l'Objectif, la Portée, les Contraintes et la Validation.
Étape 5 : Quitter et vérifier la modification du fichier
Quittez Codex (utilisez le raccourci ou la commande indiquée dans votre interface), puis affichez le contenu du fichier dans votre terminal :
cat stats.py（Sous Windows PowerShell, utilisez type stats.py）
Résultat attendu : le fichier stats.py intègre désormais la vérification de la liste vide (par exemple if not nums: return 0). Le code correspond exactement à votre demande de l'étape 4, confirmant que vous maîtrisez la formulation des prompts.
Comparons les deux approches :
| Élément | Étape 3 (Mauvais prompt) | Étape 4 (Bon prompt) |
|---|---|---|
| Objectif | Non défini, laissé à l'appréciation du modèle | Renvoyer 0 en cas de liste vide |
| Portée | Non définie, recherche globale | Ciblée sur la fonction average |
| Contraintes | Non définies | Utiliser Python standard sans bibliothèque |
| Validation | Non définie, arrêt arbitraire | Deux cas de test précis avec exécution |
| Résultat | Modification incertaine ou hors sujet | Correction exacte et validée du premier coup |
💡 En résumé : Sur un même fichier et pour un même bug, un prompt imprécis oblige Codex à faire des choix à votre place, tandis qu'un prompt structuré autour des quatre points « Objectif / Portée / Contraintes / Validation » garantit un résultat exact. Exécuter cet exercice pratique montre concrètement cette différence d'efficacité.
07 Synthèse visuelle : du prompt au code
Le schéma suivant résume le parcours d'une demande, de sa formulation jusqu'à l'intégration du code par Codex :
Ce schéma met en évidence deux étapes clés : le choix de la planification (les tâches complexes doivent faire l'objet d'un plan ou de la commande /plan au préalable) et la présence d'une validation automatisée (qui permet de fermer la boucle d'agent et de laisser Codex corriger le code de manière autonome). Maîtriser ces deux étapes garantit une collaboration efficace avec Codex.
💡 En résumé : Une formulation efficace suit le parcours « découpage ou
/planpour les tâches complexes → structure en quatre points → validation automatisée pour fermer la boucle → relecture finale du diff ». Les blocages proviennent généralement du non-respect de ces étapes.
08 Récapitulatif
Cet article a présenté les principes fondamentaux pour formuler vos demandes de manière à ce que Codex puisse les traiter efficacement sans supposer vos besoins.
Voici les outils clés à retenir :
| Méthode | Principe | Application pratique |
|---|---|---|
| Le cadre en quatre points | Structurer la demande autour de l'Objectif, la Portée, les Contraintes et la Validation pour éviter les suppositions de l'IA | « Modifier average (portée), renvoyer 0 si vide (objectif), sans bibliothèque (contraintes), valider avec deux tests (validation) » |
| Transmission directe | Fournir les données brutes plutôt que de les décrire verbalement | Indiquer le chemin exact du fichier, sélectionner le code dans l'IDE, coller l'intégralité d'un message d'erreur ou joindre une capture d'écran |
| Découpage des tâches | Diviser les tâches complexes en étapes simples intégrant chacune leur propre validation | Utiliser la commande /plan pour concevoir le plan d'action, et valider chaque étape l'une après l'autre |
Mode objectif /goal | Fixer un critère de réussite strict et laisser Codex corriger le code en autonomie jusqu'à validation | Définir un objectif évaluable de manière binaire (Vrai / Faux) et activer l'option features.goals |
Vous êtes désormais capable de : transformer une consigne floue en une demande structurée pour Codex, en appliquant les quatre points (Objectif, Portée, Contraintes, Validation), en fournissant directement les sources de contexte, en découpant vos tâches complexes ou en utilisant la commande /goal pour automatiser la validation. Ces principes de communication constituent le socle de votre utilisation de Codex — quelle que soit l'interface utilisée, la qualité du résultat dépendra toujours de la clarté de vos prompts.
Une question en guise de réflexion : s'il est indispensable de clarifier ses consignes, devez-vous pour autant répéter les mêmes règles de projet (comme « n'ajoute pas de bibliothèque » ou « place les tests dans le dossier tests/ ») à chaque message ? N'y a-t-il pas un moyen pour que Codex s'en souvienne de lui-même ? (Le chapitre 11 · AGENTS.md contient des éléments de réponse.)
Le chapitre suivant, 14 · Flux de travail courants, applique ces principes à des cas d'usage concrets et fréquents : analyser un projet inconnu, corriger un bug, refactoriser du code ou rédiger des tests. Nous détaillerons la démarche à suivre pour chacune de ces situations.