La plupart des équipes utilisent encore l’IA comme un assistant de rédaction : on demande, on reçoit une réponse, puis on relance avec un nouveau prompt.
Le problème : dès que la tâche devient un peu complexe (tests qui échouent, performance à optimiser, bug intermittent), cette approche se transforme en ping-pong. C’est là que la fonctionnalité Goals de Codex change la donne : elle permet de définir un objectif persistant sur plusieurs itérations, jusqu’à preuve de réussite.
Pourquoi ce sujet est important
Pour une organisation, la valeur d’un agent IA ne se mesure pas à sa capacité à produire du code “plausible”, mais à sa capacité à :
- atteindre un résultat vérifiable (tests OK, benchmark atteint, artefact livré) ;
- itérer sans supervision constante ;
- s’arrêter proprement quand il est bloqué, au lieu de tourner en rond.
Les Goals structurent exactement cela : une boucle de travail autonome avec une ligne d’arrivée claire.
Prompts classiques vs Goals : la différence qui compte
Le prompt classique : une instruction immédiate
Un prompt standard demande à Codex d’exécuter une action puis d’attendre la suite. Même si le modèle “pense” avoir fini, il n’a pas d’obligation formelle de vérifier, ni de continuer.
Le Goal : un contrat d’achèvement
Un Goal agit comme un contrat : Codex doit avancer, vérifier par lui-même si l’objectif est atteint (avec des preuves), et continuer jusqu’à limite atteinte (budget, itérations, temps), ou blocage justifié avec condition d’arrêt.
En pratique, vous passez d’une séquence de prompts isolés à une démarche : Plan → Exécute → Vérifie → Corrige → Valide.
Les 6 éléments d’un Goal solide
Un Goal efficace n’est pas “écris un code meilleur”. Il doit réduire l’ambiguïté et verrouiller la fin du travail.
Voici les six éléments clés à définir :
1) Le résultat attendu (output)
Décrivez le livrable final, de façon observable.
- “Tous les tests unitaires passent”
- “Le temps moyen de réponse descend sous 200 ms”
- “Le script produit un fichier CSV conforme”
2) La surface de vérification (preuves)
Indiquez où Codex doit regarder pour confirmer la réussite.
- sortie de tests (pytest, npm test)
- benchmark de performance
- logs de build/CI
- artefacts générés (fichiers, rapports)
3) Les contraintes (ce qu’on ne doit pas casser)
Exemples :
- ne pas modifier l’API publique
- garder la compatibilité avec une version cible
- ne pas augmenter la complexité cyclomatique
4) Le périmètre de travail
Définissez la zone de travail :
- fichiers autorisés
- outils autorisés
- interdictions (ex. “ne pas ajouter de dépendance”)
5) La politique d’itération
Expliquez comment itérer :
- “fais de petites modifications, puis relance les tests”
- “une hypothèse à la fois”
- “documente chaque changement dans un log”
6) La condition d’arrêt (blocage)
C’est essentiel : si Codex est coincé, vous voulez un arrêt clair plutôt qu’une boucle.
- “Arrête-toi si 3 itérations consécutives échouent au même endroit”
- “Arrête-toi si tu dois modifier plus de 5 fichiers”
- “Arrête-toi si tu as besoin d’un accès ou d’une info manquante”
Cycle de vie : des Goals “thread-scoped”, pas une mémoire globale
Un point important : les Goals sont attachés à un fil de discussion (thread-scoped), pas à une mémoire globale.
Conséquences positives :
- tout le contexte utile (décisions, essais, erreurs) reste dans le thread ;
- vous évitez que l’agent mémorise des comportements indésirables d’une session à l’autre — chaque Goal vit dans son propre fil.
Selon la logique décrite, l’utilisateur peut gérer l’objectif avec des commandes du type :
/goal: définir l’objectif/goal pause: mettre en pause/goal resume: reprendre/goal clear: nettoyer / retirer l’objectif
Et surtout : l’IA reprend le travail de manière autonome quand le fil est inactif, en respectant le budget alloué (itérations/ressources).
La règle d’or : validation par les preuves (pas “au feeling”)
Un Goal ne se termine pas parce que “Codex estime que c’est bon”.
Il se termine uniquement quand des preuves concrètes confirment le succès :
- tests unitaires réussis
- commande de build OK
- sortie de terminal attendue
- artefacts générés et validés
C’est ce qui rend les Goals adaptés à des environnements sérieux : vous pouvez les brancher à vos pratiques de qualité (tests, CI, benchmarks) au lieu de faire confiance à une déclaration.
Cas d’usage idéaux : ligne d’arrivée claire, chemin incertain
Les Goals excellent quand le sujet permet des itérations (essais, hypothèses).
Exemples très concrets :
- optimisation de performance avec un benchmark comme juge
- résolution de tests instables (flaky tests)
- chasse à des bugs complexes et intermittents
- refactoring guidé par une suite de tests stricte
- recherche approfondie et reproductible (ex. reproduction d’analyses quantitatives)
Quand ne pas utiliser les Goals
Les Goals ne sont pas un marteau pour tout clou. Évitez-les quand :
- la modification est triviale (“change une ligne”)
- la question est simple (“explique ce message d’erreur”)
- l’objectif est vague (“améliore ce code”)
Pourquoi ? Parce que sans condition de fin fiable, l’agent ne sait pas quand s’arrêter — et vous perdez le bénéfice principal : l’autonomie contrôlée.
Comment les équipes devraient les utiliser (recommandations terrain)
1) Écrivez vos Goals comme des tickets “testables”
Si votre objectif ressemble à un ticket qui peut être “accepté” avec des critères clairs, vous êtes sur la bonne voie.
2) Identifiez votre juge objectif
Votre juge, c’est souvent :
- la suite de tests
- la CI
- un benchmark simple
Si ce juge n’existe pas, commencez par le créer. Sinon, votre agent ne peut pas prouver qu’il a réussi.
3) Ajoutez toujours une condition d’arrêt
C’est votre sécurité anti-boucles et votre garde-fou de coût.
4) Privilégiez des itérations petites et traçables
Demandez explicitement :
- un changement à la fois
- un re-test systématique
- un mini journal des modifications
Conclusion
Les Goals transforment Codex d’un générateur de réponses en un agent orienté résultat : vous donnez une ligne d’arrivée, un juge (preuves), des limites, et une politique d’itération. L’agent avance, se corrige, et s’arrête quand il a démontré qu’il a terminé — ou quand il est rationnel de vous repasser la main.
Si vous voulez intégrer des agents dans vos workflows (dev, QA, CI/CD), c’est une brique structurante : moins de bruit, plus de résultats, et surtout une fin claire.
Vous souhaitez appliquer ces idées à votre organisation ? FD Stratégies peut vous accompagner dans la création de solutions numériques, l’automatisation de vos processus et la structuration de votre présence en ligne.
