Tu as branché ton agent IA — un programme autonome qui appelle des outils externes pour accomplir des tâches — sur une douzaine de serveurs MCP (Model Context Protocol — une norme universelle de branchement pour outils IA, un peu comme l'USB mais pour les données). Tu l'as testé. La démo était nickel. Tu l'as mis en production, là où les vrais systèmes cassent de vraies façons.

Et puis le premier timeout d'outil est tombé. Ton agent a retenté le même appel foireux neuf fois, cramé 12 $ en tokens (les unités de texte que l'IA traite, facturées à l'usage), et halluciné un faux résultat. Parce que rien — absolument rien dans le protocole — ne lui disait que l'erreur était permanente.

Quatre priorités, zéro sur les erreurs

Le 19 avril, le projet MCP a publié sa feuille de route 2026. Quatre priorités : évolution du transport, communication entre agents, gouvernance, maturité entreprise. La taxonomie des erreurs — le truc qui fait planter tous les agents en production — n'y figure pas. Pas mentionnée. Pas prévue. Dans le radar de personne.

Ce n'est pas un oubli qu'on peut balayer d'un revers de main. La spécification officielle MCP (révision en vigueur : 25 novembre 2025) définit les erreurs d'exécution d'outils comme isError: true accompagné d'une chaîne de texte libre en anglais — la même structure qu'une réponse réussie, sauf qu'un booléen a changé de valeur. Pas de champ de code d'erreur. Pas d'en-tête retry-after. Pas de niveau de sévérité. La spec dit littéralement que les erreurs d'outils contiennent « un retour actionnable que les modèles de langage peuvent utiliser pour s'auto-corriger ». Ce « retour actionnable », c'est une phrase en anglais non structurée que le LLM doit lire et interpréter tout seul.

HTTP — le protocole que ton navigateur utilise — a résolu ça il y a plus de trente ans. 404 signifie « n'existe pas ». 429 signifie « lève le pied ». 503 signifie « réessaie plus tard ». Trois chiffres. Une table de correspondance. MCP demande à un modèle de langage probabiliste de faire ce qu'un if-statement devrait faire.

Chacun bricole dans son coin

Alexey Tyurin a publié un MCP Reliability Playbook le 9 mars 2026, via Google Cloud Community. Il a dû inventer sa propre taxonomie d'erreurs — CircuitOpenError, TimeoutError, RateLimitError — sous forme d'erreurs typées custom, parce que le protocole n'en fournit aucune. Circuit breaker avec un seuil d'erreur à 50 %, backoff exponentiel avec jitter. 317 tests rien que pour empêcher les outils de crasher son agent. Tout en custom. Tout par serveur. Tout incompatible avec le bricolage du voisin.

Pendant ce temps, des chercheurs de Polytechnique Montréal ont analysé 407 bugs spécifiques à MCP dans 385 dépôts (publié le 5 mars 2026) et ont découvert que la gestion des réponses d'outils était la catégorie de défaillance la plus fréquente — 66,7 % des praticiens interrogés l'avaient rencontrée. Et un bug Claude Code du 11 mars a montré le protocole qui casse de façon encore plus basique : quand les outils MCP renvoyaient des données dans le champ content sans structuredContent, Claude Code percevait une réponse vide et retentait indéfiniment. L'agent ne savait pas qu'il recevait déjà la bonne réponse.

Les chiffres ne mentent pas

Une étude des AWS Heroes du 18 mars a quantifié les dégâts : 97,1 % des outils MCP ont au moins un problème de qualité de description, et des appels d'outils chaînés avec 95 % de réussite individuelle chacun n'atteignent que 85,7 % de fiabilité globale. Ajoute une gestion d'erreurs non structurée à cette chaîne, et tu joues aux dés avec ton trafic de production.

Le AAIF MCP Summit du 19 avril à New York a attiré 1 200 participants, et le CEO de la Linux Foundation, Jim Zemlin, a qualifié MCP de « Linux des agents ». Comparaison audacieuse — Linux a livré des codes d'erreur corrects dès le premier jour.

Ce que tu devrais faire maintenant

En attendant qu'Anthropic — le propriétaire du protocole — publie une révision de la spec MCP avec des types d'erreur lisibles par une machine, encapsule tes outils MCP avec des enveloppes d'erreur structurées : un error_type de type string, un booléen is_retryable, et un retry_delay_seconds numérique. Fixe un budget de retry strict par outil côté client. Trois tentatives max. Ensuite, échoue bruyamment.

L'écosystème d'outils pour agents rejoue le chaos de gestion d'erreurs du web des débuts, mais en 10 fois plus vite. Quelque part entre « erreur d'outil » et « 12 $ de tokens cramés », il y a un code de statut à trois chiffres qui attend d'être inventé. La plateforme qui le livrera en premier possèdera la couche de fiabilité dont tous les autres dépendront — comme 200 OK est devenu une infrastructure invisible à laquelle plus personne ne pense.

En attendant, ton agent devine. Et il n'est pas terrible pour deviner.