Laisser Claude travailler seul : /goal, /loop, routines et workflows

Le principe

Jusqu'ici, tu valides chaque tour : Claude propose, tu relis, tu relances. Avec les outils de ce chapitre, tu fixes un objectif ou un rythme, Claude enchaîne les tours seul, tu contrôles le résultat à la fin.

Ça ne marche qu'à deux conditions.

1. Claude ne doit pas s'arrêter à chaque commande. Sans auto mode, il te demande la permission de lancer les tests, et l'autonomie s'arrête au premier npm test. L'auto mode est le mode de départ des nouvelles sessions Pro, Max et Team depuis le 14 août 2026, et de tous les plans depuis fin septembre 2026 (v2.1.283) : un classifieur autorise ce qui est sûr et bloque les commandes destructives et les déploiements en prod. Le détail est au chapitre 9.
2. La fin doit être vérifiable. Une suite de tests qui passe, un build qui sort sans erreur, une file d'issues vide. Si tu ne sais pas dire comment prouver que c'est fini, Claude non plus.

/goal : travailler jusqu'à une condition

Ce que ça fait

Arrivé en v2.1.139, en mai 2026. Tu écris une condition de fin. Après chaque tour, un modèle à part (l'évaluateur) lit la conversation et rend un verdict : pas encore, rempli, ou impossible. Pas encore : Claude relance un tour tout seul, avec la raison de l'évaluateur comme consigne. Rempli ou impossible : le goal s'efface et une entrée le note dans la conversation.

Le goal s'efface aussi tout seul quand un tour plante sur une erreur que toi seul peux régler : authentification refusée, crédits épuisés, contexte saturé que l'auto-compact n'arrive pas à vider, modèle indisponible. Claude Code affiche alors Goal cleared after an unrecoverable error. Tu corriges, puis tu relances /goal.

Syntaxe

/goal tous les tests de src/billing passent et npm run build sort sans erreur
/goal
/goal clear

• /goal <condition> fixe l'objectif et démarre aussitôt un tour. Pas besoin d'envoyer un prompt en plus.
• /goal seul affiche l'état : la condition, depuis combien de temps elle tourne, le nombre de tours, les tokens dépensés, la dernière raison de l'évaluateur.
• /goal clear arrête tout (stop, off, cancel marchent aussi). Un /clear efface le goal avec la conversation.
• Un seul goal par session. En fixer un nouveau remplace l'ancien.
• Tant qu'il tourne, l'indicateur ◎ /goal active s'affiche. Ctrl+O montre la raison derrière chaque verdict.

Ça marche en interactif, à distance via Remote Control (depuis ton téléphone) et en non interactif avec -p, où la boucle va au bout en un seul appel :

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

/goal ne change pas ton mode de permission. En mode manuel, Claude te demandera toujours avant de lancer les tests. Combine-le avec l'auto mode : l'auto mode supprime les validations par outil, /goal supprime les validations par tour.

Écrire une bonne condition

L'évaluateur ne lance aucune commande et n'ouvre aucun fichier. Il juge uniquement sur ce que Claude a affiché dans la conversation. Ta condition doit donc décrire une preuve que Claude peut produire lui-même.

Ajoute une borne pour éviter que ça tourne indéfiniment, par exemple ou arrête-toi après 20 tours. Claude rend compte de sa progression contre cette borne à chaque tour. La condition peut faire jusqu'à 4 000 caractères.

Exemple

Tu passes un module de paiement sur une nouvelle version de SDK. Tu lances :

/goal tous les appels à stripe.charges dans src/billing sont migrés vers paymentIntents,
npm test sort en 0, npm run build passe, aucun fichier hors de src/billing n'est modifié,
ou arrête-toi après 15 tours

Tu pars faire autre chose. Claude migre, lance les tests, voit deux échecs, les corrige, relance. L'évaluateur dit "pas encore" tant que la sortie de npm test n'est pas verte. Quand tu reviens, /goal te montre le nombre de tours et ce que ça a consommé. Tu relis le diff avant de commiter, comme d'habitude.

Quand le goal ne s'arrête pas

Claude Code a un frein de secours : si Claude répond à l'évaluateur plusieurs tours de suite sans utiliser aucun outil, la boucle s'arrête et tu reprends la main, goal toujours posé. Ne compte pas dessus pour un goal qui avance mal mais avance quand même.

L'évaluateur tourne sur le petit modèle rapide configuré pour ton fournisseur. D'après la doc, ses tokens sont généralement négligeables à côté des tours principaux. La vraie dépense vient des tours qu'il relance : chacun renvoie toute la conversation.

/loop : relancer à intervalle

Ce que ça fait

/loop relance un prompt ou une skill en boucle, tant que la session reste ouverte. Ferme le terminal et la boucle s'arrête, sauf si tu as d'abord envoyé la session en arrière-plan avec /bg (voir plus bas). C'est l'outil pour surveiller : un déploiement, une CI, une PR en review.

Syntaxe

Le prompt de maintenance reprend le travail en cours dans la conversation et s'occupe de la PR de ta branche : commentaires de review, CI en échec, conflits. Pour le remplacer par tes propres consignes, écris-les dans .claude/loop.md :

Regarde la PR de la branche release/next. Si la CI est rouge, récupère le log
du job en échec, diagnostique et propose un correctif minimal. Si de nouveaux
commentaires de review sont arrivés, traite-les. Si tout est vert, dis-le en
une ligne.

Exemple

Tu viens de pousser une branche, Vercel build, tu veux savoir quand c'est fini sans rafraîchir l'onglet :

/loop 5m vérifie si le déploiement de la branche feat/onboarding est terminé, et s'il a échoué, lis les logs de build et dis-moi pourquoi

Les limites à connaître

• Une tâche récurrente expire au bout de 7 jours. C'est voulu : ça borne ce qu'une boucle oubliée peut consommer.
• 50 tâches planifiées maximum par session.
• Esc arrête une boucle auto-cadencée qui attend sa prochaine itération. Claude peut aussi l'arrêter lui-même quand le travail est fini. Pour une boucle à intervalle fixe, demande à Claude : "annule la tâche de vérification du déploiement".
• Les horaires ont un décalage volontaire, pour que toutes les sessions ne tapent pas l'API à la même seconde : jusqu'à 30 minutes de retard pour une tâche récurrente (la moitié de l'intervalle si elle tourne plus d'une fois par heure). Pour un rappel ponctuel à heure précise, évite les minutes rondes (:00, :30).

Monitor : suivre une commande au lieu de repasser toutes les 5 minutes

Monitor est un outil de Claude Code (depuis la v2.1.98, en avril 2026). Il lance une commande en arrière-plan et renvoie à Claude chaque nouvelle ligne de sortie. Pour des logs ou une CI, c'est mieux qu'une boucle : Claude réagit à la ligne qui arrive au lieu de relancer un tour complet toutes les 5 minutes pour voir si quelque chose a bougé.

Lance npm run dev en arrière-plan avec Monitor et préviens-moi dès qu'une erreur apparaît dans les logs.

Quand tu demandes un /loop auto-cadencé, Claude peut d'ailleurs choisir Monitor de lui-même.

Ce que coûte une boucle

Chaque itération est un tour complet : toute la conversation repart, plus le résultat de la vérification. Une boucle toutes les 5 minutes pendant 7 jours, c'est 2 016 tours. Et sur abonnement, le cache de la conversation tient 1 heure : une boucle espacée de plus d'une heure repart à froid à chaque itération, au prix fort. Pour une surveillance longue et espacée, une routine est souvent plus adaptée.

Les routines : planifier dans le cloud

Ce que ça fait

Depuis le 14 avril 2026, en research preview, sur Pro, Max, Team et Enterprise.

Une même routine peut combiner plusieurs déclencheurs.

Syntaxe

Deux chemins. Sur le web, claude.ai/code/routines, bouton New routine. Ou depuis le terminal, en langage naturel :

/schedule daily PR review at 9am
/schedule tomorrow at 9am, summarize yesterday's merged PRs

Claude te pose ses questions (quels repos, quel prompt, quel horaire) puis enregistre la routine sur ton compte. /routines est un alias. Ensuite, /schedule list les affiche, /schedule update en modifie une (par exemple pour poser une expression cron précise), /schedule run en lance une tout de suite. Le déclencheur API s'ajoute depuis le web, le déclencheur GitHub depuis le web ou le terminal.

/schedule demande une connexion avec ton abonnement claude.ai (/login). Avec une clé API Console, Bedrock ou Google Cloud, la commande n'est pas disponible.

Et si tu as besoin de tes fichiers locaux

L'app desktop propose un entre-deux : les tâches planifiées locales (page Routines de l'onglet Code, bouton New routine, puis Local). Elles tournent sur ta machine, avec tes fichiers et tes outils, jusqu'à une fois par minute. En échange, l'app doit être ouverte et l'ordinateur allumé.

