Un prompt Codex utile décrit un changement que vous pourrez constater. « Améliore mon application » laisse le résultat ouvert. « La recherche doit retrouver une note même si la casse diffère » donne déjà un comportement précis à produire.
Ce guide explique comment construire et affiner une demande sur un projet logiciel. Pour sélectionner directement un modèle, utilisez la bibliothèque de prompts. Si Codex ne voit pas les bons fichiers, commencez par vérifier le dossier du projet : une formulation plus longue ne répare pas un contexte absent.
Commencer par le comportement attendu
Décrivez ce que l’utilisateur doit pouvoir faire, dans quelle situation et avec quel résultat. Pour une erreur, distinguez ce que vous observez de ce que vous attendez. Pour une nouvelle fonction, indiquez un exemple d’entrée et la sortie souhaitée.
La documentation officielle sur les consignes recommande de fournir les éléments utiles : objectif, contexte, sortie et limites. Elle ne prescrit pas de formule rigide. Pour Codex, le comportement attendu, les fichiers concernés et la façon de vérifier le changement sont particulièrement utiles.
Donner le contexte qui change vraiment la réponse
Une bonne information permet de prendre une décision. « Le site doit rester simple » est interprétable ; « conserve le formulaire et ses champs actuels, change seulement la règle de recherche » précise ce qui doit rester stable.
| Indication vague | Précision utile |
|---|---|
| Ça ne marche pas | Après la saisie de « facture », la note « Facture mars » n’apparaît pas |
| Fais quelque chose de propre | Réutilise les composants et styles du projet ; ne refais pas l’écran |
| Teste tout | Vérifie les quatre cas d’acceptation ci-dessous et indique les contrôles non exécutés |
| Tu as tous les fichiers | Lis le fichier qui implémente la recherche ; si tu ne l’identifies pas, signale-le avant de modifier |
Ne devinez pas un nom de fonction pour rendre la demande plus technique. Vous pouvez décrire l’écran et laisser Codex retrouver le code, en lui demandant de citer le fichier identifié.
Exemple avant/après : rechercher une note
Exemple fictif. Une application affiche les notes « Facture mars », « Devis avril » et « Budget ». Nous définissons ici le comportement souhaité ; nous ne présentons pas ces lignes comme un test exécuté sur votre application.
La demande initiale « Améliore la recherche de notes » ne dit pas s’il faut ajouter des filtres, corriger la casse, chercher dans le contenu ou modifier l’interface. Choisissons un seul résultat : chercher dans le titre sans distinguer majuscules et minuscules.
| Saisie | Notes attendues | Règle vérifiée |
|---|---|---|
| facture | Facture mars | Correspondance partielle |
| FACTURE | Facture mars | Insensibilité à la casse |
| Champ vide | Les trois notes, dans leur ordre actuel | Aucune recherche active |
| absent | Aucune note | Aucune correspondance |
Dans le projet ouvert, retrouve le code de recherche des notes et indique le fichier concerné. Modifie uniquement la recherche dans les titres pour qu’elle ne distingue plus majuscules et minuscules. Exemples de notes : « Facture mars », « Devis avril », « Budget ». Les saisies « facture » et « FACTURE » doivent toutes deux retrouver seulement « Facture mars ». Un champ vide doit afficher toutes les notes dans leur ordre actuel ; « absent » ne doit en afficher aucune. Conserve l’interface, les données et le tri existants. N’ajoute ni dépendance ni recherche dans le contenu des notes. Si une règle existante contredit ces critères, explique le conflit avant de modifier. Utilise les vérifications pertinentes déjà disponibles. Termine par les fichiers modifiés, les contrôles réellement exécutés et ceux qui restent à faire. Ne publie rien.
La consigne précise les cas importants sans imposer chaque ligne de code. Elle laisse aussi une limite visible : le traitement des accents, par exemple, n’est pas défini par l’insensibilité à la casse. Si vous en avez besoin, ajoutez un exemple spécifique ; ne supposez pas qu’il est inclus.
Quand demander une analyse avant la modification ?
Si vous ne connaissez pas l’organisation du projet ou si le changement touche plusieurs fonctions, commencez par une demande de lecture. Vous pourrez valider le périmètre avant de demander l’exécution :
Ne modifie aucun fichier pour le moment. Retrouve comment la recherche de notes fonctionne, cite les fichiers concernés et indique quelles règles de filtrage sont déjà présentes. Propose le plus petit changement permettant de rendre la recherche insensible à la casse. Signale les décisions qui manquent dans ma demande.
Cette étape est utile si elle résout une incertitude concrète. Elle n’est pas obligatoire pour chaque petite modification. Un plan reste une proposition : vérifiez qu’il couvre vos critères avant d’autoriser la suite.
Corriger le résultat avec un retour précis
Supposons que le résultat retrouve correctement « FACTURE », mais trie maintenant les notes par ordre alphabétique. « Ce n’est pas bon » ne localise pas l’écart. Un retour utile rappelle le comportement à rétablir :
La recherche avec « FACTURE » correspond au besoin, mais l’ordre des notes a changé. Conserve la recherche insensible à la casse et rétablis l’ordre précédent, y compris lorsque le champ est vide. Ne change aucun autre comportement. Vérifie à nouveau les quatre cas d’acceptation et précise ce que tu as effectivement exécuté.
Ce retour décrit une situation pédagogique possible, pas une erreur mesurée pendant un essai. Dans votre projet, citez le résultat observé, l’entrée utilisée et ce qui doit être différent. Ajoutez une capture seulement si elle aide à comprendre l’écart.
Lire le bilan sans confondre réponse et preuve
- Fichiers modifiés : correspondent-ils à la recherche demandée ? Une refonte générale réclame une explication.
- Contrôles exécutés : le bilan indique-t-il ce qui a été lancé et son résultat, plutôt qu’une liste de tests conseillés ?
- Vérification manuelle : pouvez-vous reproduire les quatre saisies dans l’application ?
- Limites : un contrôle non réalisé ou un accès manquant est-il explicitement signalé ?
Une consigne précise améliore la possibilité de contrôler le travail ; elle ne garantit pas un code correct. Si vous débutez, entraînez-vous d’abord sur la première tâche Codex du site, dont le résultat est plus facile à comparer.
Adapter la méthode à votre prochaine demande
Avant d’envoyer votre message, complétez cette phrase : « Dans cette situation, je veux observer ce résultat, sans changer ces éléments. » Ajoutez les fichiers utiles et deux ou trois cas qui permettraient de déceler un écart. Supprimez les détails qui n’influencent ni l’implémentation ni le contrôle.
Vous pouvez ensuite partir du modèle de nouvelle fonction dans le générateur ou choisir un autre cas dans la bibliothèque. Ces outils préparent la consigne ; ils ne valident pas son exécution.
Source et périmètre
Documentation officielle consultée le 28 septembre 2026 : Prompting pour ChatGPT et Codex. Les demandes, le tableau de critères et le retour correctif sont nos exemples originaux. Ce guide porte sur une consigne ponctuelle ; les règles persistantes du projet et la conception détaillée des tests constituent des sujets séparés.
Passer à l’action
Choisissez une tâche réelle et notez son comportement attendu, les éléments à conserver et trois cas de vérification avant de rédiger la demande.