Comment lancer des centaines d’agents dans Claude Code avec Dynamic Workflows

Retrouvez d’autres ressources sur la configuration des outils dans la documentation Ailoot.

Que sont les Dynamic Workflows dans Claude Code ?#

Auparavant, le format lui-même limitait l’échelle : une conversation = un plan = une fenêtre de contexte. Les subagents étaient utiles, mais Claude, dans la conversation principale, décidait toujours « quoi exécuter ensuite », et chaque résultat intermédiaire occupait cette même fenêtre de contexte. Cela devenait un goulot d’étranglement pour une tâche impliquant 500 fichiers ou dix hypothèses indépendantes.

Dynamic Workflows déplacent le plan dans le code. Claude formule la tâche sous la forme d’un script d’orchestration, l’environnement d’exécution lance ce script dans un environnement isolé, et les résultats intermédiaires restent dans les variables du script plutôt que dans votre contexte. La session reste réactive pendant que les agents travaillent en arrière-plan.

Ce qui change concrètement par rapport à l’ancienne approche : des agents indépendants remettent en question les conclusions des autres, et seules celles qui résistent à la vérification arrivent jusqu’à vous. Le terme « dynamique » dans le nom fait précisément référence à cela : chaque exécution est écrite pour la tâche en cours. Il n’existe pas de liste de processus prédéfinie.

En quoi un workflow diffère d’un subagent et d’une Skill : 3 types d’orchestration#

Pour choisir entre un workflow, un subagent et une Skill, je me pose deux questions : qui détient le plan, et où se trouvent les résultats intermédiaires ?

Le principal changement, c’est que le plan passe dans le code. Avec des subagents et des Skills, Claude reste toujours l’orchestrateur : il décide en cours de route quoi lancer ensuite, et chaque retour arrive dans la fenêtre de contexte. Un Workflow conserve pour lui-même la boucle, les embranchements et les résultats intermédiaires ; seule la réponse finale parvient à Claude.

Vous pouvez exécuter le même plan de manière à ce que des agents indépendants l’examinent sous différents angles, puis que le script rassemble ce qui résiste à l’analyse. Impossible de faire cela au cours d’un échange classique dans une seule conversation : Claude n’a pas de point de synthèse indépendant.

Voici comment je choisis : pour une tâche courante comportant plusieurs étapes, utilisez des subagents ou une Skill. Pour une tâche qui ne tient pas dans une seule conversation, ou un processus que vous souhaitez relancer à la demande, utilisez un workflow. J’ai présenté en détail les quatre primitives dans le guide de référence Skills, Subagents, MCP ou Plugins.

3 façons de démarrer un workflow dans Claude Code#

Méthode 1. Le mot-clé workflow dans un prompt. L’option la plus simple ; elle ne modifie pas les paramètres de la session. Il suffit d’insérer le mot workflow dans n’importe quel prompt : Claude Code le mettra en évidence pendant la saisie et générera un script d’orchestration plutôt qu’une conversation classique.

Run a workflow to audit every API endpoint under src/routes/ for missing auth checks

Si Claude Code met le mot en évidence alors que vous ne vouliez pas démarrer de workflow, alt+w désactive le déclencheur pour ce prompt.

Méthode 2. Le mode /effort ultracode. Il active l’effort maximal du modèle (xhigh) et permet aussi à Claude de décider lui-même quand une tâche justifie un workflow.

/effort ultracode

Dans ce mode, une seule requête peut donner lieu à plusieurs workflows successifs : un pour comprendre le code, un autre pour effectuer une modification et un troisième pour vérifier le résultat. Chaque exécution utilise davantage de tokens et prend plus de temps qu’un niveau d’effort classique. Le mode ne s’applique qu’à la session en cours et est réinitialisé à l’ouverture d’une nouvelle session. Lorsque vous reprenez des tâches courantes, /effort high désactive ultracode.

Méthode 3. La commande intégrée /deep-research. Un workflow Anthropic prédéfini pour la recherche sur le Web. La section suivante présente cette méthode.

Pour ces trois méthodes, Claude Code demande une confirmation lors de la première exécution et affiche la liste des phases. Les choix de réponse sont Yes, run it, Yes, and don't ask again for <name> (mémorise votre autorisation), View raw script (ouvre le code avec Ctrl+G) et No. En mode Auto, la confirmation n’est nécessaire que la première fois ; les exécutions suivantes se déroulent sans demander. Avec claude -p et l’Agent SDK, aucune confirmation n’est demandée : les autorisations des subagents proviennent alors de la liste d’autorisation partagée.

Le workflow prédéfini /deep-research : exemple de première exécution#

