Claude Code Workflows : 41 agents, 5M de tokens, testés

Claude Code Workflows : 41 agents, 5M de tokens, testés

Quarante et un agents. C'est le nombre d'instances Haiku qu'un de mes workflows Claude Code a lancé la semaine dernière, toutes en même temps, pour auditer et noter chaque skill que j'avais installé. J'ai regardé le compteur grimper dans le terminal — 12, 28, 41 — chacun un appel Claude complet et indépendant, évaluant une recette différente selon les critères que j'avais transmis à l'orchestrateur. L'ensemble a consommé environ 5 millions de tokens d'entrée avant d'en avoir fini.

Ce nombre m'a arrêté. Cinq millions. Avec la plupart des calculs tarifaires, ça semble être une facture à provoquer la panique. Mais voici le rebondissement qui a recadré toute la fonctionnalité pour moi : la sortie était minuscule. Un rapport classé, quelques centaines de lignes. Toute cette dépense de tokens est allée dans la lecture — exploration, analyse, notation — pas dans la génération. Gourmand en calcul, certes. Excessivement cher ? Pas vraiment. Les tokens d'entrée Haiku sont bon marché, et 41 d'entre eux lisant en parallèle ont terminé en une fraction du temps réel qu'un seul agent aurait mis à traiter la même pile séquentiellement.

C'est le moment où les workflows Claude Code ont fait tilt pour moi. Pas comme un mot à la mode du lancement d'Opus 4.8. Comme un outil spécifique avec une forme spécifique — un outil véritablement différent des skills, des sous-agents et des équipes d'agents, et un outil incroyablement facile à mal utiliser si vous ne comprenez pas cette forme.

C'est donc ce que cet article est. Pas une annonce de fonctionnalité. Un guide de terrain. À la fin, vous saurez exactement lequel des cinq primitifs d'orchestration choisir — skill, sous-agent, équipe d'agents, workflow ou la boucle /goal — et approximativement ce que chacun vous coûte en tokens et en complexité. J'ai appris la plupart de cela de manière un peu coûteuse. Vous n'avez pas à le faire.

Ce qu'Anthropic a réellement livré avec les Workflows le 28 mai

Les workflows dynamiques sont arrivés le 28 mai 2026, intégrés à la version Claude Opus 4.8 en tant qu'aperçu de recherche. Si vous avez déjà lu mon analyse des niveaux d'effort d'Opus 4.8, pensez aux workflows comme l'autre moitié de cette version — le modèle a reçu un curseur de réflexion, et Claude Code a reçu un moyen de distribuer cette réflexion à travers des centaines d'agents simultanément.

Vous avez besoin de Claude Code v2.1.154 ou ultérieur pour les exécuter. Ils fonctionnent dans le CLI, l'application de bureau et l'extension VS Code. Et la façon dont vous en déclenchez un est presque suspecte de simplicité : vous mettez simplement le mot workflow quelque part dans votre prompt. Dites « lance un workflow pour auditer chaque route API pour les vérifications d'authentification manquantes » et Claude fait quelque chose qu'il n'a jamais fait auparavant — il écrit un script d'orchestration JavaScript à la volée, le confie à un runtime en arrière-plan, et ce runtime lance les agents.

Deux limites dures à graver au fer rouge dans votre mémoire : le runtime exécute jusqu'à 16 agents simultanément, et limite un seul workflow à 1 000 agents au total. Mon audit de skills à 41 agents n'a pas approché le plafond. Mais il est très facile d'écrire un prompt qui le fait — « analyser chaque fichier de ce monorepo » contre quelques milliers de fichiers saturera ce plafond rapidement et maintiendra la file d'attente en mouvement. Nous y reviendrons, car c'est la principale façon dont les gens brûlent de l'argent avec cette fonctionnalité.

Voici le détail architectural qui compte réellement cependant. Celui qui rend les workflows différents et pas juste « des sous-agents en plus ». Laissez-moi vous montrer.

Ce qui rend les Workflows différents : le plan vit en dehors de la tête de Claude

