Claude Code Workflows : Ce Que C'est et Quand Vous en Avez Vraiment Besoin

Claude Code Workflows : Ce Que C'est et Quand Vous en Avez Vraiment Besoin

Mettez à jour Claude Code vers la v2.1.154 et vous trouverez une nouvelle ligne dans /config intitulée Dynamic workflows. Activez-la et Claude peut désormais écrire un script JavaScript qui distribue le travail à 16 agents tournant simultanément. C'est la fonctionnalité dont tout le monde parle. La doc officielle vous explique ce que ça fait. Elle ne vous dit pas ce qui vous intéresse vraiment : est-ce qu'il vous en faut un, ou les subagents que vous avez déjà suffisent-ils ?

Voilà le vide à combler. Les workflows Claude Code sont arrivés en preview, et la doc ressemble à de la documentation de référence, pas à du conseil. Alors on a lancé le seul workflow inclus, /deep-research, dans notre propre pipeline de contenu, on a enregistré les vrais chiffres, et on a écrit le verdict honnête. Version courte : si vous pouvez encore suivre vos agents à la main, vous n'avez pas encore besoin d'un workflow. Quelques-uns d'entre vous en ont absolument besoin. Voyons dans quel groupe vous êtes.

Points clés :

• Un workflow Claude Code est un script JavaScript que Claude écrit pour orchestrer des subagents à grande échelle (preview, v2.1.154+, tous les plans payants).
• Vous n'en avez besoin que quand une tâche requiert plus d'agents qu'une seule conversation ne peut en coordonner. Sinon, les subagents suffisent.
• Un seul workflow existe aujourd'hui : /deep-research. Il tourne en arrière-plan pendant que votre session reste réactive.
• Les workflows consomment beaucoup de tokens. On a mesuré une vraie exécution avant de recommander quoi que ce soit (chiffres ci-dessous).

Qu'est-ce qu'un Workflow Claude Code ?

