Architecture multi-agent : diviser sans discernement, c'est se tirer une balle dans le pied

« Est-ce que découper mon agent en plusieurs agents le rendra plus performant ? »

La réponse est « ça dépend ». Les recherches d’Anthropic montrent que les systèmes multi-agents surpassent les agents uniques de 90 % - mais uniquement lorsque l’architecture est bien choisie. En pratique, les écarts de performance varient considérablement selon le type de tâche à résoudre.

Voici trois scénarios concrets qui révèlent quand chaque pattern tient réellement ses promesses.

Les quatre patterns en un coup d’œil

Avant d’entrer dans le vif du sujet, un résumé rapide des architectures disponibles :

• Sous-agents : Un agent principal invoque des agents spécialisés comme des outils. Excellents pour l’exécution en parallèle, mais chaque résultat doit remonter à l’agent principal
• Skills : Un agent unique charge dynamiquement des prompts experts à la demande. Léger à mettre en place, mais le contexte s’accumule au fil du temps
• Handoffs : L’agent actif est remplacé à chaque étape. Conçu pour les workflows séquentiels, mais incapable d’exécuter des tâches en parallèle
• Routeur : Classifie les requêtes, les distribue en parallèle et agrège les résultats. Stateless - aucun contexte conversationnel n’est conservé

Voyons maintenant comment ces patterns se comportent face à des situations réelles.

Scénario 1 : requêtes ponctuelles

Imaginons qu’un utilisateur dise « Achète-moi un café » - une requête unique pour laquelle un agent spécialisé peut appeler un outil buy_coffee.

Comparaison des performances :

• Sous-agents : 4 appels (principal → sous-agent → exécution de l’outil → retour au principal → réponse)
• Skills / Handoffs / Routeur : 3 appels (exécution directe)

Ce qu’il faut retenir : Les tâches ponctuelles n’ont pas besoin de gestion d’état. Skills, Handoffs et Routeur sont donc les plus efficaces. Les sous-agents ajoutent un aller-retour supplémentaire via l’agent principal, ce qui se traduit directement en latence. Pour des tâches simples, recourir à une architecture multi-agent est tout simplement disproportionné.

En pratique : Les bots FAQ, l’exécution de commandes simples et les requêtes de données ponctuelles fonctionnent parfaitement avec un agent unique. Ici, le multi-agent relève de la sur-ingénierie.

Scénario 2 : requêtes répétées

L’utilisateur dit maintenant « Achète-moi un autre café » - la même requête, formulée une seconde fois. Le contexte conversationnel est conservé.

Comparaison des performances (deuxième tour) :

• Sous-agents : 4 appels → 8 au total (stateless, cycle complet à chaque fois)
• Skills / Handoffs : 2 appels → 5 au total (réduction de 40 %)
• Routeur : 3 appels → 6 au total (réduction de 25 %)

Ce qu’il faut retenir : Les patterns avec état - Skills et Handoffs - dominent clairement. Ils réutilisent le contexte déjà chargé et sautent entièrement les étapes de routage et d’initialisation. Les sous-agents, stateless par conception, répètent le cycle complet à chaque requête. En contrepartie, ils offrent une meilleure isolation du contexte - un surcoût justifié si la sécurité ou le sandboxing sont prioritaires.

En pratique : Les chatbots, les assistants conversationnels et les services basés sur des sessions ont besoin de patterns avec état. Si vos utilisateurs disent souvent « refais comme la dernière fois », privilégiez Skills ou Handoffs. Un Routeur peut toujours être encapsulé comme outil au sein d’un agent avec état si nécessaire.

Scénario 3 : requêtes multi-domaines

Un utilisateur demande « Compare Python, JavaScript et Rust » - une requête qui couvre plusieurs domaines spécialisés. Supposons environ 2 000 tokens de documentation de référence par langage.

Comparaison des performances :

• Sous-agents : 5 appels, ~9K tokens (chaque sous-agent travaille dans un contexte isolé)
• Skills : 3 appels, ~15K tokens (les trois contextes de skills s’empilent dans le contexte principal)
• Handoffs : 7+ appels, ~14K+ tokens (exécution séquentielle uniquement)
• Routeur : 5 appels, ~9K tokens (exécution en parallèle)

Ce qu’il faut retenir : Les patterns capables d’exécution en parallèle - Sous-agents et Routeur - l’emportent nettement. Les sous-agents traitent la documentation de chaque langage dans des contextes isolés, consommant 67 % de tokens en moins par rapport aux Skills (9K contre 15K). Les Skills effectuent moins d’appels, mais empilent les connaissances des trois domaines dans le contexte principal, ce qui fait exploser la consommation de tokens. Les Handoffs, limités à l’exécution séquentielle, sont les moins adaptés à ce type de travail.

En pratique : Les systèmes de recherche, les analyses comparatives multi-sources et les bases de connaissances d’entreprise qui interrogent simultanément plusieurs domaines indépendants appellent des Sous-agents ou un Routeur. Quand on manipule de grandes quantités de connaissances par domaine, l’isolation du contexte a un impact direct sur le coût en tokens.

Guide de sélection des patterns

Scénario	Pattern recommandé
Tâches ponctuelles	Un agent unique suffit
Requêtes répétées fréquentes	Skills ou Handoffs
Plusieurs domaines interrogés simultanément	Sous-agents ou Routeur
Workflows séquentiels	Handoffs

Un dernier conseil pratique

Ne commencez pas par le multi-agent. Partez d’un agent unique, appuyé par de bons prompts et des outils bien définis. Ne passez au multi-agent que lorsque vous heurtez une limitation claire - puis utilisez les scénarios ci-dessus pour choisir le bon pattern.

La leçon des recherches d’Anthropic, ce n’est pas « plus d’agents = mieux ». C’est que la bonne architecture, appliquée à la bonne tâche, est ce qui produit cette amélioration de 90 %.