Dynamic Workflows dans Claude Code : ce que change l'orchestration externalisée

Le 28 mai 2026, Anthropic a publié une fonctionnalité dans Claude Code qui mérite d’être lue comme un changement d’architecture, pas comme une amélioration d’orchestration : les dynamic workflows. L’idée tient en une phrase, le plan d’orchestration vit dans un script écrit à la volée, en dehors de la fenêtre de contexte du modèle. Ce déplacement, qui peut sembler une optimisation technique, change ce qu’un agent de code peut réellement faire en une session. Il fait passer le plafond de quelques subagents qu’on demande explicitement à des centaines d’agents qui se relancent eux-mêmes jusqu’à converger, sur des tâches qui s’étalent sur des heures et des jours. Le cas d’usage le plus visible, le port de Bun de Zig vers Rust, environ 750 000 lignes en onze jours, 99,8 % des tests passants, n’est plus une expérience de laboratoire mais le résultat documenté d’une seule chaîne d’outils. Le reste de ce post est ce que ça signifie pour qui shippe du code aujourd’hui.

Ce billet est long parce que le sujet est gros. Il couvre l’architecture, le cas Bun en détail, les modes de déclenchement, le pattern de vérification adverse qui distingue ces workflows des simples subagents, l’économie de tokens, les zones où ne pas les utiliser, la gouvernance pour les équipes, et la place qu’ils prennent dans l’écosystème des autres orchestrations possibles. Vous pouvez le lire en séquence ou sauter à la section qui vous concerne.

L’idée centrale : le plan d’orchestration sort de la fenêtre de contexte

Pour comprendre pourquoi les dynamic workflows sont structurellement différents des subagents qu’on utilise depuis des mois, il faut nommer la contrainte qu’ils lèvent.

Un agent normal, même avec des subagents, garde son plan d’exécution dans le contexte du modèle. Le modèle réfléchit, décide de fan-out, attend les retours, intègre. À chaque étape, le plan voyage avec lui dans la fenêtre, ce qui veut dire que plus le plan grandit, moins de place reste pour le travail réel. Au-delà d’une certaine échelle, l’agent passe son temps à raisonner sur sa propre coordination plutôt que sur le code.

Les dynamic workflows franchissent cette barrière en réifiant le plan sous forme de script. La documentation officielle le pose en une phrase : “a dynamic workflow is a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task you describe, and a runtime executes it in the background while your session stays responsive.”. Ce n’est pas une métaphore, le script existe vraiment, comme fichier, sous ~/.claude/projects/<session>/. On peut le lire, le diffuser, le diff avec une exécution précédente, l’éditer et demander à Claude de relancer depuis la version modifiée. L’orchestration n’est plus un comportement émergent du modèle ; c’est un artefact qu’on inspecte.

Anthropic synthétise la conséquence dans le blog post de lancement : “coordination happens outside the conversation, the plan stays on track no matter how big the task gets”. Le mot-clé est outside the conversation. Le plan n’est plus une partie du contexte ; il est une partie du runtime.

Trois conséquences directes, qui font la valeur du release :

D’abord, le nombre de subagents tolérables explose. La documentation pose deux plafonds concrets : “up to 16 concurrent agents, fewer on machines with limited CPU cores” et “1,000 agents total per run”. Le premier borne la consommation locale, le second prévient les boucles d’emballement. En pratique, le régime de croisière documenté est de “dozens to hundreds of agents per run”, ce n’est pas un raffinement à la marge, c’est un changement d’ordre de grandeur par rapport aux trois ou quatre subagents qu’on déclenchait à la main en Opus 4.7.

Ensuite, la durée d’une session se libère. Quand le plan ne mange plus le contexte, une session peut tourner pendant des heures, et le runtime sait reprendre un workflow en pause sans réexécuter ce qui a déjà tourné, les agents déjà terminés restituent leur résultat caché, seuls ceux qui restent tournent vraiment. Le release note revendique des runs qui s’étalent “hours and days”. À une nuance importante près : la reprise marche dans la même session Claude Code. La doc est explicite, “if you exit Claude Code while a workflow is running, the next session starts the workflow fresh”. Pour les runs vraiment longs, garder la session en vie est un prérequis, pas un détail.

Enfin, la vérification adverse devient économique. Quand chaque finding est passé à un second agent qui cherche à le réfuter, la confiance dans le résultat final monte de plusieurs crans. Pour des passes de sécurité ou de migration critique, c’est exactement le ratio qu’on cherche : du compute en plus, du jugement humain en moins.

