Chapitre 14 — Benchmarking, tests et performance

Quinzième et dernier billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Le chapitre où l'architecture doit enfin répondre à la question sans sentimentalité — le système fonctionne-t-il vraiment ? — et où la réponse arrive par de vrais benchmarks, deux modes de défaillance systémiques, et une falaise de débit dix-pour-un que la plupart des équipes découvrent le jour du déploiement en production.

Pourquoi ce chapitre existe

Un protocole soigneusement conçu, durci en sécurité et proprement enveloppé dans un framework doit encore répondre à la question sans sentimentalité : le système fonctionne-t-il vraiment ? L'agent résout-il les tâches pour lesquelles il a été bâti ? Tient-il quand la charge double ? Où sont les falaises de performance qui transforment une dégradation gracieuse en panne ? Les chapitres précédents portaient sur le bon réglage de l'architecture ; celui-ci porte sur la mesure de la livraison une fois l'architecture bâtie. Il parcourt le MCP-Universe Benchmark — le premier harnais public testant de vrais LLM contre de vrais serveurs MCP — les deux modes de défaillance systémiques que le benchmark a découverts et les atténuations qui commencent à fonctionner, et le côté débit où l'écart entre un pool de sessions bien conçu et le patron naïf par requête est d'un ordre de grandeur.

14.1 MCP-Universe : mesurer les agents sur de vrais serveurs

Pendant l'essentiel de 2024 et du début de 2025, l'évaluation publique des agents vivait dans un endroit étrange. Les benchmarks d'usage d'outils mesuraient si les modèles émettaient des appels syntaxiquement corrects contre des API synthétiques. Les benchmarks d'agents mesuraient l'achèvement de tâche dans des environnements en bac à sable. Ce qui manquait, c'était un benchmark testant les modèles contre de vrais serveurs MCP avec authentification réelle, vrais rate limits, vrais schémas qui dérivent, vrais outils qui renvoient parfois des résultats vides. MCP-Universe, sorti par Salesforce AI Research en 2025, a été la première tentative sérieuse. Six domaines d'évaluation couvrant onze serveurs MCP de production réels — Google Maps, GitHub, Yahoo Finance, Blender, Playwright, vrais moteurs de recherche — et 231 tâches, chacune avec un évaluateur automatique qui vérifie si l'état final correspond au résultat attendu plutôt que si le modèle a émis les « bons » appels en chemin.

Le résultat principal a tenu à travers les rafraîchissements de modèles. Claude 3.5 Sonnet, qui score dans les quatre-vingts sur les benchmarks synthétiques, n'a atteint que les quarante bas à moyens sur MCP-Universe global. GPT-4o, Gemini 1.5 Pro et les variantes Llama-3 70B se sont regroupés dans un territoire similaire. L'écart entre la performance d'usage d'outils en circuit fermé et la performance MCP réelle était d'environ quarante points absolus, et l'échelle seule ne le fermait pas. Les défaillances se regroupent en catégories reconnaissables : dégradation à long contexte à mesure que les sorties d'outils remplissent la fenêtre ; exploration d'outils inconnus à mesure que le modèle lit mal des schémas peu familiers ; coordination entre serveurs où les formats de sortie ne correspondent pas et où aucun pont sémantique n'existe ; et raisonnement spécifique à la tâche où le modèle sélectionne le bon outil, l'appelle correctement, obtient la bonne réponse, et arrive quand même à la mauvaise conclusion finale parce qu'il a échoué à intégrer la sortie d'outil dans le raisonnement plus large. Les choix structurels qui font de MCP-Universe un instrument sérieux sont l'évaluation par exécution (faire tourner les appels contre de vrais serveurs, pas comparer à une trace de référence), les données en temps réel (données de marché vivantes, l'évaluateur traçant ce qu'était la réponse à l'instant du test), et l'évaluation multi-tours (noter l'état final, pas chaque étape). Un effet de bord utile : le benchmark opère comme un signal de qualité indirect sur la conception des serveurs, et les auteurs de serveurs qui se soucient de la performance des agents ont désormais une cible publique.

