Un harness adapté à chaque tâche : les workflows dynamiques de Claude Code

• Les workflows dynamiques permettent à Claude Code d’écrire à la volée un harness adapté à la tâche, en prenant nativement en charge dans le code des harness personnalisés qui étaient auparavant construits séparément
• Ils exécutent des fichiers JavaScript pour créer et orchestrer des subagents, avec la possibilité de choisir le modèle utilisé par chaque agent ainsi que l’isolation ou non via worktree
• Ils empêchent structurellement, grâce à des contextes séparés, des modes d’échec comme agentic laziness, self-preferential bias, goal drift qui apparaissent dans une fenêtre de contexte unique
• Ils peuvent aussi servir à des tâches non techniques hors du codage, comme les migrations, deep research, classements, triage, analyses de causes racines
• Leur consommation de tokens est élevée, donc ils ne sont pas nécessaires pour toutes les tâches, mais constituent un point de départ pour étendre Claude Code de façon créative

---

Vue d’ensemble des workflows dynamiques

• La semaine dernière, Claude Code a lancé les workflows dynamiques, qui permettent à Claude d’écrire à la volée un harness adapté à la tâche
• Le harness de base de Claude Code a été conçu pour le codage, mais comme beaucoup de tâches ressemblent à des tâches de développement, il peut aussi être utile pour d’autres types de travaux
• Des outils comme Research, security analysis, agent teams ou Code Review obtenaient jusqu’ici les meilleures performances en construisant des harness personnalisés au-dessus de Claude Code
• Les workflows résolvent désormais nativement ces problèmes dans Claude Code, avec prise en charge du partage et de la réutilisation
• Les bonnes pratiques sont encore en cours d’évolution, et comme la consommation de tokens est élevée, il faut réfléchir avec soin au moment et à la manière de les utiliser

Exemples de prompts

• « Ce test peut échouer environ une fois sur 50 exécutions. Construis un workflow capable de reproduire cela. Formule plusieurs hypothèses sur la course et continue jusqu’à ce qu’une hypothèse plausible émerge à partir des preuves. »
• « Utilise un workflow pour examiner les 50 dernières sessions, repérer ce qui est corrigé de façon répétée, puis transformer les éléments récurrents en règles CLAUDE.md »
• « Utilise un workflow pour analyser #incidents sur Slack sur les 6 derniers mois et trouver des causes racines récurrentes pour lesquelles personne n’a créé de ticket. »
• « Prends mon business plan et exécute un workflow dans lequel plusieurs intervenants l’analysent minutieusement du point de vue des investisseurs, des clients et des concurrents. »
• « Voici un dossier contenant 80 CV. Utilise un workflow pour classer les CV adaptés à un poste backend, puis revérifie les 10 meilleurs. Utilise l’outil AskUserQuestion pour m’interviewer selon une grille d’évaluation. »
• « Il faut donner un nom à cet outil CLI. Utilise un workflow pour brainstormer plusieurs options et sélectionner les 3 meilleures sous forme de tournoi. »
• « Utilise un workflow pour renommer partout le modèle User en Account. »
• « Relis très attentivement le brouillon de mon article de blog et utilise un workflow pour confronter la codebase à toutes les affirmations techniques. Je ne veux pas publier d’informations incorrectes. »

Comment fonctionnent les workflows dynamiques

• Exécution d’un fichier JavaScript incluant plusieurs fonctions spéciales qui facilitent la création et l’orchestration de subagents
• Prise en charge du traitement de données grâce aux fonctions JavaScript standard comme JSON, Math ou Array
• Possibilité de choisir le modèle utilisé par les agents et de décider si les subagents doivent être isolés dans un worktree, Claude choisissant le niveau d’intelligence et d’isolation nécessaire
• Même si un workflow est interrompu par une action de l’utilisateur ou la fermeture du terminal, il peut reprendre au point d’arrêt lors de la reprise de session

Pourquoi les workflows dynamiques sont nécessaires

• Le harness de base effectue la planification et l’exécution dans une fenêtre de contexte unique ; c’est efficace pour de nombreuses tâches de codage, mais cela montre ses limites pour les tâches longues, massivement parallèles, très structurées ou adversariales
• Plus une tâche complexe reste longtemps dans un seul contexte, plus elle devient vulnérable à certains modes d’échec
  • Agentic laziness : arrêt avant la fin d’une tâche complexe en plusieurs étapes, avec déclaration de réussite après une exécution partielle seulement (par exemple, 20 points traités sur 50 dans une revue de sécurité)
  • Self-preferential bias : tendance à privilégier son propre résultat lors de la vérification ou de l’évaluation par rapport à un rubric
  • Goal drift : perte progressive de fidélité à l’objectif initial au fil des tours, surtout après compaction, avec disparition des exigences edge-case ou des contraintes du type « ne pas faire X »
