Ne dictez pas chaque étape. Donnez à Claude une ligne d'arrivée.

Il y a une forme de fatigue bien particulière qui vient avec une bonne utilisation de Claude Code. Vous lui donnez une tâche, il en réalise une partie, s’arrête et vous rend la main. Vous jetez un œil au résultat, puis vous dites « oui, continuez » ou « non, les tests échouent encore, réessayez ». Il passe alors à la partie suivante et s’arrête de nouveau. Encore et encore. Vous ne faites plus le travail, mais vous restez planté derrière lui à le relancer toutes les quelques minutes, comme une caisse automatique au ralenti.

La commande /goal est la réponse d’Anthropic à ce problème précis. Vous définissez la ligne d’arrivée une fois. Claude continue à avancer vers elle, tour après tour et de manière autonome, puis ne revient vers vous que lorsqu’un modèle distinct confirme qu’elle est franchie. Vous lancez la commande, puis vous allez vous faire un café.

Je préfère préciser d’emblée à qui cette commande s’adresse. /goal donne le meilleur de lui-même pour les travaux dont l’état final est net et vérifiable. Une bonne partie de ces travaux relève du développement: mettre les tests au vert, faire passer le build, vider la file d’issues. Si vous ne développez pas, mais entretenez un site web ou faites passer du contenu par Claude Code, la commande reste utile. Vous devrez simplement réfléchir un peu plus à ce que « terminé » signifie pour votre type de tâche. J’y reviendrai.

Ce qu’est vraiment un objectif

Claude Code fonctionne normalement tour par tour. Il travaille, s’arrête, vous rend la main, puis vous lui donnez l’étape suivante. C’est le rythme par défaut de cet aller-retour.

Un objectif change ce qui déclenche le tour suivant. Au lieu que vous décidiez qu’il est temps de repartir, une condition d’achèvement s’en charge. Vous lancez /goal, suivi d’une description en langage courant de ce à quoi ressemble le travail « terminé ». À partir de là, Claude lance de nouveaux tours de lui-même jusqu’à ce que la condition soit remplie. Elle ne l’est pas encore? Il lance un autre tour. Elle l’est? L’objectif s’efface et vous récupérez la main.

Le modèle mental auquel je reviens toujours est celui d’un artisan engagé pour peindre une pièce. Dans la version tâche par tâche, vous restez dans l’embrasure après chaque mur: « d’accord, le mur suivant ». Dans la version avec objectif, vous dites: « La pièce est terminée quand chaque mur a reçu deux couches, qu’il ne reste plus de ruban adhésif sur les boiseries et que les bâches sont repliées. » Puis vous partez. L’artisan sait exactement quand son travail est terminé, et vous aussi, parce que vous vous êtes mis d’accord sur la ligne d’arrivée avant même que le pinceau ne sorte.

Cette analogie montre aussi ce qui peut mal tourner, et nous y reviendrons. Une ligne d’arrivée trop vague (« faites en sorte que la pièce soit jolie ») laisse l’artisan s’arrêter quand bon lui semble. Gardez ça en tête.

Comment ça fonctionne sous le capot

Ce qui m’a surpris, c’est que Claude ne corrige pas sa propre copie. Deux modèles interviennent.

Le modèle principal, Sonnet, Opus ou celui que vous utilisez, fait le vrai travail à chaque tour. Puis, chaque fois qu’il termine un tour, la condition que vous avez écrite et toute la conversation jusque-là sont transmises à un second modèle, plus petit et plus rapide (Haiku par défaut), qui joue le rôle d’arbitre. Il lit tout et répond simplement oui ou non, avec une raison en une ligne. « Non » dit à Claude de continuer, et la raison devient un indice pour le tour suivant. « Oui » efface l’objectif et le marque comme atteint.

Le fait d’avoir deux modèles distincts compte. Celui qui s’acharne sur le problème est souvent le plus mauvais juge pour décider si le travail est vraiment terminé. Il est impliqué, il fixe le même code depuis dix tours, il veut en finir. Un arbitre au regard neuf, qui n’a pas fait le travail, est plus difficile à tromper. C’est la différence entre corriger votre propre copie et la faire corriger par quelqu’un d’autre.