Le moyen le plus rapide d’essayer Dynamic Workflows consiste à exécuter un workflow prédéfini plutôt qu’à écrire le vôtre. Anthropic inclut le workflow intégré /deep-research dans Claude Code. Il explore une question sous plusieurs angles indépendants, trouve des sources, soumet chaque affirmation au vote et ne conserve dans le rapport que celles qui résistent à la vérification.

1. Exécuter la commande

   Dans une session Claude Code, saisissez /deep-research et formulez votre question dans un prompt détaillé. Plus la formulation est précise, moins le script perdra de temps à lancer des phases inutiles.

2. Autoriser le workflow

   Une boîte de dialogue affichera les phases et les boutons Yes / View raw script / No. Si vous choisissez une option contenant don't ask again, l’autorisation est mémorisée pour le projet.

3. Suivre la progression avec /workflows

   L’exécution passe en arrière-plan et la session reste disponible. La commande /workflows affiche la liste des exécutions en cours et terminées. Utilisez les flèches pour sélectionner une phase, Enter pour la développer et voir ses agents, j/k pour parcourir les détails, p pour mettre en pause, x pour arrêter l’exécution, r pour redémarrer un agent et s pour enregistrer le script.

4. Lire le rapport

   Une fois l’exécution terminée, le rapport et ses liens apparaissent dans la session. Les affirmations qui n’ont pas résisté à la vérification sont automatiquement filtrées.

Contrairement à une conversation classique avec une seule recherche Web, /deep-research parallélise les requêtes de lui-même et rapproche les divergences entre les sources. Je l’utilise pour explorer un sujet avant de rédiger un guide : c’est un moyen pratique de se faire une idée de l’utilisation des tokens avant de passer à une plus grande échelle.

Ultracode : le mode où Claude décide quand démarrer un workflow#

Ultracode associe deux éléments : un effort de raisonnement maximal et l’autorisation pour Claude de démarrer des workflows de lui-même. Par défaut, même /effort xhigh produit une conversation classique : Claude réfléchit plus longtemps, mais garde les étapes dans son propre contexte. Ultracode autorise en plus Claude à transformer lui-même une tâche en workflow dès qu’il comprend qu’une seule session ne suffira pas.

/effort ultracode

Lorsque le mode est activé, une requête peut lancer deux ou trois workflows à la suite : l’un examine la base de code, un autre effectue une modification, et un troisième tente de la réfuter au cours d’une exécution distincte. On retrouve le même schéma de « plusieurs tentatives indépendantes ⇒ synthèse finale », sans que vous ayez à démarrer chaque phase manuellement.

Le coût est évident : chaque requête prend plus de temps et coûte davantage qu’avec /effort high. En arrière-plan, plusieurs exécutions se déroulent avec leurs propres limites, et Anthropic lui-même ne recommande pas ultracode comme mode par défaut. Il ne s’applique qu’à la session en cours et est réinitialisé à la suivante.

Lorsque vous reprenez des tâches courantes, /effort high désactive ultracode, et la session redevient une conversation classique avec des subagents. Sur les modèles qui ne prennent pas en charge xhigh, l’option ultracode n’apparaît tout simplement pas dans /effort.

Limites, tokens et pièges de la première exécution#

L’environnement d’exécution impose les limites techniques suivantes :

• Jusqu’à 16 agents exécutés simultanément. Le nombre est inférieur sur les machines comportant peu de cœurs. Il s’agit d’un budget de ressources local.
• 1 000 agents par exécution. Cette limite protège contre les boucles incontrôlées : si un script commence à lancer des agents sans fin, l’environnement d’exécution l’arrête.
• Impossible d’attendre une saisie utilisateur pendant l’exécution. Seules les autorisations d’outils peuvent la mettre en pause. Si vous devez valider chaque phase, répartissez le travail entre plusieurs workflows.
• Le script lui-même n’a pas d’accès direct aux fichiers ni à l’interpréteur de commandes. La lecture, l’écriture et l’exécution des commandes sont effectuées par les agents qu’il lance. Le script ne fait que les coordonner.
• Claude Code v2.1.154 ou une version ultérieure est requis. La fonctionnalité est disponible avec Pro, Max, Team et Enterprise (Pro doit être activé via /config), ainsi qu’avec Claude API, Amazon Bedrock, Vertex AI et Microsoft Foundry.

Le principal avertissement concerne le coût.

Chaque agent d’une exécution utilise le modèle de la session, sauf si le script attribue une phase à un autre modèle. Avant une grande exécution, vérifiez /model : si vous avez l’habitude de passer à un modèle moins cher pour les tâches courantes, ultracode et /deep-research peuvent faire grimper la facture si vous omettez cette vérification. Vous pouvez demander explicitement à Claude dans votre prompt d’« utiliser un modèle moins cher pour les phases qui ne nécessitent pas des capacités maximales » : c’est une façon valable de gérer les coûts.

