---

Le survey qui dérange : ce qu’un an de littérature dit vraiment sur les agents multi-outils

Il faut commencer par une mise au point honnête, parce qu’elle conditionne tout ce qui suit. Le survey de 2026 qui cartographie le glissement des agents LLM du simple appel d’outil vers l’orchestration multi-outils existe bien — un relais média en a publié la synthèse sous le titre évocateur « Survey maps how LLM agents moved from single tool calls to multi-tool orchestration ». Mais dans la matière que nous avons pu rassembler pour cette enquête, nous n’avons accès qu’au titre et à l’objet du survey, pas à son contenu intégral : ni le nombre exact de papiers analysés, ni la période couverte, ni la taxonomie formelle proposée ne sont disponibles de première main. Nous le disons d’emblée : cet article s’appuie sur les résultats accessibles du survey, sur la littérature technique datée de 2026 collectée par la rédaction, et sur les faits documentés du magazine. Là où une donnée manque, nous restons général plutôt que d’inventer un chiffre.

Cela posé, le basculement conceptuel que le survey décrit est réel et il est massif. Pendant la période 2023-2025, la littérature sur les agents s’est organisée autour d’une question simple : un modèle, un outil, un appel. ReAct, Toolformer, puis les benchmarks d’appel d’outils (ToolBench, API-Bank, BFCL) ont construit un imaginaire du « function calling » propre et borné : le modèle remplit un schéma JSON, le harnais exécute, on recommence. En 2026, l’objet d’étude a changé d’échelle. La question n’est plus « le modèle sait-il appeler un outil ? » mais « comment un système coordonne-t-il une dizaine d’outils hétérogènes, dans le bon ordre, avec reprise sur erreur, sans exploser en latence ni en coût ? ». C’est un problème d’architecture distribuée déguisé en problème d’IA.

Pourquoi 2026 et pas 2025 ? Parce que trois courbes se sont croisées. D’abord, l’infrastructure s’est standardisée : le Model Context Protocol (MCP), devenu un standard ouvert documenté (modelcontextprotocol.io), a transformé chaque éditeur SaaS en fournisseur potentiel d’outils — Forrester, repris par Studeria, projette une adoption MCP par les éditeurs SaaS passant de 30 % en 2026 à 60 % en 2027. Ensuite, les modèles eux-mêmes ont intégré l’appel d’outil comme primitive native : l’Agents API d’OpenAI, en bêta publique depuis le 10 septembre 2026, livre un harnais où « le modèle remplit du JSON, le harness appelle les outils » (jsonsort.com). Enfin, les échecs en production sont devenus trop visibles pour être ignorés : les agents déployés en production affichent un taux d’échec à la mise en service de 88 % en 2026. Le survey arrive donc au moment exact où la promesse marketing rencontre le réel de l’exploitation.

---

Anatomie d’une orchestration : planifier, router, mémoriser, rattraper, paralléliser

Ce que le survey formalise, c’est une chaîne technique en cinq maillons. Déroulons-la, et pour chacun, voyons ce que cela implique concrètement dans le code.

1. La planification. Avant d’appeler quoi que ce soit, il faut décomposer la tâche en sous-tâches ordonnées. C’est le maillon le plus fragile, parce qu’il est purement cognitif : rien ne garantit que le plan produit soit exécutable avec les outils disponibles. Dans le code, cela se traduit par une interface de plan explicite — une liste d’étapes avec dépendances déclarées — plutôt qu’un prompt fourre-tout. Le pattern « plan-and-execute » identifié par les cabinets de conseil (ayinedjimi-consultants.fr) sépare justement la génération du plan de son exécution, ce qui permet de valider le plan avant de brûler des tokens d’appel.

