Anthropic a lancé les dynamic workflows dans Claude Code le 28 mai 2026 avec Claude Opus 4.8. Le principe : au lieu qu'un seul agent traite une tâche en série, Claude génère un plan d'orchestration et déploie des dizaines à des centaines de sous-agents en parallèle, avec des agents adverses chargés de vérifier et réfuter les résultats avant restitution. C'est une capacité inédite dans un outil de coding IA grand public. Ce que cela change concrètement pour une équipe technique, comment ça fonctionne, quand c'est utile et quand c'est excessif : voici le décryptage pragmatique.
Ce que sont vraiment les dynamic workflows
Avant les dynamic workflows, Claude Code fonctionnait comme un agent unique : il recevait une instruction, utilisait des outils (lecture/écriture de fichiers, exécution de commandes, appels API), progressait pas à pas et revenait à l'utilisateur pour validation ou question. Utile, mais structurellement linéaire.
Les dynamic workflows cassent cette linéarité. Claude ne travaille plus seul, pas à pas : il planifie d'abord une architecture d'orchestration, puis délègue des sous-tâches à des dizaines voire des centaines d'agents qui s'exécutent en parallèle dans la même session. Chaque agent a un périmètre précis, travaille indépendamment des autres, et voit ses résultats soumis à des agents de vérification adverses avant d'être intégrés.
C'est ce que Ken Takao, Lead Systems Engineer chez Anthropic, résume ainsi : les dynamic workflows comblent le vide entre lancer un seul sous-agent et construire une équipe d'agents complète. Ce vide était, jusqu'ici, le principal obstacle pour traiter des tâches d'ingénierie vraiment à grande échelle.
Research preview
Les dynamic workflows sont disponibles en research preview depuis le 28 mai 2026 avec Claude Opus 4.8. La fonctionnalité est en cours de stabilisation. Pour les usages en production critique, anticiper des évolutions d'interface et de comportement dans les semaines à venir.
Pour comprendre pourquoi c'est différent des workflows classiques comme ceux que l'on construit dans n8n ou Make, notre article sur workflows et agents IA : quand utiliser l'un ou l'autre pose la distinction de fond.
Comment fonctionne l'orchestration en pratique
La boucle d'un dynamic workflow suit toujours le même schéma en quatre temps.
Étape 1 : génération du plan
Claude analyse la tâche demandée et produit un plan d'orchestration explicite : quelles sous-tâches, dans quel ordre ou en quelle parallélisation, quelles dépendances entre les résultats. Ce plan est visible par l'utilisateur avant l'exécution si l'activation manuelle est choisie.
Étape 2 : déploiement des sous-agents en parallèle
Les sous-agents sont lancés simultanément dans la même session. Chacun a un contexte ciblé, des outils adaptés à sa sous-tâche et un objectif précis. La coordination se déroule hors de la conversation principale : l'utilisateur n'est pas noyé dans les échanges intermédiaires. La progression est sauvegardée en continu, ce qui permet de reprendre après une interruption sans tout recommencer.
Étape 3 : vérification adverse
Des agents indépendants reçoivent les résultats et ont pour mission explicite de les réfuter ou valider : chercher les erreurs, tester les cas limites, détecter les régressions. C'est le principe du red teaming appliqué à l'orchestration d'agents. Si un résultat est rejeté, la boucle repart sur la sous-tâche concernée.
Étape 4 : convergence et restitution
Le système itère jusqu'à ce que l'ensemble des sous-tâches passe la validation adverse. Claude restitue ensuite un résultat consolidé, avec un rapport de progression si la tâche était longue. Les tâches qui s'étendent sur plusieurs heures ou plusieurs jours bénéficient de cette reprise automatique.
Ce mécanisme est analogue à ce que des équipes d'ingénierie structurent manuellement via des revues de code, des CI/CD et des tests automatisés. La différence : ici, tout le cycle se passe dans une session Claude Code, sans outillage supplémentaire à configurer.
Comment activer et configurer les dynamic workflows
Deux modes d'activation sont disponibles.
Mode explicite : vous demandez directement à Claude de créer un workflow pour la tâche. Exemple : "Crée un workflow pour migrer tous les appels à l'API v1 vers l'API v2 dans le dépôt." Claude présente son plan et attend votre validation avant de lancer les agents. C'est le mode recommandé pour se familiariser avec la fonctionnalité et garder le contrôle sur ce qui est exécuté.
Mode ultracode (effort xhigh) : en activant le réglage ultracode dans Claude Code, vous laissez Claude juger lui-même quand une tâche mérite un workflow. Il peut alors décider seul de déployer des agents parallèles si la tâche dépasse un certain seuil de complexité. Ce mode est pratique pour des usages avancés, mais il augmente la consommation de tokens de façon non déterministe.
Règles de gouvernance
Le premier déclenchement d'un dynamic workflow demande toujours une confirmation utilisateur. Les administrateurs d'organisation peuvent désactiver la fonctionnalité au niveau du compte. La disponibilité par plan : activé par défaut sur Max et Team, activation requise par un admin sur Enterprise.
Les dynamic workflows fonctionnent sur l'ensemble de l'écosystème Claude Code : CLI, application Desktop, extension VS Code, API Claude directe, Amazon Bedrock, Google Vertex AI et Microsoft Foundry. Pas besoin de changer d'environnement selon la plateforme que vous utilisez déjà.
Vous évaluez Claude Code pour votre équipe d'ingénierie ?
On construit un test sur votre base de code et on mesure ce que les dynamic workflows apportent réellement avant de les déployer.
Cas d'usage entreprise : ce pour quoi c'est fait
Les dynamic workflows ne sont pas un assistant IA généraliste amélioré. Ils sont pensés pour un profil précis de tâches : volume élevé, parallélisable, avec un risque d'erreur qui justifie une vérification indépendante.
Migrations massives de code
C'est le cas d'usage le plus direct. Changer de framework sur une base de code de plusieurs dizaines de milliers de lignes, porter un service d'une version de langage à une autre, mettre à jour des centaines d'appels à une API dépréciée : toutes ces tâches sont répétitives, parallélisables par fichier ou par module, et critiques (une erreur de migration peut passer inaperçue pendant des mois).
Avec un workflow, Claude cartographie d'abord les dépendances, génère les transformations en parallèle et soumet chaque fichier modifié à une validation croisée avant de l'intégrer. Ce qui prendrait des semaines à une équipe en revue manuelle peut être cadré et exécuté en quelques jours.
Audits de dépôt à grande échelle
Alessio Vallero, Senior Engineering Manager chez Klarna, le formule directement : les dynamic workflows sont très utiles pour la découverte et la revue sur de grandes bases de code, et aident les ingénieurs à aller plus vite sur la maintenance et le refactoring.
Concrètement : audit de sécurité sur tout un dépôt (détection de secrets exposés, d'injections potentielles, de dépendances vulnérables), chasse aux bugs systémique avec vérification croisée, détection de code mort sur une base historique volumineuse. Ce sont des tâches pour lesquelles un agent unique atteint ses limites de contexte, et qu'une équipe humaine ne peut pas traiter exhaustivement sans outils dédiés.
Travaux critiques nécessitant une vérification adverse
Certaines tâches ne se contentent pas de "probablement juste". Un port de langage qui va en production, une refonte d'architecture de base de données, un changement de bibliothèque cryptographique : l'erreur a des conséquences élevées et le résultat doit être vérifié de façon indépendante, pas juste relu par le même agent qui l'a produit.
C'est exactement le rôle des agents adverses dans un dynamic workflow : ils n'ont pas accès à la logique du premier agent, ils partent du résultat et cherchent à le mettre en défaut. C'est une forme de séparation des responsabilités appliquée à l'IA.
Pour aller plus loin sur la logique d'orchestration multi-agents, notre article sur les agents IA autonomes face aux chatbots développe les fondements utiles à un décideur.
L'exemple Bun : 750 000 lignes de Rust en onze jours
L'exemple de référence publié par Anthropic au lancement est la migration de Bun (runtime JavaScript haute performance) du langage Zig vers Rust, réalisée par Jarred Sumner avec les dynamic workflows.
Les chiffres publiés :
- Environ 750 000 lignes de Rust générées
- 99,8 % de compatibilité avec la suite de tests existante
- Du premier commit au merge : onze jours
Le projet a mobilisé plusieurs workflows parallèles successifs, chacun avec un objectif précis :
- Un workflow de cartographie des lifetimes Rust (gestion mémoire propre au langage)
- Un workflow de génération des fichiers .rs avec relecteurs indépendants sur chaque module
- Une boucle de correction en continu sur les erreurs de build et les tests en échec
- Un workflow d'optimisation nocturne lancé pendant les heures creuses
Mise en perspective
Bun est un projet open source de référence, porté par un ingénieur très expérimenté dans les deux langages cibles. Un résultat comparable sur une base de code interne d'entreprise nécessite une supervision humaine active, un jeu de tests solide en amont et un découpage de périmètre rigoureux. L'outillage amplifie la productivité d'une bonne équipe ; il ne remplace pas l'expertise métier du domaine.
Ce que cet exemple montre surtout : la valeur des dynamic workflows n'est pas dans la vitesse brute de génération de code, mais dans la capacité à maintenir la cohérence et à détecter les erreurs à l'échelle du projet entier, pas fichier par fichier.
Le coût réel en tokens : ce qu'il faut anticiper
Anthropic est explicite sur ce point et il serait malhonnête de le minimiser : les dynamic workflows consomment beaucoup plus de tokens qu'une session classique. Lancer des dizaines à des centaines d'agents en parallèle, c'est autant de contextes initialisés, de raisonnements lancés et de résultats échangés entre agents.
Quelques repères pour calibrer :
- Une session Claude Code classique sur une tâche de refactoring ciblée : quelques milliers à quelques dizaines de milliers de tokens.
- Un dynamic workflow sur un audit de dépôt de taille moyenne : plusieurs millions de tokens selon la taille du dépôt et le nombre d'agents.
- Un workflow de migration à grande échelle sur plusieurs jours : potentiellement des dizaines de millions de tokens.
Avec le tarif d'Opus 4.8 (5 dollars par million de tokens en entrée, 25 dollars par million en sortie), un workflow de plusieurs millions de tokens représente une facture de l'ordre de la centaine à quelques centaines de dollars selon les volumes. Ce n'est pas négligeable, mais c'est à comparer au coût d'une ou plusieurs semaines d'ingénieur sur la même tâche.
La recommandation d'Anthropic est claire : commencer par des tâches bien cadrées et mesurer la consommation avant de monter en échelle. Le mode ultracode en particulier peut déclencher des workflows inattendus sur des tâches que vous considériez simples.
Pour replacer ce poste de coût dans une vision globale des dépenses IA, notre article sur le coût d'un projet IA en PME en 2026 donne la grille complète des postes budgétaires à anticiper.
Vous pilotez les coûts IA de votre organisation ?
On cadre l'architecture, on dimensionne la consommation de tokens et on vous donne une estimation réaliste avant de lancer.
Pertinent ou overkill : la grille de décision
Les dynamic workflows ne sont pas la bonne réponse à tous les problèmes d'ingénierie. Voici la grille pour décider si la fonctionnalité est adaptée à votre situation.
| Situation | Dynamic workflow | Approche recommandée à la place |
|---|---|---|
| Migration de framework sur 50 000 lignes ou plus | Pertinent | S/O |
| Audit sécurité sur tout un dépôt | Pertinent | S/O |
| Refactoring critique nécessitant vérification indépendante | Pertinent | S/O |
| Correction d'un bug sur un fichier unique | Overkill | Session Claude Code standard |
| Assistant IA interne sur vos documents | Overkill | RAG avec un LLM adapté |
| Automatisation d'un processus métier répétitif | Overkill | Workflow n8n / Make avec un agent simple |
| Extraction et traitement de documents à grande échelle | Overkill | Pipeline de traitement par lots avec un modèle léger |
Le signal le plus clair : si votre tâche peut être découpée en sous-tâches identiques et parallélisables sur un grand volume, et si une erreur dans une sous-tâche a des conséquences sérieuses, les dynamic workflows sont dans leur zone de valeur. Si la tâche est ponctuelle, de taille modeste ou ne nécessite pas de vérification adverse, une session standard ou un agent classique sera plus rapide et moins coûteux.
Pour les usages IA courants d'une PME (assistant documentaire, traitement de données, automatisation de processus), l'approche RAG reste la voie la plus directe et la plus maîtrisable. Notre article sur l'agentic RAG et la retrieval augmented generation détaille pourquoi.
Et si vous cherchez à évaluer plusieurs options de modèles et d'architectures avant de décider, le guide pour évaluer un LLM en entreprise avec les bonnes métriques propose une méthode pratique.
Les dynamic workflows s'inscrivent dans la trajectoire plus large d'Opus 4.8, dont les capacités agentiques (69,2 % sur SWE-Bench Pro) et l'architecture multi-niveaux d'effort font le socle. Pour le portrait complet du modèle, l'article Claude Opus 4.8 : ce que le nouveau modèle change pour votre entreprise couvre l'ensemble des évolutions.
Questions fréquentes
Pour aller plus loin
- Claude Opus 4.8 pour votre entreprise : le portrait complet du modèle qui embarque les dynamic workflows, avec benchmarks, fast mode et niveaux d'effort.
- Workflows IA ou agents IA : quand choisir l'un ou l'autre : la distinction fondamentale entre orchestration déterministe et autonomie agentique.
- Agents IA autonomes face aux chatbots en PME : comprendre la logique d'orchestration d'agents avant de se lancer.
- Agentic RAG et retrieval augmented generation : l'architecture la plus adaptée pour les usages documentaires en entreprise.
- Évaluer un LLM en entreprise avec les bonnes métriques : méthode pour tester les dynamic workflows sur vos propres données avant de les déployer.
- Coût d'un projet IA en PME en 2026 : pour replacer la facture en tokens des dynamic workflows dans un budget projet complet.