Comment ça fonctionne, étape par étape

L’architecture documentée tient en quatre étapes, c’est le squelette qu’on retrouve sous toutes les formes du release.

Génération du plan. Claude reçoit la demande, l’analyse, et produit un plan d’orchestration explicite. Ce plan n’est pas une réponse en langage naturel, c’est un script JavaScript qui décrit les sous-tâches, leur séquencement, ce qui peut paralléliser, et les dépendances entre étapes. Dans le mode explicite, ce plan vous est présenté avant exécution ; vous validez, ajustez, ou refusez.

Déploiement parallèle. Le script lance les subagents simultanément. Chaque subagent reçoit un contexte ciblé pour son objectif spécifique, pas le contexte de la session entière. C’est ce qui permet d’en faire tourner des centaines sans saturer aucune fenêtre individuelle. La coordination, qui retourne ses résultats, qui doit attendre quoi, se passe dans le script orchestrateur, pas dans une conversation Claude.

Vérification adverse. C’est l’étape qui distingue ces workflows des fan-outs naïfs. Pour chaque finding non trivial, des agents indépendants tentent activement de le réfuter, ils cherchent l’erreur, le contre-exemple, la régression possible. Anthropic le formule clairement : “agents address problems from independent angles, other agents try to refute what they found, the run iterates until the answers converge”. Un finding qui ne survit pas à sa critique est relancé, raffiné, ou écarté. Ce n’est qu’à la convergence que le résultat remonte à l’utilisateur.

Convergence et restitution. Quand tous les sous-objectifs ont passé leur validation indépendante, l’orchestrateur consolide les résultats et les restitue. Pour les sessions longues, le progrès est sauvegardé en cours de route, un crash machine ou une fermeture de laptop ne tue pas dix heures de travail. C’est ce qui rend la promesse de runs “hours and days” opérationnelle, pas juste théorique.

Le résultat net, vu depuis le terminal de l’utilisateur, c’est une seule conversation qui produit un livrable consolidé. La machinerie qui l’a produit, le script orchestrateur, les centaines de subagents, les boucles de réfutation, reste sous le capot.

Le cas Bun : ce que le port Zig → Rust en onze jours révèle

Le cas d’usage le plus documenté du release est le port de Bun de Zig vers Rust. Les chiffres sont précis dans la communication d’Anthropic : environ 750 000 lignes de code, onze jours du premier commit au merge, 99,8 % de la suite de tests passants à l’arrivée. Ce qui mérite d’être analysé n’est pas la performance brute mais le découpage qui l’a rendue possible.

Le processus, tel qu’il est décrit, se déploie en trois phases.

Phase 1, un workflow cartographie les lifetimes Rust. Avant d’écrire une ligne de Rust, un premier workflow analyse l’ensemble du code Zig existant et produit la cartographie de mémoire et de durée de vie nécessaire pour la transposition. Cette étape capitale ne paralléise pas massivement, c’est de la planification, et la planification est mieux faite par un raisonneur unique de grande qualité. Le workflow l’utilise pour générer le brief que la phase 2 consommera.

Phase 2, des centaines d’agents écrivent les fichiers .rs en parallèle, deux relecteurs par fichier. C’est l’étape où le fan-out massif est utile. Chaque fichier source devient une tâche autonome avec son brief, la cartographie produite en phase 1, et un agent l’écrit. Chaque sortie est vue par deux relecteurs indépendants qui cherchent les erreurs de lifetime, les régressions de comportement, les divergences de signature. Un fichier qui échoue chez l’un des deux relecteurs est renvoyé en réécriture. La boucle ne sort que quand les deux passes valident.

Phase 3, boucle de correction sur les erreurs build/tests, puis optimisation overnight avec PR par fichier. Une fois que le port compile et que la majorité des tests passent, un workflow différent passe sur la queue d’erreurs et de tests rouges, les attribuant à des agents qui corrigent en parallèle. La phase d’optimisation, qui tourne la nuit, génère une pull request par fichier modifié, ce qui permet une revue humaine atomique plutôt qu’un méga-diff illisible.

Ce qu’il faut retenir de cette structure, indépendamment de Bun :