Voici la contrainte qui régit tout le reste: l’arbitre ne voit que la conversation. Il ne peut ni lancer vos tests, ni ouvrir vos fichiers, ni vérifier votre base de données. Il juge uniquement ce que Claude a fait apparaître dans le chat. La condition « tous les tests du dossier auth passent » fonctionne donc très bien, mais uniquement parce que Claude lance vraiment ces tests et que leur résultat positif apparaît dans la transcription, où l’arbitre peut le lire. Si la preuve n’apparaît jamais dans la conversation, l’arbitre n’a aucun élément pour trancher.

Un autre détail mécanique mérite d’être connu: définir un objectif déclenche immédiatement un tour, avec votre condition comme instruction. Vous ne saisissez pas l’objectif avant d’envoyer un prompt séparé. La condition est le prompt. Pendant l’exécution, un petit indicateur ◎ /goal active affiche depuis combien de temps l’objectif tourne.

Quand son utilisation a du sens

Utilisez un objectif quand le travail est conséquent, en grande partie mécanique, et possède un état final que vous pouvez réellement vérifier. Les exemples officiels donnent une bonne idée du type de tâche:

• Migrer un module vers une nouvelle API jusqu’à ce que tous les appels utilisent la nouvelle API, que le module compile et que les tests passent
• Implémenter un document de conception jusqu’à ce que tous ses critères d’acceptation soient remplis
• Découper un fichier trop volumineux en modules plus petits jusqu’à ce que chacun respecte une limite de taille
• Traiter un backlog d’issues étiquetées jusqu’à ce que la file soit vide

Regardez leur point commun. Chacune demande d’enchaîner péniblement de nombreuses étapes similaires et possède un moment où vous pouvez montrer quelque chose en disant « voilà, c’est terminé »: une suite de tests au vert, une file vide, un fichier de moins de 300 lignes. Cette combinaison, fastidieuse et vérifiable, est le terrain idéal.

Pour mon propre travail sur ce site, l’exemple qui me parle est la passe de style éditorial. Je parcours régulièrement les guides pour y supprimer les tics d’écriture IA: les formulations raides, les oppositions « pas X, mais Y », les tirets cadratins trop fréquents. Cela représente des dizaines de modifications presque identiques dans deux douzaines de fichiers, avec un résultat final vérifiable: chaque guide respecte la checklist stylistique. C’est un objectif. Par exemple: chaque guide du dossier guides a été relu au regard de protocols/content-style.md et ses tics ont été corrigés, sans modifier les liens, les faits ni les titres. Signalez chaque fichier dès que vous l’avez terminé. C’est fastidieux, répétitif, et la ligne d’arrivée peut être décrite. Exactement le travail que je n’ai pas envie de relancer fichier par fichier.

Quand vaut-il mieux ne pas l’utiliser? Quand le travail est court (faites simplement une demande normale), lorsqu’il est vraiment créatif ou subjectif (un texte qui exige une voix humaine cohérente n’a pas de ligne d’arrivée qu’un arbitre puisse valider), ou quand vous ne pouvez pas décrire « terminé » d’une manière visible dans la conversation. Si vous ne pouvez pas compléter la phrase « ce travail est terminé quand ______ » par quelque chose de concret, l’objectif est le mauvais outil.

Écrire une condition qui fonctionne vraiment

Tout se joue là. Un objectif ne vaut que par sa ligne d’arrivée, et la plupart des échecs que j’ai vus viennent d’une condition formulée à la va-vite.

Une condition qui tient sur de nombreux tours comporte généralement trois parties:

Un seul état final mesurable. Le résultat d’un test, le code de sortie d’un build, un nombre de fichiers, une file vide. Quelque chose qui a une valeur précise, pas une impression. « Le code est meilleur » n’a pas d’état final. « Chaque fichier du dossier components fait moins de 200 lignes » en a un.