Un workflow Claude Code est un script JavaScript qui orchestre des subagents à grande échelle. Vous décrivez la tâche, Claude écrit le script, et un runtime l'exécute en arrière-plan pendant que votre session de chat reste réactive. C'est une fonctionnalité en preview dans Claude Code, qui requiert Claude Code v2.1.154+ et fonctionne sur tous les plans payants (Pro, Max, Team, Enterprise, plus l'API et Bedrock/Vertex/Foundry).

Voici la version du quotidien. Imaginez que vous vous approchez d'un comptoir de cuisine et décrivez le repas que vous voulez. Le chef écrit une recette, la passe à une cuisine arrière pleine de cuisiniers, et ils se mettent au travail pendant que vous continuez à discuter au comptoir. Vous ne gérez pas chaque cuisinier. La recette s'en charge. Cette recette, c'est le workflow ; les cuisiniers sont les subagents ; et la cuisine qui tourne en coulisse est le runtime.

Un workflow n'est pas un autre agent. C'est le script qui indique à vos agents quoi faire, dans quel ordre, et quoi faire des résultats. Cette distinction compte plus que tout le reste dans cet article, et on va la rendre concrète dans la section suivante.

Une confusion rapide à dissiper. Cherchez "claude code workflows" et vous tomberez sur des dépôts GitHub, des plugins, et une marketplace pleine d'outils swarm communautaires comme Ruflo, claude-flow et wshobson/agents. Ce sont des orchestrateurs tiers. Les Dynamic workflows officiels d'Anthropic sont une fonctionnalité intégrée distincte. Si elle n'apparaît pas dans /config sur la v2.1.154+, ce n'est pas l'officielle.

Ça s'inscrit dans la lignée des autres previews d'Anthropic, comme la récente preview du mode fast : livré tôt, derrière un toggle, encore un peu brut. Traitez-le comme une preview, parce que c'est ce que c'est. La spec complète se trouve dans la documentation officielle des workflows.

Workflows, Subagents et Skills : Qui Tient le Plan ?

La façon la plus simple de distinguer ces trois éléments est de poser une question : qui tient le plan ? Un skill est un ensemble d'instructions et de connaissances que Claude charge à la demande. Un subagent est un contexte séparé qui effectue une tâche déléguée unique. Un workflow est le script d'orchestration qui coordonne les subagents à grande échelle, jusqu'à 16 simultanément. La même boîte à outils, trois rôles différents.

Voici la comparaison que la doc officielle suggère sans jamais la poser côte à côte :

Si une seule conversation Claude peut encore tenir tout le plan en tête, vous voulez un subagent, pas un workflow. Le moment où vous faites tourner plus d'agents que vous, l'humain, ne pouvez en suivre — qui fait quoi et dans quel ordre — c'est que le plan a outgrown la conversation. C'est la ligne que franchit un workflow.

Vous voulez approfondir le premier volet ? Notre tutoriel sur les skills couvre le packaging des connaissances que Claude charge à la demande. Et si vous pesez l'option d'un framework agent complet plutôt que l'orchestration native, cette comparaison aide aussi. Notre avis honnête : les primitives natives vont plus loin que vous ne le pensez avant qu'un framework devienne rentable.

Quand Avez-vous Vraiment Besoin d'un Workflow Claude Code ?

Vous avez besoin d'un workflow Claude Code quand (a) la tâche requiert plus d'agents qu'une seule conversation peut en coordonner, (b) vous voulez l'orchestration enregistrée en code réexécutable plutôt qu'un prompt ponctuel, ou (c) vous avez besoin d'une révision adversariale ou croisée où plusieurs agents vérifient le travail des autres. Si rien de tout ça n'est vrai, les subagents suffisent. Soyez honnête avec vous-même.

C'est la partie que la doc ne dira pas à voix haute, alors on le dit : vous n'avez probablement pas encore besoin d'un workflow. Une poignée de subagents coordonnés dans une conversation ordinaire gère le travail quotidien. Les workflows ne sont pas une montée en grade vers laquelle on évolue. Ce sont un outil pour un type précis de problème : plus d'agents qu'un seul cerveau ne peut en suivre.

Passez-vous cette checklist. Vous avez probablement besoin d'un workflow si vous répondez oui à au moins un point :

• La tâche requiert plus d'agents qu'une seule conversation ne peut en suivre.
• Vous voulez l'orchestration en code réexécutable, pas un prompt à retaper à chaque fois.
• Vous avez besoin d'une révision adversariale ou croisée (plusieurs agents se vérifiant mutuellement).
• Vous allez exécuter le même travail multi-agents de façon répétée, comme un audit de code récurrent ou une migration de 500 fichiers.

Vous avez répondu non aux quatre ? Restez avec les subagents. Vous économiserez des tokens, garderez les choses déboguables, et ne perdrez rien. Les adeptes de la spec reconnaîtront ce pattern dans les meilleures pratiques CLAUDE.md : écrire le plan une fois, le rendre réexécutable, arrêter de le retaper. Un workflow, c'est cette idée poussée jusqu'au point où le plan lui-même a besoin d'un runtime pour s'exécuter.

Le Seul Workflow que Vous Avez Déjà : /deep-research

/deep-research est le seul workflow inclus livré dans la preview. Invoquez-le avec une question et il distribue des subagents pour rechercher le sujet en parallèle, vérifie leurs résultats les uns contre les autres, et renvoie une réponse synthétisée dans votre contexte, le tout en tournant en arrière-plan pour que votre session reste utilisable.

/deep-research Quels sont les vrais coûts en tokens d'une recherche multi-agents dans Claude Code ?

C'est toute l'interface. Sous le capot, ça passe par plusieurs phases : il décompose votre question en fils de recherche, spawne des agents pour suivre chacun, lance une phase de vérification croisée pour que les agents corrigent les affirmations faibles des autres, puis synthétise une réponse finale dans votre chat. Vous ne le pilotez pas en cours d'exécution. Vous demandez, ça travaille, ça rend compte.

C'est vraiment utile pour les questions de recherche complexes où vous ouvririez sinon dix onglets et perdriez votre après-midi. Si vous câblez déjà des outils de recherche, notre tour d'horizon des meilleurs serveurs MCP se marie bien avec ce type de recherche en distribution. Mais "utile" et "rentable par rapport à la facture de tokens" ne sont pas la même chose, ce qu'on s'est justement mis à mesurer.

Ce Qui S'est Passé Quand on a Lancé un Workflow dans Notre Pipeline

Notre exécution de /deep-research a spawné 9 subagents sur 4 phases, brûlé un peu plus d'un million de tokens, et terminé en environ 8 minutes de temps réel. Ça en valait-il la peine ? Pour une question rapide, pas du tout. Pour une tâche de recherche qu'on aurait sinon coordonnée manuellement entre une demi-douzaine d'agents, ça s'est rentabilisé. Voici le bilan honnête.

Dans notre pipeline, cet article que vous lisez a lui-même été produit par un système multi-agents : recherche, brief, rédaction, validation, traduction et publication tournent chacun en subagents séparés. On vit donc déjà dans le monde du "trop d'agents pour une seule conversation" décrit dans la checklist ci-dessus. Ce qui faisait de nous le bon cas de test, pas un cas artificiel.

On a lancé /deep-research sur un mot-clé qu'on recherchait déjà et enregistré l'exécution complète :

Ce qui nous a le plus surpris, c'est la phase de vérification croisée. Quelques affirmations initiales qu'un agent avait produites ont été silencieusement corrigées après qu'un autre agent les a contestées, ce qui est exactement le genre de chose qu'une seule conversation tend à laisser passer. Cette étape adversariale est la vraie valeur, plus que le simple parallélisme. Le coût en tokens est élevé, cependant, et ces agents tournent sur des modèles Opus-tier (voir les nouveautés d'Opus 4.8 pour comprendre ce que ça représente sur la facture). Un million de tokens pour une question à laquelle deux prompts suffisaient, c'est un mauvais calcul. Pour une question qui nécessite vraiment de réconcilier six sources, c'est une bonne affaire sur votre temps.

C'est exactement le type d'orchestration qu'on construit pour les clients chez Techsy, alors on avait déjà une bonne idée d'où ça paie et d'où ça brûle du budget. Notre conclusion : lancez-le sur les questions difficiles, évitez-le pour les faciles.

Comment Écrire et Enregistrer Votre Propre Workflow

Pour créer votre propre workflow, décrivez la tâche à Claude en langage naturel en utilisant le mot-clé workflow, vérifiez et approuvez le script qu'il génère, puis enregistrez ce script en tant que /command réutilisable. Pour un effort plus élevé, définissez /effort ultracode et Claude planifie un workflow tout seul. Aucun JavaScript requis de votre côté ; Claude écrit le script, vous l'approuvez.

Voici la boucle complète, qui sert aussi de guide si vous suivez pas à pas :

1. Activez Dynamic workflows. Sur Pro, ouvrez /config et activez la ligne Dynamic workflows. (Vous êtes bien sur la v2.1.154+, non ?)

   bash

   /config
   # puis activez la ligne "Dynamic workflows"

2. Décrivez la tâche avec le mot-clé workflow. Incluez le mot workflow n'importe où dans votre prompt, par exemple : "Lance un workflow pour auditer chaque fichier de routes de ce dépôt pour les vérifications d'auth manquantes." Claude Code surligne le mot et écrit un script plutôt que de travailler tour par tour. Vous voulez que Claude décide tout seul ? Définissez /effort ultracode, qui associe un raisonnement xhigh à une orchestration automatique de workflow pour chaque tâche substantielle (et brûle plus de tokens, donc revenez à /effort high pour le travail ordinaire).

3. Vérifiez et approuvez le script généré. Claude vous montre l'orchestration JavaScript avant d'exécuter quoi que ce soit. Lisez-le. C'est votre chance de repérer une distribution plus large que vous ne le souhaitez.

4. Enregistrez-le en tant que /command pour réutilisation. Une fois qu'il fonctionne, enregistrez le workflow comme commande slash personnalisée pour que l'audit du trimestre prochain se fasse en un seul appui de touche.

La réutilisabilité est le gain discret. Un /deep-research ponctuel est pratique, mais un workflow enregistré pour "auditer l'auth sur toutes les routes" ou "migrer ce répertoire vers la nouvelle API" transforme un travail de coordination de plusieurs heures en une commande répétable unique. C'est là que le coût en tokens commence à s'amortir sur plusieurs exécutions plutôt que de faire mal une fois.

Limites, Coût et Comment Désactiver les Workflows

Les workflows tournent jusqu'à 16 agents simultanés avec un plafond dur de 1 000 agents par exécution, n'acceptent aucune entrée en cours d'exécution, et ne sont reprenables que dans la même session. Ils consomment beaucoup de tokens par conception, puisque chaque agent consomme son propre contexte. Vous pouvez désactiver la fonctionnalité entièrement avec disableWorkflows dans la config ou la variable d'environnement CLAUDE_CODE_DISABLE_WORKFLOWS.

Chacune de ces limites a une signification pour votre tâche. Aucune entrée en cours d'exécution signifie que vous ne pouvez pas corriger le tir une fois lancé, donc un prompt vague gaspille tous les tokens d'une exécution complète. Reprenables uniquement dans la même session signifie que si vous fermez votre terminal, l'exécution est perdue. 1 000 agents par exécution semble énorme, mais une distribution large aux tarifs Opus-tier, c'est du vrai argent, alors traitez le défaut de 16 simultanés comme une fonctionnalité, pas comme un plafond à repousser.

Pour désactiver :

export CLAUDE_CODE_DISABLE_WORKFLOWS=1
# ou définissez "disableWorkflows": true dans votre config

Le problème de version piège les gens : si /config n'affiche pas de ligne Dynamic workflows, vous êtes en dessous de la v2.1.154. Mettez d'abord à jour. Et si vous construisez des pipelines d'agents comme celui-là pour un vrai travail et voulez qu'ils soient rentables, on construit des pipelines d'agents pour des équipes B2B. Obtenez une consultation gratuite → si l'orchestration devient un goulot d'étranglement.

Conclusion

Voici tout l'article en cinq lignes. Un workflow Claude Code est un script JavaScript que Claude écrit pour orchestrer des subagents à grande échelle, livré en preview dans la v2.1.154. Le seul qui existe aujourd'hui est /deep-research. Vous avez besoin d'un workflow uniquement quand une tâche dépasse ce qu'une seule conversation peut coordonner, quand vous voulez une orchestration réexécutable, ou quand vous avez besoin que les agents se vérifient mutuellement. Notre vraie exécution a coûté ~1 M de tokens pour 9 agents en 8 minutes, ce qui est excessif pour les questions faciles et rentable pour la recherche difficile. Vous n'en avez probablement pas encore besoin, et c'est très bien.

Foire Aux Questions

Qu'est-ce qu'un workflow Claude Code ?

Un workflow Claude Code est un script JavaScript qui orchestre des subagents à grande échelle. Vous décrivez la tâche, Claude écrit le script, et un runtime l'exécute en arrière-plan pendant que votre session reste réactive. C'est une fonctionnalité en preview dans Claude Code v2.1.154+, disponible sur tous les plans payants.

Quelle est la différence entre un workflow et un subagent ?

Un subagent est un travail délégué unique tournant dans son propre contexte séparé, coordonné par vous en conversation. Un workflow est le script d'orchestration qui coordonne les subagents simultanément, jusqu'à 16 à la fois. Si une conversation peut encore tenir tout le plan, utilisez un subagent. Si le plan a besoin d'un runtime pour suivre les agents, utilisez un workflow.

Combien coûte un workflow Claude Code en tokens ?

Dans notre exécution mesurée de /deep-research, 9 subagents sur 4 phases ont brûlé environ 1,05 million de tokens en 8 minutes. Les workflows sont gourmands en tokens par conception car chaque agent consomme son propre contexte, et ces agents tournent sur des modèles Opus-tier. Pour les questions simples c'est du gaspillage ; pour une vraie recherche multi-sources, ça vaut son coût.

Faut-il un plan payant pour utiliser les workflows Claude Code ?

Oui. Les Dynamic workflows fonctionnent sur tous les plans payants Claude (Pro, Max, Team, Enterprise) ainsi que l'API et Bedrock/Vertex/Foundry. Il n'y a pas d'accès en tier gratuit. Sur Pro, vous activez la fonctionnalité en basculant la ligne Dynamic workflows dans /config après avoir mis à jour vers Claude Code v2.1.154 ou supérieur.

Qu'est-ce que /deep-research dans Claude Code ?

/deep-research est le seul workflow inclus livré dans la preview. Vous lui soumettez une question et il distribue des subagents pour rechercher le sujet en parallèle, lance une phase de vérification croisée où les agents vérifient les résultats des autres, puis synthétise une réponse unique dans votre contexte, le tout en tournant en arrière-plan.

Comment enregistrer un workflow en tant que commande slash ?

Décrivez la tâche à Claude en utilisant le mot-clé workflow, vérifiez et approuvez le script JavaScript qu'il génère, puis enregistrez ce script approuvé en tant que /command personnalisé. Après ça, tout le travail multi-agents s'exécute en un seul appui de touche, ce qui est là où les workflows commencent à amortir leur coût en tokens sur plusieurs exécutions.

Combien d'agents un workflow peut-il faire tourner simultanément ?

Un workflow tourne jusqu'à 16 agents simultanés, avec un plafond dur de 1 000 agents par exécution. Le défaut de 16 simultanés existe pour une bonne raison : une distribution large aux tarifs Opus-tier devient vite coûteuse. Traitez les limites comme des garde-fous plutôt que des cibles, et gardez votre distribution aussi étroite que la tâche le permet.

Comment désactiver les Dynamic workflows ?

Définissez disableWorkflows à true dans votre config, ou exportez la variable d'environnement CLAUDE_CODE_DISABLE_WORKFLOWS=1 avant de lancer Claude Code. L'une ou l'autre désactive complètement la fonctionnalité. Si vous ne voyez tout simplement pas de ligne Dynamic workflows dans /config, vous êtes probablement en dessous de la v2.1.154 requise et devez d'abord mettre à jour.

Avez-vous vraiment besoin des workflows Claude Code, ou les subagents suffisent-ils ?

Les subagents suffisent jusqu'à ce qu'une tâche dépasse une seule conversation. Une poignée de subagents coordonnés dans une conversation normale couvre le travail quotidien sans le coût en tokens. Vous avez vraiment besoin d'un workflow seulement quand une tâche spawne plus d'agents qu'une seule conversation ne peut en suivre, quand vous voulez une orchestration réexécutable en code, ou quand vous avez besoin que les agents se vérifient mutuellement de façon adversariale.