Codex /goal : la boucle Ralph devient native

Pendant un an, une petite secte de développeurs a écrit des scripts shell qui enveloppaient Claude Code et Codex dans des boucles while. Ils appelaient le pattern « Ralph » — pointez un agent vers un objectif, laissez-le agir, tester, réviser et itérer jusqu'à ce que ce soit fini. Maudit mais efficace.

Cette semaine, Codex CLI et Claude Code ont livré la même idée nativement. La commande s'appelle ‎/goal et elle transforme les agents de codage de partenaires de discussion en travailleurs auto-évaluateurs qui s'arrêtent lorsque la tâche est vérifiablement terminée.

Si vous tapez encore un prompt à la fois en regardant défiler les tokens, c'est le basculement que vous avez manqué.

Du dialogue au résultat

Le modèle mental par défaut du codage assisté par IA était conversationnel : vous écrivez un prompt, l'agent écrit du code, vous lisez le diff, vous corrigez, vous répétez. Andrej Karpathy appelle cela le « vibe coding » — rapide, intuitif et fragile au-delà d'un certain seuil de complexité.

Les agents orientés objectif inversent la boucle. Vous déclarez le résultat et les critères de succès. L'agent prend en charge l'itération :

1. Planifier — décomposer l'objectif en sous-tâches vérifiables
2. Agir — exécuter la prochaine sous-tâche (éditer du code, lancer un script, appeler un outil)
3. Tester — exécuter les vérifications par rapport aux critères de succès
4. Réviser — comparer son propre output à l'objectif
5. Itérer — choisir la sous-tâche suivante ou s'arrêter si c'est terminé

C'est la boucle Ralph en cinq lignes. Le ‎/goal de Codex et son équivalent dans Claude Code exécutent désormais cette boucle sans baby-sitter.

Configuration dans Codex CLI

La commande a atterri dans Codex CLI à partir de la version 0.128. Pour l'activer, éditez votre ~/.codex/config.toml :

[features]
goals = true
 
[goal]
max_iterations = 40
auto_mode = true
require_tests = true

Redémarrez le CLI, puis posez un objectif :

codex
> /goal Ajouter la rotation des refresh tokens JWT au service d'authentification. Les tests existants dans tests/auth doivent passer. Ajouter un nouveau test qui vérifie qu'un token roté invalide bien le précédent.

Codex planifie le travail, édite les fichiers, lance la suite de tests, lit les échecs, édite encore et s'arrête lorsque les critères de succès sont au vert. Shift+Tab passe en mode auto pour que l'agent ne s'arrête plus jamais pour demander confirmation entre les étapes.

Claude Code utilise une interface quasi identique. Les deux outils ont convergé vers la même forme en quelques semaines — signal fort que l'ingénierie d'objectifs est le nouveau standard, pas un pattern de niche.

Écrire un objectif qui aboutit

Le plus grand mode d'échec des boucles autonomes, ce sont les objectifs ambigus. L'agent tournera à l'infini, ou s'arrêtera trop tôt, si « terminé » est flou.

Un objectif qui fonctionne tient en trois parties :

Objectif : <une phrase qui décrit le résultat>
Contraintes : <fichiers, bibliothèques, bornes de performance>
Succès : <vérifications mesurables>

Comparez :

# MAUVAIS
/goal Rends la recherche plus rapide.
 
# BON
/goal Réduire la latence P95 de GET /search de 480ms à moins de 200ms.
Contraintes : ne pas modifier l'API publique, ne pas ajouter de dépendance.
Succès : un nouveau benchmark dans tests/perf/search_bench.ts qui passe en affirmant que la P95 reste sous 200ms sur 1000 requêtes face à la fixture seedée.

La bonne version est un système fermé. L'agent peut écrire le benchmark, le lancer, voir le nombre et ne s'arrêter qu'au vert. C'est ce qui rend la boucle terminable.

Là où la boucle Ralph excelle

Trois familles de travail s'inscrivent proprement dans les agents orientés objectif :

