Tu as branché ton agent IA sur quinze serveurs MCP — Slack, GitHub, Jira, une base de données — et tu as testé le tout jusqu'à ce que ça roule comme sur des roulettes. MCP (Model Context Protocol), c'est la prise universelle qui permet aux agents IA de communiquer avec des outils externes, comme l'USB mais pour la data. Ta démo était nickel. Ton chef a hoché la tête. Tu as mis en prod.

Voilà ce que personne ne t'a dit : les serveurs MCP ne sont pas des paquets statiques posés sur ton disque. Ce sont des processus vivants et des endpoints distants. Et au 25 avril 2026, pas une seule plateforme d'agents ne te prévient quand l'un d'eux tombe, rame comme un fou, ou se met à renvoyer n'importe quoi.

La moitié de tes outils sont peut-être déjà morts

Le 20 avril, RapidClaw a audité 1 847 serveurs MCP publics sur sept registres. Résultat : 52 % sont morts ou abandonnés. Seuls 17 % — 315 serveurs — sont jugés aptes à la production. Le serveur MCP médian cumule six commits à vie, un seul mainteneur, zéro test, et n'a pas bougé depuis 142 jours.

Voilà l'écosystème dont dépend ton agent. C'est un pile ou face qui décide si l'outil qu'il appelle fonctionne encore.

Et le protocole MCP lui-même ne t'aide en rien. Aucun endpoint de health check intégré — aucun moyen standardisé pour un serveur de dire « je suis vivant et fonctionnel ». Les SDK implémentent un ping basique, mais il n'y a ni /health, ni /ready, ni sonde de liveness. Chaque équipe bricole la sienne, ou — plus souvent — ne bricole rien du tout.

Le trou béant dans le protocole

Le problème n'est pas que dans les plateformes — il est dans la spec. HTTP a ses codes de statut. gRPC a ses services de health check. Kubernetes a ses sondes de liveness et readiness. MCP a... une méthode ping qui confirme que la couche transport respire, pas que le serveur est capable de faire son boulot.

Un serveur MCP de base de données peut répondre au ping alors que son pool de connexions est saturé. Un serveur MCP GitHub peut renvoyer un pong alors que son token d'authentification a expiré il y a trois semaines. Le protocole ne trace aucune ligne entre « le transport marche » et « l'outil marche ». Cette distinction compte quand ton agent crâme des tokens à re-tenter un outil qui répond techniquement mais qui ment fonctionnellement.

L'Agent Observability de Google, livré le 22 avril dans la Gemini Enterprise Agent Platform, suit le nombre de requêtes et la latence p95 des serveurs MCP. Deux métriques. On a déjà couvert les lacunes plus larges de la plateforme — en résumé, Google a construit du tracing au niveau agent, pas du monitoring au niveau outil. AWS a présenté une approche catalogue similaire avec Agent Registry le 17 avril — un annuaire pour agents, pas un moniteur de santé. Les deux reconnaissent que les outils méritent un traitement d'infrastructure. Aucun des deux ne vérifie réellement si tes outils sont vivants.

À titre de comparaison, n'importe quel microservice à peu près sérieux — un petit composant indépendant de ton backend — bénéficie de health checks, de taux d'erreurs, d'analyse de qualité des réponses et d'alertes automatiques. Ton serveur MCP, lui, a droit à un compteur de requêtes et un chronomètre.

Ce qui casse quand un outil casse

Quand un serveur MCP se dégrade en silence, ton agent ne le sait pas. Soit il hallucine une réponse (il invente), soit il retente en silence en brûlant des tokens — les unités de texte que l'IA traite, chacune facturée — soit il échoue sans te dire quel outil a planté. Les traces d'observabilité d'agent montrent ce que l'agent a décidé. Elles ne montrent pas si l'outil était en bonne santé quand il a répondu. Tu vois le symptôme. Tu ne peux pas diagnostiquer la cause.

C'est comme monitorer ton appli web sans monitorer sa base de données. Le dashboard reste au vert jusqu'à ce que tout soit en feu.

Ce qu'il faut faire maintenant

Si tu fais tourner des agents en production, traite chaque serveur MCP comme une dépendance microservice :

  • Mets des timeouts. Le protocole MCP ne le fera pas pour toi.
  • Définis des fallbacks. Si un outil est down, ton agent a besoin d'un plan B, pas d'une hallucination improvisée.
  • Monitore la qualité des réponses. Un 200 OK qui renvoie du n'importe quoi, c'est pire qu'un échec propre.
  • Encapsule tes connexions dans des circuit breakers — un mécanisme qui coupe l'accès à un service défaillant avant qu'il n'entraîne tout le reste dans sa chute.
  • Accepte le plafond. Ton agent est exactement aussi fiable que son outil le moins fiable.

La plupart des équipes n'ont pas budgété cette tuyauterie. La plupart des équipes vont comprendre pourquoi elles auraient dû.

La couche manquante

Le stack agent en avril 2026 a des modèles plus malins, des registres plus gros et des passerelles plus sophistiquées. Ce qu'il n'a pas, c'est du tool SRE — du Site Reliability Engineering appliqué aux outils dont les agents dépendent. De précédents articles sur ce canal ont soutenu que l'ingénierie de fiabilité des agents n'existe pas encore. L'audit de RapidClaw prouve que le problème est un cran plus profond : impossible d'avoir des agents fiables quand le protocole qu'ils parlent ne définit même pas ce que « en bonne santé » signifie pour un outil.

La première plateforme à livrer du monitoring de santé au niveau outil avec des endpoints /health et /ready intégrés dans la spec MCP — pas greffés par chaque éditeur — capte la couche de fiabilité qui manque à tout l'écosystème.

Tu as commencé avec quinze serveurs MCP qui marchaient parfaitement en dev. En production, environ huit d'entre eux sont à un pile ou face de la mort. Personne ne surveille. Peut-être que c'est par là qu'il faut commencer.