• Ces problèmes sont évités en coordonnant plusieurs Claude avec des fenêtres de contexte séparées et des objectifs ciblés et isolés

Workflows dynamiques vs statiques

• Jusqu’à présent, il était possible d’écrire des workflows statiques pour orchestrer plusieurs instances de Claude Code via le Claude Agent SDK ou claude -p
• Les workflows statiques doivent couvrir tous les edge cases, ce qui les rend en général plus génériques
• Avec Claude Opus 4.8 et les workflows dynamiques, Claude est désormais assez intelligent pour écrire lui-même un harness sur mesure adapté au cas d’usage

Schémas d’utilisation des workflows dynamiques

• On peut demander à Claude de générer un workflow, ou garantir sa création avec le mot déclencheur ultracode
• Il existe des schémas récurrents que Claude combine lorsqu’il construit un workflow

• Classify-and-act

  • Un agent classifieur détermine le type de tâche, puis la route vers différents agents ou actions selon le cas, ou utilise un classifieur final pour décider de la sortie

• Fan-out-and-synthesize

  • La tâche est découpée en petites étapes, un agent étant exécuté pour chaque étape avant synthèse des résultats
  • Utile lorsqu’il y a beaucoup de petites étapes ou que chaque étape bénéficie d’une fenêtre de contexte propre, afin d’éviter interférences et contaminations croisées
  • L’étape de synthèse agit comme une barrière : elle attend tous les agents de fan-out puis fusionne les sorties structurées en une seule

• Adversarial verification

  • Pour chaque agent généré, un agent séparé exécute une vérification adversariale de la sortie par rapport à un rubric ou à des critères

• Generate-and-filter

  • Génère de nombreuses idées sur un sujet puis les filtre via un rubric ou une vérification, déduplique et ne retourne que les meilleures idées validées

• Tournament

  • Au lieu de découper le travail, les agents sont mis en concurrence : N agents tentent la même tâche avec des approches différentes, et un agent arbitre juge en pairwise jusqu’à désigner un gagnant

• Loop until done

  • Quand la charge de travail est incertaine, on crée des agents de manière répétée jusqu’à satisfaction d’une condition d’arrêt, au lieu d’un nombre fixe d’itérations

Cas d’usage

• Les workflows peuvent parfois être encore plus utiles pour des tâches non techniques

• Migration et refactorisation

  • Bun a été réécrit de Zig vers Rust grâce à un workflow ; plus de détails dans le thread X de Jarred
  • Le point clé consiste à décomposer en étapes de travail comme les callsites, les tests en échec ou les modules
  • Des subagents sont créés dans des worktrees pour chaque modification, puis d’autres agents effectuent une revue adversariale avant fusion
  • On peut aussi leur demander d’éviter les commandes gourmandes en ressources pour maximiser le parallélisme sans épuiser la machine

• Deep research

  • Une skill de deep research (/deep-research) utilisant les workflows dynamiques a été publiée ; elle fait du fan-out sur la recherche web, récupère les sources, vérifie les affirmations de manière adversariale, puis synthétise un rapport avec citations
  • Au-delà de la recherche web, elle peut servir à rédiger des rapports d’état à partir du contexte Slack ou à analyser en profondeur une codebase pour comprendre le fonctionnement d’une fonctionnalité

• Vérification approfondie

  • Pour vérifier et sourcer toutes les affirmations factuelles d’un rapport, un workflow peut faire identifier toutes les affirmations par un agent, puis les faire vérifier en détail une par une par des subagents
  • Les agents de vérification peuvent aussi évaluer la qualité des sources utilisées par les subagents chargés des sources

• Classement

  • Utile pour classer des éléments selon des critères qualitatifs, par exemple des tickets de support par gravité de bug
  • Trier plus de 1000 lignes dans un seul prompt dégrade la qualité et peut dépasser le contexte ; à la place, on peut utiliser un tournoi, un pipeline de comparaisons pairwise ou un bucket-rank parallèle avant fusion
  • Le jugement comparatif est plus fiable qu’un score absolu ; comme chaque comparaison est faite par un agent distinct, une boucle déterministe conserve le bracket et seul l’ordre d’exécution reste dans le contexte