Chaque autre outil d'orchestration dans Claude Code garde son plan à l'intérieur de la fenêtre de contexte du modèle. La session principale se souvient de ce qu'elle a délégué, suit ce qui est revenu, maintient l'état courant dans sa propre mémoire de travail. C'est bien pour une poignée de tâches. Ça s'effondre à grande échelle, parce que les fenêtres de contexte sont finies et chaque résultat délégué que vous réinjectez mange de l'espace dont vous avez besoin pour le raisonnement réel.

Les workflows brisent complètement cette règle. Le plan et l'état d'exécution vivent dans un fichier JavaScript externe, pas dans le contexte de Claude.

Relisez ça, parce que c'est tout le jeu. Quand vous lancez un workflow, Claude ne décide pas simplement de lancer des agents — il écrit un vrai script : des boucles, une logique de branchement, combien d'agents lancer, ce que chacun reçoit, comment combiner les résultats, quelles passes de vérification exécuter. Ce script est sauvegardé dans un dossier que vous spécifiez. Un runtime séparé l'exécute dans un environnement isolé, complètement à part de votre session de chat. Les résultats intermédiaires — chaque sortie brute d'agent, chaque calcul intermédiaire — restent dans les variables du script. Ils ne touchent jamais votre conversation.

Ce qui revient à votre session est uniquement la réponse finale combinée.

Imaginez la différence physiquement. Avec les sous-agents, votre session principale est un manager tenant un presse-papiers, suivant personnellement chaque rapport à son arrivée. Avec un workflow, votre session principale écrit un programme, le confie à un serveur de build, s'en va, et revient avec un seul artefact terminé. Le presse-papiers ne déborde jamais. C'est pourquoi mon audit à 41 agents n'a pas fait exploser la fenêtre de contexte même s'il a traité 5 millions de tokens d'entrée — 99 % de ces tokens ont vécu et sont morts dans les variables du script. Ma session n'a jamais vu que le rapport classé à la fin.

Cela a deux conséquences que je n'ai pas appréciées avant d'en avoir exécuté quelques-uns. Premièrement, parce que l'orchestration est un fichier sauvegardé, les workflows sont réexécutables et versionnables. Vous pouvez commiter le script, le différencier, le transmettre à un coéquipier. Sauvegardez-en un utile et il devient une commande slash — votre workflow de revue de branche devient /my-review, répétable pour toujours. Deuxièmement, et c'est critique pour le modèle mental : les agents lancés ne se parlent pas entre eux. Chacun est un appel Claude totalement indépendant avec son propre contexte isolé. Ils se dispersent, font leur unique travail, retournent un résumé, et c'est tout. Pas de bavardage croisé. Pas de débat. La combinaison se fait dans la logique du script, pas dans une conversation entre agents.

Gardez ce détail « les agents ne se parlent pas » en tête. C'est exactement la ligne qui sépare un workflow d'une équipe d'agents — et se tromper sur cette ligne est la façon dont les gens choisissent le mauvais outil et paient pour ça.

Skill vs Sous-agent vs Équipe d'agents vs Workflow vs /goal : le modèle mental

Bien. Voici la partie pour laquelle vous êtes venu. Cinq primitifs, et la vérité honnête est que la plupart des gens n'avaient besoin que de deux d'entre eux et ont choisi les plus chers par enthousiasme. Moi aussi. Laissez-moi parcourir chacun de la façon dont je les utilise réellement maintenant, du moins cher au plus cher, parce que le coût et la complexité grimpent ensemble en une échelle propre : skills → sous-agents → équipes d'agents → workflows. La boucle /goal se situe sur un axe différent, et je vais expliquer pourquoi.

Qu'est-ce qu'un skill dans Claude Code ?

Un skill est une recette réutilisable qui s'exécute dans votre session Claude Code personnelle. C'est une automatisation mono-agent — un ensemble d'instructions sauvegardé que Claude peut appeler à la demande, par vous ou par d'autres outils, sans rien lancer en parallèle.

C'est le premier échelon, et il devrait être votre choix par défaut. Un skill ne distribue pas. Il n'obtient pas son propre contexte séparé. Il s'exécute directement dans votre session, comme une fonction que vous pouvez appeler par nom. Ma routine de vérification SEO, mon formateur de messages de commit, ma recette « auditer ce fichier pour les requêtes N+1 » — tous des skills. Peu coûteux à exécuter, triviaux à maintenir, et réutilisables partout. J'ai écrit tout un argumentaire pour construire des skills avant de recourir aux agents, et j'y tiens encore plus fermement maintenant qu'au moment de sa publication. La grande majorité des instincts « j'ai besoin d'un agent pour ça » sont en fait « j'ai besoin d'un skill pour ça ».