2. La sélection et le routage d’outils. C’est le cœur du « function calling » moderne : le modèle reçoit un catalogue de schémas JSON et choisit lequel invoquer. La distinction entre tool calling (le logiciel exécute l’action) et function calling (terminologie fournisseur) est désormais documentée (bird.com), et MCP ajoute une couche : le serveur MCP expose des outils que l’agent découvre dynamiquement. Conséquence de code : vos schémas d’outils sont un contrat. Un schéma qui change casse silencieusement l’agent. Il faut versionner ces schémas et tester la non-régression dessus.

3. La gestion d’état et la mémoire. Un agent multi-étapes doit se souvenir de ce qu’il a fait. Le survey distingue la mémoire de contexte (le scratchpad dans la fenêtre du modèle) de l’état externe (une base, un checkpoint). La leçon pratique est brutale : ne comptez pas sur le contexte seul. Les données du magazine sur Claude Code illustrent l’échelle du problème — environ 128K tokens de contexte par sous-agent, une sortie de 64K tokens, et un simple déploiement de 12 agents Opus consommant environ 168K tokens par minute, soit 5,6 fois la limite d’un palier d’entrée de gamme (30K ITPM). Sans état externe, vous ne tenez pas la charge.

4. La reprise sur erreur. Retry, fallback, vérification. C’est ici que la plupart des implémentations amateurs s’effondrent. Un outil qui échoue une fois sur dix, appelé huit fois dans une chaîne, donne un taux d’échec composé qui grimpe vite. Le survey formalise les « boucles de vérification » : après chaque appel critique, un second appel (ou une règle déterministe) confirme que le résultat est plausible avant de continuer. Coût : un appel de plus. Bénéfice : un agent qui ne propage pas une erreur silencieuse.

5. La parallélisation. Fan-out/fan-in : lancer plusieurs appels indépendants en concurrence, puis agréger. C’est le levier de latence le plus direct — et le plus piégeux. Un agent avec huit appels d’outils séquentiels affiche plus de 6 secondes de latence avant réponse (à 800 ms par appel). Paralléliser les appels indépendants divise ce temps, mais multiplie la consommation de tokens par minute et peut saturer vos quotas. Le dispatch parallèle existe côté produit (l’Agent Tool de Claude Code dispatche en parallèle avec un contexte frais par sous-agent), mais la hiérarchie reste plate — un seul niveau, pas de nesting — et l’échec d’un sous-agent n’est visible que par un retour textuel, pas par un statut structuré. Autrement dit : la parallélisation vous rend plus rapide et plus difficile à déboguer.

---

Quatre familles d’architectures : séquentiel, DAG, boucle réactive, débat multi-agents

La vraie valeur du survey pour un praticien, c’est la grille de lecture des patterns. Quatre familles se dégagent, et elles ne se valent pas selon la tâche.

Architecture	Mécanique	Coût de coordination	Latence	Tolérance aux erreurs	Observabilité
Pipeline séquentiel	Étapes fixes, une après l’autre	Faible	Cumulée, linéaire	Faible (erreur propage)	Excellente (trace linéaire)
DAG d’outils	Graphe acyclique, dépendances déclarées, parallélisation possible	Moyen	Optimisable (fan-out)	Moyenne (isolation par branche)	Bonne (graphe traçable)
Boucle réactive (ReAct)	Penser → agir → observer, en boucle	Élevé (tokens)	Imprévisible	Bonne (auto-correction)	Difficile (boucles)
Débat multi-agents	Plusieurs agents, consensus/vérification croisée	Très élevé	Longue	Très bonne (recoupement)	Très difficile

Le pipeline séquentiel est le plus simple et le plus sous-estimé. Quand les étapes sont connues d’avance, il bat tout le reste en fiabilité et en coût. Son défaut : aucune adaptativité.

Le DAG ajoute la parallélisation et l’isolation des branches. C’est le sweet spot pour les tâches à dépendances connues mais nombreuses : vous déclarez le graphe, vous exécutez les branches indépendantes en concurrence, une branche qui échoue ne contamine pas les autres. C’est aussi le pattern le plus proche d’un orchestrateur classique — ce qui n’est pas un hasard (on y revient).

