Claude Code Dynamic Workflows : orchestrer des agents IA

Le 28 mai 2026, Anthropic a livré Claude Code 2.1.154 avec une fonctionnalité qui change la façon dont le coding agentique passe à l'échelle : les dynamic workflows. Au lieu de dérouler une tâche difficile étape par étape, Claude écrit désormais son propre script d'orchestration et répartit le travail sur des dizaines à des centaines de sous-agents en arrière-plan dans une seule session.

Les dynamic workflows dans Claude Code sont des scripts d'orchestration JavaScript que Claude écrit pour une tâche que vous décrivez. Un runtime en arrière-plan exécute le script, coordonne de nombreux sous-agents en parallèle, conserve l'état intermédiaire dans des variables de script et vérifie les résultats avant qu'ils ne vous parviennent.

Cela ressemble à une petite mise à jour de la CLI. Ce n'en est pas une. Cela sort l'orchestration du tour de chat pour la placer dans le code — et pour les équipes qui font du coding agentique à l'échelle de production, cela change le calcul de capacité et de coût. Voici ce qui a réellement été livré, ce que cela signifie sur le plan architectural et comment un studio de développement devrait penser son adoption.

Ce que sont réellement les dynamic workflows

Un dynamic workflow est un script JavaScript qui orchestre des sous-agents à grande échelle ; Claude écrit le script pour la tâche que vous décrivez, et un runtime l'exécute en arrière-plan pendant que votre session reste réactive (Claude Code Docs).

La mécanique compte. Dans l'ancien modèle, une seule conversation coordonnait tout : chaque résultat de sous-agent revenait dans une fenêtre de contexte, et la fenêtre se remplissait vite. Les dynamic workflows inversent cela. La logique d'orchestration — boucles, branchements, décisions sur le nombre d'agents, passes de vérification — vit dans des variables de script, et la fenêtre de contexte du modèle ne reçoit que les résultats condensés (TechTimes). Le script tient l'état ; le modèle tient le jugement.

Selon Anthropic, Claude « écrit ses propres scripts d'orchestration, répartit le travail sur des dizaines à des centaines de sous-agents parallèles dans une seule session et vérifie ses propres résultats avant que quoi que ce soit ne vous parvienne » (Anthropic). La research preview prendrait en charge jusqu'à 1 000 sous-agents par workflow (Pasquale Pillitteri). Vous les déclenchez et les inspectez avec la nouvelle commande /workflows (Claude Code Changelog).

C'est le même glissement que nous avions signalé lorsque le cockpit multi-agents est arrivé dans Claude Code Agent View : l'unité de travail n'est plus un prompt, c'est une flotte coordonnée.

Pourquoi c'est un saut de paradigme, pas un patch

La contrainte que brisent les dynamic workflows est le goulet d'étranglement de la fenêtre de contexte unique — le plafond strict sur la quantité de travail parallèle qu'une seule conversation pouvait coordonner.

Avant les dynamic workflows, le nombre de sous-agents qu'une tâche pouvait utiliser était limité par ce qu'une seule conversation pouvait suivre. En déplaçant la coordination dans un script, Claude Code supprime ce plafond et permet à une session d'orchestrer des centaines d'agents à la fois.

Claude Code propose désormais trois primitives de collaboration distinctes — Dynamic Workflows, Subagents et Agent Teams — et choisir la bonne pour la structure de votre problème n'est plus un simple bonus (Ken Huang). Les Subagents gèrent la délégation bornée. Les Agent Teams gèrent la collaboration persistante basée sur les rôles. Les dynamic workflows gèrent le cas où une tâche a simplement besoin de plus d'agents qu'une conversation ne peut en coordonner.

Les affirmations sur l'échelle sont réelles, extrêmes au sommet. Un cas rapporté a vu un workflow générer 750 000 lignes de Rust en 11 jours — non reproductible sur tous les projets, mais un signal clair de l'endroit où se situe désormais le plafond (Pasquale Pillitteri). La formulation d'Anthropic est sans détour : un travail que vous planifieriez normalement en trimestres peut être terminé en jours (r/ClaudeAI).