Utilisez un skill quand la tâche est petite, répétable et autonome. Si vous pouvez la décrire comme une recette, c'est un skill. Terminé.

Qu'est-ce qu'un sous-agent ?

Un sous-agent s'exécute en parallèle de votre session principale mais ne partage pas sa fenêtre de contexte, ne peut pas parler aux autres sous-agents, et rapporte son résultat uniquement à la session principale.

C'est l'échelon suivant, et le mot clé est décharger. Un sous-agent sert quand vous voulez qu'une tâche annexe soit gérée sans encombrer la mémoire de votre fil principal. Disons que je suis en plein refactoring et que je veux un résumé de l'explication de la suite de tests sans dérailler mon contexte — je le confie à un sous-agent. Il part, fait le travail, revient avec une réponse, et la mémoire de travail de ma session principale reste propre. Le compromis qu'il élimine est la surcharge de communication. Un sous-agent ne coordonne pas, ne négocie pas, ne boucle personne d'autre. C'est une course à sens unique. C'est une fonctionnalité, pas une limitation — ça rend les sous-agents peu coûteux et prévisibles.

Utilisez un sous-agent quand vous avez une tâche annexe simple et indépendante et que vous la voulez hors de votre contexte principal. Pas de collaboration nécessaire. Juste « va gérer ça et fais un rapport ».

Qu'est-ce qu'une équipe d'agents ?

Une équipe d'agents est un petit groupe d'agents qui communiquent, partagent des tâches et collaborent vers un objectif, au sein de leur propre fenêtre de contexte partagée — les agents débattent, se coordonnent et construisent sur le travail des autres.

Maintenant nous sommes à l'échelon coûteux, et le mot distinctif est parler. Contrairement aux sous-agents, les membres d'une équipe d'agents peuvent se voir et échanger des informations. Ils partagent le contexte. La découverte d'un agent informe celle d'un autre. Ils argumentent, se passent le relais, convergent. J'ai détaillé exactement comment et quand les agents devraient se parler dans un article dédié, et la version courte est : cette conversation est tout l'intérêt, et c'est aussi pourquoi les équipes coûtent de l'argent réel. Contexte partagé plus échanges signifie plus de tokens, plus de tours, plus de calcul.

Utilisez une équipe d'agents quand la tâche est véritablement collaborative — quand la discussion entre agents produit quelque chose qu'aucun agent seul ne pourrait produire, et quand le partage de contexte entre eux est vital. Débats d'architecture. Revues multi-perspectives où la critique d'un agent affine la proposition d'un autre. Pas pour le débit. Pour la délibération.

Qu'est-ce qu'un workflow ?

Un workflow est un système orchestré par JavaScript qui lance de nombreux agents indépendants — potentiellement des centaines — tournant en parallèle sur différentes parties d'une tâche, puis combine leurs résultats dans la logique du script. Les agents ne communiquent pas ; le plan vit dans un fichier externe, pas dans le contexte de Claude.

Échelon supérieur. Le plus puissant, le plus complexe, le plus cher. Tout ce que j'ai décrit deux sections plus haut. Le trait distinctif, ce qui le sépare d'une équipe d'agents : de l'ampleur sans conversation. Une équipe, c'est quelques agents qui parlent. Un workflow, c'est beaucoup d'agents qui ne parlent pas — chacun travaillant sur sa propre tranche, les résultats fusionnés par le code. Mes 41 évaluateurs Haiku étaient un workflow type : 41 travaux indépendants, zéro échange croisé, un classement combiné à la fin.

Utilisez un workflow quand une tâche se fragmente naturellement en de nombreuses pièces indépendantes et parallélisables. Explorer une base de code entière. Noter un grand jeu de données. Recherche large sur des dizaines d'angles. Le genre de travail où les pièces n'ont pas besoin de se connaître — elles doivent juste toutes être faites, rapidement, et consolidées.

Que fait la commande /goal ?