La boucle réactive type ReAct est la plus « intelligente » et la plus coûteuse. Elle excelle quand le chemin n’est pas connu d’avance et qu’il faut s’adapter à ce que renvoient les outils. Son talon d’Achille : les boucles infinies. Les anti-patterns documentés sont sans appel — absence de max_handoffs, manque de checkpoints, observabilité insuffisante. Sans plafond d’itérations, une boucle réactive peut tourner jusqu’à épuisement du budget.

Le débat multi-agents (supervisor, swarm, consensus) est le plus coûteux de tous. Il fait intervenir plusieurs agents qui se vérifient mutuellement. La littérature cite un ordre de grandeur frappant : une consommation de jetons jusqu’à 15 fois supérieure à un simple chat pour l’orchestration multi-agents (chiffre attribué à Anthropic via un cabinet tiers, non retrouvé en source primaire dans notre corpus — à prendre avec précaution). Sa justification est étroite : tâches à très forte incertitude où la vérification croisée vaut son prix. Pour la plupart des cas d’usage, un seul agent bien réglé suffit encore.

Critères de choix, en une phrase chacun : décomposition forte et stable → pipeline ou DAG ; dépendances connues et parallélisables → DAG ; chemin inconnu, adaptation requise → boucle réactive ; incertitude élevée, erreur coûteuse → débat, avec parcimonie.

---

Ce que les benchmarks disent (et ne disent pas) : mono-outil vs multi-outils

C’est ici qu’il faut être le plus prudent, car c’est ici que les vendeurs trichent le plus. Le survey compile des résultats sur les benchmarks canoniques — ToolBench, API-Bank, BFCL, GAIA, AgentBench, SWE-bench — mais nous ne disposons pas, dans notre corpus, des chiffres précis par benchmark. Nous ne les inventerons pas. Ce que nous pouvons dire avec certitude, c’est comment ces benchmarks biaisent la mesure.

Premier biais : les tâches synthétiques. ToolBench et API-Bank évaluent l’appel d’outil sur des API propres, documentées, stables. En production, les API changent, les schémas dérivent, les permissions se resserrent. Un score de laboratoire mesure la performance sur un monde figé.

Deuxième biais : l’absence de coût réel. Les benchmarks comptent le taux de réussite, rarement le coût par tâche. Or un agent qui réussit en 12 étapes à 15 fois le coût d’un chat n’est pas « meilleur » qu’un pipeline qui réussit en 3 étapes déterministes. Les chiffres de production du magazine sont éloquents : un agent correctement architecturé coûte 29 à 50 dollars par mois, un agent non optimisé environ 200 dollars — un facteur de 4 à 7 pour la même fonction nominale. Le benchmark ne voit pas cette différence ; votre facture, si.

Troisième biais : la saturation. Les benchmarks d’appel d’outil mono-outil sont saturés — les meilleurs modèles plafonnent, ce qui pousse la recherche vers le multi-outils. Mais saturer un benchmark ne signifie pas résoudre le problème réel ; cela signifie que le benchmark ne discrimine plus.

Quatrième biais, le plus insidieux : le taux d’échec composé. Un benchmark mesure des tâches isolées. La production enchaîne. Un agent de support client non surveillé dépasse 30 % de tâches ratées après trois semaines d’exploitation. Aucun benchmark mono-tâche ne capture cette dégradation temporelle, qui vient de la dérive des outils et de l’accumulation d’états corrompus.

Conclusion : les chiffres de laboratoire ne se transposent pas linéairement en production. Ils indiquent une direction (le multi-outils aide sur les tâches composites), pas une magnitude transposable.

---

Le mur de la production : latence, coût, fiabilité, observabilité

Le survey décrit des architectures ; la production impose des contraintes que le survey effleure. Quatre murs.

Le mur des tokens. La coordination coûte cher en contexte. Chaque étape réinjecte l’historique, chaque sous-agent a son propre contexte. Un agent avec accès à 15 serveurs MCP n’en sollicite qu’une demi-douzaine par tâche — mais le simple fait de charger les catalogues de 15 serveurs dans le contexte initial pèse. Le remède : ne charger que les schémas pertinents, filtrer dynamiquement.

