Un harness pour chaque tâche : des workflows dynamiques dans Claude Code

Présentation des Dynamic Workflows de Claude Code

Il s’agit d’un article publié par l’équipe Claude Code d’Anthropic (Thariq Shihipar, Sid Bidasaria), qui présente la nouvelle fonctionnalité de dynamic workflows introduite dans Claude Code. Les dynamic workflows permettent à Claude d’écrire lui-même à la volée, sous forme de fichier JavaScript, sa propre structure d’exécution (harness) adaptée à la tâche, afin de coordonner plusieurs sous-agents. Le harness par défaut de Claude Code est optimisé pour les tâches de développement, mais il montrait ses limites pour les travaux longs, massivement parallèles ou nécessitant une vérification adversariale. L’idée centrale est donc de laisser Claude créer lui-même un harness sur mesure pour y répondre.

Contexte d’introduction et mode de fonctionnement

• Limites d’un contexte unique : lorsqu’on mène planification et exécution simultanément dans une seule fenêtre de contexte, trois modes d’échec apparaissent. Il s’agit de la paresse agentique (agentic laziness), où l’agent déclare avoir fini alors qu’il n’a fait que la moitié du travail, du biais d’auto-préférence (self-preferential bias), qui l’amène à évaluer trop favorablement ses propres résultats, et de la dérive d’objectif (goal drift), où l’objectif initial s’estompe au fil de la compression du contexte.
• Structure de fonctionnement : le workflow exécute un fichier JavaScript pour créer et coordonner des sous-agents, tout en pouvant utiliser des fonctions standard comme JSON, Math ou Array. Le workflow décide lui-même du type de modèle de chaque sous-agent (Sonnet, Opus, etc.) ainsi que de l’isolation éventuelle par worktree. En cas d’interruption, l’exécution peut reprendre via la reprise de session.
• Méthode d’appel : il suffit de demander à Claude de créer un workflow, ou d’utiliser le mot déclencheur "ultracode".

Résumé des principaux patterns

• Classify and Route : un agent classificateur identifie le type de tâche, puis la redirige vers l’agent ou le flux de traitement approprié. Il peut aussi servir à classer le résultat à l’étape finale.
• Fan-out and Synthesize : une grosse tâche est découpée en petites unités, chacune confiée à un agent distinct, puis toutes les sorties sont réunies et fusionnées à l’étape de synthèse (synthesize). Ce pattern convient bien à de nombreux petits travaux nécessitant chacun un contexte propre.
• Adversarial Verification : chaque agent d’exécution est associé à un agent de vérification distinct, chargé de contester et de valider les résultats selon une rubric (grille de critères d’évaluation).
• Generate and Filter : plusieurs idées sont générées, puis filtrées à l’aide d’une rubric et d’un mécanisme de vérification, avec suppression des doublons, afin de ne conserver que les meilleurs candidats.
• Tournament : pour une même tâche, N agents s’affrontent avec des approches différentes, puis un agent arbitre désigne le vainqueur au moyen d’une comparaison par paires (pairwise comparison). L’article explique que cette méthode est plus fiable qu’une évaluation en score absolu.
• Loop Until Convergence : lorsque le volume de travail n’est pas connu à l’avance, la création d’agents se répète jusqu’à ce qu’il n’y ait plus de nouvelle découverte ni d’erreur à corriger.

Résumé des cas d’usage