Si une exécution dévie, ouvrez /workflows, sélectionnez-la et appuyez sur x. Les agents qui ont déjà terminé conservent leurs résultats. Vous pouvez reprendre l’exécution arrêtée à cet endroit avec p, ou demander à Claude de redémarrer le script à partir du même point : les agents dont les résultats sont en cache les renvoient, tandis que les autres continuent à travailler en direct. Cela fonctionne dans une même session : dès que vous quittez Claude Code, le workflow repart de zéro à la session suivante.

Si vous prévoyez de longues exécutions, commencez à gérer votre consommation grâce au guide Comment ne pas épuiser les limites de Claude Code et au Second Brain : avec la bonne structure de projet, le workflow ne chargera pas le dépôt entier dans chaque agent.

Comment enregistrer votre workflow dans un projet#

Si Claude a préparé un workflow pour une tâche récurrente (par exemple, examiner chaque branche ou effectuer régulièrement un audit de sécurité), vous pouvez enregistrer le script et éviter de décrire cette tâche à chaque fois.

1. Ouvrir /workflows

   La commande affiche la liste des exécutions récentes. Utilisez les flèches pour sélectionner celle qui vous intéresse.

2. Appuyer sur s

   Une boîte de dialogue d’enregistrement s’affiche. Tab permet de changer l’emplacement de stockage.

3. Choisir un dossier

   .claude/workflows/ se trouve dans le projet et est visible par toutes les personnes qui ont cloné le dépôt. ~/.claude/workflows/ se trouve dans votre répertoire personnel, est disponible dans tous vos projets et n’est visible que par vous.

4. L’appeler comme une commande

   /[script_name] démarre le workflow à l’aide du même script que la première fois. Si des workflows de même nom existent dans les dossiers du projet et du répertoire personnel, celui du projet est prioritaire.

Voici un schéma intéressant : une personne de l’équipe met au point un workflow, le committe dans .claude/workflows/, puis chaque membre de l’équipe exécute la même orchestration à l’aide d’une commande. Le script est du JavaScript lisible, que vous pouvez examiner, modifier et committer dans une nouvelle version.

La première fois que vous exécutez un workflow enregistré dans un projet, Claude Code affiche toujours une boîte de dialogue d’autorisation ; l’enregistrement du script ne l’approuve donc pas automatiquement. L’autorisation est accordée séparément avec Yes, and don't ask again.

Pour quelles tâches les workflows valent-ils vraiment la peine ?#

Anthropic énumère explicitement les cas d’usage pour lesquels l’environnement d’exécution a été conçu :

• Audits de l’ensemble de la base de code — vérifier chaque point de terminaison, fichier et fonction à l’aide d’une liste de contrôle. Par exemple, rechercher des vérifications d’authentification manquantes ou de la logique dupliquée, ou auditer la sécurité selon les règles OWASP. Un agent distinct est lancé pour chaque branche de la liste.
• Migrations à grande échelle — changer de framework, abandonner une API obsolète ou porter des milliers de fichiers vers un autre langage. Le workflow suit la progression, les agents travaillent en parallèle sur les fichiers et des agents de vérification recherchent les oublis.
• Recherche avec vérification croisée — une question qui exige des sources venant de différents angles et une évaluation des affirmations qui résisteront à la vérification. C’est le cas d’usage de base pour lequel le workflow intégré /deep-research a été conçu.
• Un plan complexe à élaborer sous plusieurs angles indépendants — le workflow produit plusieurs ébauches de plan indépendantes, des agents chargés de les contester les examinent, puis une synthèse est fournie. C’est utile lorsque « le coût d’une erreur est élevé et qu’un seul passage ne suffit pas ».

Pour une tâche comme « corriger un bug » ou « ajouter une fonction », Dynamic Workflows sont moins avantageux qu’une session classique : la consommation des tokens ne vaut pas le temps investi. La documentation d’Anthropic est claire à ce sujet : « commencez par une tâche ciblée afin de vous faire une idée de la consommation ». Ma règle : s’il y a moins de 5 sous-tâches indépendantes ou moins de 50 fichiers, une conversation classique avec quelques subagents fera l’affaire à moindre coût.

Si vous dirigez une équipe avec un forfait Enterprise, un administrateur a peut-être désactivé les Workflows dans les paramètres gérés ou avec le commutateur de la page d’administration de Claude Code. Avant de considérer les Workflows comme une « solution à tout », vérifiez qu’ils sont bien activés : /config → l’entrée Dynamic workflows.

Retrouvez d’autres ressources sur l’utilisation des outils dans la documentation Ailoot.