Cela rejoint directement la thèse que nous avons défendue dans Le rapport 2026 d'Anthropic sur le coding agentique : l'ère de l'orchestration : le facteur différenciant n'est plus la qualité brute du modèle, c'est l'orchestration.

Les dynamic workflows sont arrivés avec Opus 4.8

Claude Code 2.1.154 n'a pas livré les dynamic workflows seuls — ils sont arrivés avec Claude Opus 4.8, qui passe désormais par défaut en high effort, avec /effort xhigh disponible pour les tâches les plus difficiles (Classmethod).

Le couplage est délibéré. Un modèle orchestrateur plus puissant qui écrit les scripts signifie de meilleures décisions sur le nombre d'agents et des passes de vérification plus serrées. Nous avons couvert le palier de modèle lui-même dans La prochaine vague d'Anthropic : Opus 4.8, Sonnet 4.8, Mythos ; la nouveauté ici, c'est ce que ce modèle fait désormais pour vous en arrière-plan.

Deux notes opérationnelles. Premièrement, le high effort par défaut change la consommation de tokens — budgétez-le. Deuxièmement, des versions de correction ont suivi rapidement après 2.1.154, y compris des correctifs concernant le comportement d'Opus 4.8, alors utilisez le dernier Claude Code plutôt que de vous figer sur la première version (Claude Code Changelog).

Le calcul de capacité et de coût change

Les dynamic workflows changent l'équation de coût autant que celle de capacité : des centaines d'agents parallèles augmentent le débit, mais aussi la facture si vous ne maîtrisez pas le nombre d'agents.

Les sous-agents parallèles augmentent à la fois la vitesse et le coût. Pour garder les dynamic workflows économiques, il faut maîtriser combien d'agents une tâche lance et vérifier les résultats à bas coût, plutôt que de laisser chaque tâche se déployer jusqu'à son nombre maximal d'agents.

L'analyse de coût des agents Claude Code montre que la vraie question n'est plus le prix d'une seule complétion, mais ce que coûtent réellement les sessions parallèles — et que les plus grandes économies viennent de l'adéquation entre le nombre d'agents et la structure de la tâche, pas de la réduction des capacités (CloudZero). C'est le même prisme du « coût par résultat accepté » que nous avons utilisé dans L'économie des tokens d'Anthropic.

Pour une agence, le glissement est structurel. Une facturation construite autour des heures de développeur s'accorde mal avec un outil qui comprime un trimestre de travail en jours. La position défendable est de facturer l'efficacité d'orchestration et les résultats vérifiés — ce qui ne fonctionne que si vous pouvez prouver que le résultat est correct.

Comment un studio de développement devrait l'adopter

Adoptez les dynamic workflows là où le travail est réellement parallèle et vérifiable — gros refactorings, génération de tests à grande échelle, migrations multi-fichiers — et gardez une porte d'approbation humaine sur tout ce qui touche à la logique métier centrale.

L'étape de vérification est tout le jeu. Anthropic a intégré l'auto-vérification dans le runtime du workflow, mais l'auto-vérification n'est pas la même chose que votre vérification. La discipline que nous avons défendue dans Le tokenmaxxing a besoin de reviewmaxxing s'applique encore plus durement : plus d'agents produisant plus de code signifie que le débit de revue, et non le débit de génération, devient le goulet d'étranglement.

Séquence pratique pour les équipes :

Commencez par des tâches bornées et parallèles. Génération de tests sur un module, montée de dépendance sur de nombreux fichiers, passe de documentation. Faciles à vérifier, faible rayon d'impact.
Utilisez les sessions en arrière-plan pour ne pas bloquer les humains. Vous listez les agents en cours avec /sessions et reprenez l'un d'eux avec /switch <session-id> (MindStudio).
Traitez les agents de longue durée comme des processus de longue durée. Les schémas pour les agents en arrière-plan dans Claude Code 2.1 ressemblent davantage à l'exploitation de services qu'à des tours de chat — l'observabilité et l'arrêt propre comptent (CallSphere).
Maîtrisez le nombre d'agents. Par défaut, la plus petite flotte qui résout la tâche ; réservez les exécutions à des centaines d'agents au travail prouvé parallèle.

Rien de tout cela n'est du vibe coding. C'est la discipline d'ingénierie que nous avons décrite dans L'ingénierie agentique n'est pas du vibe coding, désormais avec un rayon d'impact bien plus large.

