L’essentiel
- Anthropic recommande aux entreprises de vérifier si leurs sous-agents peuvent être regroupés dans un agent principal qui charge son contexte à la demande.
- Dans une comparaison publiée par l’éditeur, l’architecture à agent unique tourne environ deux fois plus vite que la version multi-agents, avec un coût et une latence en baisse.
- Les modèles récents (Opus 4.5, Opus 5.5, Fable 5.1) gèrent des plans complexes dans une seule boucle ; un kit de migration est publié sur GitHub.
- Les sous-agents gardent trois cas d’usage : contexte qui se dégrade, tâches parallèles, mauvaise sélection d’outils.
Une entreprise avait logé une douzaine de sous-agents spécialisés dans son agent de relation client. Les clients y trouvaient un discours de marque incohérent, et chaque réponse se faisait attendre. L’exemple vient d’Anthropic, qui l’a observé chez plusieurs clients grands comptes, et l’éditeur en tire une consigne nette : regroupez.
Derrière cette consigne, un aveu sur l’histoire récente du métier : une bonne part de l’architecture multi-agents bâtie depuis deux ans compensait les limites des modèles, pas les besoins des utilisateurs.
Un agent qui charge ce dont il a besoin, quand il en a besoin
Un agent principal garde la main sur toute la tâche et va chercher, au moment voulu, les compétences (skills) et les outils nécessaires, au lieu de déléguer à une escouade. L’équipe Applied AI d’Anthropic affirme qu’un tel agent produit régulièrement un meilleur travail qu’un seul prompt géant comme qu’un montage à sous-agents.
Le développement logiciel en donne un exemple parlant. Dans la version multi-agents, une partie écrit la fonctionnalité, une autre écrit les tests, une troisième relit le code. À chaque passage de relais, du contexte se perd. Dans la version à agent unique, le même agent écrit la fonctionnalité et ses tests, puisqu’il sait déjà ce qu’il vient de construire ; un vérificateur distinct se contente de lancer les tests et de rapporter les résultats. Dans la comparaison citée par l’éditeur, ce second montage va environ deux fois plus vite.
Quand l’architecture recopie l’organigramme
L’éditeur invoque lui-même la loi de Conway, cet adage selon lequel un système finit par reproduire la structure de l’organisation qui le conçoit. Appliquée aux agents, elle donne ceci : chaque équipe livre son sous-agent, et des centaines d’agents aux périmètres qui se chevauchent s’accumulent, sans standard commun. Vient ensuite ce qu’Anthropic appelle le « Frankenprompt » : chaque équipe ajoute ses règles au prompt système, et ces règles finissent par se contredire.
Quiconque a monté un agent d’entreprise connaît le schéma classique. Une détection d’intention, un pipeline fixe, une segmentation des utilisateurs, des branches de recommandation séparées, et un orchestrateur au sommet. Pour Anthropic, le modèle sait désormais faire seul une large part de ce travail, du moins pour le cas d’usage visé. Sa recette de remplacement : un prompt système propre, quatre ou cinq outils de données sobres, des garde-fous de sortie fixes.
L’éditeur applique la leçon à son propre produit. Le prompt système de Claude Code a été réduit de plus de 80 % pour les modèles récents, en partie parce que skills et outils ne se chargent plus qu’à l’usage. Ces modèles commentent aussi leur progression et vérifient leur propre travail, ce qui rend certaines couches de contrôle superflues.
Une recommandation d’éditeur, des mesures internes
Anthropic vend des modèles, et a intérêt à ce que l’on confie davantage de travail à un modèle puissant. La recommandation repose en outre sur des retours de terrain et des comparaisons internes, pas sur un benchmark public reproductible. Le gain de vitesse du simple au double vaut pour un montage précis ; rien n’autorise à l’étendre à votre pipeline. L’éditeur n’est toutefois pas isolé sur cette ligne : le guide pratique d’OpenAI sur la construction d’agents conseillait déjà de commencer par un agent unique et de ne passer au multi-agents que lorsque la complexité l’exige.
Anthropic prévient aussi qu’il ne faut pas fusionner à l’aveugle. Lors d’un test sur un agent de support, intégrer un sous-agent a bien réduit la latence, mais cassé un processus qui fonctionnait : l’agent principal s’était mis à répondre seul au lieu de consulter le bon spécialiste. Un gain de vitesse qui détruit un comportement validé reste une régression.
Ces gains concernent par ailleurs les modèles récents, à partir d’Opus 4.5. Sur un modèle plus ancien ou plus petit, choisi pour des raisons de coût, le raisonnement ne tient plus : le sous-agent y reste une béquille légitime.
Trois cas où le sous-agent garde sa place
L’éditeur en retient trois, mesurables :
- le contexte d’un agent unique montre une dégradation de performance mesurable ;
- plusieurs tâches doivent tourner en parallèle, chacune dans sa propre fenêtre de contexte ;
- l’agent unique peine à choisir le bon outil parmi trop d’options.
Tout le reste est à justifier. Le kit de migration publié sur GitHub propose une démarche en trois temps : repérer les schémas existants, évaluer les alternatives, vérifier la meilleure option. C’est avant tout un protocole d’évaluation : on mesure avant de supprimer.
La bibliothèque de skills qui enfle
La simplification déplace le risque. Au lieu d’un agent par équipe, Anthropic recommande de packager les workflows en skills et de charger les outils à la demande. Si chaque équipe y dépose les siens sans règle commune, la loi de Conway revient par une autre porte : un catalogue de compétences qui grossit, se recoupe et se contredit, avec un seul agent pour s’y perdre. L’éditeur met lui-même en garde contre cette prolifération.
Le premier geste tient sur une feuille : la liste de vos sous-agents, et pour chacun la raison technique de son existence. Si la réponse est « le modèle d’alors ne tenait pas le plan », la vérification vaut le coup. Si c’est « l’équipe voulait son périmètre », le problème est d’organisation, et aucune architecture ne le résoudra.
Mon avis
Les sous-agents bâtis pour calquer un organigramme ne survivront pas aux deux prochaines générations de modèles : ils masquaient un défaut de gouvernance derrière une architecture. Ceux qui paralléliseront vraiment du travail resteront. Je trierais dès maintenant, avant que le prochain modèle ne le fasse à ma place et sans prévenir.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 22 évaluations
Faire appel à mes services →
