Dynamic Workflows et /goal Claude Code : orchestrer
Claude Code propose désormais deux modes d’orchestration distincts : la commande /goal, qui fait boucler un agent jusqu’à atteindre une condition mesurable, et les Dynamic Workflows, où Claude écrit un script d’orchestration lançant plusieurs sous-agents en parallèle. Le premier travaille en profondeur (depth-first), le second en largeur (width-first).
Ces deux nouveautés répondent à un problème récurrent du codage agentique : la tendance de l’agent à s’arrêter trop tôt ou à traiter les tâches une par une. J’ai testé les deux sur un projet réel, et la distinction depth-first / width-first change concrètement la façon de découper un travail. Selon la documentation d’Anthropic, un Dynamic Workflow peut orchestrer des « dizaines à centaines de sous-agents parallèles » dans une seule session.
/goal : la boucle autonome jusqu’à l’objectif (depth-first)
La commande /goal définit un objectif persistant et laisse Claude Code itérer seul jusqu’à ce que cet objectif soit atteint. C’est la boucle agentique dans sa forme la plus pure : un seul agent, une seule tâche, plusieurs passages successifs.
Le fonctionnement est simple. Vous saisissez /goal suivi d’une condition vérifiable, et Claude entre dans une boucle : il évalue où en sont les choses, exécute une action, vérifie si l’objectif est rempli, puis recommence si ce n’est pas le cas. La boucle s’arrête d’elle-même une fois la condition remplie.
La boucle depth-first de /goal : un seul agent tourne jusqu’à ce que l’objectif binaire soit atteint.
À quoi sert le mode depth-first
Le /goal excelle sur les tâches séquentielles où chaque étape dépend de la précédente. Faire passer une suite de tests, atteindre 100 % de couverture, corriger toutes les erreurs de lint : autant de cas où l’agent doit boucler, corriger, revérifier.
Ce mode combat directement ce que la communauté appelle la « paresse agentique » — l’agent qui déclare une tâche terminée alors qu’il reste des cas non traités. Avec /goal, la condition de sortie est explicite : tant que les tests échouent, la boucle continue. Addy Osmani a baptisé cette approche « loop engineering » en juin 2026, marquant un glissement du prompt engineering vers la construction de cycles d’exécution autonomes.
La règle d’or : un objectif binaire
Pour que la boucle converge, l’objectif doit être mesurable et binaire. « Améliore le code » ne fonctionne pas : Claude ne sait pas quand s’arrêter. « Fais passer tous les tests de tests/ » fonctionne, car la condition est vérifiable par un outil (compilateur, linter, suite de tests).
Le coût suit le nombre d’itérations. Une tâche qui demande 20 cycles coûte environ 20 fois un prompt unique. C’est le prix de la persistance : /goal ne lâche pas tant que la cible n’est pas atteinte. Pour ajuster la profondeur de raisonnement de chaque itération, vous pouvez combiner cette approche avec les 5 niveaux d’Effort Control de Claude.
Dynamic Workflows : l’orchestration parallèle (width-first)
Les Dynamic Workflows adoptent la logique inverse : au lieu de creuser un problème, ils l’étalent. Claude écrit dynamiquement un script d’orchestration en JavaScript qui répartit le travail entre plusieurs sous-agents s’exécutant en parallèle, chacun avec sa propre fenêtre de contexte.
Anthropic décrit le mécanisme ainsi : Claude « écrit des scripts d’orchestration qui lancent des dizaines à des centaines de sous-agents parallèles dans une seule session, en vérifiant son travail avant que quoi que ce soit ne vous parvienne ». L’orchestrateur découpe la tâche, distribue les sous-tâches, puis contrôle et fusionne les résultats.
L’orchestrateur distribue le travail à jusqu’à 16 sous-agents concurrents (cap 1 000 par workflow), puis vérifie et fusionne leurs résultats.
L’architecture orchestrateur / sous-agents
Un agent de haut niveau — l’orchestrateur — décompose le problème en sous-tâches indépendantes et les confie à des sous-agents. Ces sous-agents tournent en parallèle en arrière-plan, pendant que votre session principale reste réactive. Leurs résultats remontent ensuite vers l’orchestrateur, qui les vérifie avant de les intégrer.
Selon les rapports de lancement, Claude Code exécute jusqu’à 16 sous-agents concurrents à un instant donné, avec un plafond global pouvant atteindre 1 000 sous-agents sur l’ensemble d’un workflow. Chaque sous-agent reçoit un contexte propre et ciblé, ce qui évite la pollution de contexte typique d’une longue session monolithique.
Persistance et reprise
Les Dynamic Workflows sont pensés pour des travaux longs, qui peuvent s’étendre sur des heures voire des jours. La progression est sauvegardée au fil de l’exécution : un job interrompu reprend là où il s’était arrêté, sans repartir de zéro.
Cette logique d’exécution asynchrone en arrière-plan rappelle les Routines Claude Code, qui automatisent des tâches sans serveur, et les Managed Agents d’Anthropic pour les agents autonomes dans le cloud. La différence : ici, l’orchestration se déroule au sein de votre session Claude Code, pilotée par un script que Claude génère à la volée.
Depth-first contre width-first : /goal creuse une tâche en profondeur, les Dynamic Workflows l’étalent sur des sous-agents parallèles.
/goal ou Dynamic Workflows : le tableau de décision
Le choix dépend de la nature de votre tâche. Si les étapes sont interdépendantes, choisissez /goal. Si elles sont indépendantes et parallélisables, choisissez les Dynamic Workflows.
| Critère | /goal (depth-first) | Dynamic Workflows (width-first) |
|---|---|---|
| Type de tâche | Étapes séquentielles interdépendantes | Sous-tâches indépendantes, parallélisables |
| Nombre d’agents | Un seul agent qui boucle | Jusqu’à 16 concurrents, cap 1 000 par workflow |
| Vitesse | Limitée par le séquentiel | Compresse fortement le temps réel |
| Complexité de mise en place | Minimale (une commande) | Nécessite une décomposition en sous-tâches |
| Condition de sortie | Objectif binaire vérifiable | Fusion des résultats vérifiés |
| Coût en tokens | Proportionnel au nombre d’itérations | Élevé (contexte par sous-agent) |
Les deux modes ne s’excluent pas. Un pattern fréquent consiste à utiliser un orchestrateur Dynamic Workflow qui distribue des sous-tâches, chaque worker exécutant ensuite une boucle de type /goal jusqu’à son propre objectif. Vous cumulez alors largeur et profondeur.
Exemple concret : auditer la sécurité d’une codebase
Prenons un cas parlant : l’audit de sécurité d’une base de code de 40 modules. La même mission se traite de deux façons radicalement différentes selon le mode choisi.
Version /goal (linéaire)
Avec /goal, vous formulez : /goal audite chaque module pour les injections SQL, XSS et secrets exposés, et corrige jusqu'à ce que le scanner ne remonte plus aucune alerte critique. Claude parcourt les modules l’un après l’autre, corrige, relance le scanner, et boucle tant qu’il reste des vulnérabilités critiques.
Cette approche est robuste sur la convergence — la condition de sortie est nette — mais lente : les 40 modules sont traités en série. Sur une grosse codebase, l’audit peut prendre des heures.
Version Dynamic Workflow (parallèle)
Avec un Dynamic Workflow, vous demandez : Crée un dynamic workflow qui audite la sécurité de chaque module en parallèle. Claude écrit un script d’orchestration qui assigne un sous-agent par module (ou par lot de modules), dans la limite de 16 agents concurrents. Chaque sous-agent analyse son périmètre isolément, puis l’orchestrateur agrège les rapports et vérifie les résultats.
Le gain est le temps réel : 40 audits menés en parallèle par vagues de 16 se terminent bien plus vite qu’en série. Le revers est le coût en tokens, chaque sous-agent consommant sa propre fenêtre de contexte. Pour ce type de mission, je recommande de croiser cette lecture avec notre guide de sécurité pour Claude Code afin de cadrer les permissions des agents.
Prérequis et activation
Les Dynamic Workflows exigent Claude Code v2.1.154 ou une version ultérieure. Vérifiez la vôtre avec claude --version et mettez à jour si nécessaire. La fonctionnalité couvre le CLI, l’application desktop et l’extension VS Code.
Côté plans, elle est disponible sur Pro, Max, Team et Enterprise avec Claude Code activé, ainsi que via l’API Claude, Amazon Bedrock, Vertex AI et Microsoft Foundry. Pour déclencher un workflow, deux méthodes : demander explicitement « Crée un dynamic workflow », ou activer le réglage ultracode depuis le menu d’effort — ce qui règle l’effort sur xhigh et pousse Claude à orchestrer en largeur.
La commande /goal, elle, ne demande aucune configuration particulière : elle fonctionne dès que vous disposez de Claude Code, aux côtés des autres primitives de boucle comme /loop et /schedule. Pour installer et prendre en main l’outil, notre guide complet de Claude Code détaille chaque étape.
Mon avis
Mon verdict : /goal et les Dynamic Workflows ne sont pas concurrents, ce sont deux outils complémentaires. Réservez /goal aux tâches où la convergence prime — tests, refactors, corrections de bugs — et les Dynamic Workflows aux tâches massivement parallélisables comme les audits, les migrations multi-fichiers ou les analyses par module.
Le point de vigilance reste le coût. Un Dynamic Workflow qui lance des dizaines de sous-agents consomme vite, et le mode ultracode amplifie la dépense. Commencez toujours par un périmètre restreint, mesurez la consommation, puis passez à l’échelle. Pour les développeurs francophones, ces deux primitives placent Claude Code parmi les outils d’orchestration agentique les plus aboutis de 2026 — à condition de choisir le bon mode pour la bonne tâche.
Sources : documentation Claude Code (code.claude.com), blog Claude « Introducing dynamic workflows », MindStudio, TechTimes (juillet 2026).