/goal exécute un processus en boucle où un agent itère continuellement sur le même problème jusqu'à ce qu'une condition de complétion soit remplie — il peut effectuer de nombreux cycles et prendre beaucoup de temps.

Voici pourquoi j'ai dit que /goal se situe sur un axe différent. Tout ce qui précède concerne combien d'agents et s'ils parlent. /goal concerne combien de fois un effort itère. C'est une boucle. Vous lui donnez un objectif et une définition de « terminé », et il s'acharne — essayer, évaluer, affiner, réessayer — jusqu'à ce que la condition soit satisfaite. Il peut effectuer une douzaine de cycles. Il peut tourner longtemps. C'est attendu.

Utilisez /goal quand la tâche nécessite de la profondeur — un raffinement itératif vers un objectif dur — plutôt que de l'ampleur.

Et ce mot, profondeur, est la clé de toute la carte. Laissez-moi rendre ça concret.

Ampleur vs Profondeur : le cadre qui a finalement fait cliquer tout ça

Voici la phrase unique qui a réorganisé ma façon de penser tout cela :

Les workflows sont l'ampleur. /goal est la profondeur.

Un workflow s'étend vers l'extérieur — beaucoup d'agents, chacun gérant une tranche différente, tous en même temps. L'ampleur. Vous l'utilisez quand le travail est large : cent fichiers à scanner, cinquante affirmations à vérifier, un gros tas plat de tâches indépendantes. Le gain est le parallélisme. Vous échangez des tokens contre du temps réel et accomplissez un travail large rapidement.

La boucle /goal fore vers le bas — un seul effort, affiné encore et encore, jusqu'à ce qu'il soit correct. La profondeur. Vous l'utilisez quand le travail est profond : un seul problème épineux qui doit être martelé cycle après cycle jusqu'à ce qu'il atteigne un seuil. Le gain est la persistance. Vous échangez du temps contre de la qualité sur une seule chose difficile.

Une fois que j'avais ce cadre, choisir l'outil a cessé d'être du hasard. Large et superficiel ? Workflow. Étroit et profond ? /goal. Besoin des deux — un travail large où chaque pièce nécessite aussi un raffinement itératif ? C'est là que vous les combinez soigneusement, et je serai honnête sur comment ça se passe dans une minute, parce que c'est puissant et c'est un excellent moyen de brûler une fortune.

Cette optique ampleur-versus-profondeur explique aussi les deux fonctionnalités phares qu'Anthropic a livrées au-dessus des workflows. Les deux sont des workflows sous le capot, visant les deux extrémités de ce spectre.

Ultra Code et /deep-research : les Workflows sans limites

Deux choses se situent au-dessus du moteur de workflow brut, et vous devriez savoir que les deux existent avant de décider si vous en avez besoin.

Ultra Code (/effort ultracode) est le réglage maximal : effort de raisonnement le plus élevé plus orchestration automatique de workflow. Activez-le et Claude décide, pour chaque tâche substantielle de la session, s'il faut planifier un workflow pour elle. Une seule requête peut se déployer en plusieurs workflows successifs — un pour comprendre le code, un pour faire la modification, un pour la vérifier. C'est le mode le plus capable de Claude Code. C'est aussi, sans surprise, la chose la plus chère que vous puissiez exécuter. L'effort le plus élevé brûle le plus de tokens de réflexion, et l'envelopper dans une orchestration automatique multiplie le nombre d'agents. J'utilise ultracode quand je fais quelque chose de véritablement difficile et véritablement important. Je ne le laisse pas activé par défaut. C'est comme ça qu'on obtient une facture surprise.

/deep-research est le workflow intégré visant la forme recherche. Posez-lui une question et il déploie des recherches web à travers de multiples angles, récupère et vérifie les sources en les croisant, fait voter les agents sur les affirmations concurrentes, et synthétise un seul rapport cité. C'est un workflow conçu pour l'ampleur d'investigation — l'ampleur appliquée à la connaissance plutôt qu'au code. Si vous avez utilisé les divers outils de deep-research qui circulent, c'est ce pattern, natif à Claude Code, fonctionnant sur le même moteur d'orchestration que mon audit à 41 agents.

