Équipes d’agents Claude Code : quand recourir à plusieurs agents et comment le faire.

Une équipe d’agents coordonnés qui communiquent entre eux au sein de l’écosystème Claude Code est désormais accessible, et une version finale peut fonctionner très bien. Cependant, la mettre en œuvre est plus difficile qu’il n’y paraît, et de nombreuses personnes se lancent dans la création d’équipes d’agents sans évaluer les compromis. Les équipes d’agents semblent être la prochaine étape logique une fois que les sous-agents fonctionnent correctement. Or, ce n’est pas automatique. Une équipe représente une couche de coordination qui entraîne des coûts réels en termes de tokens, présente des modes d’échec connus et ne traite efficacement qu’un ensemble restreint de problèmes.

La leçon moins glamour tirée de mois d’utilisation réelle de systèmes multi-agents est aussi la plus utile : commencez par un agent bien configuré, de bons outils et une gestion disciplinée du contexte. N’ajoutez pas d’autres agents tant que vous ne pouvez en citer une raison précise. Les conseils d’Anthropic pour créer des agents efficaces disent la même chose, conseillant aux équipes de chercher la solution la plus simple fonctionnelle et d’ajouter de la complexité uniquement lorsque c’est nécessaire.

Ce qui suit est une manière de réfléchir à la décision et de savoir quoi faire après l’avoir prise. Il est supposé que vous êtes familier avec les sous-agents, la manière dont ils diffèrent des compétences et pourquoi isoler le contexte est la raison principale d’en utiliser un. La question ouverte est de savoir quand un seul sous-agent qui rapporte des informations ne suffit plus, et ce qu’il convient de mettre à sa place.

Le matériel aborde ces domaines :

• Pourquoi la plupart des équipes n’ont pas encore besoin de plusieurs agents, et l’erreur courante qui consiste à recourir à des équipes parce qu’on les perçoit comme plus puissantes.
• Quatre facteurs concrets indiquant qu’un agent a atteint ses limites.
• Quatre modèles de combinaison d’agents, selon une taxonomie neutre par rapport aux fournisseurs : orchestrateur, pipeline, spécialistes en parallèle et essaim.
• La pile Anthropic pour les équipes d’agents, permettant de distinguer ce qui est stable de ce qui est expérimental ou uniquement en version préliminaire.
• Qu’est-ce que les équipes d’agents Claude Code et en quoi elles diffèrent des sous-agents.
• Comment les agents communiquent : trois formes, quatre schémas de synchronisation et ce qui doit être transmis entre eux.
• Huit modes de défaillance avec des solutions pratiques.
• Un cadre de décision pour l’orchestration native, faite soi-même ou hybride.

La plupart des équipes n’ont pas besoin de plus d’un agent

Beaucoup de personnes qui cherchent des équipes d’agents résolvent le mauvais problème. Le raisonnement habituel est que les sous-agents ont fonctionné, que le système devient de plus en plus complexe et que les équipes représentent l’étape suivante. Cette logique confond capacité et complexité. Une équipe ne rend pas le système plus capable ; elle le rend plutôt plus distribué, et la distribution constitue un coût plutôt qu’une amélioration.

Le post d’Anthropic sur la création d’agents efficaces explique en détail les aspects économiques. Les flux de travail qui ne reposent pas sur des agents sont plus prévisibles, moins chers et plus faciles à déboguer ; le conseil principal est le suivant : lorsque une fonction ordinaire peut accomplir la tâche, écrivez cette fonction plutôt que de réunir un comité de distributions de probabilité. Ce point est facile à manquer pour ceux qui n’ont pas compris que les LLM sont probabilistes. Même une instruction explicite peut être ou non suivie correctement. Chaque agent ajouté représente un composant de plus susceptible de tomber en panne, de générer des hallucinations ou d’émettre des résultats que le prochain agent interprétera de manière erronée, ce qui augmente les risques d’erreurs à grande échelle.

Le plafond de capacité d’un agent unique est plus élevé que ce que l’on imagine. Un agent disposant des outils adéquats, d’instructions claires, d’une délégation efficace des tâches complexes à des sous-agents et d’une gestion minutieuse du contexte peut accomplir une quantité de travail surprenante. Ce plafond est atteint lorsque l’un au moins des quatre éléments suivants s’applique :

