Claude sait désormais lancer jusqu'à 1000 sous-agents et trouver 66 bugs sur 70

Anthropic ajoute des workflows dynamiques à Claude Managed Agents : un agent principal peut désormais répartir les tâches entre des sous-agents, jusqu'à 1000 travaillant en même temps. Le chiffre phare de cette version vient d'un test sur une base de code contenant 70 bugs dissimulés au préalable. Un agent seul n'en trouvait pas plus de 27, alors que le workflow multi-agents atteignait systématiquement 66. Soit environ 94% contre 39%.

Comment ça fonctionne

Le schéma repose sur deux niveaux. L'agent principal analyse la tâche, décide comment la découper et envoie les morceaux aux sous-agents. Ceux-ci travaillent en parallèle, puis les résultats remontent vers le leader. À en juger par le nom, la structure du workflow n'est pas définie à l'avance par le développeur : elle se construit au fil de la tâche. C'est ce qui distingue cette approche des pipelines rigides, où le nombre d'étapes et leur ordre sont connus avant le lancement.

La fonctionnalité fait partie de Claude Managed Agents, c'est-à-dire de la plateforme managée pour agents. Selon toute apparence, c'est Anthropic qui prend en charge l'infrastructure de lancement et de coordination, et non l'équipe qui développerait son propre orchestrateur.

Les paramètres clés de l'annonce :

• plafond : 1000 sous-agents travaillant simultanément ;
• rôle du leader : décomposer la tâche et distribuer les sous-tâches ;
• tâche de test : trouver 70 bugs cachés dans une base de code ;
• agent seul : 27 bugs trouvés au maximum (environ 39%) ;
• workflow multi-agents : systématiquement 66 (environ 94%) ;
• écart : 2,4 fois plus de bugs détectés.

Ce que montre le test

Le mot « systématiquement » compte. Si le schéma multi-agents n'avait gagné qu'une fois, on aurait pu y voir un coup de chance. Ici, le résultat s'est répété, tandis que, pour l'agent seul, même la meilleure exécution est restée à 27.

On peut expliquer sans magie pourquoi le parallélisme aide précisément pour la recherche de bugs. Une grande base de code ne tient pas tout entière dans le champ d'attention d'un seul agent. Il parcourt une partie des fichiers, tire ses conclusions et part sur une autre piste. Quand chaque sous-agent reçoit un périmètre étroit et n'est responsable que de celui-ci, la couverture s'élargit. Les quatre bugs manqués sur 70 montrent toutefois qu'il existe bel et bien un plafond.

Les réserves sont évidentes. Il s'agit d'un seul test, conçu par l'entreprise elle-même. L'article de The Decoder ne donne aucune donnée sur le coût d'une telle exécution, sur le temps d'exécution ni sur le nombre de faux positifs. Pour la recherche de bugs, ce dernier indicateur est critique : 66 problèmes détectés valent peu si 200 autres, inventés, s'y ajoutent. On ignore aussi dans quelle mesure ce résultat se transpose à d'autres tâches.

Comment aborder le déploiement

Inutile de commencer avec mille agents. Il est plus raisonnable de choisir une tâche qui se découpe naturellement en parties indépendantes, puis de comparer une exécution à agent unique et une exécution multi-agents sur ses propres données.

Parmi les candidats adaptés : l'audit d'un dépôt, la recherche de vulnérabilités, la génération de tests module par module, la vérification d'une migration vers une nouvelle version d'une bibliothèque, l'analyse d'un grand volume de documents. Les tâches dont les étapes dépendent étroitement les unes des autres s'y prêtent moins : le parallélisme n'y apporte presque rien.

Avant de passer à l'échelle, il faut mesurer trois choses : le coût par bug confirmé, la proportion de faux positifs et le délai avant l'obtention d'un rapport finalisé. Il faut aussi fixer un budget et une limite sur le nombre de sous-agents, faute de quoi la facture arrivera avant le résultat. Mieux vaut confier la vérification finale des découvertes à un humain ou à un agent vérificateur distinct, plutôt que de prendre le rapport du leader pour argent comptant.