Serveur MCP et observabilité : détecter les signaux faibles avec l'IA

Quand on regarde ses tableaux de bord tous les jours, on finit par ne plus voir ce qui bouge lentement. Une courbe qui monte de 2 % par semaine paraît plate à l’échelle d’une journée. Ce n’est qu’en reculant de trois ou quatre mois qu’on voit apparaître la pente, souvent au moment où elle devient un incident. L’un des usages de l’IA qui m’apporte le plus en ce moment consiste justement à lui donner accès aux outils d’observabilité, via un serveur MCP, pour aller chercher ces signaux faibles à ma place.

MCP en deux phrases

Le Model Context Protocol est un standard ouvert qui permet de brancher un assistant IA sur des outils externes : une base de métriques, une supervision, un inventaire, une documentation. Le serveur MCP expose une liste d’actions précises (« exécuter une requête PromQL », « lister les alertes actives ») et c’est lui, pas l’IA, qui décide de ce qui est autorisé.

Concrètement, au lieu de copier des captures d’écran de Grafana dans une conversation, l’assistant interroge lui-même les métriques, sur la période et la granularité qu’il juge utiles, et revient avec une analyse.

Pourquoi on rate les dérives lentes

La supervision classique est construite pour détecter des ruptures : un service tombe, un disque passe au-dessus de 90 %, une latence dépasse un seuil. Elle le fait très bien. Ce qu’elle fait mal, c’est signaler une tendance qui reste sous tous les seuils pendant des mois.

Et l’œil humain n’aide pas beaucoup. On consulte les tableaux de bord sur les dernières 24 heures, au mieux sur la semaine. À cette échelle, une dérive lente est noyée dans le bruit quotidien. Il faudrait prendre régulièrement le temps de dézoomer sur un trimestre, service par service, métrique par métrique. Personne ne le fait, parce que personne n’en a le temps.

Le genre de signaux qu’on voit apparaître sur trois mois

Quand on donne à l’IA l’accès aux métriques avec la consigne de comparer les tendances sur plusieurs mois, ce sont typiquement ces signaux qui ressortent :

• une mémoire qui ne redescend jamais complètement après les redémarrages applicatifs, signe d’une fuite qui finira en saturation ;
• une durée de sauvegarde qui s’allonge chaque semaine, jusqu’à déborder un jour sur la plage de production ;
• un volume qui se remplit plus vite depuis une mise en production précise, avec une date de saturation qu’on peut enfin estimer ;
• une latence au 95e centile qui glisse alors que la moyenne reste stable, ce qui annonce souvent une contention ou un index qui se dégrade ;
• un nombre de redémarrages de conteneurs discret mais en hausse régulière ;
• des erreurs réseau rares, quelques-unes par jour, mais de plus en plus fréquentes sur un même lien ou un même équipement.

Aucun de ces signaux ne déclenche d’alerte. Tous finissent par coûter cher s’ils sont découverts trop tard. L’intérêt de l’IA ici n’est pas de remplacer la supervision, mais de faire régulièrement le travail de recul que personne ne fait.

Comment je l’utilise en pratique

Le serveur MCP est branché sur la base de métriques (Prometheus, VictoriaMetrics ou l’équivalent) et éventuellement sur Grafana pour retrouver les tableaux de bord existants. L’assistant peut alors lancer ses propres requêtes, par exemple comparer l’utilisation mémoire moyenne par semaine sur 16 semaines :

avg_over_time(
  (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)[7d:1h]
)

La demande que je lui fais ressemble à ceci : « Sur les quatre derniers mois, repère les métriques dont la tendance s’est dégradée de façon continue, même si elles restent sous les seuils d’alerte. Pour chacune, donne la pente, la date à laquelle elle a commencé et la projection à trois mois. » Il parcourt les métriques, revient avec une courte liste, et c’est là que mon travail commence : vérifier chaque signal, écarter les faux positifs (une hausse saisonnière, un changement de collecte), et décider de ce qui mérite une action.

L’exercice prend une heure par mois. Il remplace une analyse qui, faite à la main, ne serait tout simplement jamais faite.

Lecture seule d’abord, et pour longtemps

Brancher l’IA sur un outil de production n’est pas anodin. Mes règles de départ sont toujours les mêmes :

• lecture seule : le serveur MCP n’expose que des requêtes de consultation, aucune action sur les systèmes, aucun acquittement d’alerte ;
• compte de service dédié : avec des droits limités au strict nécessaire, révocable à tout moment, jamais le compte d’un administrateur ;
• périmètre explicite : on choisit les sources exposées, et on exclut ce qui contient des données personnelles ou métier sensibles ;
• journalisation : chaque requête faite par l’assistant est tracée, on sait ce qu’il a consulté et quand.

Les actions, comme redémarrer un service ou créer un ticket, viennent éventuellement plus tard, une par une, avec validation humaine systématique. Dans la plupart des contextes, la lecture seule apporte déjà l’essentiel de la valeur.

Où vont les données

C’est la première question que posent les RSSI, et elle est légitime. Les métriques d’infrastructure sont généralement peu sensibles (des pourcentages, des latences, des compteurs), mais les noms de serveurs, d’applications ou de clients qu’elles portent peuvent l’être. Selon le contexte, on anonymise les libellés, on limite les métriques exposées, ou on fait tourner le modèle dans un environnement maîtrisé. Le choix se fait avec le client, avant de brancher quoi que ce soit.

Démarrer en une journée

Pour une équipe qui veut essayer, je recommande un périmètre volontairement réduit :

1. un seul outil branché, la base de métriques, en lecture seule ;
2. une dizaine de serveurs ou de services représentatifs ;
3. une question précise, par exemple « qu’est-ce qui dérive depuis trois mois ? » ;
4. une revue des résultats avec l’équipe d’exploitation, qui connaît le contexte.

Si la première séance fait remonter ne serait-ce qu’un signal réel que personne n’avait vu, l’essai est concluant. D’expérience, c’est rarement un seul.

Ce qui ne marche pas encore

L’IA reste mauvaise juge de la saisonnalité métier : une hausse de charge avant les soldes est normale, elle peut la signaler comme une dérive. Elle peut aussi produire des requêtes coûteuses sur de grandes périodes, ce qui impose de limiter la résolution et la durée interrogeables. Enfin, la qualité de l’analyse dépend directement de celle des métriques : une supervision mal étiquetée donnera des conclusions floues.

Rien de tout ça n’empêche de s’en servir. Ça impose simplement de garder un humain qui connaît le SI dans la boucle, ce qui est le principe de toute IA appliquée à l’infrastructure sérieuse. Si vous voulez tester ce type d’usage sur votre supervision, écrivez-moi.