1. Le travail est trop volumineux pour une seule fenêtre de contexte, même avec la délégation à des sous-agents.
2. Differentes parties du travail exigent vraiment des spécialisations distinctes, ce qui implique des accès à des outils et des limites comportementales différentes, et non simplement des instructions différentes.
3. Une partie du travail peut être exécutée en parallèle, et le temps écoulé est important.
4. La qualité du résultat nécessite une évaluation indépendante, par exemple par un second agent qui n’a pas vu le raisonnement du premier.

Aucune de ces affirmations ne concerne les capacités ; elles portent toutes sur l’architecture. Lorsqu’on applique une telle approche, des agents supplémentaires s’avèrent justifiés. En l’absence de cela, ils ne font qu’ajouter des obstacles, et si l’on ne peut citer aucun cas spécifique, la solution avec un seul agent reste envisageable.

Les quatre déclencheurs, avec des exemples

Isolement du contexte. Supposons que la tâche nécessite de lire des dizaines de fichiers, d’effectuer des recherches approfondies et de conserver de gros résultats intermédiaires, dont aucun n’a besoin de rester dans la session principale. Un sous-agent peut gérer cela. Mais si l’enquête est si vaste que même le contexte d’un sous-agent est saturé, ou si la tâche se divise en enquêtes parallèles indépendantes, il devient nécessaire d’utiliser plusieurs agents. C’est le déclencheur légitime le plus courant.

Spécialisation. Ce type de travail exige plus que des instructions séparées ; il nécessite un accès à des outils différents ainsi que des contraintes comportementales particulières. Un revueur de code qui ne peut pas écrire de fichiers ou exécuter des commandes shell présente un profil de risque complètement différent de celui d’un générateur de code. Cependant, ces différences peuvent souvent être encodées sous forme de sous-agents distincts, chacun disposant de son propre prompt système et d’une liste d’outils restreinte ; par conséquent, la spécialisation seule ne devrait pas être la raison de passer à des équipes. La documentation sur les équipes d’agents indique elle-même que les sous-agents se révèlent utiles dans ce contexte : ils permettent des contextes isolés, des résumés renvoyés à l’utilisateur et des instructions spécifiques à la tâche.

Travail parallèle. La tâche se divise en sous-tâches indépendantes qui ne partagent aucun état mutable : trois agents examinant en même temps différents aspects d’un bug dans un codebase, ou quatre agents chacun consultant un autre chapitre d’un document. C’est dans ce cas que les systèmes multi-agents permettent des économies réelles en temps réel, puisque les agents s’exécutent simultanément. Le prix à payer est un nombre total plus élevé de tokens, donc cet échange n’est judicieux que lorsque le temps écoulé compte plus que les coûts engagés.

Critique indépendante. Le résultat nécessite un deuxième avis qui n’ait pas été influencé par la logique du premier. Imaginez un évaluateur qui ne lit que le résultat final sans prendre connaissance des raisonnements qui l’ont conduit, ou un agent d’équipe rouge qui cherche des défauts plutôt que de valider les affirmations. C’est l’idée à l’origine du système de recherche multi-agents d’Anthropic, où des sous-agents travaillant en parallèle explorent différents aspects et un agent principal synthétise les informations de manière indépendante.

Lorsqu’une de ces affirmations est clairement vraie et que l’on sait laquelle, l’ajout d’agents justifie son coût.

Quatre façons de combiner des agents

Supposons que la décision ait été prise. La recherche révèle rapidement un certain désordre, car les laboratoires de pointe ont chacun développé des modèles multi-agents de manière différente, bien qu’il existe quelques éléments communs. Ce qui suit est une taxinomie synthétisée à partir de la documentation sur le flux de travail d’Anthropic et de l’expérience pratique de son équipe d’ingénierie. Il ne s’agit pas d’une classification officielle d’Anthropic ; c’est plutôt un résumé analytique qui correspond à ce que décrivent ces sources.

Tuyau séquentiel