D’abord, l’orchestration n’est pas un seul workflow géant. C’est une chaîne de workflows spécialisés où chacun produit l’artefact que le suivant consomme. La cartographie n’est pas mélangée à l’écriture ; l’écriture n’est pas mélangée à la correction ; l’optimisation est isolée pour permettre une revue PR-par-PR.

Ensuite, la revue humaine reste l’étape qui valide. 99,8 % de tests passants veut aussi dire que les 0,2 % restants ont demandé un humain. La structure en “PR par fichier” dans la phase d’optimisation est explicitement faite pour cadrer cette intervention humaine, pas pour l’éliminer.

Enfin, le coût matériel est massif et assumé. Un projet de ce calibre consomme des dizaines de millions de tokens. À 5 $ le million de tokens d’entrée sur Opus 4.8, c’est plusieurs milliers de dollars de compute, un investissement qui ne se justifie que parce que l’alternative (port manuel par une équipe sur plusieurs mois) coûte vingt à cinquante fois plus en salaire et en time-to-market.

Comment on déclenche un workflow

Trois entrées possibles, et le choix entre les trois modifie qui décide quoi.

Un workflow déjà fourni : /deep-research. C’est le workflow bundled livré avec Claude Code. On lui passe une question, il fan-out sur plusieurs angles de recherche web, croise les sources, vote sur chaque claim, et restitue un rapport cité où les claims qui n’ont pas survécu au croisement sont déjà filtrés. C’est la façon la plus simple de voir un workflow en action sans en écrire un. Ça nécessite que l’outil WebSearch soit disponible dans votre installation.

Demande explicite avec le mot-clé ultracode. Vous incluez ultracode dans votre prompt, ou une formulation naturelle équivalente comme “use a workflow”, “run a workflow”, et Claude écrit un script de workflow plutôt que de travailler tour par tour. Avant la version 2.1.160 le mot-clé littéral était workflow ; les formulations en langage naturel marchent dans les deux versions. Le clavier permet de désamorcer un déclenchement involontaire : Option+W sur macOS ou Alt+W sur Windows et Linux annule le highlight pour ce prompt. C’est le mode à privilégier pour des tâches où le contenu du plan importe, migrations, audits de sécurité, refactorings critiques.

Mode automatique via /effort ultracode. Ce niveau d’effort combine xhigh de raisonnement avec une décision automatique de workflow à chaque tâche substantielle de la session. Une seule requête peut alors déclencher plusieurs workflows successifs, un pour comprendre le code, un pour appliquer le changement, un pour vérifier. C’est puissant mais moins prévisible : un “refactore ce module” anodin peut se transformer en dépense de centaines de milliers de tokens. Le réglage ultracode dure pour la session courante et se réinitialise quand on en démarre une nouvelle, /effort high pour revenir au routinier.

Quel que soit le mode, un prompt de confirmation s’affiche avant le premier workflow dans le mode de permission par défaut. Le prompt liste les phases planifiées, propose “Yes, run it”, “Yes, and don’t ask again for this workflow in this project”, “View raw script”, et “No”. Ctrl+G ouvre le script dans votre éditeur. Tab permet d’ajuster le prompt avant le lancement. Le détail à retenir, côté sécurité : les subagents lancés par un workflow tournent toujours en acceptEdits mode, quel que soit le mode de permission de la session. Les édits de fichiers sont auto-approuvés. Les commandes shell, web fetches et outils MCP qui ne sont pas dans votre allowlist peuvent encore prompter à l’exécution, d’où la recommandation, pour les runs longs, d’ajouter à l’allowlist les commandes que les agents vont avoir besoin avant de démarrer.

Côté requirements et plans, les dynamic workflows sont en research preview et exigent Claude Code v2.1.154 ou supérieur. Ils sont disponibles sur tous les plans payants, Pro, Max, Team, Enterprise, avec quelques nuances : sur Pro, c’est à activer dans /config (ligne Dynamic workflows) ; sur Max et Team, c’est activé par défaut ; sur Enterprise, c’est désactivé par défaut, à charge des administrateurs de l’activer via les managed settings. Côté plateformes, c’est disponible partout : CLI Claude Code, Desktop, extension VS Code, mode non-interactif claude -p, Agent SDK, et côté infrastructure sur Anthropic API, Amazon Bedrock, Google Vertex AI, Microsoft Foundry.

