Mille agents sous un seul plan : Claude passe du copilote au contremaître

Le 9 octobre 2026, Anthropic a mis en bêta publique une fonction qui retourne la hiérarchie habituelle : un agent Claude écrit lui-même le programme qui en pilote des centaines d'autres. Le plafond annoncé est de 1 000 agents lancés au fil d'un même « run », c'est-à-dire une exécution complète du workflow, de son démarrage à son dernier résultat. 64 agents travaillent réellement en même temps.

Un plan écrit en code, un chantier qui tourne sans lui

Dans le multi-agent classique, Claude décide tour après tour quel sous-agent appeler, et tout remonte dans sa fenêtre de contexte, sa mémoire de travail. Le workflow dynamique sort le plan de cette fenêtre. Claude rédige un script, le serveur d'Anthropic l'exécute en arrière-plan, et la conversation reste libre. Les résultats intermédiaires vivent dans les variables du script. Le contexte de l'agent chef ne sature donc plus au milieu du travail.

Le contremaître de l'intertitre n'est pas une figure de style gratuite. Il dessine le plan, répartit les équipes et contrôle la livraison, mais il ne pose pas les briques. Et le règlement du chantier est strict : une fois le run lancé, l'agent chef ne peut plus envoyer de message à ses sous-agents, que le serveur archive à la fin. Pour corriger le tir, il faut attendre la fin de la phase, ou relancer.

Côté limites, la documentation en donne une dizaine. Trois comptent : 1 000 agents par run, 64 en parallèle, sans garantie, et 24 heures de durée de vie par défaut. Le reste (dix runs ouverts par session, vingt agents prédéfinis listables) relève du manuel.

« Un workflow est un programme qui exécute de nombreux agents par phases et combine leurs résultats. » — note de version d'Anthropic, 9 octobre 2026.

Soixante-six bugs sur soixante-dix

L'argument chiffré tient en un test maison. L'équipe a caché 70 bugs dans 116 000 lignes de code. Un agent seul en a retrouvé 14, 15 puis 27 selon les exécutions. Le workflow en a sorti 66, trois fois de suite. Le nombre le plus intéressant n'est pas 66 : c'est la reproductibilité. Un agent isolé varie du simple au double, alors que le workflow rend la même copie à chaque essai. Pour une équipe qui doit livrer à date fixe, cela compte souvent plus que le score brut.

Reste que le test appartient à Anthropic, tourne sur du code choisi par Anthropic, et ne s'accompagne d'aucun chiffre de coût.

À quoi ressemble un run, côté équipe web

Aucun retour de praticien n'est encore publié dans les sources consultées, la fonction ayant une semaine. Le cas d'usage se déduit donc de la documentation de Claude Code, qui cite les audits de code, les migrations massives et la recherche à sources croisées. Prenons un scénario hypothétique : migrer 400 gabarits d'un site vers une nouvelle version de framework. Un script découpe le lot en tranches, un agent par tranche applique la migration, un second relit chaque diff, et un dernier agrège les cas douteux en une liste unique. L'équipe ne lit plus 400 diffs, mais cette liste. Le gain est là, à condition que les critères de recette (ce qui compte comme « migré correctement ») aient été écrits avant le lancement.

La revue change aussi de nature. Un script peut faire relire les bugs détectés par un agent par un autre agent, ou faire rédiger un plan sous plusieurs angles avant d'en retenir un. La contradiction devient un composant que l'on code.

Qui a raison, Anthropic ou le sceptique d'OpenAI ?

Chercher 70 bugs semés exprès est un exercice calibré : les défauts existent, ils sont trouvables par construction, et personne ne paie les fausses alertes. En production, nul ne sait combien de bugs dorment dans le dépôt. Imaginons, par hypothèse, un scanner qui remonte 66 signalements dont un tiers de bruit : l'équipe passe alors son temps à trier les 22 fausses alertes.

En face, un ingénieur senior d'OpenAI parle de gaspillage massif de tokens pour un gain de qualité nul. Les sources consultées ne le nomment pas et ne datent pas sa déclaration, ce qui oblige à la manier avec précaution. Anthropic répond par un seul test, sur son propre terrain. Les deux camps n'ont donc pas produit de preuve décisive. Sur les tâches parallélisables dont le résultat se vérifie mécaniquement (tests, audits, migrations), le test d'Anthropic donne un avantage réel, et le sceptique a tort de le balayer. Sur tout le reste, c'est lui qui garde la charge de la preuve en sa faveur, et Anthropic celle de la démonstration. Pour trancher, il manquerait le même test sur du code non truqué, avec la facture à côté.

La facture : un calcul d'ordre de grandeur

Anthropic le dit sans détour : un run n'a pas de prix propre. Les agents se facturent au token, aux tarifs habituels, plus la session Managed Agents à 0,08 $ par heure, avec un budget plafonnable. La session, elle, est négligeable : 24 heures coûtent 1,92 $.

Le poste lourd, ce sont les tokens. Posons des hypothèses, qui ne sont pas des tarifs publiés : chaque sous-agent consomme 200 000 tokens (lecture de code comprise), à un tarif moyen de 5 $ le million, soit environ 1 $ par agent. Mille agents donnent alors de l'ordre de 1 000 $ pour un run complet. Avec 50 000 tokens par agent, on tombe vers 250 $. À l'inverse, un modèle plus cher peut tripler la note. L'écart est d'un ordre de grandeur, ce qui justifie la recommandation officielle de commencer petit.

Pour une équipe web, commencer petit veut dire un run de quelques dizaines d'agents, sur un périmètre fermé, avec des critères de réussite écrits avant le lancement. L'indicateur à suivre est un seul chiffre : le coût par résultat réellement exploité, c'est-à-dire par bug confirmé ou par page migrée sans retouche. Pour l'instant, personne ne sait dire si 66 bugs sur 70 valent mille agents sur un projet réel.