• Refactoring et migration à grande échelle : les travaux sont découpés par callsite, tests en échec ou modules ; des sous-agents modifient chaque worktree, puis un autre agent effectue une revue adversariale avant fusion. Un cas réel de réécriture de Zig vers Rust est cité, et il est possible de maximiser le parallélisme en demandant d’éviter les commandes gourmandes en ressources.
• Deep research (skill /deep-research) : la recherche web est distribuée en fan-out pour collecter les sources, les affirmations sont vérifiées par validation adversariale, puis le tout est synthétisé en un rapport avec citations. Cela peut aussi servir à rédiger des rapports d’état dans Slack ou à explorer un codebase en profondeur.
• Fact-checking : un agent identifie d’abord toutes les affirmations factuelles d’un rapport, puis un sous-agent de vérification contrôle les sources de chaque affirmation, tandis qu’un agent distinct évalue aussi la qualité des sources.
• Alignement qualitatif et classement : pour des tâches difficiles à traiter en une fois, comme trier plus de 1 000 lignes de tickets de support par gravité, le système s’appuie soit sur un pipeline de comparaisons par paires de type tournoi, soit sur une division en buckets traités en parallèle puis fusionnés.
• Validation de règles et automatisation de CLAUDE.md : des agents de vérification par règle détectent les oublis, tandis qu’un agent à persona sceptique examine la validité même des règles. À l’inverse, les corrections récurrentes observées dans les sessions récentes et les revues de code peuvent être regroupées pour dériver automatiquement de nouvelles règles.
• Débogage de pannes intermittentes et analyse post-mortem : des agents indépendants formulent des hypothèses à partir d’éléments de preuve séparés — logs, fichiers, données — puis un panel de validateurs et de contradicteurs évalue chaque hypothèse. L’approche s’applique non seulement au code, mais aussi à l’analyse d’une baisse de chiffre d’affaires ou d’une panne de pipeline de données.
• Triage et gestion du backlog : les files de support et bug reports sont classées, dédupliquées par rapport aux éléments existants, puis soit corrigées automatiquement, soit remontées à un humain. Un pattern d’isolation (quarantine) est recommandé pour séparer les agents qui lisent du contenu externe non fiable de ceux qui exécutent des actions privilégiées. Combiné à /loop, cela permet une exploitation continue.
• Exploration créative et évaluation (Eval) : pour des tâches où le goût entre en jeu, comme le design ou le naming, plusieurs propositions sont générées puis notées et sélectionnées par des agents de revue selon une rubric. Cela peut aussi servir à de petites évaluations visant à noter et améliorer la qualité d’un skill lui-même.
• Model Routing : un agent classificateur examine d’abord la complexité de la tâche, puis choisit et route vers le modèle le plus adapté entre Sonnet et Opus.

Avantages et différenciation

• Différenciation : les workflows statiques (static) construits avec le Claude Agent SDK ou claude -p doivent être écrits de façon générique pour traiter des cas variés, alors que les dynamic workflows se distinguent par le fait que Claude rédige à chaque fois un harness sur mesure, à la volée.
• Avantages : comme plusieurs agents aux contextes séparés se concentrent chacun sur leur propre objectif, les problèmes de paresse, d’auto-préférence et de dérive d’objectif peuvent être structurellement réduits. Sur le plan opérationnel, la fonctionnalité prend en charge la reprise des sessions interrompues, la définition d’un budget de tokens ("use 10k tokens"), la combinaison avec /goal et /loop, ainsi que le partage via l’enregistrement avec la touche "s" puis le répertoire ~/.claude/workflows ou via des skills.
• Limites et points d’attention : la consommation de tokens peut fortement augmenter, ce qui rend l’approche inadaptée à toutes les tâches. Les auteurs soulignent eux-mêmes qu’un travail de développement ordinaire n’a pas besoin d’un panel de cinq relecteurs, et recommandent de se demander d’abord : « a-t-on vraiment besoin de plus de calcul ? ». Les bonnes pratiques sont encore en cours d’émergence.

Les dynamic workflows apparaissent comme une évolution de Claude Code, qui passe d’un simple assistant de développement à un méta-orchestrateur coordonnant de multiples agents. L’approche vise un point intermédiaire entre pipeline statique et agent autonome, et semble particulièrement efficace pour des travaux longs et structurés comme les migrations de code, le deep research, le triage ou les analyses post-mortem. En revanche, le coût en tokens est élevé et les bonnes pratiques ne sont pas encore stabilisées, ce qui invite à évaluer avec soin la pertinence de chaque pattern et à commencer petit, via des "quick workflows".