Sauvegarder un workflow qui a bien marché. Quand un run produit ce que vous vouliez, vous pouvez sauvegarder son script comme commande. Depuis la vue /workflows, sélectionnez le run et pressez s. La boîte de dialogue propose deux emplacements, .claude/workflows/ dans le projet (partagé via le repo) ou ~/.claude/workflows/ personnel (visible uniquement par vous). Le workflow devient alors une commande /<nom> réutilisable. Il peut accepter des arguments via une variable globale args lue par le script. C’est exactement le pattern de capitalisation qui transforme une découverte ponctuelle en outil d’équipe.

Le pattern adverse : le second passage qui change tout

C’est probablement la partie la plus sous-estimée du release. Les dynamic workflows ne sont pas juste “des subagents, mais beaucoup”. Ils sont “des subagents qui produisent du travail, suivis par d’autres subagents qui cherchent à démolir ce travail”.

La distinction compte. Un fan-out naïf, cinquante agents qui scannent cinquante fichiers en parallèle, a un mode d’échec connu : si l’un d’eux se trompe, son erreur passe inaperçue dans le rapport consolidé. Sur cinquante fichiers, ça reste gérable ; sur cinq cents, l’erreur silencieuse devient la règle plutôt que l’exception.

La couche adverse résout ça en demandant à un autre agent, avec un contexte différent, parfois un modèle différent, de chercher activement le contre-exemple. Si le finding initial est “cette fonction est dead code”, le second agent doit chercher tout usage qui invaliderait ce verdict : imports indirects, références par chaîne, hooks de plugin, métaprogrammation. Si le second agent trouve un usage, le finding initial est retourné en correction, pas mergé.

Ce pattern fait écho à ce qui est documenté dans la littérature sur l’auto-vérification, mais l’industrialisation en est nouvelle. C’est aussi pour ça que les retours de premiers utilisateurs publiés par Anthropic se concentrent sur les tâches de discovery and review, dead code chez Klarna, longs runs à confier sans perdre visibilité chez CyberAgent. Ces tâches sont exactement celles où le rapport coût-bénéfice du second passage est le plus favorable : on cherche dans une grande surface, on tolère mal le faux positif, on tolère encore moins le faux négatif.

L’économie de tokens : ce que les benchmarks de coût disent

Il faut nommer le coût directement. Un workflow dynamique consomme substantiellement plus de tokens qu’une session Claude Code typique, c’est dans la documentation, ce n’est pas une trahison à dénoncer.

Quelques repères concrets, tels que rapportés par des analyses pratiques :

À l’étape 15 d’un workflow long, chaque appel peut coûter dix mille tokens rien que pour le raisonnement de contexte, avant tout travail utile.
Un workflow qui rencontre un obstacle et boucle peut dépenser cinq fois plus que la même tâche exécutée proprement.
Pour des audits de repository moyens, on parle de plusieurs millions de tokens ; pour des migrations multi-jours, de dizaines de millions.

À la grille tarifaire d’Opus 4.8, 5 $ par million de tokens d’entrée, 25 $ par million de tokens de sortie, une migration sérieuse, c’est plusieurs centaines à plusieurs milliers de dollars de compute. La logique de justification est simple : si le travail équivalent humain coûte plus que ça (et pour une migration de 750 000 lignes, c’est largement le cas), le workflow est rentable. Sinon, ce ne l’est pas.

Trois leviers concrets pour cadrer la dépense :

Modèle par tâche. Utilisez Opus pour l’orchestrateur et les sous-tâches qui demandent du raisonnement profond. Sonnet pour la complexité moyenne. Haiku pour le travail à fort volume mais peu profond, “trouve tous les fichiers qui importent X”, “liste les fonctions sans tests”. La même analyse pratique évalue à 60-80 % la réduction de coût quand on hiérarchise correctement les modèles par tâche.

Budgets de tokens explicites. Un workflow sans plafond est un mode d’échec. Définissez à l’avance le budget que vous êtes prêt à consommer ; le workflow doit s’arrêter et demander une décision quand il l’approche, pas le dépasser silencieusement.

Vérification de complétion séparée. Un appel dédié, à la fin, qui valide que le résultat répond au prompt initial, pas à un objectif dérivé. C’est un coût marginal pour éviter qu’un workflow ne consomme dix millions de tokens à résoudre la mauvaise question.

Quand ne pas utiliser un workflow dynamique

C’est l’angle le plus important du release et le moins commenté. Les workflows dynamiques ne sont pas un upgrade gratuit ; ils sont l’outil qui convient à une catégorie spécifique de tâches. Pour les autres, ils sont au mieux du gaspillage, au pire un mode d’échec coûteux.