Vous gérez tout cela avec une seule commande : /workflows. Exécutez-la à tout moment pour voir ce qui tourne, ce qui est terminé, et ouvrir une vue de progression — ou pour arrêter un workflow qui déraille clairement. J'ai appuyé sur ce bouton stop. Plus d'une fois. Ce qui m'amène à la partie de cet article que je veux le plus que vous lisiez.

Ce que j'ai mal fait : les erreurs de tokens dont personne ne vous prévient

Je vais être direct avec vous — mon premier instinct avec les workflows a été de les jeter sur tout, et c'était une erreur qui m'a coûté des tokens et m'a appris les vraies règles.

Erreur numéro un : j'ai utilisé un workflow pour un travail qui n'était pas large. Au début, j'ai lancé un workflow sur une tâche qui n'était en réalité que trois étapes séquentielles sur un seul fichier. Monter l'orchestration, écrire le script, lancer des agents — tout ce surcoût, pour quelque chose qu'un simple skill aurait géré avec un quart des tokens. Les workflows sont excessifs pour les travaux petits ou simples, point final. L'orchestration coûte quelque chose même avant que les agents ne tournent. Si la tâche ne se fragmente pas véritablement en de nombreuses pièces indépendantes, vous payez la taxe de mise en place pour rien.

Erreur numéro deux : j'ai été vague, et un workflow m'a pris au pied de la lettre. J'ai demandé à un de « revoir la base de code pour les problèmes ». Pas de périmètre, pas de livrable, pas de limites. Il s'est joyeusement déployé sur bien plus de fichiers que ce qui m'intéressait, chaque agent étant un appel Claude complet, le compteur de tokens d'entrée tournant comme une machine à sous. C'est le mode d'échec. Les workflows peuvent brûler des tokens d'entrée de manière absurde sur des travaux larges précisément parce qu'ils sont conçus pour explorer large. Un workflow fait exactement ce que vous avez dit — et à l'échelle de centaines d'agents parallèles, « exactement ce que vous avez dit » inclut chaque interprétation lâche d'un prompt bâclé.

La solution pour les deux est la même, et elle est ennuyeuse, et elle fonctionne : soyez explicite et spécifique. Définissez le livrable. Délimitez le périmètre. « Auditer les 14 fichiers dans app/Http/Controllers pour les middleware d'autorisation manquants et retourner un tableau avec fichier, route et vérification manquante » donne à l'orchestrateur un mur où s'arrêter. « Revoir le code » lui donne un continent.

Voici la règle par laquelle je vis maintenant. Un workflow est le bon outil uniquement quand toutes ces conditions sont vraies : la tâche est grande, les pièces sont indépendantes, et ces pièces sont parallélisables. Ratez l'une d'entre elles et vous avez choisi le mauvais primitif. Grande mais séquentielle ? Utilisez /goal. Petite mais répétée ? Utilisez un skill. Collaborative et basée sur la discussion ? Utilisez une équipe d'agents à la place. Les choix d'orchestration suivent la même logique de forme de tâche que j'ai développée dans mon analyse de l'architecture d'essaim d'agents — faites correspondre la structure au travail, pas à votre enthousiasme.

Si vous préférez ne pas apprendre ce calcul en brûlant des tokens sur un dépôt client en production, c'est exactement le genre de configuration d'orchestration que je construis et ajuste pour les équipes — vous pouvez voir ce que j'accepte sur mon Fiverr. Bien choisir le primitif du premier coup, c'est l'essentiel de la valeur.

L'astuce qui change l'économie : imbriquer des Skills dans les Workflows

Voici la manœuvre qui a rendu les workflows moins comme un gouffre financier et plus comme un levier. Vous pouvez imbriquer des skills dans un workflow. Chacun des nombreux agents qu'un workflow lance peut appeler vos recettes réutilisables existantes.

Réfléchissez à ce que ça fait. Vous investissez l'effort une seule fois pour écrire un skill serré et bien testé — disons, une recette précise « noter ce fichier skill selon ces dix critères ». Puis un workflow lance 41 agents et chacun exécute ce même skill contre une cible différente. Vous obtenez le parallélisme d'un workflow avec la constance et la maintenabilité d'un skill. La couche coûteuse et complexe s'appuie sur la couche bon marché et simple. C'est l'architecture sur laquelle j'ai convergé pour l'audit qui a ouvert cet article, et c'est pourquoi la sortie était si propre — chacun de ces 41 agents évaluait selon la grille identique, parce qu'ils exécutaient tous le skill identique.

