# Faut-il construire une seule boucle d’agent ou une équipe de sous-agents?

Date: 2026-10-23 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/une-boucle-agent-ou-sous-agents/

**Answer:** Le guide d’Anthropic du 22 octobre 2026 soutient que bien des agents d’entreprise construits avec un routeur et des sous-agents spécialisés fonctionnent mieux sous forme d’une seule boucle d’agent qui charge compétences et outils seulement au besoin, et il fournit une trousse à code source ouvert pour faire la transition une étape mesurée à la fois. Les sous-agents restent pertinents pour le travail en parallèle dans un contexte neuf, la vérification indépendante ou quand une boucle se dégrade de façon mesurable, et les preuves se limitent pour l’instant aux comptes rendus d’Anthropic et à deux petites exécutions consignées.

Le 22 octobre 2026, Anthropic a publié un guide destiné aux entreprises qui construisent des agents sur sa plateforme : [« *Building agents: When to fold subagents into your main agent loop* »](https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop) (construire des agents : quand intégrer les sous-agents à la boucle principale). Son message : bien des agents ont été construits avec plus de pièces mobiles que les modèles d’aujourd’hui n’en ont besoin. Au lieu d’un routeur d’accueil qui confie chaque demande à l’un d’une douzaine d’agents spécialisés, Anthropic propose un seul agent, dans une seule conversation, qui va chercher les consignes et les outils dont il a besoin au fur et à mesure. Un dépôt d’accompagnement, la [trousse *single agent loop kit*](https://github.com/anthropics/single-agent-loop-kit), guide une équipe dans ce changement et mesure chaque étape.

C’est une question de conception que se pose toute personne qui construit des agents. Il vaut donc la peine de distinguer ce que le guide soutient, les preuves qu’il avance, et les points où d’autres praticiens expérimentés, et les travaux antérieurs d’Anthropic elle-même, vont dans l’autre sens.

## Quelles sont les deux conceptions, en mots simples?

Une **boucle d’agent** est un modèle qui travaille par cycles : il examine la situation, appelle des outils (une recherche, une base de données, une calculatrice), regarde les résultats et décide de l’étape suivante, jusqu’à ce qu’il réponde ou épuise son budget.

Un **sous-agent** est un deuxième agent à qui l’agent principal confie une tâche. Il a ses propres consignes, ses propres outils et sa propre **fenêtre de contexte**, la mémoire de travail qu’un modèle transporte tout au long d’une tâche. Quand il a terminé, il renvoie un résumé. Une conception courante en entreprise place un **orchestrateur** ou routeur au sommet et un ensemble de sous-agents spécialisés en dessous : un pour les commandes, un pour l’expédition, un pour les retours.

La conception que privilégie le guide est une **boucle d’agent unique à divulgation progressive**. L’agent unique ne voit que de courtes descriptions de ses **compétences** (*skills*, des dossiers de consignes qui expliquent comment une équipe fait un type de travail) et de ses outils. Il ne charge la compétence ou la définition d’outil complète que lorsqu’une tâche l’exige, si bien que le prompt de départ reste court même quand l’agent couvre de nombreux domaines.

## Que soutient le guide?

Anthropic dit que son équipe Applied AI a comparé les conceptions dans plusieurs déploiements en entreprise, et qu’un agent unique doté de compétences a souvent battu à la fois un prompt géant tout-en-un et la conception à sous-agents sur la qualité des réponses, fréquemment avec un coût et un temps d’attente plus faibles par tâche. Elle donne trois raisons :

1. **Un contexte partagé donne de meilleures réponses.** Un agent qui a vu chaque étape précédente peut les relier. Les sous-agents renvoient des résumés, et chaque passage de relais perd des détails.
2. **La divulgation progressive élimine l’ancienne raison de diviser.** Les équipes répartissaient le travail entre sous-agents surtout parce qu’un seul prompt ne pouvait pas tout contenir. Le chargement à la demande règle ce problème. Anthropic dit avoir réduit de plus de 80 % le prompt système de Claude Code pour ses modèles les plus avancés, en partie de cette façon.
3. **Les modèles en gèrent maintenant davantage.** Anthropic affirme qu’à partir de Claude Opus 4.5, les modèles gèrent beaucoup plus de choses dans une seule boucle que la plupart des équipes ne le prévoyaient, et que des structures multi-agents rigides empêchaient souvent les modèles plus récents d’assumer une plus grande part du travail.

Le guide nomme aussi les façons dont les grandes organisations font fausse route quand chaque équipe construit son propre agent : du contexte perdu entre les agents, des centaines de sous-agents qui se chevauchent sans responsable, un prompt système commun où chaque équipe a ajouté une règle jusqu’à ce qu’elles se contredisent, et des tests étroits que chaque équipe ajuste pour sa propre partie. Le guide résume la chose ainsi : l’architecture devient une copie de l’organigramme. Un client, dit-il, a mesuré qu’une boucle unique tournait environ deux fois plus vite que sa version multi-agents.

## Quand les sous-agents gardent-ils l’avantage?

Le guide dit clairement que les sous-agents gardent leur place. Il les recommande quand :

- une boucle montre un déclin **mesurable** parce que son contexte est devenu trop gros;
- plusieurs tâches doivent tourner **en parallèle**, chacune dans un contexte neuf qu’on peut jeter ensuite;
- un agent **a du mal à choisir le bon outil**, ou ses consignes se contredisent.

La trousse ajoute la **vérification indépendante** (un vérificateur qui n’a pas vu le raisonnement du travailleur) et le travail qui lit beaucoup plus de matériel que ce que l’agent principal doit conserver. Si vous divisez quand même, le guide conseille de découper selon le contexte, pas selon le type de problème : confiez à un sous-agent une tâche autonome qui dépend peu du reste et qui renvoie un résultat court, comme une piste de recherche distincte ou un composant à l’interface bien définie.

Voici comment le guide transpose les pièces d’un système multi-agents typique dans une seule boucle :

| Dans une conception routeur et spécialistes | Dans la boucle unique |
|---|---|
| Un planificateur ou une étape de code qui bâtit le plan à partir d’un catalogue de règles | Le modèle écrit et révise son propre plan dans son contexte |
| Le prompt de chaque spécialiste : étapes, règles, jugements | Une compétence, chargée au besoin |
| Les appels d’API de chaque spécialiste | Des outils (souvent des outils MCP), regroupés selon l’intention de l’utilisateur |
| Les règles strictes comme les approbations et la validation | Des vérifications dans les outils, qui renvoient un refus en clair que le modèle peut lire |
| Les permissions propres à chaque utilisateur | Chaque outil vérifie ce que l’utilisateur courant a le droit de voir ou de modifier |
| Les documents de référence | Une base de connaissances derrière un outil de recherche, ou des fichiers dans une compétence |
| Les limites globales | Des budgets de tours et de coûts et des **barrières d’écriture** (une règle voulant qu’une modification de données exige une approbation) dans le harnais, le code qui entoure le modèle |

La boucle elle-même : à chaque tour, le modèle demande plusieurs appels d’outils à la fois, le harnais les exécute côte à côte, et les résultats bruts reviennent à ce même modèle. Elle s’arrête quand le modèle répond ou qu’un budget est épuisé, et un vérificateur peut contrôler la réponse ensuite. Deux limites pratiques tirées du guide : regroupez les outils selon l’intention de l’utilisateur, parce que le choix devient moins bon au-delà d’environ 30 à 50 définitions d’outils, et confiez le prompt système et les tests communs à une petite équipe centrale.

## Quelles sont les étapes de migration? Un exemple concret

Le guide ne demande pas de tout réécrire. Sa séquence :

1. **Construire d’abord une évaluation de bout en bout.** Une **évaluation** (*eval*) est un ensemble de tests automatisés pour un système d’IA. Dix exemples « de référence » dont on connaît le bon résultat suffisent pour commencer. Tant qu’un routeur existe, vérifiez aussi s’il a choisi le bon sous-agent; après une intégration, vérifiez si l’agent a chargé la bonne compétence ou le bon outil.
2. **Fusionner les sous-agents qui s’exécutent toujours ensemble.** Si une grande part du trafic passe par le spécialiste A puis par le spécialiste B, ils sont candidats à n’en former qu’un.
3. **Appeler les sous-agents conservés comme des outils.** L’agent principal garde la conversation et reçoit un résultat structuré, au lieu de transférer l’utilisateur.
4. **Intégrer un sous-agent à la fois** sous forme de compétence et d’outils, relancer la même évaluation, et garder le sous-agent seulement quand la version intégrée fait moins bien à cette évaluation.

L’exemple du guide montre pourquoi l’étape 4 demande de la prudence. Dans un agent de soutien à la clientèle servant d’exemple, l’intégration d’un spécialiste l’a rendu plus rapide, mais a brisé une tâche qui réussissait auparavant : l’agent principal détenait désormais l’outil de consultation des commandes et répondait lui-même à une question de livraison, sans demander la vraie date au spécialiste de l’expédition. Cet échec n’est apparu que dans une exécution sur deux. Le guide conseille donc de regarder quelles tâches ont changé de résultat, pas seulement le score total, de s’assurer que les tests couvrent chaque chaîne d’agents utilisée par le trafic réel et chaque règle que l’agent doit respecter, et d’exécuter chaque tâche plus d’une fois.

## Que fait la trousse, et qu’est-ce qu’elle n’a pas démontré?

La trousse est une compétence Claude Code accompagnée de scripts, sous licence Apache 2.0, présentée comme une implémentation de référence qui n’est pas maintenue. Elle examine un dépôt et attribue à chaque sous-agent l’un de quatre verdicts : l’intégrer, le fusionner avec un autre, l’appeler comme un outil ou le garder. Elle effectue ensuite un changement à la fois, en lançant l’évaluation avant et après. Elle s’arrête pour consulter une personne à des moments fixes : après l’audit, avant toute exécution payante (avec une estimation du nombre de jetons), après la mesure de référence et après chaque changement. Ses scripts repèrent dans les traces quels sous-agents s’exécutent ensemble, comparent deux exécutions sur le taux de réussite, la latence, les appels au modèle, les jetons et le coût, et vérifient que l’évaluation couvre chaque chaîne de sous-agents présente en production.

Elle comprend un petit exemple de centre de soutien avec un routeur et six sous-agents, ainsi qu’un test de fumée gratuit, hors ligne, qui remplace le vrai modèle par un substitut fondé sur des mots clés. Ce test prouve seulement que la tuyauterie fonctionne; il n’est pas noté.

Le fichier README de la trousse est d’une franchise inhabituelle sur ses preuves. Seules deux exécutions sur un vrai modèle sont consignées, par une seule personne, sur un seul modèle, avec 12 puis 17 tâches répétées surtout deux fois chacune. Les résultats mesurés ont été retirés des comptes rendus publiés. Plusieurs parties n’ont jamais été essayées sur un vrai modèle : l’étape de fusion, l’étape d’entretien, la version finale à boucle unique de l’exemple, et tout autre système que cet exemple; de plus, la formulation de la compétence a changé après la dernière exécution. Les notes d’une des exécutions indiquent que deux répétitions étaient trop peu pour trancher, et la personne a eu besoin de 16 conversations de plus avant de conserver le changement.

## Quels sont les autres points de vue?

L’argument en faveur d’une seule boucle n’est pas nouveau, et tout le monde ne trace pas la ligne au même endroit.

- **L’agent de recherche d’Anthropic elle-même utilise des sous-agents.** En juin 2025, Anthropic a décrit son système de recherche multi-agents, où un agent principal lance des sous-agents qui cherchent en parallèle. Sur son test de recherche interne, cette conception a battu un agent unique de 90,2 %, pour environ 15 fois les jetons d’une conversation. Anthropic disait aussi que les tâches où les agents partagent beaucoup de contexte, comme la plupart des travaux de programmation, conviennent mal aux conceptions multi-agents. Le nouveau guide est cohérent avec cela : la recherche avec des pistes indépendantes est l’un des cas où il recommande encore des sous-agents.
- **Cognition s’est prononcée contre les conceptions multi-agents en 2025.** Dans un billet de juin 2025 intitulé « Don’t Build Multi-Agents » (ne construisez pas de systèmes multi-agents), Cognition, qui fabrique l’agent de programmation Devin, soutenait que des sous-agents en parallèle font des hypothèses contradictoires et qu’un agent à fil unique au contexte partagé est plus fiable. C’est proche de la nouvelle position d’Anthropic, à laquelle un concurrent était arrivé plus d’un an plus tôt.
- **Les preuves viennent d’un fournisseur.** Les affirmations du guide sur la qualité, le coût et la rapidité proviennent des comparaisons d’Anthropic chez ses propres clients, avec un seul chiffre approximatif (deux fois plus rapide pour un client) et aucun jeu de données publié. Le guide les présente comme des tendances observées, et son conseil final est de mesurer sur votre propre système plutôt que d’adopter une conception par principe.

## Comment tester le changement sur votre propre agent?

Commencez par l’évaluation, pas par l’architecture. Écrivez dix vraies demandes que votre agent traite et, pour chacune, notez ce qu’est un résultat correct, en des termes qu’un script ou une grille stricte peut vérifier : le bon montant de remboursement, le bon outil appelé, aucune donnée modifiée sans approbation. Incluez au moins une demande qui touche deux spécialistes, et une qui devrait être refusée. Exécutez le système actuel sur les dix, au moins trois fois chacune, et conservez les scores, la latence et le coût. C’est votre mesure de référence.

Choisissez ensuite un sous-agent : le guide suggère de commencer par les plus utilisés, alors que l’exemple de la trousse commence par le plus petit pour que le changement soit facile à observer. Transformez son prompt en compétence et ses appels d’API en outils que l’agent principal peut appeler, relancez les mêmes dix demandes trois fois et comparez tâche par tâche. Si une tâche est passée de la réussite à l’échec, lisez cette transcription avant de décider. Gardez l’intégration seulement si elle tient la route, puis recommencez avec le sous-agent suivant.

Vous pouvez lancer l’audit avec un prompt comme celui-ci :

```prompt
Voici le code (ou une description) de mon agent : [colle le routeur, le prompt de chaque sous-agent et ses outils].
Pour chaque sous-agent, dis-moi :
1. Avec quels autres sous-agents il est habituellement appelé, et s’il a besoin de leurs résultats.
2. S’il fait un travail qui profite d’un contexte neuf et séparé (recherche en parallèle,
   vérification indépendante, lecture de beaucoup de matériel dont l’agent principal n’a pas besoin ensuite).
3. Ton verdict : l’intégrer sous forme de compétence et d’outils, le fusionner avec un autre sous-agent, l’appeler comme un outil,
   ou le garder tel quel, avec une phrase de justification.
Dresse ensuite la liste des demandes que je dois inclure dans mon ensemble de tests pour qu’un passage de relais brisé soit détecté.
```

> **À essayer :** choisissez un passage de relais dans un agent que vous exploitez, écrivez cinq demandes de test qui passent par lui et exécutez-les trois fois avant et trois fois après l’intégration de ce sous-agent. Notez toute tâche qui a réussi une fois et échoué une fois : c’est le genre de bris qu’une exécution unique cache.

Si vous n’avez pas encore de sous-agents, la trousse elle-même conseille de commencer par une seule boucle et d’ajouter outils et compétences seulement quand les tests montrent que vous en avez besoin. Pour l’autre côté de la question, voyez [ce que sont les sous-agents et quand leur répartir le travail](/fr/apprendre/sous-agents-repartir-travail/) et [comment construire un flux de travail multi-agents](/fr/apprendre/construire-flux-de-travail-multi-agents/).

## Sources

- Building agents: When to fold subagents into your main agent loop: https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
- Single agent loop kit (README and example runs): https://github.com/anthropics/single-agent-loop-kit
- How we built our multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-system
- Don't Build Multi-Agents: https://cognition.ai/blog/dont-build-multi-agents

---

Tiré du Guide de l’intelligence artificielle, par Robert Scales, publié par Holistic Hybrid inc. Partage et adaptation permis selon la licence CC BY-NC-SA 4.0 (https://creativecommons.org/licenses/by-nc-sa/4.0/) : citez le guide, mettez un lien vers https://guidetoartificialintelligence.com/fr/apprendre/une-boucle-agent-ou-sous-agents/, pas d’usage commercial sans permission, et gardez la même licence.