Exploitation production et posture SRE

Bienvenue

Un serveur MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire qui fonctionne en démonstration n'est pas un serveur MCP prêt pour la production. La différence tient moins au code qu'à tout ce qui l'entoure : comment on sait qu'il est en bonne santé, comment on fait évoluer ses tools sans casser les agentsagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire qui en dépendent, comment on mesure sa fiabilité, comment on le coupe en urgence, et comment on réagit quand un agent l'utilise de façon incontrôlée.

Ce chapitre s'adresse à qui va opérer MCP au quotidien : équipe plateforme, SRE, ou développeur qui devient de facto responsable de la disponibilité d'un serveur MCP interne. Il ne traite pas de l'implémentation du protocole (vue dans les chapitres précédents) mais de sa conduite en production.

Dès qu'un agent en production dépend d'un serveur MCP pour agir — envoyer un e-mail, modifier une base, déclencher un déploiement — ce serveur hérite des exigences d'un service critique : astreinte, SLO, runbook, gestion de version. Le traiter comme un simple wrapper d'API est la cause la plus fréquente d'incidents évitables.

Déploiement : ce qui change avec MCP

Un serveur MCP se déploie comme n'importe quel service HTTP ou processus long-vivant, mais deux particularités méritent attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire.

D'abord, la surface de tools exposée doit être stable pendant toute la durée de vie d'une session agent. Si un déploiement change silencieusement la liste des tools ou leur schéma pendant qu'un agent est en train de raisonner sur un plan d'action, l'agent peut invoquer un tool qui n'existe plus, ou avec des paramètres qui ne correspondent plus au schéma annoncé. Un déploiement bleu-vert ou canary doit donc garantir la cohérence du catalogue de tools sur toute la durée d'une session, pas seulement au niveau de la requête HTTP individuelle.

Ensuite, la latence de démarrage compte différemment. Un agent qui initialise une session MCP attend souvent une réponse initialize avant de pouvoir planifier quoi que ce soit. Un cold start de plusieurs secondes, tolérable pour un utilisateur humain qui clique sur un bouton, peut représenter une fraction significative du budget de latence d'un agent qui enchaîne plusieurs appels d'outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire dans un même tour de raisonnement.

Stratégies de déploiement recommandées

• Rolling update avec drain de session : ne pas couper les connexions actives, laisser les sessions en cours se terminer naturellement, router les nouvelles sessions vers la version à jour.
• Canary par pourcentage d'agents, pas de requêtes : router un sous-ensemble d'identités appelantes (par exemple un agent de test interne) vers la nouvelle version, plutôt qu'un pourcentage aléatoire de requêtes qui casserait la cohérence de session évoquée plus haut.
• Rollback rapide sur le catalogue de tools : garder la capacité de revenir à un schéma de tools précédent indépendamment du reste du code applicatif, car c'est souvent le schéma, pas la logique métier, qui casse les agents.

Un serveur peut corriger un bug interne sans changer une seule ligne de schéma de tool. À l'inverse, changer un seul champ required dans un schéma JSON peut casser tous les agents qui l'utilisent, même si le code métier est identique. Versionnez ces deux dimensions séparément dans vos changelogs internes.

Healthchecks : au-delà du "le process répond"

Un healthcheck classique (GET /health renvoie 200) vérifie que le processus tourne et que le transport réseau fonctionne. Pour un serveur MCP, cela ne dit presque rien de l'essentiel : est-ce que les tools eux-mêmes fonctionnent ?

Un serveur MCP typique agrège plusieurs dépendances : une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, une API tierce, un système de fichiers, un service d'authentification. Le protocole MCP peut répondre parfaitement (le serveur écoute, l'initialize réussit, la liste des tools est renvoyée) alors que la moitié des tools échouent systématiquement parce que la dépendance qu'ils appellent est en panne.

Il faut donc distinguer trois niveaux de santé :

Un serveur MCP peut afficher un healthcheck vert alors que 100 % des appels de tools échouent, si la sonde ne teste que le protocole. C'est l'équivalent MCP d'une API REST qui répond 200 sur /health pendant que toutes les routes métier renvoient 500. Instrumentez un appel de tool synthétique par dépendance critique, pas seulement un ping.

Ces sondes fonctionnelles alimentent aussi la décision de routage : un serveur MCP multi-instances peut retirer du pool une instance dont un tool critique échoue, même si son readiness protocole reste vert.

Versioning des tools : éviter le breaking change silencieux