Les agents ou les étapes s’exécutent dans un ordre fixe, et les étapes ultérieures utilisent les résultats des étapes précédentes. De ces quatre types, c’est le plus simple à expliquer aux ingénieurs, car il ressemble à du logiciel ordinaire : recherche puis synthèse, rédaction puis critique, extraction puis validation.

Sa force réside dans des contrats explicites entre les étapes. Sa faiblesse, ce sont les erreurs en cascade, car une erreur d’extraction à la première étape peut entraîner des erreurs dans les étapes suivantes, avec de lourdes conséquences. Des points de validation entre les étapes sont indispensables, car ils empêchent le processus de progresser à tort avec assurance. Les schémas de contrat JSON et d’autres éléments permettant de tracer l’historique tout au long du traitement constituent les meilleurs points de validation.

Orchestrateur central, ou planificateur-exécutant

Un agent principal divise la tâche, la délègue aux travailleurs et synthétise les résultats. Les travailleurs ne coordonnent pas entre eux ; ils font rapport à l’orchestrateur. C’est le mode par défaut le plus courant et le plus utile. L’utilisez lorsque la structure des sous-tâches n’est pas connue à l’avance mais que la responsabilité claire au niveau supérieur est importante. La fonction Research d’Anthropic suit exactement cette structure : un agent principal analyse la requête, lance des sous-agents spécialisés en parallèle et fusionne ensuite leurs résultats.

N’utilisez pas ce mode si le flux de travail est déjà suffisamment bien défini pour être automatisé par un script ; dans ce cas, une chaîne de traitement sera plus simple et plus prévisible.

Sa défaillance caractéristique est la défaillance de l’orchestrateur : un agent principal dont les instructions de délégation sont vagues amène les travailleurs à répéter des recherches similaires, à dépasser les limites ou à produire des résultats incohérents. La solution consiste à donner à chaque travailleur un objectif, un format de résultat attendu, des indications sur les sources et des limites claires pour sa tâche.

Spécialistes en parallèle, débat et équipe rouge

Ici, plusieurs agents s’occupent en même temps de la même tâche ou de sous-tâches voisines, et leurs résultats sont ensuite soumis à un vote, à des critiques ou à une agrégation. Cette méthode convient aux cas où la résilience prime sur la perfection : explications concurrentes concernant une erreur, examen critique d’une décision stratégique, analyse de sécurité sous plusieurs angles.

Le coût est évident. Plus d’agents signifie beaucoup plus de tokens, davantage de travail d’agrégation et un risque de confiance erronée issue du consensus. Le système de recherche d’Anthropic aurait dû introduire des budgets d’effort et une délégation plus stricte pour empêcher les collaborateurs de travailler sans discipline. Utilisez ce modèle uniquement lorsque le domaine l’exige réellement.

Essaim, ou contexte partagé décentralisé

La coordination émerge d’un état partagé, de threads de messages communs ou de changements dans l’environnement, plutôt que d’un leader strict. Ici, les systèmes multi-agents commencent à devenir des systèmes distribués, avec toute la complexité que cela implique : responsabilités floues, conditions de course sur l’état partagé et débogage difficile. Ce modèle convient aux problèmes véritablement ouverts où les agents doivent interopérer au-delà des limites des sessions ou du temps de fonctionnement. Évitez-le lorsque des responsabilités claires ou un respect strict des règles sont nécessaires.

Pour la plupart des praticiens, les deux premiers modèles couvrent presque tout.

Ce que propose Anthropic aujourd’hui

Avant de créer votre propre stack, il est utile de vérifier ce que Anthropic offre déjà et ce que ses approches enseignent. Il existe plusieurs interfaces pour le travail agent, mais elles ne sont pas interchangeables. Imaginez une échelle allant du contrôle brut à la gestion hébergée. L’image ci-dessous représente une vue d’environ avril 2026, et ces produits évoluent rapidement.

1. Messages API. Vous contrôlez entièrement le processus. L’utilisation d’outils est possible, mais c’est vous qui écrivez la logique d’exécution, et il n’y a pas de support intégré pour plusieurs agents. C’est le niveau le plus flexible, mais aussi celui qui exige le plus de travail.

