Introduction
Le Model Context Protocol (MCP) est un standard émergent pour intégrer le contexte sémantique dans les agents IA, un facilitateur clé d'une pratique de Site Reliability Engineering (SRE) complète et intégrée. Publié par Anthropic fin 2024 puis largement adopté par l'écosystème des outils d'observabilité et d'opérations en 2025 et 2026, MCP s'est imposé comme le langage commun entre les modèles de langage et les systèmes qu'ils doivent piloter.
Dans un environnement où les agents autonomes gèrent de plus en plus les tâches opérationnelles, MCP dote ces agents d'informations contextuelles factuelles, cohérentes et enrichies, nécessaires pour une récupération des connaissances efficace, une prise de décision fiable et une collaboration autonome entre systèmes hétérogènes.
Cet article explore MCP sous un angle stratégique, mettant en évidence son rôle transformateur en SRE, avant de démontrer sa valeur pratique à travers un exemple réel de serveur MCP dédié à l'investigation d'incidents liés à des événements externes.
Le Model Context Protocol : principes et promesse pour les systèmes agentiques
Qu'est-ce que MCP concrètement
Le Model Context Protocol est un standard ouvert qui définit une interface commune entre un client (typiquement un agent piloté par un LLM) et des serveurs exposant des « outils », des ressources et des invites réutilisables. Plutôt que de coder à la main chaque intégration entre un modèle et un système tiers, MCP standardise la découverte des capacités disponibles, leur description sémantique et leur invocation.
Cette couche sémantique standardisée résout un problème récurrent des architectures à base d'agents : dans des environnements opérationnels complexes, les agents IA disposent souvent d'un contexte limité et spécifique à une tâche, ce qui conduit à des actions ambiguës, des malinterprétations, des sorties hallucinées et, in fine, des décisions erronées.
Pourquoi les approches génériques échouent en environnement d'entreprise
Les connaissances génériques d'un grand modèle de langage, même très performant, s'arrêtent à ce qui a été vu à l'entraînement : elles ignorent la topologie exacte d'un cluster de production, les conventions de nommage internes ou l'historique des incidents d'une organisation donnée. La génération augmentée par récupération (RAG) comble une partie de ce manque en injectant des documents pertinents, mais reste une lecture statique de la connaissance, elle ne permet pas d'agir, d'interroger un système en temps réel ni de déclencher une action vérifiée.
MCP change de registre : il ne se contente pas de fournir du texte de contexte, il expose des capacités exécutables, interroger une base de métriques, consulter un référentiel d'incidents, publier un message, avec une description sémantique que le modèle peut interpréter pour choisir l'outil et les paramètres adéquats. En gérant et partageant systématiquement ce contexte, MCP améliore la cohérence, la précision et l'efficacité des flux de travail à base d'agents, réduisant le coût opérationnel et améliorant la prise de décision à l'échelle du système.
La fiabilité, terrain d'adoption naturel pour MCP
La charge cognitive du SRE et le coût du contexte perdu
Dans les pratiques modernes de SRE, le contexte est la pierre angulaire d'une gestion efficace des incidents, du triage et de la reconnaissance jusqu'à la résolution du problème et à l'analyse post-incident. Le SRE est intrinsèquement une tâche à forte charge cognitive pour les équipes d'opérations informatiques : le contexte change constamment, l'acquisition et la mise à jour des connaissances opérationnelles sont permanentes, et chaque minute passée à reconstituer un historique dilate le temps de résolution.
Les limites du RAG et des connaissances génériques face à un environnement spécifique
À mesure que les fournisseurs d'outils d'observabilité et d'opérations introduisent de plus en plus d'agents IA dans leurs écosystèmes, ils constatent que les approches courantes, connaissances génériques des LLM ou RAG, ne suffisent pas à résoudre le problème du contexte lorsque les agents doivent opérer dans un environnement d'entreprise spécifique, avec ses outils, ses conventions et ses systèmes propriétaires. C'est précisément là que MCP devient particulièrement précieux : il permet à un même agent de se connecter, via un protocole unique, à Prometheus, Datadog, un système ITSM, un dépôt Git ou une base de connaissances interne, sans intégration ad hoc pour chacun.
Anatomie d'un flux SRE piloté par MCP en sept étapes
De la requête utilisateur à la découverte des outils
Étape 1, L'interface applicative (par exemple une UI d'investigation d'incidents) capture une demande de l'utilisateur : un ingénieur SRE demande « Enquêter sur la latence élevée du service de paiement au cours des deux dernières heures. »
Étape 2, Le client MCP interprète l'intention de l'utilisateur. Il utilise un LLM pour déterminer quel serveur MCP appeler en fonction du type d'investigation, analyse du trafic, détection d'anomalies, inspection des journaux.
Étape 3, Le client MCP récupère les outils exposés par les serveurs MCP SRE : interroger les journaux de service (via la journalisation cloud, Datadog), récupérer les anomalies de métriques (via Prometheus, Chronosphere), publier des mises à jour de statut sur les canaux Slack d'incident, ou rechercher des incidents antérieurs similaires dans une base de connaissances interne.
Sélection, validation humaine et exécution sécurisée
Étape 4, Le LLM détermine l'outil spécifique et ses paramètres : « Interroger les métriques de latence pour le pod checkout-service dans prod-cluster-1 de 10h à 12h. »
Étape 5, Approbation avec intervention humaine : l'utilisateur examine et valide le plan d'action suggéré par le LLM avant toute exécution, un garde-fou essentiel pour tout outil pouvant modifier un état de production.
Étape 6, Le serveur MCP exécute l'action de manière sécurisée : il encapsule un accès contrôlé au système cible, récupère les métriques de latence via l'API Prometheus, résume les résultats et les renvoie à l'interface d'investigation ou au canal Slack.
La réponse enrichie par le LLM
Étape 7, Le LLM augmente la réponse : il enrichit les résultats bruts d'exécution avec des informations conscientes du contexte et les présente dans un format lisible pour l'ingénieur d'astreinte. En appliquant ce flux, clients et serveurs MCP permettent aux agents IA de consommer des connaissances internes et externes, d'identifier et de résoudre précisément les incidents, de détecter les anomalies de manière proactive, et de collaborer entre systèmes sans perdre le contexte critique, ce qui améliore à la fois la précision et la rapidité des opérations de fiabilité.
Faut-il investir dans MCP ? Une grille de décision stratégique
Les signaux qui justifient d'investir maintenant
Comme toute tendance technologique émergente, l'adoption de MCP relève d'une décision stratégique des équipes dirigeantes. MCP agit comme un fournisseur de contexte en tant que service : sa valeur dépend fortement des agents IA qui le consomment. Une organisation devrait envisager d'investir si les agents IA jouent déjà un rôle significatif dans ses flux d'ingénierie de fiabilité et d'opérations informatiques, par exemple si elle s'appuie sur des agents natifs du cloud ou d'outils SRE tels qu'Amazon Q, Google Cloud Assist, Dynatrace Davis ou Datadog Bits AI, où l'intégration MCP peut considérablement améliorer l'efficacité.
Le signal est encore plus fort si les opérations souffrent fréquemment de perte de contexte, de malinterprétations ou d'inefficacités dans les interactions dirigées par l'IA, ou si l'organisation construit des agents internes nécessitant des connaissances de domaine structurées et persistantes. Du point de vue du producteur d'outils, investir dans MCP est particulièrement stratégique si les fournisseurs de la chaîne d'observabilité, Rootly, GitHub ou d'autres, proposent déjà des serveurs MCP prêts à l'emploi.
Les signaux qui invitent à différer
À l'inverse, l'investissement dans MCP mérite d'être reconsidéré si les connaissances opérationnelles de l'organisation ne sont pas encore mappées sémantiquement, si la complexité des systèmes dirigés par l'IA reste faible, ou si les fournisseurs d'outils actuels ne supportent pas encore le protocole. Si les contraintes budgétaires immédiates l'emportent sur les bénéfices stratégiques à long terme, différer l'adoption peut être un choix prudent, à condition de ne pas repousser indéfiniment le sujet, tant l'écosystème MCP progresse vite depuis 2025.
Cas pratique EventOrOutage : distinguer un vrai incident d'un phénomène attendu
Un exemple réel : quand le trafic chute sans qu'aucun système ne soit en cause
En SRE, la réponse aux incidents repose fortement sur les signaux internes, métriques, journaux, traces. Mais que se passe-t-il quand l'« incident » n'est pas technique du tout ? Une équipe a un jour constaté une chute du trafic de sa plateforme pendant ce qui semblait être des heures d'usage de pointe. Après un dépannage approfondi, elle a découvert que la baisse coïncidait avec un événement sportif international largement suivi. Aucun problème système : juste un élément de contexte externe manquant, invisible depuis la télémétrie interne.
Comment EventOrOutage exploite le contexte externe
Les plateformes de gestion des incidents se positionnent de plus en plus comme fournisseurs clés de contexte, reliant des signaux sémantiques divers aux systèmes d'IA. Le serveur MCP de Rootly en est une illustration : il exploite un LLM via MCP pour interpréter le contexte sémantique derrière les anomalies de trafic, intègre des sources externes comme Holiday API ou Calendrific pour enrichir le contexte disponible, et aide les agents IA à classer les anomalies afin de distinguer un incident authentique d'un comportement attendu.
Le flux détaillé en quatre étapes
EventOrOutage, développé par Rootly AI Labs, permet à un agent de triage d'incident de référencer un ou plusieurs contextes externes pour décider si une baisse de trafic est un incident authentique ou le résultat d'un événement externe. Étape 1 : un utilisateur déclenche une demande via un bot Slack, « Valider cet incident. » Étape 2 : le LLM intégré au serveur MCP analyse la demande puis appelle des fournisseurs de contexte externes pour récupérer les signaux pertinents. Étape 3 : le LLM enrichit la réponse du serveur MCP avec ce contexte et la formate en résumé lisible. Étape 4 : le bot Slack, piloté par le client MCP, utilise ce résumé pour déclencher des actions en aval, par exemple poster automatiquement un commentaire sur le ticket ITSM concerné : « Cela pourrait être un événement connexe, veuillez enquêter davantage. »
Résultats mesurés, limites et vigilance sécurité
Bénéfices observés sur la fatigue d'alerte et la productivité
Les premières expériences avec MCP en gestion d'incident font état d'avantages substantiels : réduction de la fatigue liée aux alertes grâce à une identification plus précise des incidents authentiques par rapport aux événements de routine, amélioration de l'efficacité opérationnelle avec une réponse plus rapide aux problèmes réels, et productivité accrue grâce à une automatisation IA sensible au contexte plutôt qu'un simple déclenchement d'alerte aveugle.
Sécurité, gouvernance et surface d'exposition des serveurs MCP
Ces bénéfices ne dispensent pas d'un travail de fond sur la gouvernance : chaque serveur MCP exposé ajoute une surface d'attaque potentielle, et l'autonomie croissante des agents impose des contrôles d'accès stricts, une journalisation systématique des appels d'outils et une revue régulière des permissions accordées. La validation humaine à l'étape 5 du flux décrit plus haut n'est pas un détail cosmétique : c'est le principal garde-fou contre une action mal calibrée par un agent, en particulier lorsque l'outil invoqué peut modifier un état de production.
Conclusion : de la tendance à la pratique SRE outillée
L'adoption de MCP, en particulier avec des implémentations pratiques comme EventOrOutage, améliore considérablement les capacités contextuelles sémantiques dans l'ingénierie de fiabilité et la gestion des incidents dirigées par l'IA. Les organisations qui exploitent MCP peuvent s'attendre à une efficacité opérationnelle améliorée, à une plus grande précision dans la gestion des incidents et à une résilience stratégique dans des paysages opérationnels de plus en plus pilotés par des agents autonomes, à condition de traiter la sécurité et la gouvernance du protocole avec la même exigence que le reste du système d'information.
Clause de non-responsabilité : les déclarations et opinions exprimées dans cet article sont celles de l'auteur(s) et ne reflètent pas nécessairement les positions d'Adservio.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