14.2 Les deux défis systémiques et ce qui marche

La dégradation à long contexte et l'exploration d'outils inconnus sont les deux modes de défaillance assez grands pour mériter un traitement soigneux, parce que les atténuations ne sont pas évidentes. La dégradation à long contexte dans les agents MCP a une forme spécifique : le contexte se remplit de sorties d'outils qui sont toutes pertinentes en un sens — chacune était le résultat d'un appel que le modèle a choisi de faire — mais chacune est volumineuse et le fait qui porte vraiment à l'intérieur de chacune est petit. Les atténuations opèrent au niveau de la présentation de l'information. Le résumé des résultats d'outils fait passer un modèle bon marché (Haiku, GPT-4o-mini, Gemini Flash) sur la sortie brute d'outil avant que le résultat n'atterrisse dans le contexte de l'agent ; les déploiements de production rapportent une amélioration de deux à trois fois des taux de complétion à long contexte, et le coût par appel est dominé par le modèle bon marché. La sortie d'outil structurée avec un champ summary à côté de la charge utile JSON — formalisée dans la révision de protocole de 2025 — fait un travail similaire sans l'appel modèle supplémentaire. La compaction de contexte sur la boucle d'agent, appariée à un scratchpad géré par l'agent qui survit textuellement à la compaction, gère le cas où la conversation elle-même est devenue trop longue ; les déploiements de production déclenchent la compaction toutes les vingt à quarante étapes et préservent environ un tiers du contexte original.

L'exploration d'outils inconnus a une forme différente. Quand un agent se connecte à un serveur avec des outils sur lesquels il n'a pas été entraîné, les premiers appels du modèle échouent souvent — mauvais types, mauvais ordre, parfois mauvais outil. L'atténuation est une phase d'exploration avant la boucle principale : le framework demande au modèle de lire la description de chaque outil, de résumer ce qu'il fait, de générer un exemple d'invocation, et de signaler les paramètres dont il n'est pas sûr. La note résultante préfixe le contexte de l'agent. Le coût est de quelques appels bon marché au début de session ; le bénéfice est de vingt à trente points de pourcentage de mieux à la complétion sur des benchmarks comme MCP-Universe et un registre auditable de la compréhension déclarée de l'agent qui aide à attribuer les défaillances ultérieures. Le patron s'étend aux outils modifiés : hasher la surface d'outils à la connexion, lancer la phase d'échauffement chaque fois que le hash change, et le mode de défaillance par dérive silencieuse (serveur mis à jour, agents qui échouent pendant des semaines avant que quelqu'un ne remarque) disparaît. Une troisième question liée à nommer : la qualité des descriptions d'outils. Beaucoup de serveurs ont livré des descriptions écrites pour des développeurs humains — lapidaires, chargées de jargon, supposant le contexte. Les serveurs réécrits comme pour un stagiaire qui n'a jamais vu le système montrent des améliorations mesurables contre les mêmes modèles sans changement de code d'agent. La seule fenêtre du modèle sur l'outil, c'est la description, et une description qui ne se suffit pas à elle-même produit un modèle qui ne peut pas utiliser l'outil.

14.3 La falaise de débit du pool de sessions

La justesse est la moitié de l'histoire ; la réalité de production est que les choix de conception qui rendent un agent rapide ont souvent des implications sur la justesse et inversement. Le plus grand problème de débit dans les déploiements MCP de 2025-2026, c'est l'écart entre deux façons de gérer les sessions Streamable HTTP, et l'écart est d'environ dix-pour-un. Session-par-requête ouvre une nouvelle session par requête d'agent, exécute les appels d'outils à l'intérieur, et la ferme à la fin. Pool de sessions partagées maintient un pool de sessions longues et assigne chaque requête à l'une d'elles. La différence de débit sur un serveur standard avec une charge représentative se pose constamment autour de dix fois — environ trente requêtes par seconde pour session-par-requête, environ 290 à 300 pour le pool, sur du matériel courant. Les équipes qui ignorent l'écart le découvrent à la dure : le staging tourne bien, le rollout de production frappe un mur au taux de requêtes où le surcoût de création de session domine.