Claude Agent SDK. La boucle d’agent, les outils, la gestion du contexte, les sous-agents, les hooks et le suivi des coûts proviennent d’Anthropic, mais s’exécutent sur l’infrastructure que vous gérez. Les sous-agents sont natifs, et tout système multi-agent qui dépasse ce cadre relève principalement de votre propre conception. L’authentification s’effectue via Bedrock, Vertex AI et Azure Foundry, ce qui en fait le niveau le plus portable.

Claude Managed Agents. Anthropic gère pour vous l’environnement d’exécution : conteneurs, compression, mise en cache des prompts, historique des événements, sessions à état et un ensemble d’outils intégrés. L’utilisation avec un seul agent est déjà bien développée, tandis que les sessions multi-agents se trouvent dans une version préliminaire distincte et restreinte.

Agents gérés multiagent. Une version de prévisualisation pour la recherche, à accès restreint et présentant une contrainte notable : la conception ne prend en charge qu’un seul niveau de coordinateur. Un coordinateur peut appeler d’autres agents, mais ces derniers ne peuvent pas à leur tour appeler d’autres agents. Il s’agit donc d’une orchestration multiagent, mais ce n’est pas encore une société récursive générale d’agents.

Sous-agents Claude Code. Des contextes de travail isolés au sein d’une seule session principale qui rapportent les résultats. Il s’agit d’une fonctionnalité officielle, mais pas de équipes peer-to-peer.

Équipes d’agents Claude Code. D’après l’état au mois d’avril 2026, cette fonctionnalité est expérimentale et désactivée par défaut ; elle peut être activée via une variable d’environnement spécifique. Les limites connues incluent le comportement de reprise de session, des cas particuliers dans la coordination des tâches, ainsi que des sessions reprises qui font référence à des membres d’équipe qui n’existent plus.

En pratique, l’affirmation « Claude prend en charge les équipes d’agents » est vraie, tandis que l’affirmation « Claude offre une orchestration multi-agents de niveau production et polyvalente sur tous les supports » ne l’est pas.

Claude Code et les équipes d’agents en pratique

Rappel rapide de la différence :

• Sous-agents : ils s’exécutent au sein d’une seule session principale. L’instance principale de Claude Code les crée ; chacun travaille seul dans sa propre fenêtre de contexte et envoie les résultats, vous étant chargé de l’orchestration. La session principale ne prend jamais en charge le travail effectué pour produire un résultat.

Les équipes d’agents sont des sessions distinctes de Claude Code qui communiquent entre elles. Chaque membre de l’équipe dispose de sa propre fenêtre de contexte et d’état de session, ainsi que d’une liste de tâches partagée et d’une boîte aux lettres pour les messages directs. Les membres de l’équipe peuvent se transférer des tâches et coordonner leurs actions sans avoir à attendre que le chef transmette chaque instruction. Le chef définit la direction, et les membres de l’équipe peuvent agir en conséquence tout en échangeant entre eux.

La configuration

1. La configuration de l’équipe se trouve à ~/.claude/teams/{name}/config.json.
2. Une liste de tâches partagée est stockée à ~/.claude/tasks/{name}/.
3. Les membres de l’équipe sont définis dans des fichiers d’agents réutilisables, en fait des définitions de sous-agents auxquels sont attribués des rôles de membre d’équipe.
4. Les hooks peuvent servir de points de contrôle qualité entre les transitions de tâches.

Deux aspects architecturaux sont importants pour la conception. Premièrement, les sous-agents peuvent conserver leur propre mémoire automatique. Cela facilite la spécialisation, mais une fois le travail divisé entre plusieurs agents dotés de mémoires distinctes, il faut prendre une décision architecturale quant aux connaissances qui restent locales, celles qui sont partagées et celles qui doivent être résumées. Il s’agit là d’une question de conception de système.

Deuxièmement, la documentation indique clairement quand les équipes se comportent moins bien que les sous-agents : pour les tâches séquentielles, les modifications du même fichier et le travail impliquant de nombreuses dépendances entre étapes. Si les agents doivent transmettre le même artefact dans l’ordre, sans travailler en parallèle, les sous-agents au sein d’un pipeline séquentiel sont plus simples et plus prévisibles.

