Claude Code : automatiser avec Goals et Workflows

En bref : Claude Code propose deux primitives pour sortir du prompting manuel tour par tour : /goal, qui maintient Claude actif jusqu’à ce qu’une condition vérifiable soit remplie, et les Dynamic Workflows, qui orchestrent jusqu’à 1 000 agents via un script JavaScript. Comprendre ces deux approches, et surtout quand choisir l’une plutôt que l’autre, change fondamentalement la façon de concevoir l’automatisation avec Claude.

Chaque fois que vous envoyez un message à Claude, que vous attendez la réponse, puis renvoyez un message, vous jouez le rôle de l’orchestrateur. Sur des tâches courtes, ce mode fonctionne très bien. Sur une migration de 300 fichiers ou un audit de sécurité complet, il devient le goulot d’étranglement : vous passez plus de temps à relancer Claude qu’à travailler sur le fond. Claude Code a introduit des primitives spécifiques pour résoudre ce problème. Les comprendre, c’est passer d’un agent réactif à un agent autonome.

Pourquoi le prompting itératif atteint ses limites

Le modèle de base du prompting est synchrone : vous envoyez une instruction, Claude travaille, vous récupérez un résultat, vous envoyez la suivante, etc… Pour une tâche simple, ce cycle prend quelques secondes. Pour une tâche qui nécessite 20, 30 ou 100 itérations, il devient coûteux en attention et en temps.

Prenons un cas concret : vous voulez que Claude migre toutes les routes d’une API vers un nouveau format, teste chaque changement, et itère jusqu’à ce que tous les tests passent. En mode question-réponse, vous demandez, Claude migre un sous-ensemble, revient, vous renvoyez la suite, et ainsi de suite. Chaque retour est une interruption de contexte : un moment où vous réévaluez l’état d’avancement et décidez quoi faire ensuite. Le même problème se pose pour vider un backlog de tickets, corriger les erreurs CI d’une branche, ou optimiser un score Lighthouse jusqu’à un seuil précis. Ce sont des tâches avec un objectif clair et un critère de fin vérifiable. Elles appellent une automatisation, pas de la supervision.

La réponse de Claude Code s’organise autour du concept de boucle : un agent qui répète des cycles de travail jusqu’à ce qu’une condition d’arrêt soit remplie, sans attendre l’humain entre chaque tour. Delba de Oliveira et Michael Segner, dans un article Anthropic publié le 30 juin 2026, décrivent quatre patterns distincts selon le déclencheur et le critère d’arrêt.

Quels sont les quatre patterns de boucle dans Claude Code ?

Type	Déclencheur	Critère d’arrêt	Primitive
Turn-based	Prompt utilisateur	Claude juge lui-même	Prompt standard
Goal-based	Fin de chaque tour	Évaluateur externe (Haiku) confirme la condition	/goal
Time-based	Intervalle de temps	Vous, ou Claude si tâche terminée	/loop, /schedule
Proactive	Événement ou planning	Script ou orchestration	Dynamic Workflows, routines cloud

 

Les deux dimensions clés sont le déclencheur (qui décide de lancer le prochain tour) et le critère d’arrêt (qui décide que c’est terminé). Ces deux variables définissent le niveau d’autonomie réel de l’agent. Pour un tech lead, ce tableau sert de grille de lecture pratique : si vous interrompez votre travail pour relancer Claude, vous êtes dans la zone turn-based. Si vous voulez vous libérer de cette supervision, les deux patterns suivants sont les réponses de Claude Code.

Comment fonctionne /goal et pourquoi l’évaluateur indépendant change tout ?

Le principe de /goal tient en une phrase : vous définissez une condition, Claude travaille, et après chaque tour un modèle séparé vérifie si la condition est remplie. Si ce n’est pas le cas, Claude repart pour un nouveau tour sans vous solliciter.

/goal all tests in test/auth pass and the lint step is clean

Dès que vous tapez cette commande, Claude commence à travailler. L’indicateur ◎ /goal active s’affiche avec la durée d’exécution. À chaque fin de tour, l’évaluateur (Haiku par défaut sur les versions actuelles de Claude Code), rend son verdict et affiche une courte raison. Cette raison apparaît dans le transcript et guide le tour suivant. Si la condition n’est pas remplie, Claude repart immédiatement.