Une vérification explicite, qui indique comment Claude doit apporter la preuve. N’oubliez pas que l’arbitre ne lit que la transcription. Dites donc à Claude comment démontrer le succès d’une façon qui apparaisse dans le chat: « lancez la suite de tests et montrez qu’elle se termine avec un code de sortie 0 », « lancez git status et montrez que l’arbre de travail est propre ». Vous ne nommez pas seulement l’objectif, vous nommez aussi la preuve.

Les contraintes importantes, ce qui ne doit pas changer. C’est la partie que les gens oublient, et la plus importante. Précisez tout ce qui doit rester vrai sur le chemin de la ligne d’arrivée: « ne modifiez aucun autre fichier de test », « ne touchez pas à l’API publique », « ne supprimez rien pour faire passer la vérification ».

Ce dernier point n’est pas de la paranoïa. C’est le principal piège des objectifs, et il mérite sa propre section.

Les inconvénients, franchement

Le problème de la patte de singe. Vous avez demandé « aucun test en échec ». Un exécutant qui interprète vos mots à la lettre et subit la pression de remplir cette condition voit une manière évidente de tricher: supprimer les tests qui échouent. Il n’y a alors plus aucun test en échec. Condition remplie, l’arbitre répond oui, l’objectif s’efface et votre code est plus défectueux qu’au départ. C’est un vrai mode d’échec, directement lié au fait que Claude cherche à satisfaire les mots que vous avez écrits plutôt que votre intention. La solution consiste à intégrer des garde-fous dans la condition: « tous les tests passent sans supprimer ni ignorer le moindre test ». Chaque fois que vous écrivez un objectif, prenez une seconde pour réfléchir comme un juriste pointilleux qui chercherait le moyen le moins coûteux de le satisfaire, puis fermez cette porte.

Il peut tourner indéfiniment. Si la condition ne peut jamais être prouvée, parce qu’elle est vague, réellement impossible ou que la preuve n’apparaît jamais dans le chat, Claude continuera à lancer de nouveaux tours sans fin et consommera des tokens pendant tout ce temps. Pour vous en protéger, fixez une limite: ajoutez directement à la condition une clause comme « ou arrêtez-vous après 20 tours ». Claude indique à chaque tour où il en est par rapport à cette clause, et l’arbitre déclarera le travail terminé une fois la limite atteinte.

Il coûte de vrais tokens. Chaque tour est un tour complet pendant lequel le modèle principal travaille sans surveillance. Un objectif qui dure trente tours représente trente tours de dépense. Si votre forfait impose des limites hebdomadaires, un objectif ambitieux lancé pour la nuit peut engloutir une bonne partie de votre budget. (L’arbitre lui-même coûte peu: c’est le petit modèle Haiku, donc cette partie est négligeable. Ce sont les tours du modèle principal qui s’additionnent.)

Sans surveillance veut vraiment dire sans surveillance. Pour qu’un objectif s’exécute sans vous, Claude doit aussi pouvoir agir sans s’arrêter pour vous demander l’autorisation à chaque appel d’outil. C’est le rôle du mode auto, et les deux vont ensemble: le mode auto supprime les demandes par outil, /goal supprime celles par tour. Lâchez un modèle capable sur votre dépôt avec les deux activés et aucun garde-fou, et vous pouvez causer de vrais dégâts. Lancez-le sur une branche, jamais sur main.

L’arbitre juge un récit, pas la réalité. Comme il ne voit que la conversation, Claude peut en principe raconter avec assurance un succès qui n’a jamais eu lieu et obtenir un « oui ». Deux modèles rendent ce scénario bien plus difficile que l’auto-évaluation, sans l’exclure complètement. La parade reste la même: exigez dans la condition de vraies preuves dans la transcription, pas un résumé. « Les tests passent », appuyé par le vrai résultat des tests, vaut mieux que « j’ai tout corrigé ».

Comment l’essayer concrètement

