Dynamic workflows : Anthropic a industrialisé la consommation de tokens

Il y a deux façons de lire l’annonce des dynamic workflows dans Claude Code, publiée le 28 mai. La première, celle que tout le monde reprendra, tient dans le slogan : un travail que vous planifiiez en trimestres se boucle désormais en quelques jours. La seconde se cache dans une note discrète, répétée deux fois dans le même billet : la fonctionnalité consomme « sensiblement plus » de quota qu’une session normale, et Anthropic vous recommande de commencer sur une tâche réduite « pour vous faire une idée de la consommation ».

C’est cette seconde lecture qui m’intéresse. Parce que la vraie nouveauté n’est pas la capacité. C’est la facture.

Ce que la chose fait, en deux paragraphes

Le principe : au lieu de lancer un seul agent qui avance pas à pas, Claude Code écrit dynamiquement un script d’orchestration qui répartit la tâche sur des dizaines à des centaines de sous-agents tournant en parallèle dans une même session. Certains attaquent le problème sous des angles indépendants, d’autres jouent les adversaires et tentent de réfuter ce que les premiers ont trouvé, et la boucle itère jusqu’à convergence. La progression est sauvegardée au fil de l’eau, donc une exécution interrompue reprend où elle s’était arrêtée, et la coordination se passe hors conversation pour que le plan ne dérive pas quand la tâche grossit.

Côté usage, deux portes d’entrée : demander explicitement à Claude de créer un workflow, ou activer un nouveau réglage maison, ultracode, qui pousse l’effort au niveau xhigh et laisse Claude décider seul du moment où déclencher l’orchestration. La fonctionnalité est en research preview, disponible sur les plans Max, Team et Enterprise ainsi que via l’API, Bedrock, Vertex et Foundry. Voilà pour la mécanique. Elle est élégante. Elle n’est pas le sujet.

Le sujet, c’est le compteur

J’avais écrit, en mars, que la promesse d’IA illimitée était un mirage et que le modèle économique réel d’un éditeur de LLM consiste moins à ce que vous réussissiez une tâche qu’à ce que vous en consommiez le plus possible en la réussissant (Le mirage de l’IA illimitée, pour qui veut le raisonnement complet). Les dynamic workflows ne contredisent pas cette thèse. Ils l’instancient.

Réfléchissons à ce qui est optimisé. Un agent unique qui résout un bug consomme un certain nombre de tokens. Cent agents qui s’attaquent au même bug, dont une moitié travaille à démolir le travail de l’autre, en consomment un ordre de grandeur de plus, pour un résultat dont l’annonce reconnaît elle-même qu’il « converge » plutôt qu’il ne se déduit. On a remplacé la déduction élégante par une force brute algorithmique, et chaque tour de réfutation, chaque réexécution contre la suite de tests, se paie en calcul. La valeur ajoutée technique est réelle sur certaines tâches massives. La valeur ajoutée commerciale, elle, est mécanique : plus de calcul facturé pour la même unité de problème résolu.

C’est exactement la logique inverse de celle que je documentais dans Prompt caching, où l’enjeu était de payer dix fois moins cher pour les mêmes tokens. Là, on paie dix fois plus pour le même livrable, et on appelle ça un progrès.

Le double verrouillage, ou l’aveu qui en dit long

Voici le détail que je n’aurais pas osé inventer. Sur les plans Max et Team, les dynamic workflows sont activés par défaut. Sur Enterprise, ils sont désactivés par défaut au lancement, charge à l’administrateur de les ouvrir.

Lisez-le lentement. Les deux plans où le mode « brûle du token » s’active tout seul sont les plans grand public les plus chers, ceux vendus sur la promesse du confort et de l’abondance. Le plan Enterprise, lui, est protégé par défaut, parce qu’en face il y a un service achat qui regarde la note et un administrateur qui peut dire non. Autrement dit : Anthropic oriente spontanément vers le mode le plus dispendieux les clients qui ne verront pas passer la dépense ligne à ligne, et met une sécurité là où quelqu’un surveille.

L’aveu ne s’arrête pas là. La première fois qu’un workflow se déclenche, Claude Code affiche ce qui va tourner et vous demande de confirmer. On présente cela comme de la transparence. C’est surtout la preuve qu’Anthropic sait que la facture peut surprendre, au point de devoir vous prévenir avant de débiter. Une abondance qui demande votre accord avant de dépenser n’est pas une abondance : c’est un forfait à compteur qui a gardé le mot « illimité » sur la brochure.

Le cas Bun : une démo de vitesse, pas une preuve de fiabilité

L’annonce s’appuie sur un exemple spectaculaire : la réécriture de Bun, porté de Zig vers Rust avec, dit-on, environ 750 000 lignes de Rust, 99,8 % de la suite de tests existante qui passe, et onze jours entre le premier commit et le merge. Des agents par centaines, deux relecteurs par fichier, une boucle de correction qui pilote build et tests jusqu’au vert.

Le chiffre est conçu pour qu’on s’incline. Instruisons-le plutôt, avec la grille que j’appliquais déjà aux modèles dans les LLM sont des gruyères, où je montrais que la surface impressionnante d’un LLM cache des trous structurels.

Trois questions, donc. D’abord, que valent 0,2 % de tests en échec sur un runtime système ? Sur la plupart des logiciels, c’est anecdotique. Sur un runtime JavaScript, dont le métier consiste précisément à gérer correctement les cas limites que les autres ignorent, ces 0,2 % sont peut-être exactement la partie difficile, celle qui justifiait d’écrire le projet en premier lieu. Le pourcentage qui rassure mesure le facile et masque le coûteux.

