Comment bien utiliser /goal dans Codex sans perdre le contrôle
Résumé synthétique
Un guide pratique pour comprendre à quoi sert la commande /goal dans Codex, quand l’utiliser, comment l’écrire correctement, et pourquoi elle peut améliorer un workflow tout en augmentant les coûts en tokens.
Comment bien utiliser /goal dans Codex
Quand beaucoup de gens découvrent , ils l’utilisent comme un chatbot classique : une tâche, un , une réponse.
Et au début, ça fonctionne très bien.
Tu demandes une correction, une nouvelle page, un composant, une petite amélioration, et exécute. Le problème arrive quand le projet grandit.
Petit à petit, les limites apparaissent :
l’IA oublie certaines décisions prises plus tôt ;
le design devient moins cohérent ;
l’architecture commence à dériver ;
tu dois répéter les mêmes consignes ;
comprend la tâche, mais pas toujours la direction globale du projet.
C’est exactement ce que /goal essaie de résoudre.
Plutôt que de donner uniquement une consigne locale, /goal permet de définir une direction globale que garde en tête pendant le workflow.
À lire ensuite
Bien utilisé, ça peut vraiment améliorer la cohérence d’un projet. Mais mal utilisé, ça peut aussi coûter plus cher, ralentir certaines tâches, ou pousser à faire trop de choses.
Ce qu’il faut comprendre avant d’utiliser /goal
La première erreur, c’est de voir /goal comme un simple plus long.
Ce n’est pas vraiment ça.
Un classique dit plutôt :
Fais cette tâche.
Un /goal dit plutôt :
Voilà le type de produit qu’on essaie de construire.
La différence est importante.
Le but n’est pas seulement de générer du code. Le but est d’orienter les décisions du modèle sur plusieurs dimensions :
l’architecture ;
l’expérience utilisateur ;
le style ;
les priorités ;
les contraintes ;
le comportement général du projet.
En pratique, /goal agit presque comme un brief produit permanent.
C’est ce qui le rend très utile sur un vrai projet. Mais c’est aussi ce qui le rend dangereux si la direction donnée est floue, trop large ou contradictoire.
Si ton goal est mauvais, risque de prendre de mauvaises décisions de manière cohérente. Et parfois, c’est pire qu’une simple erreur locale.
Comment écrire un bon /goal
Un bon /goal doit donner une direction claire.
Pas besoin d’écrire trois pages. Il faut surtout aider à comprendre ce que tu construis vraiment.
Un bon goal doit contenir :
une vision produit claire ;
des priorités concrètes ;
des contraintes utiles ;
une idée du type d’expérience attendue.
Exemple de mauvais /goal
/goal Build a website
Ici, ne comprend presque rien.
Quel type de site ? Pour qui ? Avec quel style ? Quelles priorités ? Quelles contraintes techniques ?
Le modèle est obligé d’improviser.
Et quand l’IA improvise trop, le projet peut vite partir dans une direction que tu n’avais pas prévue.
Exemple de /goal moyen
/goal Build a recipe sharing platform
C’est déjà mieux.
On comprend la catégorie du produit : une plateforme de partage de recettes. Mais ça reste trop large.
Est-ce que le produit doit être social ? Mobile-first ? Très visuel ? Pensé pour cuisiner rapidement ? Pour des créateurs ? Pour des familles ? Pour des étudiants ?
a un début de contexte, mais pas encore de vraie direction.
Exemple de bon /goal
/goal Build a recipe platform where users can save recipes in under 10 seconds, quickly switch between mobile cooking mode and desktop browsing, and always keep ingredient lists readable while cooking.
Là, tout change.
Le modèle comprend beaucoup mieux les priorités :
la sauvegarde doit être rapide ;
l’usage mobile est important ;
l’expérience en cuisine compte vraiment ;
la lisibilité des ingrédients est prioritaire ;
le produit doit rester pratique dans un contexte réel.
Même sans cahier des charges complet, peut déjà prendre de meilleures décisions.
Il comprend qu’un ingrédient ne doit pas être caché derrière trois menus, que les temps de chargement comptent, et qu’un mode cuisine doit probablement éviter les distractions inutiles.
C’est là que /goal devient intéressant : il ne décrit pas seulement ce qu’il faut construire, il explique pourquoi on le construit comme ça.
Trois exemples concrets de bons /goal
Un bon /goal n’a pas besoin d’être long. Il doit surtout être précis sur l’usage réel.
Pour une application d’étude
/goal Build a study app designed for students who revise in short sessions between classes, with instant note access, distraction-free reading and extremely fast loading times.
Ici, Codex comprend que les sessions sont courtes, que l’accès aux notes doit être instantané, et que la rapidité est plus importante que les effets visuels.
Pour un portfolio de photographe
/goal Build a portfolio website for photographers where images should always feel immersive, fullscreen and smooth even on slower connections.
Ce goal donne une direction claire : l’expérience visuelle est centrale, mais elle ne doit pas casser la performance.
Codex peut donc mieux arbitrer entre qualité des images, compression, lazy loading, transitions et fluidité.
Pour une plateforme de recettes
/goal Build a recipe platform where users can save recipes in under 10 seconds, quickly switch between mobile cooking mode and desktop browsing, and always keep ingredient lists readable while cooking.
Cet exemple fonctionne parce qu’il part d’un usage concret.
On ne dit pas simplement “faire une app moderne de recettes”. On explique ce qui compte vraiment pour l’utilisateur.
Et c’est souvent ça, la clé d’un bon /goal : moins de mots vagues, plus de contexte d’usage.
Quand utiliser /goal
/goal devient surtout utile quand ton projet commence à avoir une vraie structure.
Par exemple :
plusieurs pages ;
une architecture claire ;
une identité visuelle ;
des décisions à garder cohérentes ;
beaucoup d’itérations ;
des importants ;
une logique produit qui doit rester stable.
C’est particulièrement efficace pour :
des ;
des dashboards ;
des applications mobiles ;
des plateformes de contenu ;
des projets long terme ;
des produits avec une vraie logique .
Dans ces cas-là, /goal aide Codex à ne pas traiter chaque demande comme une tâche isolée.
Il comprend que chaque modification doit s’intégrer dans une vision plus large.
Quand ne pas utiliser /goal
À l’inverse, /goal n’est pas forcément utile partout.
Pour une micro-tâche, il peut être excessif.
Par exemple :
corriger un bug isolé ;
modifier une couleur ;
renommer une variable ;
écrire un petit script ;
ajuster un bouton ;
corriger une erreur simple.
Dans ces cas-là, un classique suffit largement.
Utiliser /goal pour une tâche très locale peut même être contre-productif. Codex risque d’aller lire plus de fichiers, de réfléchir plus largement, ou de proposer des changements plus ambitieux que nécessaire.
Parfois, tu veux juste corriger une ligne. Pas repenser le produit.
Les erreurs les plus fréquentes
Changer le /goal trop souvent
Si le goal change toutes les vingt minutes, Codex perd sa cohérence globale.
Le but de /goal, justement, est de donner une direction stable.
Il vaut mieux garder le même goal pendant une vraie phase de travail, puis le modifier seulement quand la direction produit évolue réellement.
Tu peux le changer si tu fais une refonte , si tu changes de cible utilisateur, si tu modifies la philosophie du produit ou si tu passes d’un prototype à une version plus sérieuse.
Mais si tu changes le goal à chaque petite tâche, il perd une grande partie de son intérêt.
Écrire un goal trop vague
Un goal comme celui-ci n’aide presque pas :
/goal Build a modern app
Le mot “modern” peut vouloir dire beaucoup de choses : minimaliste, très visuel, enterprise, mobile-first, sobre, premium, expérimental.
Codex ne peut pas deviner exactement ce que tu as en tête.
Au lieu de dire “moderne”, explique ce que tu veux vraiment obtenir : une interface rapide, une navigation simple, une expérience lisible, un design sobre, une app pensée pour mobile, ou un produit qui charge vite même avec beaucoup de données.
Mettre trop d’informations
L’erreur inverse existe aussi.
Certains goals deviennent des blocs énormes, avec trop de détails et trop de contraintes.
Le problème, c’est que plus le goal devient dense, plus Codex peut perdre les vraies priorités, mélanger les contraintes ou surinterpréter un détail secondaire.
Un bon /goal doit rester lisible rapidement.
Le bon équilibre, c’est souvent une phrase bien construite ou un court paragraphe.
Laisser Codex partir trop loin
Avec /goal, Codex peut parfois devenir très ambitieux.
Il peut proposer un gros , une architecture plus complexe, de nouvelles abstractions ou des fichiers supplémentaires.
Parfois, c’est utile. Mais parfois, tu voulais juste modifier un composant.
Le goal donne une direction globale, mais tes prompts locaux doivent rester précis.
Par exemple :
Only update this component. Do not change the global architecture.
Ou :
Make the smallest possible change to fix this issue.
Le goal ne remplace pas le pilotage. Il l’améliore.
Le coût caché : les tokens
C’est probablement l’un des aspects les moins discutés de /goal.
Quand tu utilises /goal, Codex travaille avec une vision plus globale du projet. Cette vision peut l’amener à consommer plus de tokens.
Pourquoi ?
Parce qu’il peut avoir tendance à :
lire plus de fichiers ;
conserver plus de contexte ;
raisonner plus longtemps ;
explorer davantage l’architecture ;
proposer des changements plus larges.
Sur un projet complexe, ce coût peut être justifié. /goal peut te faire gagner du temps, réduire les incohérences et limiter le micro-management.
Mais pour des micro-tâches, c’est souvent inutile.
La bonne question à se poser est simple :
Est-ce que cette tâche a besoin d’une vision produit globale, ou seulement d’une instruction locale ?
Si la réponse est “instruction locale”, /goal n’est probablement pas nécessaire.
Le workflow recommandé
Le meilleur usage de /goal consiste à séparer deux choses :
la direction globale du projet ;
les tâches locales à exécuter.
1. Définir un goal stable
Commence par écrire un goal qui résume la vraie direction du projet.
Il doit inclure la vision produit, les priorités , les contraintes importantes et le type d’expérience que tu veux créer.
Pas besoin d’être parfait. Il doit surtout éviter à Codex d’improviser la direction générale.
2. Garder ce goal pendant une vraie phase de travail
Une fois le goal défini, évite de le modifier constamment.
Garde-le pendant une phase cohérente : construction d’une feature, refonte d’une page, amélioration d’un dashboard, stabilisation de l’ ou nettoyage d’une architecture.
Le goal sert de boussole. Si tu changes la boussole tout le temps, elle ne sert plus à grand-chose.
3. Utiliser des prompts classiques pour les tâches locales
Ensuite, utilise des prompts classiques pour guider Codex sur les tâches précises.
Par exemple :
Update the article card component to make the title more readable on light cover images. Keep the current layout and avoid changing unrelated files.
Ou :
Fix the loading state on the dashboard. Make the smallest possible change and do not refactor the data fetching logic.
Le /goal donne le contexte global. Le local donne l’action exacte.
Les deux sont complémentaires.
4. Modifier le goal seulement quand la direction change
Tu peux modifier ton goal, bien sûr.
Mais fais-le quand la direction du projet change réellement : passage en production, changement de cible, refonte , changement de philosophie produit ou restructuration de l’architecture.
Si tu changes juste un bouton, une page ou un composant, le goal n’a probablement pas besoin d’être modifié.
La bonne manière de penser /goal
Le plus simple, c’est de ne pas voir /goal comme une commande magique.
Ce n’est pas un bouton qui rend Codex automatiquement meilleur.
C’est plutôt un outil de cadrage.
Il permet de dire au modèle :
Voici la direction. Maintenant, prends tes décisions dans ce cadre.
C’est très puissant quand tu veux construire un produit cohérent. Mais ça demande aussi de la discipline.
Un bon /goal doit être :
clair ;
stable ;
orienté usage ;
assez précis pour guider ;
assez court pour rester lisible.
Et surtout, il doit aider Codex à comprendre les arbitrages.
Parce que dans un vrai projet, le problème n’est pas seulement de produire du code. Le problème, c’est de produire du code qui va dans la bonne direction.
Conclusion
/goal devient vraiment puissant quand on arrête de le voir comme une simple commande.
Son intérêt principal n’est pas de générer plus de code. Son vrai intérêt, c’est d’aider Codex à comprendre le produit que tu essaies réellement de construire.
Bien utilisé, /goal peut réduire le micro-management, les incohérences, les répétitions, les dérives architecturales et les décisions contradictoires.
Mais mal utilisé, il peut aussi augmenter les coûts, complexifier inutilement le projet, pousser Codex à sur-ingénierer certaines parties et rendre une petite tâche plus lourde qu’elle ne devrait l’être.
Au final, /goal fonctionne surtout comme une direction produit permanente.
Et c’est probablement là que les workflows IA deviennent les plus intéressants : quand on ne demande plus seulement à l’IA d’exécuter des tâches, mais de construire dans une direction claire.
Depuis mai 2026, /goal est aussi disponible dans Code : Anthropic le présente comme une commande permettant à de continuer à travailler sur un objectif jusqu’à ce que la condition définie soit atteinte.