Vous aurez besoin de Claude Code v2.1.139 ou d’une version ultérieure, et devrez avoir accepté la boîte de dialogue de confiance pour l’espace de travail. Le mécanisme d’objectif repose sur le système de hooks et ne fonctionne donc pas dans un dossier non approuvé.

Commencez petit, sur une branche temporaire, afin d’observer la boucle sans rien risquer:

/goal chaque fichier du dossier src/utils fait moins de 100 lignes,
atteignez ce résultat en divisant les plus longs en fichiers spécialisés, sans
modifier le comportement d'aucune fonction. Lancez les tests après chaque découpage
et montrez qu'ils passent toujours. Arrêtez-vous après 15 tours.

Cette condition réunit tous les éléments: un état final mesurable (des fichiers de moins de 100 lignes), une vérification explicite (les tests passent encore et le résultat apparaît dans le chat), une contrainte (ne pas modifier le comportement) et une limite (s’arrêter après 15 tours). La définir déclenche immédiatement le premier tour. Ensuite, observez. Après chaque tour, vous verrez la raison donnée en une ligne par l’arbitre pour expliquer pourquoi le travail n’est pas encore terminé. C’est vraiment intéressant: vous voyez en direct ce que Claude pense devoir encore accomplir.

Quelques commandes à connaître pendant l’exécution:

• /goal seul, sans texte, affiche l’état: la condition, la durée d’exécution, le nombre de tours, les tokens dépensés et la dernière raison donnée par l’arbitre.
• /goal clear arrête l’objectif avant que la condition ne soit remplie. (stop, off, reset, cancel et none fonctionnent aussi, et démarrer une nouvelle conversation avec /clear le supprime également.)
• Si vous fermez la session alors qu’un objectif est encore actif, puis la reprenez avec --resume ou --continue, l’objectif revient. Le minuteur et le nombre de tours repartent toutefois de zéro.

Cela fonctionne aussi en mode headless, ce qui devient vraiment utile pour les travaux planifiés. Cette commande exécute toute la boucle jusqu’au bout en une seule fois, depuis votre terminal ou un script:

claude -p "/goal CHANGELOG.md contient une entrée pour chaque PR fusionnée cette semaine"

Ctrl+C arrête un objectif headless si vous devez abandonner.

Goal, loop ou hook?

Un dernier point, car ces notions se confondent facilement. Claude Code dispose de trois moyens de maintenir une session en cours entre vos prompts, et chacun se déclenche sur un signal différent.

/goal lance le tour suivant lorsque le précédent se termine, puis s’arrête quand l’arbitre confirme votre condition. Utilisez-le lorsque vous avez une ligne d’arrivée vérifiable.

/loop lance le tour suivant après un intervalle de temps, toutes les dix minutes par exemple, puis s’arrête quand vous l’arrêtez ou que Claude juge le travail terminé. Utilisez-le pour un travail où il faut « continuer à avancer / continuer à surveiller », cadencé par l’horloge plutôt que par une condition.

Un Stop hook est la version à faire soi-même. Il se trouve dans votre fichier de paramètres, s’applique à toutes les sessions de sa portée et exécute votre propre script ou prompt pour décider s’il faut continuer. /goal est en fait une interface conviviale pour exactement ce mécanisme: un Stop hook limité à la session en cours. Utilisez un vrai Stop hook quand vous voulez que la même vérification s’applique automatiquement à chaque session, ou lorsque vous avez besoin d’une logique personnalisée qu’une condition d’une ligne ne peut pas exprimer.

Pour la plupart des gens, la plupart du temps, /goal est la bonne réponse. Donnez à Claude une ligne d’arrivée, formulez-la bien, ajoutez le garde-fou qui l’empêche de tricher et laissez-le travailler.

---

Si vous découvrez Claude Code comme agent plutôt que comme chatbot, commencez par Claude Code: quand l’IA arrête de parler et commence à agir. Et une fois que vous savez lancer un objectif, l’étape suivante consiste à laisser Claude répartir le travail entre des sous-agents, chacun chargé d’une partie en parallèle.