Ensuite, que fait la formule « while not yet in production », glissée presque en passant à la fin du paragraphe ? Énormément de travail. Un portage qui passe les tests mais ne tourne pas en production, c’est, dans le métier, un portage qui n’est pas terminé. La distance entre les deux états est précisément là où vivent les bugs que les tests ne capturent pas. Présenter le premier état comme un accomplissement et reléguer le second en incise, c’est de la rhétorique, pas de l’ingénierie.

Enfin, et c’est le point que personne ne chiffrera : combien a coûté cette démonstration, en tokens et surtout en heures de revue humaine ? « Deux relecteurs par fichier » sur des centaines de fichiers, ce ne sont pas que des agents, ce sont des décisions à valider. La démo prouve qu’on peut produire 750 000 lignes très vite. Elle ne prouve pas qu’on peut les auditer. Confondre les deux, c’est tout l’argumentaire commercial.

Où passe le développeur

Reste la question du métier, et je vais la poser sans nostalgie de l’artisanat perdu, parce que ce registre lasse autant qu’il égare. Le problème n’est pas romantique, il est matériel.

Quand Claude déploie deux cents agents sur une migration de plusieurs milliers de fichiers et que vous « revenez à une réponse unique et coordonnée », le travail de production a bien été délégué. Mais le travail de vérification, lui, n’a disparu nulle part. Il s’est déplacé, et il a changé de nature. Vous ne relisez plus un diff que vous avez pensé : vous validez un résultat que vous n’avez pas vu se construire, produit par un essaim dont vous ne pouvez pas reconstituer le raisonnement, sur un volume qu’aucun humain ne peut auditer ligne à ligne dans le temps imparti. C’est l’exact prolongement de ce que j’analysais dans la grande dépossession, où le développeur ne perd pas son emploi mais perd la maîtrise de ce qu’il signe.

La charge cognitive ne s’évapore pas. Elle se concentre sur un point de contrôle unique, en aval, là où elle est la moins tenable. On vous vend la suppression de l’effort de production ; on vous livre une dette de vérification que l’échelle rend impayable. Le coût n’a pas disparu, il est sorti du champ de vision, exactement comme la facture énergétique du vibe coding ne disparaît pas parce qu’on ne la voit pas tourner.

Et c’est là que se joue le transfert le plus silencieux de toute l’opération. Si un workflow brûle pour 500 dollars de tokens et produit un code qui passe les tests mais plante en production, Anthropic ne rembourse rien. Vous avez payé le calcul, vous portez le défaut, et c’est votre nom qui figure sur le commit. La responsabilité, elle, ne se parallélise pas : aucun des deux cents agents ne sera convoqué quand le service tombera. Le développeur reste le fusible unique d’un système conçu pour qu’il ne puisse plus en inspecter le câblage.

Anthropic livre la tour de contrôle qu’il jugeait inutile

Je dois une honnêteté à mes propres archives. Le 23 mai, à propos de Switchboard, j’écrivais que Claude Code n’avait pas besoin d’une tour de contrôle externe pour orchestrer ses sessions (Switchboard : la tour de contrôle dont Claude Code n’avait pas besoin ?). Cinq jours plus tard, Anthropic en livre une, native, intégrée, et bien plus ambitieuse.

Deux lectures s’offrent, et je refuse de cacher celle qui me dérange. Première lecture : le besoin d’orchestration existait, et j’ai eu tort de le sous-estimer en jugeant qu’un outil tiers était de trop. Seconde lecture : Anthropic confirme l’autre intuition, celle que je posais en mars dans Claude Code va vite, mais va-t-il assez loin ?, où je doutais qu’un agent unique aille au bout du vrai travail. En industrialisant le parallélisme, l’éditeur admet noir sur blanc qu’un seul agent ne suffit pas pour les tâches qui comptent.

Les deux lectures sont probablement vraies en même temps. Switchboard répondait à un manque réel par le mauvais étage ; Anthropic répond au même manque par le bon, mais en facturant l’étage entier.

Vu du produit, vu de la caisse

Le calendrier dissipe tout doute sur la priorité. Le jour même où Anthropic dévoilait les dynamic workflows, l’entreprise bouclait une levée de 65 milliards de dollars à une valorisation de 965 milliards, dépassant OpenAI, sur la foi d’un chiffre d’affaires annualisé qui aurait progressé d’environ moitié en sept semaines. On ne valorise pas une telle trajectoire sur la qualité des réponses, on la valorise sur le volume de calcul facturé. La fonctionnalité qui multiplie votre consommation et la levée qui célèbre cette consommation ne sont pas deux actualités : c’est la même, vue du produit puis vue de la caisse.

Du forfait au compteur

La question, au bout du compte, n’est pas de savoir si les dynamic workflows fonctionnent. Sur les grands chantiers répétitifs, audits de sécurité à l’échelle d’un dépôt, migrations de framework, chasses au code mort, ils fonctionneront probablement très bien, et certains de vos chantiers en bénéficieront. La question est de savoir qui paie l’écart entre la démo et la production, entre les 99,8 % rassurants et les 0,2 % qui décident de tout, entre la ligne produite et la ligne vérifiée.

Anthropic a transformé « du trimestre au jour » en argument de vente. Il faudrait surtout y lire « du forfait au compteur ». Le gain de temps est réel. Il se règle en tokens, le règlement n’a rien d’illimité, et la garantie n’existe pas : vous payez le calcul d’avance, et s’il se trompe, vous êtes le seul à répondre du résultat. C’est peut-être la définition la plus exacte du progrès tel qu’on nous le vend en 2026, accélérer la production, externaliser le coût, et laisser la responsabilité exactement là où elle a toujours été.