Là où les dynamic workflows peuvent déraper

Le mode de défaillance n'est pas le mauvais code — c'est du code non révisable à un volume pour lequel aucune équipe humaine n'était dimensionnée, produit plus vite que votre processus de revue ne peut l'absorber.

Le principal risque des dynamic workflows est que le volume dépasse la vérification. Des centaines d'agents peuvent générer plus de changements en une journée qu'une équipe ne peut en réviser utilement, si bien que la contrainte passe de la vitesse d'écriture du code à la vitesse à laquelle on peut lui faire confiance.

Trois pièges méritent d'être anticipés avant d'activer cela dans une base de code client. Le premier est la dette de revue. Quand un workflow livre un grand ensemble de changements coordonnés, la tentation est de faire confiance à l'auto-vérification du runtime et de merger. L'auto-vérification attrape les erreurs mécaniques — tests qui échouent, builds cassés — mais elle n'attrape pas une implémentation correcte en apparence de la mauvaise exigence. Ce jugement doit rester le vôtre.

Le deuxième est l'observabilité. Les sessions en arrière-plan s'exécutent indépendamment de votre chat, c'est le but, mais cela signifie aussi qu'un workflow peut tourner longtemps avant que vous ne remarquiez qu'il a déraillé. Les schémas qui émergent autour des agents en arrière-plan dans Claude Code 2.1 ressemblent davantage à l'exploitation de services de longue durée qu'à l'envoi de messages de chat — vous voulez du logging, des vérifications d'état et un arrêt propre, pas une confiance aveugle (CallSphere). Savoir lister et reprendre les sessions avec /sessions et /switch est le minimum, pas la ligne d'arrivée.

Le troisième est la surprise de coût. Un workflow qui passe par défaut à son nombre maximal d'agents sur une tâche qui n'en avait pas besoin brûle du budget sans valeur ajoutée. Choisir la plus petite flotte qui résout réellement le problème est à la fois une décision d'architecture et une décision financière. Les studios qui traitent ces trois points comme des exigences d'ingénierie centrales, et non comme des après-coups, sont ceux qui mettent les dynamic workflows en production sans regret.

FAQ

**Que sont les dynamic workflows dans Claude Code ?** Les dynamic workflows sont des scripts d'orchestration JavaScript que Claude écrit pour une tâche. Un runtime en arrière-plan exécute de nombreux sous-agents en parallèle, conserve l'état intermédiaire dans des variables de script et renvoie un résultat vérifié et coordonné ([Claude Code Docs](https://code.claude.com/docs/en/workflows)).

Combien de sous-agents un dynamic workflow peut-il utiliser ? Anthropic décrit des dizaines à des centaines de sous-agents parallèles par session, et la research preview prendrait en charge jusqu'à 1 000 (Anthropic).

En quoi les dynamic workflows diffèrent-ils des subagents et des agent teams ? Ce sont trois primitives distinctes : les subagents pour la délégation bornée, les agent teams pour le travail persistant basé sur les rôles, et les dynamic workflows pour les tâches nécessitant plus d'agents qu'une conversation ne peut en coordonner (Ken Huang).

Quelle version de Claude Code a introduit les dynamic workflows ? Claude Code 2.1.154, livrée le 28 mai 2026, avec Claude Opus 4.8 (Classmethod).

Les dynamic workflows coûtent-ils plus cher ? Cela peut arriver. Des centaines d'agents parallèles augmentent le débit et la facture ; les économies viennent de l'adéquation entre le nombre d'agents et la structure de la tâche (CloudZero).

En résumé

Les dynamic workflows sont le premier vrai saut de paradigme dans Claude Code depuis les subagents, car l'orchestration vit désormais dans le code plutôt que dans le tour de chat. Les équipes qui gagneront avec cela ne seront pas celles qui lancent le plus d'agents — ce seront celles qui ont la discipline de vérification pour faire confiance à ce qui revient. Si vous mettez à l'échelle le coding agentique et voulez une orchestration bâtie sur des portes de revue plutôt que sur un débit aveugle, c'est précisément le travail d'ingénierie que nous faisons chez Context Studios.