C'est la partie de l'échelle coût-complexité que les gens ratent. Les échelons ne sont pas mutuellement exclusifs. Le pattern intelligent, c'est l'outil le moins cher faisant le travail réel, enveloppé dans l'outil coûteux uniquement là où vous avez véritablement besoin de l'échelle. Workflows au-dessus, skills en dessous. Vous ne choisissez pas entre eux — vous les empilez.

Vous pouvez aller plus loin et combiner un workflow avec /goal — ampleur et profondeur ensemble, de nombreux agents parallèles itérant chacun vers un objectif. C'est l'orchestration la plus puissante que j'ai exécutée. C'est aussi la chose la plus chère de tout cet article, de loin, et je la traite comme un outil électrique sans protection. Ça vaut le coup pour un travail véritablement grand et véritablement difficile. Un excellent moyen de vaporiser des tokens pour tout ce qui est moins que ça.

Une parenthèse rapide qui n'a rien à voir avec les workflows : si tout cela semble être plus d'orchestration que ce dont votre problème réel a besoin — disons que vous voulez juste livrer une app ou un site web IA avec quelques connexions MCP, pas coordonner 41 agents — Lovable est une rampe d'accès bien plus simple. Il branche des serveurs MCP et vous donne une expérience de construction qui ne nécessite rien de tout ça. C'est un outil différent pour une altitude différente. Tout le propos de cet article est de faire correspondre l'outil à la tâche, donc je serais hypocrite de ne pas le mentionner. Maintenant retour aux agents.

Ce que ça coûte réellement — et comment savoir que ça fonctionne

Laissez-moi ancrer l'économie, parce que « 5 millions de tokens » sans contexte est soit terrifiant soit insignifiant selon ce que vous supposez.

Le nombre qui compte n'est pas le total de tokens — c'est lesquels. Mon audit à 41 agents était presque entièrement des tokens d'entrée, et j'ai exécuté les évaluateurs sur Haiku. Avec la tarification publiée d'Anthropic, l'entrée Haiku coûte une fraction de centime pour mille tokens, donc 5 millions de tokens d'entrée de lecture par un modèle bon marché, c'est une facture fondamentalement différente de 5 millions de tokens de sortie de génération Opus. La leçon se généralise : le coût d'un workflow est dominé par combien ses agents lisent, multiplié par le prix du modèle avec lequel ils lisent. Choisissez le modèle délibérément. Des modèles bon marché pour l'exploration large et superficielle. Des modèles chers uniquement pour les pièces qui nécessitent un vrai raisonnement.

Comment savoir qu'un workflow est le bon choix avant de le lancer ? Faites ce test instinctif. Comptez les pièces indépendantes. Si la tâche se divise en environ dix morceaux ou plus qui ne dépendent véritablement pas les uns des autres, le parallélisme compensera le surcoût d'orchestration — c'est votre feu vert. Moins que ça, ou si les pièces dépendent les unes des autres, un primitif plus simple gagne presque certainement en coût.

Et une fois que c'est lancé, surveillez deux choses dans /workflows : le nombre d'agents et le temps réel. Si le nombre d'agents grimpe vers un territoire que vous n'aviez pas prévu — ce déploiement massif à l'échelle du monorepo — arrêtez-le et resserrez votre périmètre. Si un workflow prend bien plus longtemps que le travail séquentiel équivalent, la tâche n'était probablement pas parallélisable en premier lieu et vous avez mal choisi. Toute la promesse de l'ampleur est un temps réel plus rapide grâce au parallélisme. Si vous n'obtenez pas ça, la forme était mauvaise.

Le gain réaliste, quand la forme est bonne : des travaux qui auraient pris une heure de traitement séquentiel à un seul agent se terminent en minutes, parce que le travail était large et que vous l'avez laissé s'étendre. C'est toute la proposition de valeur. Pas de magie. Juste du parallélisme, correctement appliqué, avec le plan maintenu en sécurité hors de la tête du modèle.

La décision unique qui rend tout cela facile