Le détail qui change tout est l’indépendance de l’évaluateur. En mode standard, Claude juge lui-même s’il a terminé. Il a naturellement tendance à se déclarer satisfait trop tôt : un biais de complaisance bien documenté dans les LLM. Avec /goal, l’évaluation est confiée à un modèle qui n’a pas fait le travail. Il ne peut pas être influencé par l’effort fourni, seulement par le résultat observable dans le transcript. Cette séparation des rôles, entre celui qui travaille et celui qui évalue, est la différence fonctionnelle centrale avec un prompt standard en Auto mode.

Pour écrire une condition efficace, la documentation recommande trois éléments. Un end state mesurable : résultat de test, code de sortie, nombre de fichiers, queue vide. Un check explicite : comment Claude prouve que c’est fait, par exemple « npm test exits 0″ ou « git status is clean ». Des contraintes qui ne doivent pas changer en cours de route, par exemple « no other test file is modified ». La condition peut faire jusqu’à 4 000 caractères, ce qui laisse la place à des critères précis et composites. Et pour éviter les boucles longues, on recommande d’inclure une clause d’arrêt : « or stop after 20 turns ».

/goal est distinct d’Auto mode : Auto mode approuve les appels d’outils dans un tour sans relancer de nouveau tour. /goal ajoute un évaluateur externe qui décide si le travail est terminé et relance un nouveau tour si ce n’est pas le cas. Les deux sont complémentaires : Auto mode élimine les interruptions intra-tour, /goal élimine les interruptions inter-tours. Disponible depuis Claude Code v2.1.139.

Qu’est-ce que les Dynamic Workflows apportent que /goal ne peut pas faire ?

/goal résout la supervision tour par tour. Mais même avec un goal actif, Claude reste seul : un agent, une conversation, un contexte. Pour une migration de 500 fichiers ou un audit complet des endpoints d’une API, un seul agent devient le goulot d’étranglement. Les Dynamic Workflows répondent à un problème différent : la coordination à grande échelle.

La différence fondamentale avec les subagents classiques tient à l’emplacement du plan. Avec les subagents standard, Claude est l’orchestrateur : il décide tour par tour quoi lancer, et chaque résultat occupe de l’espace dans son contexte. Avec un Dynamic Workflow, un script JavaScript définit la boucle, le branchement et les résultats intermédiaires. Claude ne reçoit que la réponse finale. Selon la documentation Claude Code, cette architecture autorise jusqu’à 1 000 agents par run, avec 16 agents en parallèle au maximum. Le script s’exécute dans un environnement isolé, séparé de la conversation, pendant que votre session reste utilisable.

Trois patterns de composition illustrent ce que les Dynamic Workflows rendent possible au-delà de ce qu’un seul agent peut traiter : la parallélisation sur un grand corpus (chaque fichier ou endpoint traité par un agent indépendant), la revue adversariale (un agent rédige, un autre critique avant la synthèse), et la recherche multi-sources cross-vérifiée (chaque source examinée indépendamment, puis confrontation des résultats). Ce dernier pattern est exactement ce que fait le workflow intégré /deep-research : il accepte une question, lance des recherches en parallèle sur plusieurs angles, cross-vérifie les sources et retourne un rapport avec attribution des claims.

Pour vos propres tâches, incluez le mot-clé ultracode dans votre prompt (ou demandez explicitement à Claude : « use a workflow »). Claude écrit le script pour cette tâche. Vous pouvez aussi activer /effort ultracode pour la session entière : Claude planifie automatiquement un workflow pour chaque tâche substantielle. Une fois qu’un run a donné le résultat attendu, sauvegardez le script via /workflows puis touche s. Le workflow devient une commande réutilisable, stockée dans .claude/workflows/ du projet (partagée avec l’équipe via git) ou dans ~/.claude/workflows/ (personnelle). Disponible depuis Claude Code v2.1.154, sur tous les plans payants, ainsi que sur Amazon Bedrock, Google Cloud Vertex AI et Microsoft Foundry.

Comment choisir son niveau d’automatisation ?

