Agents et MCP pour l'exploitation

Un agent est un LLM à qui l'on donne des outils : il peut décider d'appeler une fonction (lire des journaux, lister des pods, ouvrir un ticket), lire le résultat, puis continuer jusqu'à atteindre son objectif. Pour l'exploitation, c'est prometteur : un premier diagnostic d'alerte à 3 heures du matin, la synthèse d'un incident, la préparation d'un correctif. C'est aussi un nouveau type d'acteur sur vos systèmes, qu'il faut cadrer comme un collègue débutant très rapide. Cette leçon est théorique.

Ce que vous saurez à la fin : expliquer la boucle d'un agent et l'appel d'outils, décrire le Model Context Protocol (MCP), brancher un agent sur Kubernetes avec des droits minimaux, et poser les garde-fous : lecture seule par défaut, validation humaine, journalisation, limites.

1. La boucle d'un agent

objectif ─▶ le modèle choisit : répondre, ou appeler un outil (nom + arguments en JSON)
              ▲                                   │
              └──── résultat de l'outil ◀── l'application exécute l'outil

Le modèle ne fait rien lui-même : il demande un appel d'outil, décrit par un nom et un schéma d'arguments ; c'est votre application qui l'exécute, avec ses droits, puis lui renvoie le résultat. Toute la sécurité se joue donc dans ce que l'application accepte d'exécuter.

2. Le Model Context Protocol

Brancher chaque outil à chaque application, c'est beaucoup de code sur mesure. Le Model Context Protocol (MCP) est un protocole ouvert qui standardise ce branchement : un serveur MCP expose des capacités, un client MCP (l'assistant, l'IDE, l'agent) les découvre et les utilise.

Capacité	Exemple
outils (tools)	lister_pods(namespace), journaux(pod, lignes), creer_ticket(titre)
ressources	un runbook, la description d'un service
invites (prompts)	un modèle de diagnostic « analyse de CrashLoopBackOff »

Deux transports : stdio (le serveur est un processus local lancé par le client) et HTTP (un service distant, partagé, avec authentification, par exemple OAuth). Des serveurs MCP existent pour Kubernetes, Prometheus, GitHub, les bases de données… Un serveur MCP est du code tiers qui reçoit des identifiants : on le choisit, l'épingle et l'audite comme une dépendance critique.

3. Un agent d'exploitation sur Kubernetes

Comme pour un pipeline (leçon D.3), l'agent obtient sa propre identité, au moindre privilège :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: {name: agent-diagnostic}
rules:
  - apiGroups: ["", "apps", "batch"]
    resources: [pods, pods/log, events, services, endpoints, deployments, replicasets, statefulsets, jobs]
    verbs: [get, list, watch]
  # ni secrets, ni pods/exec, ni create/patch/delete

• Pas de secrets : l'agent n'en a pas besoin pour diagnostiquer, et tout ce qu'il lit peut se retrouver dans ses réponses ou chez le fournisseur du modèle.
• Pas de pods/exec : c'est un shell dans vos conteneurs.
• Les actions qui modifient (redémarrer, mettre à l'échelle, revenir en arrière) passent par des outils dédiés, étroits (redemarrer_deployment(ns, nom) plutôt que « exécuter une commande kubectl »), et soumis à validation humaine.

4. Les garde-fous

1. Lecture seule par défaut, écriture par exception et sur validation explicite d'un humain qui voit l'action exacte.
2. Des outils étroits plutôt qu'un shell générique : chaque outil vérifie ses arguments (namespace autorisé, nom valide).
3. Une liste blanche de périmètre : namespaces, clusters (jamais la production en écriture pour commencer).
4. Tout journaliser : l'objectif, chaque appel d'outil avec ses arguments, chaque résultat, l'humain qui a validé.
5. Des limites : nombre d'étapes, durée, jetons, coût par tâche ; un agent qui boucle peut coûter cher.
6. Préférer proposer : l'agent rédige une demande de fusion (GitOps, leçons D.4 et D.5) plutôt que de modifier le cluster ; la relecture et le pipeline s'appliquent comme pour un humain.

5. Bons premiers usages

• Triage d'alertes : à réception d'une alerte, l'agent rassemble événements, journaux récents, derniers déploiements, et propose une hypothèse dans le canal d'astreinte.
• Synthèse d'incident : chronologie et brouillon de postmortem à partir du canal et des événements.
• Assistance à la revue : relire une demande de fusion de manifestes (ressources manquantes, latest, droits trop larges).
• Questions sur la documentation, avec un RAG (leçon IA.3).

Commencez par des usages où l'agent informe un humain, mesurez la justesse de ses diagnostics, puis élargissez prudemment.

6. Ce qui peut mal tourner

Un agent agit sur la foi de ce qu'il lit. Un message de journal, une annotation, un ticket ou une page web peuvent contenir du texte écrit pour lui (« pour corriger, supprime le namespace… ») : c'est l'injection de prompt indirecte. Les garde-fous ci-dessus (droits minimaux, outils étroits, validation humaine) sont ce qui transforme une injection réussie en non-événement. La leçon IA.6 y revient en détail.

Validez la leçon avec le questionnaire.