Puisque les équipes étaient encore expérimentales et désactivées par défaut à ce stade, n’activez-les qu’en raison d’un motif clair figurant dans la liste ci-dessus, et attendez-vous à des imperfections.

Comment les agents communiquent entre eux

La communication entre les agents est souvent considérée comme un problème de sollicitation. À grande échelle, il s’agit d’un problème systémique. Il existe trois formes principales.

1. Messages en langage simple. C’est la forme la plus évidente, mais aussi la moins fiable à grande échelle. Les collègues de Claude Code s’envoient des messages directement via la boîte aux lettres. Cela est flexible, mais le langage naturel est moins précis que les appels structurés, ce qui laisse plus de place à des malentendus entre les agents.
2. Appels structurés. Définitions d’outils via JSON Schema et utilisation stricte de ces outils. Les définitions d’outils d’Anthropic garantissent que les arguments respectent le schéma. Cette couche rend la communication entre agents et outils fiable, et le même mécanisme rend les appels entre agents plus précis lorsqu’ils sont modélisés comme des appels à des outils plutôt que comme des messages libres.

État ou artefacts partagés. La forme la plus sous-estimée. L’étude de recherche sur les multi-agents d’Anthropic recommande que des sous-agents écrivent leurs résultats dans un système de fichiers ou un système externe et retournent des références légères, plutôt que de faire passer tout le processus par le contexte de l’agent principal. La raison est simple : un fichier peut être audité, versionné et inspecté directement, tandis qu’un message résumant un fichier ne possède pas ces caractéristiques.

Le timing est tout aussi important que le format. Quatre modèles se distinguent :

• Appels synchrones. Un gestionnaire appelle un spécialiste, attend, puis continue. Facile à comprendre, mais cela peut représenter un goulot d’étranglement. L’équipe de recherche d’Anthropic aurait découvert que l’exécution synchrone par l’agent principal était bloquée par des travailleurs lents, ce qui a conduit à écarter l’idée de diriger le processus en cours d’exécution.

Transferts séquentiels. La responsabilité passe d’un agent à l’autre : l’un produit un résultat et le suivant le reprend. OpenAI distingue formellement deux approches : un transfert confère au spécialiste la responsabilité de ce qui se passe ensuite, tandis qu’un agent utilisé comme outil laisse le gestionnaire en charge. La personne responsable dépend de l’approche choisie.

Basé sur des événements ou en flux continu. Les agents réagissent aux événements plutôt qu’à des appels synchrones. Cela convient mieux aux tâches longues, mais il est plus difficile de les déboguer et de les tester ; parfois, des mécanismes d’ancrage peuvent aider.

Polling à état partagé. Ce n’est pas la méthode la plus attrayante, mais c’est souvent l’option la plus fiable. Les agents consultent un fichier ou un stockage de données partagés pour connaître l’avancement, y enregistrent leurs mises à jour puis passent à autre chose. Le travail de longue date d’Anthropic dans le domaine des outils permet de conserver les listes de fonctionnalités au format JSON, les fichiers d’avancement et les commits Git comme état partagé durable, tandis que les points de contrôle manuels s’intègrent naturellement.

La manière dont les agents s’échangent des informations détermine la fiabilité de l’ensemble du système. Transmettre l’historique complet des conversations maximise la continuité, mais augmente de manière linéaire les coûts et les délais. Un résumé compressé est souvent préférable, et c’est précisément ce que font par conception les sous-agents de Claude Code. Le transfert de documents spécifiques à une tâche, tels que des fichiers de sortie structurés, des correctifs de code, des listes de fonctionnalités au format JSON et des rapports enregistrés, constitue généralement le compromis pratique idéal. L’agent qui reçoit les informations peut examiner directement ces documents au lieu de se fier à un résumé, ce qui permet à l’ensemble du système d’être auditable d’une manière que les transferts par conversation ne peuvent pas offrir.

Ce qui est transmis détermine également la manière et le moment de ce transfert, ce qui renforce le point central : la création d’équipes d’agents relève d’un problème de conception de systèmes, et ceux-ci sont plus difficiles à résoudre qu’un flux orchestré de manière linéaire.