Contrairement à une API REST versionnée par URL (/v1/, /v2/), les tools MCP sont généralement exposés sous un nom stable sans version explicite dans l'identifiant. Un changement de schéma — renommer un paramètre, le rendre obligatoire, changer le format attendu d'une date — se propage donc instantanément à tous les agents connectés, sans période de transition.

Cela pose un problème spécifique aux agents : un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire qui a appris le schéma d'un tool en début de session (via tools/list) peut continuer à générer des appels selon l'ancien schéma si le serveur change le contrat en cours de route, ou si son promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système contient des exemples figés. Le résultat n'est pas une erreur 404 propre, mais souvent un appel malformé que le serveur rejette avec une erreur peu explicite, ou pire, un appel accepté avec une interprétation différente des paramètres.

Règles pratiques de versioning

1. Traiter tout changement de schéma comme potentiellement cassant, y compris l'ajout d'un champ required, un resserrement d'enum, ou un changement de type.
2. Préférer l'extension à la modification : ajouter un nouveau paramètre optionnel plutôt que modifier la sémantique d'un paramètre existant.
3. Exposer les changements majeurs comme de nouveaux tools (send_email puis send_email_v2) plutôt que de faire muter send_email sur place, le temps que les agents et prompts dépendants migrent.
4. Documenter la description du tool elle-même comme faisant partie du contrat : un LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire se fie autant à la description en langage naturel qu'au schéma JSON pour décider comment appeler un tool. Reformuler une description peut changer le comportement d'un agent sans qu'aucun schéma n'ait bougé.

Une équipe modifie la description d'un tool delete_record de « Supprime un enregistrement » à « Supprime définitivement et irréversiblement un enregistrement ». Sans changer le schéma, plusieurs agents deviennent nettement plus réticents à appeler ce tool, y compris dans des cas légitimes, parce que le LLM interprète la nouvelle formulation comme un signal de prudence renforcée. Le changement de texte est un changement de comportement, à tester comme tel.

SLOs pour un serveur MCP

Les indicateurs classiques (latence p99, taux d'erreur HTTP, disponibilité) restent nécessaires mais insuffisants. Un serveur MCP appelle des SLOs orientés appel d'outil, car c'est l'unité de travail que consomme réellement l'agent.

• Taux de succès par tool plutôt qu'un taux global : un tool peut avoir un taux d'erreur élevé sans que la moyenne globale ne le révèle, si les autres tools sont très sollicités et fiables.
• Latence de bout en bout d'un appel de tool, incluant les dépendances externes, pas seulement le temps passé dans le serveur MCP lui-même.
• Taux d'appels rejetés pour non-conformité de schéma : un indicateur souvent négligé qui révèle un désalignement entre ce que le LLM croit pouvoir appeler et ce que le serveur accepte réellement.
• Taux de sessions abandonnées après erreur de tool : signal indirect de l'impact réel sur l'utilisateur final, au-delà de la métrique technique brute.

Un serveur MCP qui expose dix tools hétérogènes (lecture de base, envoi de notification, appel à un service de paiement) n'a pas un seul profil de fiabilité. Fixez des objectifs différenciés : un tool de lecture peut viser 99,9 % de succès, un tool qui déclenche un paiement mérite un objectif plus strict et une alerte séparée, car le coût d'un échec silencieux y est bien plus élevé.

Le budget d'erreur (error budget) issu de ces SLOs doit alimenter directement la décision de figer ou non les évolutions de schéma pendant une période donnée, exactement comme pour n'importe quel service SRE classique.

Feature flags pour les tools à risque

Certains tools exposés à un agent portent un risque disproportionné : exécution de code, envoi de communications externes, modification de données financières, actions irréversibles. Pour ces tools, un feature flag n'est pas un luxe de confort produit, c'est un mécanisme de sécurité opérationnelle.

Le principe : chaque tool sensible peut être désactivé indépendamment, sans redéploiement, via un flag consulté à chaque appel. Trois usages concrets :

• Kill switch d'urgence : couper un tool spécifique en quelques secondes si un agent l'utilise de façon inattendue ou dangereuse, sans arrêter tout le serveur ni les autres tools.
• Activationfonction d'activationIAOpération non linéaire appliquée en sortie d'un neurone. Sans elle, empiler des couches serait inutile : une succession d'opérations linéaires reste équivalente à une seule.Voir dans le glossaire progressive : n'ouvrir un nouveau tool qu'à un sous-ensemble d'agents ou d'environnements avant généralisation.
• Dégradation ciblée en cas d'incident : si une dépendance externe d'un tool est instable, désactiver ce tool précis plutôt que de laisser les agents recevoir des erreurs en boucle qui gonflent inutilement leur nombre de tentatives.

Si un tool flaggé off disparaît simplement de tools/list, un agent qui avait déjà planifié un appel sur ce tool avant la désactivation reçoit une erreur "méthode inconnue" difficile à diagnostiquer. Préférez renvoyer une erreur MCP structurée et explicite ("tool temporairement indisponible, raison : maintenance") que l'agent peut interpréter et éventuellement relayer à l'utilisateur.

Incident response : quand un agent perd le contrôle

MCP introduit une classe d'incidents propre aux systèmes agentiques : le tool fonctionne parfaitement, le serveur est en bonne santé, mais l'agent qui l'utilise dérape — boucle d'appels répétés, séquence d'actions incohérente, exploitation d'un tool légitime dans un but non prévu par un prompt détourné (injection indirecte via un contenu externe, par exemple).

Ce type d'incident ne se détecte pas avec les alertes classiques d'infrastructure. Il demande une instrumentation spécifique :

• Détection de volume anormal par identité appelante : un agent qui appelle le même tool des dizaines de fois en quelques secondes, en dehors de tout pattern légitime connu.
• Détection de séquences suspectes : par exemple, un enchaînement lecture massive de données puis appel à un tool d'export externe, qui peut signaler une exfiltration pilotée par injection de promptInjection de promptCybersécuritéAttaque visant à détourner un LLM en insérant des instructions malveillantes dans le contexte (entrée utilisateur, document RAG, etc.).Voir dans le glossaire.
• Journalisation complète des appels de tools avec leur contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire d'origine (session, identité, éventuellement le raisonnement de l'agent si disponible), condition nécessaire pour tout post-mortem.