Le mur de la latence. Les appels en chaîne s’additionnent. Huit appels à 800 ms font plus de 6 secondes avant la première réponse utile. En parallélisant les appels indépendants et en streaming les résultats partiels, on reprend la main — mais au prix de la complexité.

Le mur de la fiabilité composée. Si chaque appel échoue 5 % du temps, une chaîne de huit appels échoue environ un tiers du temps. La reprise sur erreur n’est pas une option, c’est la condition de survie. Retry avec backoff, fallback vers un outil de secours, vérification post-appel.

Le mur de l’observabilité. Tracer une décision multi-étapes est difficile. Sans traces structurées, vous ne savez pas pourquoi l’agent a choisi tel outil. Les garde-fous à instrumenter, dans l’ordre :

• Budgets de tokens par tâche et par agent, avec coupure dure.
• Timeouts par outil, différenciés selon la criticité.
• Traces structurées (une ligne par appel : outil, entrée, sortie, latence, coût).
• Tests de non-régression sur les schémas d’outils : rejouer un jeu de tâches à chaque changement de schéma.
• Détection de dérive : surveiller le taux de succès par outil ; quand un outil change, l’agent casse — il faut le voir avant l’utilisateur.

La sécurité s’invite dans le tableau : l’OWASP 2026 LLM Top 10 titre « le modèle sera trompé » (helpnetsecurity.com), et les tests de l’agence britannique AISI ont relevé 19 actions non autorisées exécutées par des agents en août 2026. Un agent multi-outils est une surface d’attaque : chaque outil exposé est un vecteur d’injection.

---

Quand refuser l’orchestration : le retour du pipeline déterministe

Voici la recommandation que le survey, dans sa version accessible, ne formule pas assez fort : souvent, il faut refuser l’orchestration LLM. Un workflow codé en dur, un DAG déterministe, un enchaînement de prompts fixes battent l’agent multi-outils sur trois critères quand la tâche est stable.

Pourquoi ? Parce qu’un pipeline déterministe n’a pas de coût de coordination, pas de latence de raisonnement, pas d’échec composé imprévisible. Il est testable, observable, reproductible. L’agent multi-outils n’apporte de valeur que là où la décision de quel outil appeler, dans quel ordre, avec quelle adaptation, ne peut pas être codée d’avance.

Grille de décision :

• Tâche stable et répétitive, chemin connu → déterministe. Toujours. Un cron qui appelle trois API dans l’ordre n’a pas besoin d’un LLM.
• Tâche ouverte, outils hétérogènes, chemin inconnu → orchestration LLM justifiée.
• Zone grise → hybride : le LLM décide du routage (quel outil pour cette requête), le déterministe exécute la séquence connue. C’est le meilleur des deux mondes et le pattern le plus sous-utilisé.

Signaux d’alarme qui doivent vous faire revenir en arrière : le taux de succès de l’agent ne dépasse pas celui du pipeline qu’il remplace ; le coût par tâche dépasse le budget ; les traces montrent que l’agent choisit presque toujours le même chemin (alors codez-le) ; les incidents de production viennent de la coordination, pas des outils eux-mêmes.

---

Les angles morts du survey : évaluation, sécurité, coût de la coordination

Ce que la cartographie académique laisse dans l’ombre dessine les chantiers des six à douze prochains mois.

L’évaluation du coût réel. Aucun benchmark standard ne mesure le coût par tâche réussi. Il faut des métriques composites : dollars par tâche accomplie, tokens par décision utile. C’est un chantier ouvert.

La sécurité des outils exposés. MCP a standardisé l’exposition d’outils sans standardiser les permissions. Safari 27 a intégré un serveur MCP natif avec 17 outils d’automatisation et aucun contrôle MDM pour les désactiver (forkast.news) — un cas d’école de surface d’attaque involontaire. Le sandboxing des outils et le principe du moindre privilège restent à industrialiser.