Quand la tâche est répétitive et à grande échelle. Une pipeline qui doit tourner mille fois par jour ne mérite pas un workflow dynamique, elle mérite un workflow statique, codé une fois et exécuté à coût prévisible. La force des workflows dynamiques est la non-prédictibilité de leur plan. C’est aussi leur faiblesse en mode production : on n’industrialise pas un comportement non-déterministe.

Quand la structure est connue à l’avance. Si vous savez que votre tâche est “recherche → rédaction → validation”, vous n’avez pas besoin que Claude réinvente cette structure à chaque exécution. Un système de subagents flat, où vous écrivez le scénario, est plus économique et plus auditable.

Quand la prédictibilité de coût compte. Un workflow dynamique peut coûter cent dollars une fois et trois mille dollars la fois suivante, en fonction des chemins qu’il explore. Si votre budget est cadré, c’est un risque que vous n’avez pas à prendre. Préférez les architectures à coût borné.

Quand la fiabilité de production est critique. Un workflow qui décide lui-même de la décomposition de la tâche peut, occasionnellement, décider mal. Pour le développement et l’exploration, c’est acceptable et même utile. Pour un job qui tourne sans supervision à 3h du matin, ce n’est pas.

Au-delà de 30 étapes. Le seuil empirique qui circule dans les guides pratiques est qu’au-delà d’une trentaine d’étapes, un workflow dynamique commence à payer un coût de coordination disproportionné. À cette échelle, des subagents bien scénarisés sont plus efficaces et plus debuggables.

Le résumé pratique : workflows dynamiques pour l’exploration de tâches ambiguës et de grande taille ; subagents flat pour l’industrialisation ; /goal ou plan mode pour le développement interactif. Choisir le bon outil compte plus que d’avoir le plus puissant.

Gouvernance : ce que les admins doivent savoir

Pour les équipes qui paient la facture, l’arrivée des workflows dynamiques mérite trois décisions explicites.

Activer ou désactiver par défaut. Sur Enterprise, c’est désactivé par défaut. Pour les équipes Team, c’est activé. Si votre organisation a des règles de coût strictes ou des contraintes de sécurité particulières, l’option de désactivation existe via les managed settings, c’est la décision à prendre avant qu’un ingénieur curieux ne lance accidentellement un audit de tout le monorepo. Les interrupteurs concrets, documentés en clair : disableWorkflows: true dans les managed settings de l’organisation, le toggle sur la page admin de Claude Code, ou la variable d’environnement CLAUDE_CODE_DISABLE_WORKFLOWS=1 propagée via votre image de poste. Quand les workflows sont désactivés, les commandes bundled comme /deep-research disparaissent, le mot-clé ultracode ne déclenche plus rien, et ultracode est retiré du menu /effort.

Définir une politique de budget. Sans budget explicite, un workflow peut consommer en une nuit ce que vous comptiez dépenser en un mois. Anthropic n’impose pas de plafond par défaut, c’est à vous. La règle pratique qui fonctionne : un budget par session, un autre par jour, et un mécanisme d’alerte qui dit “ce workflow approche du budget, voulez-vous continuer ?”.

Observer la traçabilité des changements. Quand un workflow ouvre une PR par fichier modifié, c’est parce que la revue humaine doit pouvoir suivre. Sans cette structure, vous vous retrouvez avec un commit unique de quinze mille lignes, illisible et impossible à reviewer en bloc. La discipline du “un workflow = un changement structuré en PRs atomiques” est ce qui rend l’industrialisation tenable.

C’est aussi à ce niveau que la question de la mémoire partagée entre subagents cesse d’être théorique. Quand vous avez cent agents qui modifient le même repo en parallèle, le problème de coordination déborde le runtime de Claude Code et devient un problème de votre infrastructure. Un système de verrous applicatifs, ou plus simplement de partitionnement strict des fichiers entre agents, devient nécessaire au-delà d’un certain nombre d’agents simultanés.

Où ces workflows s’inscrivent dans l’écosystème des orchestrations

Pour conclure ce panorama, il vaut la peine de remettre les workflows dynamiques en perspective avec les autres patterns d’orchestration disponibles dans Claude Code aujourd’hui.