• Refactors mécaniques. Renommer un module, migrer d'un ORM à un autre, remplacer un client HTTP dans trente fichiers. Le critère de succès est « les tests passent toujours » — la boucle peut le vérifier à coût modique.
• Corrections de bugs avec un échec reproductible. Donnez à l'agent un test rouge ou une stack trace. La boucle tourne jusqu'à ce que le rouge devienne vert.
• Tuning de performance. Définissez un benchmark, fixez une cible, laissez l'agent essayer, mesurer, itérer. Les humains sont mauvais dans ce type de recherche par force brute. Les agents non.

Fil rouge : une vérification bon marché et déterministe sépare « terminé » de « pas terminé ». Sans cela, aucune boucle autonome ne vous fera gagner du temps.

Là où elle s'effondre

Les agents orientés objectif échouent de manière prévisible sur trois patterns :

• Décisions de design. « Construis un système de notifications » admet trop de bonnes réponses. La boucle en choisira une et foncera, souvent la mauvaise.
• Changements multi-systèmes sans tests locaux. Si vérifier le succès exige de toucher un environnement de staging ou une API payante, l'agent ne peut pas resserrer la boucle.
• Tests flaky. Un test qui échoue 1 fois sur 5 trompera l'agent : il croira avoir cassé quelque chose qu'il n'a pas cassé. Puis il « réparera » du code qui fonctionnait.

Remède commun : gardez les humains dans la phase de planification et laissez l'agent posséder l'exécution. Écrivez la spec, écrivez le test d'acceptation, puis passez l'objectif.

Sécurité et conditions d'arrêt

Une boucle auto-évaluatrice en mode auto est, par construction, un agent capable de faire beaucoup de dégâts entre l'instant où vous l'avez lancée et l'instant où vous revenez. Configurez les garde-fous avant d'appuyer sur Entrée :

[goal.safety]
allowed_paths = ["src/**", "tests/**"]
denied_commands = ["rm -rf", "git push", "npm publish"]
require_clean_git = true
max_runtime_minutes = 30
require_human_approval_for = ["migrations", "package.json"]

Traitez la config de l'objectif comme une politique CI. L'agent est désormais un contributeur qui ouvre des commits sans que vous regardiez — donnez-lui le même rayon d'action que vous donneriez à un junior à sa première semaine.

Ce qui change pour les équipes d'ingénierie

L'économie bascule pour de vrai. Un ‎/goal qui tourne 40 minutes contre un modèle à 0,10 $ le million de tokens consomme du vrai argent, et si vous en lancez dix en parallèle, votre facture mensuelle vous le dira. Les équipes MENA qui utilisent déjà Claude Code ou Codex sur du code de production doivent prévoir un budget — le travail orienté objectif est moins cher par résultat que le prompt conversationnel, mais la dépense absolue par développeur monte parce qu'on tente davantage de travail.

L'autre changement concerne la revue. Si un développeur expédie dix PR pilotées par objectif en une journée, les reviewers deviennent le goulot d'étranglement. Les entreprises qui s'adaptent le plus vite couplent ‎/goal à des templates de PR plus stricts, des résumés de diff générés automatiquement, et des tests d'acceptation obligatoires dans le corps de la PR. L'agent écrit ; les humains gardent la spec et le diff.

Comment commencer demain

Choisissez une tâche du sprint en cours dont le résultat est clairement vérifiable. Idéalement un bug avec un test rouge, ou un refactor déjà couvert par les tests existants. Écrivez l'objectif dans la forme tripartite ci-dessus. Lancez-le une fois avec ‎/goal et auto_mode = false pour observer ce que fait la boucle. À la tâche suivante, activez le mode auto et partez.

La première fois que vous reviendrez devant une suite de tests verte et un diff propre que vous n'avez pas tapé, le modèle mental conversationnel se dissout tout seul. Vous ne reviendrez pas en arrière.

La boucle Ralph n'est plus un script shell maudit. C'est le défaut. La question n'est plus s'il faut l'utiliser, mais à quel point vous savez écrire un objectif.