Revenez à ce compteur terminal grimpant au-delà de 41. La raison pour laquelle cette exécution m'a semblé bonne plutôt qu'imprudente n'était pas la technologie. C'était que j'avais fait correspondre l'outil à la forme du travail : un tas large et plat de travaux de notation indépendants, chacun exécutant un skill identique, résultats fusionnés dans le code, sortie minuscule. Bon primitif, bon modèle, périmètre délimité. Tout en aval de cette unique décision était facile.

C'est toute la compétence ici, et ça ne concerne pas vraiment Claude Code du tout. C'est regarder une tâche et poser une question avant de toucher une seule commande : est-ce large ou profond, collaboratif ou indépendant, grand ou petit ? Répondez honnêtement et l'outil se choisit tout seul. Skill pour le petit et répété. Sous-agent pour la course annexe simple. Équipe d'agents pour le véritable débat. Workflow pour l'exploration large et indépendante. /goal pour le travail itératif en profondeur. Les outils chers enveloppant les bon marché, jamais l'inverse.

Alors avant votre prochain gros travail — l'audit de base de code, la recherche large, le jeu de données que vous repoussez — arrêtez-vous et nommez sa forme à voix haute. Large ou profond ? Ce seul mot vous économisera plus de tokens que n'importe quel réglage de l'application. Quel est le travail le plus large sur votre liste que vous faites encore un fichier à la fois ?

Questions fréquemment posées

Que sont les workflows dynamiques Claude Code ?

Les workflows dynamiques Claude Code sont une fonctionnalité, lancée le 28 mai 2026, qui permet à Claude d'écrire un script d'orchestration JavaScript et d'exécuter de nombreux agents indépendants en parallèle sur différentes parties d'une tâche. Le plan vit dans un fichier externe, pas dans la fenêtre de contexte de Claude, et les agents ne communiquent pas — les résultats sont combinés dans la logique du script. Vous en déclenchez un en incluant le mot « workflow » dans votre prompt (nécessite Claude Code v2.1.154+).

En quoi les workflows diffèrent-ils des sous-agents et des équipes d'agents ?

Les workflows lancent de nombreux agents non communicants en parallèle avec le plan maintenu dans un script externe, tandis que les sous-agents exécutent des tâches annexes isolées qui ne rapportent qu'à la session principale, et les équipes d'agents sont un petit groupe qui se parle et partage le contexte pour collaborer. La règle claire : les sous-agents déchargent, les équipes délibèrent, les workflows se déploient large. Pour la distinction plus profonde sur quand les agents devraient communiquer, voir mon guide des équipes d'agents.

Quand utiliser un workflow plutôt que la commande /goal ?

Utilisez un workflow pour l'ampleur — de nombreuses pièces indépendantes et parallélisables comme explorer une base de code ou noter un jeu de données — et utilisez /goal pour la profondeur, où un effort itère en boucle jusqu'à atteindre un objectif. Les workflows s'étendent ; /goal fore en profondeur. Si la tâche est large et superficielle, workflow. Si elle est étroite et profonde, /goal.

Combien coûtent les workflows Claude Code en tokens ?

Le coût d'un workflow est dominé par combien ses agents lisent multiplié par le prix du modèle qu'ils utilisent, donc la même exécution de 5 millions de tokens est bon marché en entrée Haiku et chère en sortie Opus. Les coûts explosent quand les prompts sont vagues ou le périmètre illimité, parce que chacun des jusqu'à 1 000 agents est un appel Claude complet. Délimitez le périmètre et choisissez des modèles bon marché pour l'exploration large et superficielle. Pour le côté modèle, voir ma revue des niveaux d'effort Opus 4.8.

Qu'est-ce que le mode Ultra Code dans Claude Code ?

Ultra Code (/effort ultracode) combine le plus haut effort de raisonnement avec l'orchestration automatique de workflow, permettant à Claude de décider quand chaque tâche substantielle mérite de lancer un workflow. C'est le mode le plus capable de Claude Code et le plus cher — une seule requête peut se déployer en plusieurs workflows successifs. Utilisez-le pour un travail véritablement difficile et de haute valeur, pas comme réglage par défaut.

Travaillons ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows, ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.

• Fiverr (constructions sur mesure & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io