Exemple

Chaque matin de semaine, une routine lit les issues ouvertes la veille, pose les labels, assigne selon la zone de code touchée, et met à jour une page de synthèse. Cette page peut être un artifact : une page HTML privée publiée sur claude.ai, mise à jour en place à la même URL. Une routine peut republier sans demander un artifact privé que tu as déjà publié. Pour en créer un nouveau, elle demande. Publie la page une première fois toi-même, puis donne-la à la routine.

Ce qui coince

• Les quotas. Chaque run compte dans tes limites d'abonnement, comme une session normale. La doc ajoute des plafonds horaires : 100 runs planifiés par heure sur ton compte, 30 lancements manuels ou par API par heure et par routine. Quand ta limite d'abonnement tombe, les runs passent sur tes crédits d'usage s'ils sont activés (claude.ai/settings/usage), sinon ils sont refusés jusqu'à la fin de ta fenêtre. Les plafonds quotidiens annoncés en avril (5, 15 ou 25 runs par jour) ne figurent plus dans la doc d'octobre 2026.
• Pas de MCP local. Les serveurs que tu as ajoutés avec claude mcp add vivent sur ta machine et ne suivent pas. Ajoute-les comme connecteurs sur claude.ai, ou, pour une routine sur un seul repo, déclare-les dans un .mcp.json commité.
• Un clone neuf. La routine part de la branche par défaut du repo GitHub, pas de tes fichiers locaux. Elle pousse sur des branches préfixées claude/, sauf si ton prompt dit autre chose. Pour verrouiller, utilise les règles de protection de branche de GitHub.
• Aucune demande de permission pendant le run, à part certaines publications d'artifact. Tous tes connecteurs sont inclus par défaut, écritures comprises. Retire ceux dont la routine n'a pas besoin.
• Un run vert ne veut pas dire tâche réussie. Le statut vert dit seulement que la session a démarré et s'est terminée sans erreur d'infrastructure. Ouvre le run et lis ce que Claude a fait.
• Elle agit en ton nom. Commits, PR, messages Slack : tout apparaît comme venant de toi.