Huit manières dont les équipes d’agents échouent

La plupart des tutoriels sur les systèmes multi-agents omettent cette partie. Les notes techniques d’Anthropic constituent une bonne source. Elles ressemblent moins à un article de recherche qu’au journal intime d’une équipe qui a appris, étape par étape, que l’ajout d’agents supplémentaires multiplie les problèmes de gestion. Huit leçons peuvent en être tirées.

• Dérive de coordination. Une délégation floue pousse les agents à effectuer des recherches redondantes, à manquer de précision dans leurs actions ou à produire des résultats incohérents. Un post de recherche d’Anthropic a mis ce phénomène en évidence, et la solution consistait à apprendre à l’orchestrateur à définir clairement l’objectif, le format de sortie, les directives et la portée de chaque agent. Lorsque les responsabilités ne sont pas définies, les agents improvisent, et souvent de manière inefficace, tout comme les humains.

Propriété hallucinée. L’agent A croit que l’agent B a vérifié quelque chose que personne n’a en réalité vérifié. La solution réside dans des artefacts de finalisation explicites : des points d’ancrage pour les tâches, une vérification bout en bout avant que quoi que ce soit ne soit marqué comme terminé, ainsi que des fichiers d’état durables qui enregistrent ce qui a été effectivement confirmé, et non ce qui a été supposé.

Faute intermédiaire silencieuse. Le débogage nécessitait un suivi complet en environnement de production, car rien ne permettait de déterminer si la faute provenait de requêtes de recherche insuffisantes, de sources peu fiables ou d’un défaut dans les outils. Le flux de session de niveau supérieur n’est qu’une vue condensée ; pour comprendre ce que l’agent appelé a réellement fait, il faut examiner l’historique au niveau des travailleurs. Mettez en place le suivi dès le début, bien avant le premier incident en production.

Encombrement du contexte et pollution mémoire. La fenêtre de contexte est une ressource finie, et la mémoire partagée qui devient obsolète ou perturbée détériore l’ensemble du système. Chaque appel d’outil, lecture de fichier et analyse partielle s’ajoute au contexte et y reste, et ce phénomène s’aggrave au sein d’une équipe. Les solutions connues consistent à résumer les phases terminées, à isoler les tâches lourdes dans des sous-agents et à privilégier de petits fichiers mémoire ciblés plutôt que de grands fichiers partagés.

Désaccord de schéma et contrats de prompt fragiles. Les agents qui échangent des données en langage naturel sont vulnérables. Le deuxième agent interprète mal le résumé du premier, et l’erreur se propage silencieusement. Une utilisation stricte des outils est nécessaire car des appels non stricts peuvent générer des types incompatibles ou des champs manquants. Des contrats précis entre les agents et les outils réduisent les possibilités où cela peut se produire, ce qui revient à donner un rôle ironique aux anciens contrats d’ingénierie dans un environnement d’IA.

Utilisation abusive des outils et défaillances de sécurité. Plus d’environnements ouverts signifient davantage de points d’accès possibles pour l’injection de prompts, et plus d’outils offrent plus de moyens à un attaquant d’agir une fois à l’intérieur. La recherche d’Anthropic sur les agents fiables qualifie l’injection de prompts de vecteur d’attaque informatique plutôt que de cas particulier, et les tests de pénétration menés par METR sur le système interne de surveillance des agents d’Anthropic ont révélé de nouvelles vulnérabilités, même dans un système interne bien doté en ressources. Atténuez ces risques en limitant les permissions, en restreignant l’utilisation des outils aux besoins de la tâche, et en exigeant une approbation humaine pour les actions ayant des conséquences importantes.

Explosion des coûts et accumulation de latence. Les équipes utilisent bien plus de tokens qu’une seule session ne le nécessite. Le parallélisme peut réduire le temps total de traitement, mais il augmente la consommation totale de tokens au lieu de la diminuer, car l’accélération provient d’un effort structuré plus important déployé en même temps. À moins que la tâche ne justifie cette dépense, un agent soigneusement conçu individuellement s’avère plus rapide et moins coûteux.