• Mémoire et respect des règles

  • Si certaines règles échappent encore à Claude même une fois placées dans CLAUDE.md, un workflow peut maintenir une liste de règles et faire vérifier chacune par un agent dédié
  • Pour réduire les faux positifs, on peut créer des subagents à persona sceptique chargés d’examiner les règles
  • L’inverse est aussi possible : extraire des corrections répétées à partir des sessions récentes et des commentaires de revue de code, les regrouper via des agents parallèles, puis soumettre chaque règle candidate à une vérification adversariale (« cette règle aurait-elle réellement évité cette erreur ? ») avant de raffiner les règles survivantes dans CLAUDE.md

• Analyse de causes racines

  • Le débogage est plus efficace lorsqu’on formule et teste plusieurs hypothèses indépendantes, mais dans une fenêtre de contexte unique cela peut introduire un self-preferential bias
  • Les workflows l’évitent structurellement en générant des hypothèses via des agents séparés selon les preuves disponibles (logs, fichiers, données), puis en soumettant chaque hypothèse à un panel de validateurs et de contradicteurs
  • Cela vaut aussi pour des post-mortems hors code, comme l’analyse d’une baisse du chiffre d’affaires en mars côté ventes ou l’échec d’un pipeline côté data engineering

• Triage à grande échelle

  • Pour des files de support, bug reports ou backlogs trop volumineux pour être traités à la main, un workflow de triage peut classer chaque élément, éliminer les doublons avec les éléments déjà suivis et déclencher une action (tenter une correction ou escalader vers un humain)
  • Un schéma utile est la quarantaine, qui bloque les actions à privilèges élevés des agents lisant du contenu public non fiable, tandis qu’un agent distinct se charge du traitement de l’information
  • Il peut être combiné à /loop pour une exécution continue

• Exploration et préférences

  • Utile pour explorer des solutions fondées sur le goût, comme le design ou le naming, tout en bénéficiant d’un rubric
  • On peut faire explorer plusieurs solutions, fournir à un agent de revue un rubric décrivant ce qui fait une bonne solution, puis considérer la tâche terminée quand cet agent juge que les critères sont satisfaits ; un tournoi peut ensuite classer et sélectionner

• Évaluations (Evals)

  • On peut exécuter des évaluations légères en créant des agents séparés dans des worktrees puis en les notant par rapport à un rubric via des agents comparateurs ; par exemple, évaluer et améliorer une skill générée selon des critères donnés

• Routage modèle / intelligence

  • Un agent classifieur peut choisir le modèle le plus adapté à une tâche, après une enquête préalable dans les tâches impliquant de nombreux appels d’outils
  • Par exemple, pour la tâche « expliquer le fonctionnement du module auth », le meilleur modèle dépend du nombre de fichiers du module auth et de la forme de la codebase ; le classifieur enquête puis route vers Sonnet ou Opus selon la complexité

Quand ne pas les utiliser

• Les workflows sont une fonctionnalité récente ; ils donnent d’excellents résultats dans de nombreux cas, mais ne sont pas nécessaires pour toutes les tâches et peuvent consommer nettement plus de tokens
• Ils conviennent bien à des usages créatifs qui poussent Claude Code dans des directions auparavant impossibles
• Pour les tâches de codage ordinaires, il faut se demander : « ai-je vraiment besoin de plus de calcul ? » ; dans la plupart des cas, un panel de 5 reviewers n’est pas nécessaire pour du développement classique

Conseils pour construire des workflows dynamiques

• Prompting

  • Un prompting détaillé utilisant les techniques décrites plus haut donne les meilleurs résultats
  • Ils ne sont pas réservés aux tâches massives ; on peut aussi demander un « quick workflow » pour obtenir rapidement, par exemple, une revue adversariale d’hypothèses

• Combinaison avec /goal et /loop

  • Les workflows répétables, comme le triage, la recherche ou la vérification, peuvent être exécutés régulièrement avec /loop, et /goal permet de fixer des exigences strictes de complétion

• Budget d’utilisation des tokens

  • On peut définir explicitement un budget de tokens par tâche ; un prompt comme « use 10k tokens » permet de fixer un plafond

• Sauvegarde et partage

  • Dans le menu des workflows, appuyer sur « s » pour sauvegarder ; ils peuvent ensuite être commités dans ~/.claude/workflows ou publiés comme skill
  • Pour les partager comme skill, placer le fichier JavaScript du workflow dans le dossier de la skill et le référencer dans SKILL.md ; pour plus de flexibilité, le prompt doit le traiter comme un template plutôt que comme un script à exécuter tel quel dans la skill

• Point de départ pour l’extension

  • Les workflows constituent une nouvelle manière d’étendre Claude Code, et leur meilleur mode d’emploi reste encore largement à découvrir