Les workflows dynamiques et ultracode

Ce que ça fait

Depuis mai 2026 (v2.1.154). Un subagent, c'est une instance de Claude lancée pour une sous-tâche, dans son propre contexte (voir chapitre 7). Un workflow dynamique va plus loin : Claude écrit un script JavaScript qui orchestre des dizaines, voire des centaines de subagents, et un runtime l'exécute en arrière-plan. Ta session reste libre. Les résultats intermédiaires restent dans le script, ton contexte ne reçoit que la réponse finale.

À réserver aux tâches qui dépassent une conversation : un audit de tout le repo, une migration de 500 fichiers, une recherche dont les sources doivent être recoupées entre elles. Pas pour corriger un bug.

Syntaxe

ultracode: audite chaque endpoint de src/routes/ pour repérer les contrôles d'auth manquants

Le mot-clé ultracode au début d'un prompt lance un workflow pour cette tâche seulement. Demander "utilise un workflow" en clair marche aussi.

/effort ultracode
/effort ultracode off

/effort ultracode allume l'orchestration automatique pour toute la session : Claude planifie un workflow pour chaque tâche conséquente. Dans le sélecteur /effort, la touche Tab bascule l'interrupteur Ultracode.

/workflows
/deep-research Qu'est-ce qui a changé dans le modèle de permissions de Node.js entre v20 et v22 ?

/workflows ouvre la vue de progression : chaque phase, ses agents, ce que chacun a trouvé, la consommation de tokens. Tu peux y mettre en pause, arrêter (x) ou sauvegarder un run (s) dans .claude/workflows/, où il devient une commande réutilisable. /deep-research est le workflow intégré : il lance des recherches web sous plusieurs angles, recoupe les sources et rend un rapport cité.

Sur Pro, les workflows s'activent dans /config (ligne Dynamic workflows), avec une taille par défaut "small", soit moins de 5 agents.