Difficulté d’évaluation. Divers chemins internes très différents peuvent tous aboutir à un résultat qui semble réussi. Si la seule épreuve est de vérifier si le texte final paraît crédible, on admire alors le système plutôt que de l’évaluer. La recommandation d’Anthropic est de s’assurer que l’état final correct a été atteint, et non pas que le processus prévu a été suivi. Le processus varie, tandis que c’est le résultat qui peut être vérifié.

Natif, DIY ou hybride

La grande question est donc la suivante : développer l’orchestration soi-même ou utiliser une solution prête à l’emploi ? Il s’agit d’un compromis architectural parmi trois options, et il en existe certainement davantage ; considérez donc ceci comme une interprétation subjective.

1. Gestionné natif signifie qu’Anthropic possède le temps d’exécution ainsi que les mécanismes de coordination : Claude Managed Agents, et plus précisément encore, les Managed Agents multiagent ou les équipes d’agents Claude Code. Les avantages sont une charge de travail technique réduite, ainsi qu’un environnement et des infrastructures hébergés dont il n’est pas nécessaire de s’occuper. Les inconvénients sont une portabilité limitée (les Managed Agents ne sont accessibles qu’à travers l’API directe de Claude), une interface multi-agent encore expérimentale ou en version préliminaire restreinte, ainsi qu’une dépendance vis-à-vis d’un tiers. Choisissez cette option lorsque les problèmes liés aux infrastructures sont importants et que les contraintes spécifiques à Anthropic sont acceptables.

DIY signifie que vous possédez la logique d’orchestration et généralement aussi l’environnement de exécution, l’API Messages en étant l’exemple le plus pur. Elle offre le plus grand niveau de contrôle au prix d’un coût technique élevé. Choisissez-la si votre logique métier est particulière, que les règles de conformité sont strictes, que le routage est spécifique à votre domaine, ou si la portabilité du fournisseur est une exigence réelle.

Hybride signifie qu’Anthropic fournit le cycle de traitement et les outils tandis que vous concevez le système, et le Claude Agent SDK en est l’exemple le plus clair. Vous bénéficiez du cycle d’agent, de la gestion du contexte, des hooks, des sous-agents et de l’observabilité d’Anthropic, tout en conservant le contrôle sur la conception de haut niveau. L’authentification via Bedrock, Vertex AI et Azure Foundry offre un avantage significatif en termes de portabilité par rapport aux solutions gérées natives. Choisissez cette option lorsque vous souhaitez utiliser le cycle d’agent d’Anthropic sans devoir adapter toute votre architecture à sa vision actuelle du fonctionnement des systèmes multi-agents.

En bref : solutions gérées natives lorsque c’est l’infrastructure qui pose problème, approche DIY lorsque c’est la topologie et les politiques qui posent problème, et solution hybride lorsque vous voulez utiliser les primitives d’Anthropic tout en ayant la liberté de prendre vos propres décisions architecturales.

La question de l’architecture

La vision la plus répandue chez les équipes d’agents est celle des capacités, selon laquelle plus il y a d’agents, plus les capacités augmentent. La vision qui s’avère utile est plutôt celle de l’architecture : quel problème un agent supplémentaire résout-il, et quel en est le coût ?

Les sous-agents décident qui effectue le travail, dans quel contexte et avec quels outils. Les équipes d’agents ajoutent une couche de coordination en plus, avec un état des tâches partagé, des collègues qui communiquent directement entre eux, ainsi que des exécutions parallèles qui s’organisent d’elles-mêmes. Une telle couche ne s’avère rentable que pour les problèmes qui en ont réellement besoin.

Une équipe d’agents bien configurée pour un cas d’usage réel représente un travail raisonnable pour une semaine. La complexité peut augmenter par la suite, mais elle n’est pas obligatoirement au départ si élevée. Le catalogue des échecs et les modèles de communication mentionnés ci-dessus servent de matériel de référence, et non comme un plan pour tout construire d’un seul coup. Commencez par déterminer lequel des quatre déclencheurs est réellement actif ; s’il n’y en a aucun, la solution avec un seul agent reste la bonne.