Situation	Solution	Pourquoi
Tâche avec critère vérifiable clair (tests, lint, build)	/goal	Évaluateur indépendant, setup minimal, v2.1.139+
Tâche à grande échelle : dizaines à centaines d’agents nécessaires	Dynamic Workflow	Plan en code, jusqu’à 1 000 agents, résultats hors contexte
Réduire les interruptions d’approbation d’outils dans un tour	Auto mode	Approuve les outils dans le tour, ne relance pas de tour supplémentaire
Tâche récurrente planifiée (triage quotidien, vérifications nocturnes)	/loop ou /schedule	Déclenchement temporel, indépendant d’une session ouverte

 

Pour introduire graduellement ces patterns dans une équipe : commencez par /goal sur les tâches CI/CD qui ont déjà des critères vérifiables. C’est le terrain où les conditions se rédigent naturellement et où le bénéfice est immédiat. Passez aux Dynamic Workflows quand la tâche dépasse ce qu’un seul agent peut traiter en temps raisonnable : migrations larges, audits de codebase, recherches cross-sourcées.

Les deux primitives sont complémentaires. Un workflow peut déléguer des sous-tâches à des agents qui tournent eux-mêmes avec un goal. Et les deux s’appuient sur les mêmes outils : si vous avez déjà connecté vos serveurs via le protocole MCP, ils sont disponibles dans tous les agents du workflow sans configuration supplémentaire.

Un point à garder en tête : plus l’autonomie est grande, plus les erreurs peuvent prendre de l’ampleur. Un goal qui tourne 20 tours peut modifier beaucoup de fichiers avant que vous interveniez. Un workflow de plusieurs centaines d’agents encore plus. La sécurité des agents autonomes mérite une attention proportionnelle au niveau d’autonomie accordé : isolation des environnements, contrôle des permissions, surveillance des actions.

FAQ

Quelle est la différence concrète entre /goal et Auto mode ?

Auto mode approuve automatiquement les appels d’outils dans un tour, ce qui évite les interruptions pour chaque action de Claude. Mais il ne relance pas de nouveau tour quand Claude estime avoir terminé : l’agent s’arrête. /goal ajoute un évaluateur externe qui décide si le travail est réellement terminé et relance un tour si ce n’est pas le cas. En pratique, les deux se combinent : Auto mode pour les interruptions intra-tour, /goal pour les interruptions inter-tours.

Un Dynamic Workflow consomme combien de tokens ?

Significativement plus qu’une conversation classique, puisque chaque agent est facturé séparément. La documentation Claude Code recommande de tester sur un sous-ensemble (un répertoire plutôt que le repo entier, et sur une question précise plutôt que sur une question large) avant un « vrai » run complet. La vue /workflows affiche l’usage de chaque agent en temps réel, et vous pouvez arrêter le run à tout moment sans perdre le travail des agents déjà terminés.

Peut-on réutiliser un workflow qu’on a créé une fois ?

Oui. Depuis la vue /workflows, la touche s sauvegarde le script du run. Deux emplacements : .claude/workflows/ dans le projet (partagé avec l’équipe via git) ou ~/.claude/workflows/ dans le home directory (personnel, disponible dans tous les projets). Le workflow devient ensuite une commande accessible via l’autocomplete /, au même titre que /deep-research.

/goal fonctionne-t-il dans un pipeline CI/CD ?

Oui, via le mode non interactif : claude -p "/goal CHANGELOG.md has an entry for every PR merged this week". La boucle tourne jusqu’à la condition et s’arrête. C’est compatible avec les scripts automatisés sans interaction humaine, ce qui ouvre des cas d’usage pour les pipelines de vérification continue.

Lire l’article original : Getting started with loops →

Conclusion

La vraie question n’est pas « faut-il automatiser ? » mais « quel niveau d’autonomie conférer à cette tâche ? » /goal et les Dynamic Workflows donnent deux réponses à cette question, avec des compromis différents en termes de contrôle, de coût et de complexité. Depuis l’introduction des Dynamic Workflows avec Opus 4.8, le spectre d’automatisation disponible dans Claude Code s’étend du goal conditionnel au pipeline de centaines d’agents orchestrés. Ce qui change la donne, c’est la capacité à choisir le bon niveau selon la tâche, et à composer les deux quand les deux sont pertinents.