Garder la taille sous contrôle

Claude Code affiche un avertissement Large workflow quand un run dépasse 25 agents ou 1,5 million de tokens prévus. C'est un avertissement, pas un frein : le run continue. Pour plafonner, fixe une taille :

/config workflowSizeGuideline=small

Avec /effort ultracode allumé, chaque demande consomme plus et l'avertissement disparaît (tu as déjà accepté les gros runs). Éteins-le dès que tu reviens à du travail courant.

Sessions de fond et coordination

Les outils précédents font tourner une tâche. Ceux-là font tourner plusieurs sessions en parallèle, chacune une vraie conversation Claude Code qui continue sans terminal attaché.

Un worktree, c'est une copie de travail séparée du même repo git, sur sa propre branche. Deux sessions peuvent modifier le même fichier sans se marcher dessus.

Depuis août 2026 (v2.1.224), les sessions se parlent : Claude dispose des outils SendMessage et ListAgents, et tu peux mentionner une session avec @. Une session qui finit une migration peut prévenir celle qui attend pour lancer les tests d'intégration.

Pour suivre tout ça loin de ton bureau, Remote Control t'envoie des notifications push sur mobile et te laisse répondre depuis ton téléphone.

claude --bg "enquête sur le test instable SettingsChangeDetector"
claude --bg "mets à jour la doc de l'API après le renommage des routes"
claude agents

Les agent teams vont encore plus loin : un agent chef supervise des pairs qui travaillent en parallèle sur une liste de tâches partagée. Expérimental, à activer avec CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Quand les coéquipiers tournent en plan mode, la doc annonce environ 7 fois plus de tokens qu'une session standard.

Côté quota, chaque session de fond pioche dans tes limites, indépendamment des autres. Trois sessions en parallèle, c'est trois fois la consommation.

Quel outil pour quel besoin

Le tableau donne le détail, avec quand chaque outil s'arrête.

Les garde-fous

Cinq filets à poser avant de laisser tourner.

1. Isole le travail. Les sessions de fond passent d'elles-mêmes dans un worktree. Pour les subagents qui écrivent, demande l'isolation en worktree (chapitre 7).
2. Auto mode, pas bypass. L'auto mode garde un classifieur entre Claude et les commandes dangereuses. --dangerously-skip-permissions sur une session que tu ne regardes pas retire ce filet.
3. Garde ta deny list. Les règles qui bloquent rm -rf, git push --force ou supabase db reset s'appliquent aussi aux tours que personne ne valide. Exemple dans ma configuration.
4. Borne la dépense. Une limite de tours dans le goal, une taille small pour les workflows, un premier run sur une tranche, puis un coup d'œil à /usage.
5. Relis avant d'intégrer. Une boucle ou une routine ouvre une PR ou un brouillon. Un humain merge.

Ce que l'autonomie coûte

Pendant que tu ne regardes pas, ça consomme. Les mécaniques à garder en tête :

• Chaque tour relancé par /goal ou /loop renvoie toute la conversation. Plus elle grossit, plus chaque tour coûte.
• Sur abonnement, le cache de la conversation principale tient 1 heure. Celui des subagents et des workflows tient 5 minutes. Un workflow de 50 agents écrit 50 caches, qui expirent vite.
• Les agent teams consomment environ 7 fois plus qu'une session standard quand les coéquipiers sont en plan mode.
• Chaque session de fond et chaque run de routine compte dans tes limites d'abonnement. Au-delà, ce sont tes crédits d'usage.
• L'évaluateur de /goal tourne sur le petit modèle rapide : c'est la partie la moins chère.
• Sur abonnement, /usage liste tes boucles les plus gourmandes (une ligne par tâche /loop ou planifiée, avec ses tokens par run). Regarde-la après la première journée d'une boucle.

Le cache, le choix du modèle et le suivi de la conso sont détaillés au chapitre 19.

Sources

• Keep Claude working toward a goal (doc Claude Code)
• Run prompts on a schedule (/loop) (doc Claude Code)
• Automate work with routines et l'annonce du 14 avril 2026
• Schedule recurring tasks in Claude Code Desktop et Agent view (doc Claude Code)
• Orchestrate subagents at scale with dynamic workflows (doc Claude Code)
• Track and reduce costs (doc Claude Code)