Comment bien utiliser /goal dans Codex sans perdre le contrôle
AI resume
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 prompt, 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 encore et encore ;
comprend la tâche, mais pas toujours la direction globale du projet.
C’est exactement le problème 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.
Bien utilisé, ça peut vraiment changer la manière de travailler avec l’IA.
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 prompt plus long.
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 justement pour ça qu’il peut être très utile sur un vrai projet. Mais c’est aussi pour ça qu’un mauvais /goal peut détériorer tout un workflow.
Si la direction donnée est floue, trop large ou contradictoire, risque de prendre de mauvaises décisions de manière cohérente. Et c’est parfois pire qu’une simple erreur locale.
Comment écrire un bon /goal
Un bon /goal doit donner une direction claire.
Pas forcément un cahier des charges complet. Pas besoin d’écrire trois pages. Mais il faut donner au modèle de quoi 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.
Le problème des goals trop vagues, c’est qu’ils n’aident pas réellement le modèle à prendre des décisions.
Exemple de mauvais /goal
/goal Build a website
Ici, ne comprend presque rien du produit.
Quel type de site ? Pour qui ? Avec quel style ? Quelles priorités ? Quelle expérience utilisateur ? 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 encore trop large.
Des centaines de plateformes différentes peuvent correspondre à cette description.
Est-ce que le produit doit être social ? Mobile-first ? Très visuel ? Orienté meal prep ? Pensé pour cuisiner rapidement ? Fait pour des créateurs de contenu ? 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 du produit :
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 spécifications détaillées, peut déjà commencer à prendre de meilleures décisions.
Il peut comprendre qu’un ingrédient ne doit pas être caché derrière trois menus, que les temps de chargement comptent, ou 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 aide le modèle à comprendre pourquoi on le construit de cette manière.
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, comprend immédiatement que :
les sessions sont courtes ;
l’accès aux notes doit être instantané ;
l’interface doit éviter les distractions ;
la rapidité est plus importante que les effets visuels.
Ce goal peut influencer toute l’interface : navigation, hiérarchie des contenus, animations, chargement, organisation des notes.
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 très claire.
Codex comprend que l’expérience visuelle est centrale, mais qu’elle ne doit pas se faire au détriment de la performance.
Il peut donc mieux arbitrer entre :
qualité des images ;
compression ;
lazy loading ;
transitions ;
mise en page ;
fluidité perçue.
Le goal ne dit pas exactement quels composants coder. Il donne une philosophie produit.
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 est intéressant 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 gros ;
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 peut mieux comprendre 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 prompt 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
1. 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.
Par exemple, tu peux changer ton goal si :
tu fais une refonte ;
tu changes de cible utilisateur ;
tu modifies la philosophie du produit ;
tu restructures toute l’architecture ;
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.
2. É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 ;
façon startup ;
façon enterprise ;
mobile-first ;
glassmorphism ;
sobre ;
premium ;
expérimental.
Codex ne peut pas deviner exactement ce que tu as en tête.
Un bon goal doit donc éviter les mots trop flous lorsqu’ils ne sont pas accompagnés d’un contexte concret.
Au lieu de dire “moderne”, explique ce que tu veux vraiment obtenir.
Par exemple :
une interface rapide ;
une navigation simple ;
une expérience très lisible ;
un design sobre ;
une app pensée pour mobile ;
un produit qui charge vite même avec beaucoup de données.
3. Mettre trop d’informations
L’erreur inverse existe aussi.
Certains goals deviennent des blocs énormes, avec trop de détails, trop de contraintes, trop d’intentions différentes.
Le problème, c’est que plus le goal devient dense, plus Codex peut :
perdre les vraies priorités ;
mélanger les contraintes ;
surinterpréter certaines phrases ;
donner trop d’importance à un détail secondaire.
Un bon /goal doit rester lisible rapidement.
Il doit être assez précis pour orienter le modèle, mais pas tellement chargé qu’il ressemble à un cahier des charges complet.
Le bon équilibre, c’est souvent une phrase bien construite ou un court paragraphe.
4. 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 ;
des fichiers supplémentaires ;
des optimisations qui n’étaient pas demandées.
Parfois, c’est utile.
Mais parfois, tu voulais juste modifier un composant.
C’est pour ça qu’il faut garder le contrôle. Le goal donne une direction globale, mais tes prompts locaux doivent rester précis.
Tu peux très bien utiliser /goal pour le contexte général, puis dire ensuite :
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. Et 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 ;
effectuer plusieurs itérations sur une même tâche.
Résultat : la consommation de tokens peut augmenter rapidement.
Un petit prompt classique peut parfois coûter très peu. Mais une longue session avec /goal, beaucoup de contexte, plusieurs fichiers et des importants peut devenir beaucoup plus coûteuse.
Ce n’est pas forcément un problème si le gain de productivité est réel.
Sur un projet complexe, /goal peut te faire gagner du temps, réduire les incohérences et limiter le micro-management. Dans ce cas, le coût supplémentaire peut être justifié.
Mais pour des micro-tâches, c’est souvent inutile.
Tu risques de payer plus cher pour une tâche qui aurait pu être résolue avec un prompt simple et direct.
La bonne question à se poser est donc :
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.
Voici un workflow simple.
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 ;
le type d’expérience que tu veux créer.
Pas besoin d’être parfait. Mais il doit être assez clair pour é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’ ;
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 prompt 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.
Par exemple :
tu passes d’un prototype à une version production ;
tu changes de cible utilisateur ;
tu refonds complètement l’ ;
tu changes la philosophie du produit ;
tu restructures l’architecture.
Dans ces cas-là, mettre à jour le goal a du sens.
Mais 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 ;
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 ;
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.