Claude Code vient de recevoir une nouveauté qui mérite clairement un onglet ouvert dans ton cerveau. Elle s’appelle Dynamic Workflows, elle arrive dans la semaine du 25 au 29 mai 2026, et elle change la manière de lancer de gros chantiers avec des agents IA.
Jusqu’ici, quand tu voulais faire bosser Claude Code sur une grosse mission, tu avais surtout deux choix. Tu restais dans une conversation longue avec quelques sous agents, ou tu découpais toi même le travail en plusieurs sessions. Ça marche, mais ça devient vite pénible quand le sujet grossit. Audit complet d’un dépôt, migration de dizaines de fichiers, recherche croisée, plan de refonte, chasse aux bugs dans plusieurs modules, tout ça peut vite dépasser le petit run tranquille.
Les Dynamic Workflows ajoutent une troisième voie. Claude écrit un script JavaScript qui pilote beaucoup de sous agents en arrière plan. Le script garde le plan, les boucles, les résultats intermédiaires et les vérifications. Ta session principale reste plus lisible, avec moins de contexte brûlé pour stocker chaque détail. Dit plus simplement, tu ne demandes plus seulement à Claude de réfléchir plus fort. Tu lui demandes d’organiser le chantier.
- Dynamic Workflows est arrivé dans Claude Code fin mai 2026.
- La fonction demande Claude Code v2.1.154 ou une version plus récente.
- Elle sert à piloter beaucoup de sous agents depuis un script.
- Elle vise les audits, migrations, recherches croisées et plans complexes.
- Si ton compte affiche Dynamic workflows dans
/config, tu peux l’activer depuis là.
Ce qui change avec Dynamic Workflows
Le point le plus malin, ce n’est pas seulement le nombre de sous agents. Le vrai changement, c’est l’endroit où vit le plan. Dans une session classique, Claude garde beaucoup de choses dans le contexte de conversation. Il délègue, récupère des résumés, relance, compare, puis continue. Plus la mission dure, plus ce contexte devient chargé.
Avec un workflow dynamique, le plan part dans un script. Claude Code écrit ce script à partir de ta demande, puis le runtime l’exécute en tâche de fond. Le script peut lancer des agents, garder des variables, comparer les résultats, recommencer une passe, faire relire une conclusion par un autre agent, puis remonter un résultat final beaucoup plus propre.
Tu gagnes surtout sur les missions où une seule conversation devient trop serrée. Un audit sécurité sur tout un dépôt. Une migration de composants. Une analyse de dépendances. Une recherche technique où plusieurs sources doivent être vérifiées par des agents séparés. Une refonte qui demande plusieurs plans avant de choisir la meilleure route.
Ce n’est pas un bouton magique. C’est plutôt un moyen de forcer Claude Code à travailler avec une structure plus nette. Si tu as déjà lu notre article sur les réglages Claude Code avant un gros run, tu vois bien le lien. Plus le run est large, plus le cadre doit être carré dès le départ.
Pourquoi c’est utile pour les gros projets
Quand un agent travaille seul, il peut finir par se noyer dans ses propres notes. Il ouvre des fichiers, garde des hypothèses, corrige une piste, revient sur une autre, puis mélange un peu tout. Ça ne veut pas dire que le résultat sera mauvais. Ça veut dire que tu dois souvent relire beaucoup de bruit pour comprendre ce qui s’est passé.
Un workflow dynamique évite une partie de ce bruit. Le script peut séparer les rôles. Un agent inspecte les routes. Un autre lit les tests. Un autre vérifie les composants. Un autre cherche les risques de régression. Le résultat ne part pas directement dans ta réponse finale. Il peut être recoupé avant de revenir vers toi.
Le gros bonus, c’est la répétition. Si Claude écrit un bon workflow pour auditer un module, tu peux le relire, le garder, puis le relancer plus tard. C’est beaucoup plus propre qu’une énorme conversation qu’on ne sait jamais vraiment reproduire. Pour les projets qui bougent souvent, ce côté réutilisable peut vite faire gagner du temps.
Le bon réflexe avant de l’activer
Avant de cliquer partout, vérifie ta version. La doc annonce Claude Code v2.1.154 ou une version plus récente. Si ton installation traîne sur une version plus ancienne, commence par mettre à jour. Côté disponibilité, Max et Team sont annoncés comme actifs par défaut. Sur Enterprise, l’admin peut l’activer. Si ton compte affiche la ligne Dynamic workflows dans /config, tu peux l’activer depuis là.
Ensuite, garde un point en tête. Dynamic Workflows est encore présenté comme une research preview. Donc tu le testes d’abord sur une mission contrôlée. Pas sur une migration sauvage de 500 fichiers dès le premier run. Tu prends un dossier, une question claire, un résultat attendu, puis tu regardes comment Claude découpe le script.
Tu dois aussi lire le script avant de le lancer sur un projet sensible. C’est du JavaScript qui orchestre des agents. Même si Claude le génère, tu restes responsable des commandes, des fichiers touchés et du périmètre. Sur un dépôt client, retire les secrets, limite les permissions, travaille sur une branche dédiée et garde une commande de test claire.
Quand choisir un workflow au lieu d’un sous agent
Les sous agents restent très pratiques. Si tu veux demander à un agent de lire une doc pendant que tu continues ton prompt principal, pas besoin de workflow. Si tu veux qu’un reviewer inspecte un patch pendant que tu écris la suite, pareil. Un sous agent suffit.
Le workflow prend son sens quand tu veux une orchestration. Il ne s’agit pas seulement de lancer plusieurs travailleurs. Il s’agit de leur donner un ordre, une méthode, un passage de relais et parfois une vérification croisée. Le script devient le chef de file du run.
| Besoin | Option plus adaptée | Pourquoi |
|---|---|---|
| Lire une doc à côté | Sous agent | La tâche reste courte |
| Comparer trois pistes de refonte | Dynamic Workflow | Le résultat gagne à être recoupé |
| Auditer tout un dépôt | Dynamic Workflow | Le travail doit être découpé et suivi |
| Corriger un bug localisé | Session classique | Le périmètre est assez petit |
| Migrer plusieurs familles de fichiers | Dynamic Workflow | La répétition doit rester contrôlée |
Le prompt simple pour démarrer proprement
Le meilleur départ, c’est une demande courte avec un résultat mesurable. Tu ne veux pas lancer un workflow sur une consigne floue. Tu veux que Claude comprenne le périmètre, les fichiers à ignorer, les contraintes de sécurité et le format de sortie.
Tu peux partir sur une demande de ce style.
Crée un Dynamic Workflow pour auditer le dossier src/components.
Objectif, repérer les composants non testés et les props incohérentes.
Ne modifie aucun fichier.
Chaque sous agent doit inspecter une zone différente.
Le résultat final doit contenir les risques, les fichiers concernés et une priorité.Ce prompt évite trois pièges. Il limite le dossier, il interdit les modifications, et il demande une sortie relisable. Une fois que le premier workflow est propre, tu peux autoriser une passe plus large ou une correction ciblée. Pas l’inverse.
Les erreurs qui peuvent te coûter du temps
Première erreur, confondre workflow et effort maximum. Monter l’effort peut aider un raisonnement difficile, mais un workflow sert surtout à structurer le travail. Si ta mission est mal cadrée, tu obtiens seulement un bazar plus organisé en apparence.
Deuxième erreur, oublier le coût et la durée. Beaucoup de sous agents peuvent consommer plus de tokens qu’une session classique. Ce n’est pas grave si le résultat remplace plusieurs heures de tri manuel. Ça devient pénible si tu lances ça pour une question qui tenait en cinq minutes.
Troisième erreur, laisser le workflow écrire partout. Sur un gros dépôt, tu dois séparer lecture, rapport et patch. D’abord le diagnostic. Ensuite la correction. Puis les tests. Ce rythme paraît plus lent, mais il évite le patch géant impossible à relire.
Quatrième erreur, ignorer la carte du projet. Un workflow dynamique devient bien plus fiable si Claude sait où chercher. Notre article sur SigMap et la carte compacte pour agents IA va dans le même sens. Plus l’agent reçoit une orientation propre, moins il brûle son contexte au démarrage.
Mes idées de workflows à tester cette semaine
Tu peux commencer avec un audit de tests manquants. Un agent liste les composants. Un autre lit les tests. Un autre compare les props et les cas limites. Le workflow te rend une liste de fichiers à traiter avec une priorité. C’est concret et facile à vérifier.
Tu peux aussi tester une revue de migration. Par exemple, repérer les anciens appels API, les hooks maison obsolètes, les composants qui n’utilisent pas encore le design system ou les pages qui gardent une ancienne logique de formulaire. Le workflow peut découper par dossier et faire une synthèse propre.
Pour la recherche technique, l’usage est encore plus évident. Tu peux demander plusieurs angles indépendants, puis une passe finale qui compare les contradictions. C’est utile quand tu dois choisir une librairie, préparer une refonte ou valider une option d’architecture avant de toucher au code.
Mon avis
Dynamic Workflows n’est pas la fonction à activer pour chaque petit bug. Sur une correction locale, ça ferait trop. Par contre, pour les gros chantiers avec agents IA, c’est exactement le genre d’outil qui manquait. Il met le plan dans un script, garde la session plus propre et rend le travail plus facile à relancer.
Si tu utilises déjà Claude Code, teste cette nouveauté sur un dossier en lecture seule. Regarde le script produit, le nombre d’agents lancés, la qualité du rapport et le coût du run. Si le découpage est bon, tu tiens une méthode solide pour les audits, les migrations et les recherches croisées.
Le bon réflexe tient en une phrase. Petit bug, session classique. Tâche parallèle courte, sous agent. Gros chantier qui doit être recoupé et répété, Dynamic Workflow. Là, Claude Code commence à ressembler à un vrai poste de pilotage pour agents IA.
Qui peut utiliser Claude Code Dynamic Workflows
Max et Team sont annoncés comme actifs par défaut. Sur Enterprise, l’admin peut l’activer. Si ton compte affiche la ligne Dynamic workflows dans config, tu peux l’activer depuis là.
Faut il remplacer les sous agents par un workflow
Non. Les sous agents restent parfaits pour une tâche courte ou une vérification isolée. Le workflow devient utile quand le plan doit être répété, recoupé ou exécuté par beaucoup d’agents.
Quel premier test lancer avec Dynamic Workflows
Commence par un audit en lecture seule sur un dossier limité. Tu vérifies la qualité du découpage avant d’autoriser un workflow à modifier des fichiers.
