Claude Code nouvelle commande /goals : séparer l'exécution de l'évaluation, éviter que l'agent IA ne fasse la sieste ou ne mente

Anthropic pour Claude Code lance la commande /goals, séparant la tâche d’exécution et la décision d’achèvement en deux modèles indépendants, car laisser un même IA juger ses propres devoirs est une conception intrinsèquement défectueuse.
(Précédent : Claude Code annonce une augmentation de 50 % du plafond hebdomadaire d’utilisation des tokens ! Pour deux mois, Anthropic s’empare de l’écosystème des développeurs)
(Contexte supplémentaire : Lancement de la fonction d’exécution automatique de Claude Code : prise en charge des déclencheurs via planification, API, événements GitHub)

Vous avez peut-être déjà rencontré cette situation : l’IA a terminé la conception du code, elle vous répond que la tâche est accomplie. Mais quelques jours plus tard, vous découvrez que plusieurs modules n’ont même pas été compilés. Ce n’est pas un manque de capacité du modèle, mais le modèle a décidé lui-même qu’il « avait déjà terminé », alors qu’en réalité, ce n’était pas le cas.

Pour améliorer cette situation, Anthropic a lancé cette semaine la nouvelle commande /goals pour Claude Code. La logique est simple : le modèle chargé d’exécuter la tâche et celui chargé d’évaluer si la tâche est terminée doivent être deux rôles distincts. Le même modèle ne peut pas jouer ces deux rôles simultanément, car il sera toujours le pire juge de ses propres devoirs.

Comment faire en sorte que Claude continue à travailler jusqu’à ce que la tâche soit terminée ? Claude Code aide à cela de plusieurs façons, y compris une que nous avons récemment déployée : /goal. pic.twitter.com/QtVPmwoKct

— ClaudeDevs (@ClaudeDevs) 13 mai 2026

Pourquoi l’agent IA « quitte-t-il le travail prématurément »

Le travail d’un agent de codage IA consiste en une boucle : lire un fichier, exécuter une commande, modifier le code, puis juger si la tâche est terminée. Le problème réside dans cette dernière étape.

Le contexte accumulé durant le processus : étapes terminées, méthodes essayées, erreurs rencontrées… influence la perception du progrès par le modèle. Il a tendance à confondre « j’ai fait beaucoup » avec « j’ai terminé ». Ce problème est coûteux en environnement d’entreprise : si la migration ou la correction de tests s’arrête avant la fin, cela peut ne pas être détecté avant plusieurs jours.

Certaines solutions existent déjà dans l’industrie. OpenAI permet au modèle agent de décider lui-même quand s’arrêter, en laissant aux développeurs la possibilité d’intégrer un évaluateur externe. Google ADK supporte une évaluation indépendante via LoopAgent, LangGraph propose un mode similaire, mais ces solutions ont en commun que : le nœud critique (critic node) et la logique d’arrêt doivent être conçus par le développeur, la plateforme ne fournit pas de solution prête à l’emploi.

Une commande, deux modèles

La conception centrale de /goals consiste à séparer formellement « exécution » et « évaluation » en deux rôles distincts. Le développeur entre une condition d’objectif, par exemple :

/goal test/auth tous les tests du répertoire doivent passer, et le résultat du lint doit être propre

Chaque fois que l’agent tente de terminer, le modèle d’évaluation prend le relais pour vérifier. Par défaut, ce modèle d’évaluation utilise Claude Haiku (un modèle plus léger d’Anthropic). La raison du choix d’un petit modèle est simple : l’évaluateur doit simplement faire une décision binaire, condition remplie ou non, sans nécessiter la capacité de raisonnement d’un grand modèle.

Si la condition n’est pas remplie, l’agent continue d’exécuter ; si elle l’est, le modèle d’évaluation enregistre le résultat dans le dialogue et efface l’objectif. Tout ce processus se déroule en interne dans Claude Code, sans besoin de plateforme d’observation tierce ou de système de journalisation personnalisé.

Anthropic indique que des objectifs efficaces nécessitent généralement trois éléments : un critère de fin mesurable (résultats de test, code de sortie de build, nombre spécifique de fichiers), une méthode de validation claire (par exemple, « npm test doit retourner 0 »), et des restrictions immuables durant le processus (par exemple, « ne pas modifier d’autres fichiers de test »).