Le mécanisme est simple. La création de session est coûteuse — allocation d'état, négociation des capacités, validation des credentials, enregistrement du nettoyage, journalisation structurée — et la poignée de main au niveau MCP ajoute des allers-retours protocolaires que le transport ne peut pas éviter. Session-par-requête paie ce coût à chaque requête ; le pool le paie une fois par session et l'amortit. Les détails d'implémentation qui décident si le pool fonctionne vraiment en pratique : isolation (l'état par requête est un sous-contexte à l'intérieur de la session, créé et détruit par requête, tandis que l'état par session est partagé), dimensionnement du pool (le compte concurrent p95 avec autoscaling pour les pics), vérification de santé (vérifications de fond sur les sessions inactives, vérifications rapides à l'assignation), et affinité de requête par sessions collantes pour les outils dont l'état couvre plusieurs appels. Superposé là-dessus, le multiplexage de connexions HTTP/2 ou HTTP/3 — une connexion sous-jacente portant plusieurs flux concurrents — produit les chiffres de débit cités ; l'une ou l'autre couche de pool seule produit une amélioration bien plus petite. La dimension de la queue de latence compte aussi : le serveur session-par-requête a de longues latences de queue par moments malchanceux durant la création, le pool en a de serrées parce que le coût de création est asynchrone hors du chemin chaud de la requête. Le P99 s'améliore typiquement de trois ou quatre fois — un gain plus grand que le débit, et celui qui façonne vraiment l'expérience utilisateur.

14.4 Ce que la série a bâti

Les quatre volumes ont parcouru un arc délibéré. Le Volume I portait sur l'intérieur du modèle. Le Volume II portait sur les prompts et le raisonnement. Le Volume III portait sur la génération augmentée par récupération. Ce volume a porté sur les agents et les outils, organisé autour de MCP parce que MCP est le substrat technique qui a rendu l'architecture d'agents cohérente. Trois fils ont traversé l'ensemble. Le premier est la séparation entre cognition et opérations : le modèle est la couche cognitive, le framework et les serveurs MCP sont la couche opérationnelle, et la plupart des défaillances de production viennent d'effondrer les deux ensemble. Le second est le budget de contexte fini : le contexte est une ressource rare, et les choix architecturaux qui produisent des agents fiables sont ceux qui respectent cette rareté. Le troisième est le protocole-comme-frontière : MCP n'est pas qu'un format de fil mais une frontière à travers laquelle les capacités circulent, où la confiance doit être négociée, et où l'évolution future continuera d'arriver. Un protocole qui tient sous la pression d'ingénierie devient de l'infrastructure ; MCP semble être en train de le faire.

Ce que prépare le Volume IV

Ceci est le dernier chapitre du volume, donc ce qu'il prépare n'est pas le chapitre suivant mais le volume suivant. Le Volume V — LLM Primer V — Construire des applications LLM en conditions réelles — reprend les fondations posées à travers les Volumes I à IV et les assemble en archétypes d'applications spécifiques : assistants pour le génie logiciel, agents pour l'automatisation métier, copilotes dans des applications verticales, outils de recherche autonomes. Le traitement portera moins sur les mécanismes sous-jacents (que les volumes précédents ont couverts) et plus sur les choix d'ingénierie au niveau application — comment cadrer une application LLM pour qu'elle livre de la valeur de manière fiable, comment l'évaluer en production, comment gérer le cycle de vie des prompts, des outils et de la mémoire à mesure que l'application évolue. Le lecteur qui termine le Volume V aura parcouru le chemin d'une seule tête d'attention à une application déployée qui exerce un agent sur une vraie pile de serveurs MCP, sur une vraie infrastructure, avec le jugement d'ingénierie pour savoir pourquoi chaque couche a été bâtie comme elle l'a été.

La série continue dans LLM Primer V — Construire des applications LLM en conditions réelles.