La robustesse à long terme. Les benchmarks mesurent à l’instant t. Personne ne mesure la dérive sur trois mois. Or c’est là que les agents meurent — plus de 30 % d’échec après trois semaines pour un agent de support non surveillé.

La coordination multi-agents non résolue. Les protocoles de communication entre agents (liste de tâches partagée, événements) se standardisent à peine. L’arrivée des webhooks événementiels MCP, qui donnent au protocole une troisième jambe de communication — la capacité de réagir au monde plutôt que de seulement l’interroger (forkast.news) — ouvre la voie, mais la coordination reste artisanale.

À anticiper dès maintenant : instrumentez le coût comme une métrique de premier ordre, traitez chaque outil exposé comme une frontière de sécurité, et testez la dérive avant qu’elle ne vous teste.

---

Ce que ça change dans votre code dès lundi

Hiérarchisons, du plus sûr au plus risqué.

1. Commencez par un agent mono-outil instrumenté. Un outil, des traces structurées, un budget de tokens, un timeout. Mesurez. Vous découvrirez que beaucoup de vos « besoins multi-outils » sont des besoins mono-outil mal instrumentés.

2. N’ajoutez de la coordination qu’avec des traces et des budgets. Pas de deuxième outil sans observabilité. Pas de boucle réactive sans max_iterations. Pas de parallélisation sans plafond de tokens par minute.

3. Préférez le DAG déterministe quand les dépendances sont connues. Déclarez le graphe, exécutez les branches indépendantes en concurrence, isolez les échecs. Réservez le LLM à la décision de routage.

4. Réservez le débat multi-agents aux tâches à haute incertitude. Et acceptez-en le prix : jusqu’à 15 fois le coût d’un chat selon l’ordre de grandeur cité.

Liste de vérification avant mise en production : schémas d’outils versionnés et testés en non-régression ; timeouts par outil ; budget de tokens avec coupure dure ; traces structurées par appel ; détection de dérive par outil ; plafond d’itérations ; sandboxing des outils sensibles ; plan de repli déterministe.

Indicateurs à surveiller pour décider de complexifier — ou de simplifier : taux de succès par tâche (vs le pipeline de référence), coût par tâche réussie, latence P95, nombre moyen d’étapes, taux d’échec par outil. Si l’agent ne bat pas le déterministe sur ces cinq indicateurs, simplifiez. La meilleure orchestration multi-outils est parfois celle qu’on n’a pas écrite.

---

Sources

• Survey maps how LLM agents moved from single tool calls to multi-tool orchestration — bioengineer.org (relais du survey 2026)
• What is the Model Context Protocol (MCP)? — documentation officielle MCP
• OpenAI Agents API 2026 : JSON Schema, Tool Calling — jsonsort.com (bêta publique 10 septembre 2026)
• Qu’est-ce que le tool calling, et en quoi diffère-t-il du function calling ? — bird.com (8 septembre 2026)
• OWASP 2026 LLM Top 10: "The model will be fooled" — Help Net Security (6 août 2026)
• Safari 27 Ships a Native MCP Server — forkast.news (20 septembre 2026)
• MCP Events Complete the Agent Communication Model — forkast.news (29 septembre 2026)
• LLM pipelines et MCP : la surface d’attaque que personne ne surveille — ayinedjimi-consultants.fr (19 septembre 2026)
• Meilleurs frameworks d’agents open source pour LLM locaux en 2026 — lefilia.fr (18 septembre 2026)
• La nouvelle obsession de la tech : de bons « harnais » pour maîtriser les IA — La Tribune (1er septembre 2026)
• Données de production et coûts d’agents (29-50 $ vs ~200 $/mois ; 88 % d’échec à la mise en service ; >30 % d’échec après trois semaines ; >6 s de latence pour 8 appels ; 3-8 appels par requête) — faits documentés du magazine, 2026.