Single-agent. Un agent seul, sans subagents. C’est le baseline. À privilégier pour tout travail qui rentre dans une fenêtre de contexte sans difficulté et qui n’a pas besoin de parallélisation.

Subagents flat (/agents). Vous définissez explicitement les subagents et leur orchestration. Bon pour les pipelines connus à structure stable : research → write → review. C’est ce qui marchait déjà en Opus 4.7 et qui reste pertinent en 4.8, notamment pour les déploiements production.

Agent teams. Les subagents qui communiquent entre eux, partagent une liste de tâches, peuvent s’assigner du travail. Plus coûteux que des subagents flat, mais utiles pour les projets multi-domaines où la cohésion entre tâches compte.

Plan mode (/plan) et /goal. Pour le développement interactif où vous voulez voir le plan avant qu’il s’exécute, et où vous redirigez en cours de route. Sessions humain-dans-la-boucle, pas automatisation.

Dynamic workflows. L’option qu’on vient de couvrir. Pour les tâches grandes, ambiguës, où le plan ne peut pas être pré-spécifié, et où la vérification adverse justifie le coût supplémentaire.

L’arbre de décision pratique :

La tâche tient dans une session normale ? Single-agent.
La tâche a une structure connue avec quelques sous-tâches ? Subagents flat.
La tâche est multi-domaine avec besoin de coordination ? Agent teams.
Vous voulez voir le plan et le rediriger en cours ? Plan mode ou /goal.
La tâche est grande, ambiguë, et tolère un coût significatif pour gagner en vérification ? Dynamic workflow.

Chaque niveau dans cet arbre coûte plus que le précédent, en tokens, en latence, et en complexité de debug. Le piège commun, maintenant que les workflows dynamiques existent, va être de les utiliser pour des tâches qui auraient été parfaitement servies par un single-agent à xhigh.

Ce que ça change pour la façon dont on conçoit un agent

Pour synthétiser, voici les quatre déplacements mentaux que ce release demande à qui conçoit ou utilise des agents de code.

Penser en chaîne de workflows spécialisés, pas en workflow géant. Le cas Bun le démontre : un seul workflow qui ferait cartographier, écrire, corriger, optimiser serait inférieur à quatre workflows enchaînés. Le découpage par phase est ce qui rend la verification adverse économique et la revue humaine possible.

Penser au plan comme à du code, pas à du langage naturel. Le plan d’orchestration est désormais un artefact technique qu’on peut versionner, debugger, modifier. Pour des workflows récurrents même non-déterministes dans le détail, cataloguer les plans qui ont bien marché devient un actif.

Penser à la vérification adverse comme un composant standard. Le second passage qui cherche à réfuter n’est plus un luxe, c’est ce qui fait la différence entre un fan-out qui produit de la confiance et un fan-out qui produit du bruit. Sur toute tâche où une erreur silencieuse coûte cher, l’adversariat doit être budgété d’office.

Penser au coût comme à un paramètre, pas à un mystère. Les workflows dynamiques ne sont pas chers ; ils sont prédictiblement chers selon des leviers qu’on contrôle. Modèle par tâche, budget explicite, vérification de complétion : ces trois disciplines suffisent à rester dans le ratio coût-bénéfice qu’on visait.

Le pari implicite d’Anthropic est que cette catégorie de travail, les migrations de grande échelle, les audits exhaustifs, les modernisations qui s’étalaient sur des trimestres, est exactement celle qui était sous-servie par les agents jusqu’à présent. Les chiffres de Bun suggèrent que le pari tient. Reste à voir ce que les équipes en feront quand le release sortira des mains de quelques utilisateurs early-access pour atterrir dans les pipelines de production. Si vous travaillez sur Claude Code, c’est probablement la fonctionnalité la plus structurante des six derniers mois. Et si vous concevez un agent personnalisé, en MCP, en code, en hybride, la grammaire des workflows dynamiques est désormais le vocabulaire à connaître.

Pour aller plus loin : la lecture des quatre disciplines de Claude Code cadre les principes qui restent vrais peu importe l’orchestration. Le post sur Claude Opus 4.8 couvre le modèle qui rend tout ça possible. Et la question de la mémoire partagée entre agents devient particulièrement aiguë quand cent subagents tournent en parallèle sur le même repo.

Si cela vous a parlé, vous aimerez Claude Opus 4.8 : un modèle qui rattrape ses propres bugs et Claude Code : quatre disciplines plutôt que trente-deux hacks. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.