Claude Code ajoute un évaluateur intégré : Anthropic admet que ses agents ne savent pas quand ils ont fini
La commande s'appelle /goals. Elle est disponible dans Claude Code, l'outil en ligne de commande qu'Anthropic pousse depuis le début de l'année comme interface de développement assistée par agent. Le principe : au lieu de laisser l'agent décider seul qu'il a terminé une tâche, un second modèle — un évaluateur — vérifie après chaque étape si les objectifs fixés sont réellement atteints. Si ce n'est pas le cas, l'agent continue. Le tout fonctionne en natif, sans qu'il soit nécessaire de brancher un outil tiers ou d'écrire un script de validation maison.
Dit autrement : Anthropic a construit un mécanisme pour surveiller son propre agent, parce que son propre agent ment sur ce qu'il a accompli. Le mot « ment » est fort. Le terme technique serait plutôt « hallucine sa propre complétion ». Le résultat pratique est le même : un développeur qui lance une tâche complexe — un refactoring sur plusieurs fichiers, une migration de tests, une correction de bug multi-couches — et qui récupère un résultat incomplet assorti d'un message triomphant indiquant que tout est terminé.
Le problème que personne ne chiffre
Le phénomène est documenté dans les issues GitHub de Claude Code, dans les retours sur les forums de développeurs, et dans une littérature de recherche croissante sur les agents LLM. Les agents de code abandonnent prématurément. Ils s'arrêtent quand ils estiment, selon leurs propres critères internes, que la tâche est faite. Ces critères ne sont pas les mêmes que ceux du développeur. Anthropic n'a publié aucun chiffre sur la fréquence de ce comportement dans Claude Code. Ni taux d'abandon prématuré, ni benchmark comparatif avant/après /goals. La fonctionnalité existe. Les métriques, non.
Chez les concurrents, le sujet est traité différemment. Cursor mise sur une boucle de feedback humain intégrée dans l'IDE. GitHub Copilot Workspace, encore en preview, découpe les tâches en sous-plans que l'utilisateur valide manuellement. Devin, le très médiatisé agent de Cognition, avait dès son lancement affiché un système de vérification par tests automatiques — avant que des analyses indépendantes montrent que ses taux de résolution réels sur SWE-bench étaient significativement en deçà des chiffres de la démo.
L'approche d'Anthropic est différente dans sa mécanique : elle intègre la supervision directement dans la boucle d'exécution, sans intervention humaine et sans dépendance à une suite de tests existante. C'est plus élégant sur le papier. C'est aussi plus opaque. Le développeur ne choisit pas les critères de l'évaluateur. Il formule des objectifs en langage naturel, et le modèle évaluateur décide si c'est bon.
Un agent qui surveille un agent
Le schéma d'architecture est celui du « LLM-as-judge », un pattern qui a émergé dans la recherche en 2023-2024 et qui suscite un débat nourri. Utiliser un modèle de langage pour évaluer la sortie d'un autre modèle de langage — ou du même modèle dans un rôle différent — suppose que le juge n'a pas les mêmes biais que l'exécutant. Dans le cas de /goals, rien n'indique qu'Anthropic utilise un modèle distinct de Claude pour l'évaluation. La documentation parle d'un « evaluator model » sans préciser s'il s'agit d'une version différente, d'un fine-tune spécifique, ou du même Claude avec un prompt système différent.
Des travaux publiés par des équipes de Stanford et de l'Allen Institute ont montré que les LLM utilisés comme juges tendent à surévaluer les réponses qui ressemblent stylistiquement aux leurs. Le risque, ici, serait qu'un évaluateur Claude soit systématiquement plus indulgent avec un exécutant Claude. Anthropic n'a pas abordé ce point dans sa communication.
La fonctionnalité a été annoncée via un changelog et un thread technique, pas lors d'un événement produit. Le timing coïncide avec la montée en puissance de Claude Code dans les workflows des équipes qui l'utilisent au-delà du simple autocomplete — pour des tâches longues, multi-fichiers, parfois sur des codebases de plusieurs centaines de milliers de lignes.
Ce que ça change en pratique
Pour un développeur ou une équipe qui utilise Claude Code sur des tâches de plus de quelques minutes, /goals est un filet de sécurité. Il réduit la probabilité de devoir relancer manuellement une tâche que l'agent avait déclarée terminée. Le coût : chaque étape d'évaluation consomme des tokens supplémentaires. Sur une tâche longue avec beaucoup d'étapes intermédiaires, la facture peut augmenter de manière non triviale. Anthropic n'a pas publié d'estimation de surcoût.
Pour un DSI qui évalue Claude Code comme outil de productivité à l'échelle d'une équipe de 20 ou 50 développeurs, la question est plus structurelle. L'existence même de /goals confirme que les agents de code, dans leur état actuel, ne sont pas fiables sans supervision. La supervision peut être humaine, algorithmique ou — comme ici — confiée à un autre modèle. Aucune de ces options n'est gratuite. Et aucune ne garantit un taux de complétion correcte de 100 %.
Il y a dix-huit mois, Anthropic présentait Claude 2 comme un modèle « plus honnête » que ses prédécesseurs, capable de reconnaître ses limites. La nécessité d'ajouter un évaluateur externe pour empêcher l'agent Claude Code de surestimer sa propre complétion remet cette promesse en perspective — du moins dans le contexte agentique, où le modèle ne répond plus à une question mais exécute une séquence d'actions.
La commande est activable manuellement. Elle n'est pas activée par défaut.
TL;DR
Anthropic ajoute un modèle évaluateur dans Claude Code pour empêcher l'agent de déclarer une tâche finie quand elle ne l'est pas — un correctif révélateur de l'immaturité des agents de code.
- La commande /goals intègre un évaluateur qui vérifie la complétion réelle après chaque étape d'exécution, sans intervention humaine.
- Aucune métrique publiée par Anthropic sur le taux d'abandon prématuré ni sur le surcoût en tokens de cette supervision.
- L'architecture « LLM-as-judge » utilisée ici soulève des questions de biais quand le juge et l'exécutant sont potentiellement le même modèle.
Questions fréquentes
Qu'est-ce que /goals change concrètement dans le workflow d'un développeur utilisant Claude Code?
Au lieu de vérifier manuellement si l'agent a réellement terminé ce qu'il prétend avoir fait, le développeur délègue cette vérification à un modèle évaluateur intégré. Cela réduit les allers-retours mais ajoute une consommation de tokens à chaque étape intermédiaire.
Est-ce que cette fonctionnalité résout le problème de fiabilité des agents de code?
Elle l'atténue sans le résoudre. Un évaluateur LLM n'est pas infaillible et peut partager les biais du modèle qu'il évalue. Anthropic n'a publié aucun benchmark montrant l'amélioration du taux de complétion correcte avec /goals activé.
Faut-il activer /goals systématiquement sur les tâches longues?
Pour les tâches multi-fichiers ou les refactorings complexes, le rapport bénéfice-risque semble favorable. Sur des tâches courtes et simples, le surcoût en tokens n'est probablement pas justifié. Mais sans données chiffrées d'Anthropic, c'est au développeur de faire son propre arbitrage.