Séquence de réponse à un incident agent-hors-contrôle

1. Contenir : couper le tool concerné via feature flag, ou révoquer la session/l'identité de l'agent, sans attendre une analyse complète.
2. Isoler : ne pas redéployer ni modifier le code en pleine crise ; conserver l'état et les logs pour l'analyse.
3. Évaluer l'impact réel : distinguer ce que le tool a effectivement exécuté de ce que l'agent a seulement tenté, en s'appuyant sur les logs d'exécution côté dépendance (base de données, service tiers), pas uniquement sur les logs du serveur MCP.
4. Communiquer selon la gravité, en particulier si des actions irréversibles ont eu lieu.
5. Post-mortem sans blâme, avec une attention particulière à la question : le tool aurait-il dû être moins puissant, moins facilement accessible, ou mieux décrit pour limiter ce risque ?

Un feature flag qui n'a jamais été exercé en conditions réelles est une hypothèse, pas une garantie. Intégrez un exercice périodique de coupure d'un tool sensible dans vos exercices de type game day, au même titre qu'un test de bascule de base de données.

Runbooks : un canevas réutilisable

Un runbook MCP doit répondre à des questions précises, formulées à l'avance, pour quelqu'un qui découvre l'incident à 3 heures du matin sans contexte préalable.

Structure minimale recommandée :

• Symptôme observé : quelle alerte s'est déclenchée, sur quel tool, avec quel seuil dépassé.
• Impact utilisateur probable : quels agents, quels utilisateurs finaux, quelles actions sont affectées.
• Vérifications immédiates : requêtes ou dashboards précis à consulter en premier (pas "vérifier les logs", mais l'URL ou la commande exacte).
• Actions de mitigation disponibles, classées par réversibilité : couper le flag du tool, réduire son taux d'appel autorisé, revenir à la version de schéma précédente.
• Escalade : à qui transférer si la mitigation immédiate ne suffit pas, avec les coordonnées à jour.
• Critères de sortie d'incident : ce qui doit être vrai pour déclarer l'incident résolu, pas seulement "ça a l'air d'aller mieux".

Un runbook jamais exécuté accumule silencieusement des liens morts, des commandes obsolètes et des noms de service qui ont changé. Un exercice trimestriel de simulation, même court, vaut mieux qu'un document impeccable jamais éprouvé.

En résumé

Exploiter un serveur MCP en production, c'est appliquer à un système agentique les disciplines déjà connues du monde SRE — déploiement maîtrisé, healthchecks multi-niveaux, SLOs, feature flags, runbooks — tout en les adaptant à une spécificité centrale : l'appelant n'est pas un client déterministe mais un agent dont le comportement dépend d'un contrat (schémas, descriptions) qui peut casser de façon plus subtile qu'une simple erreur réseau. La rigueur sur le versioning des tools et la capacité à couper rapidement un tool à risque sont les deux réflexes qui distinguent une équipe préparée d'une équipe qui découvre ces problèmes en pleine crise.