MCP servers : panorama DevOps

À la fin de ce tutoriel MCP servers DevOps, vous saurez expliquer le Model Context Protocol, distinguer client / serveur / transport, cartographier les serveurs utiles ops 2026 (GitHub, filesystem, Postgres, Kubernetes, Docker, Slack…), monter un lab factice sous /tmp/lab-mcp-devops (config JSON + mock + checklist sécu), et choisir MCP vs API directe vs skill — sans tokens réels.

Niveau : Intermédiaire · Temps estimé : 45–60 min · Versions / contexte : MCP (écosystème ouvert Anthropic + community) · clients Claude Desktop / Claude Code · Cursor · configs type mcp.json · Dernière vérification : 2026-09-11

Prérequis

• Hub IA pour DevOps : parcours 2026
• Agent workflows multi-outils, AI Skills : concept, Cursor Skills
• Deep-dive CLI : Claude Code : MCP et outils (ici = panorama DevOps, pas le détail Claude Code)
• Prompt injection & sécurité
• Lab local ; aucun token GitHub / Slack / kubeconfig / .env réel

Coût lab : 0 €. Serveurs cloud = quotas API — placeholders uniquement.

Ce que nous allons construire

/tmp/lab-mcp-devops
  ├── configs/
  │     ├── mcp.json              (gabarit client — placeholders)
  │     └── allowlist-tools.json
  ├── mock-server/
  │     ├── manifest.json
  │     └── server-mock.sh        (stdio mock minimal)
  ├── fixtures/{issues,pods-readonly}.json
  └── checklist-securite.md
       → protocole · panorama · lab · sécu · quiz · FAQ

(Schéma à remplacer par une image locale, alt : « MCP : client agent → transport stdio/SSE/HTTP → serveur tools/resources/prompts ».)

Module D #32 : après les workflows multi-outils, on standardise le branchement d’outils. Suite : RAG pour docs infra.

Étape 1 — Qu’est-ce que MCP (Model Context Protocol)

MCP (Model Context Protocol) est un protocole ouvert (origine Anthropic, écosystème community) pour brancher outils et données à un agent via des serveurs standardisés. Le client découvre des capacités exposées :

Primitive	Rôle ops
Tools	Actions (issues, kubectl get, SQL lecture)
Resources	Contenu adressable (fichier, schéma, runbook)
Prompts	Templates côté serveur

Analogie : MCP ≈ contrat d’intégration IDE/agent ↔ systèmes, pas un chat propriétaire. Clients 2026 : Claude Desktop, Claude Code, Cursor, autres IDEs — les UI évoluent ; retenez client → transport → serveur. Ce n’est pas un remplacement de Terraform, Argo CD ou de la CI : c’est une couche d’accès contextuel pour lire le terrain (tickets, pods, docs) et proposer des actions sous contrôle. En ops, la valeur arrive quand l’agent cesse de « inventer » l’état du système et interroge des sources branchées. Détail CLI : claude-code-mcp.

Étape 2 — Client vs serveur vs transport (stdio / SSE / HTTP)

Rôle	Qui	Exemple
Client	Host de l’agent	Cursor, Claude Desktop / Code
Serveur	Processus tools/resources	server-filesystem, serveur GitHub
Transport	Canal	stdio, SSE, HTTP

stdio : le client lance une commande locale (npx, binaire) et échange sur stdin/stdout — idéal labs. SSE / HTTP : serveur distant / gateway ; auth et réseau à gérer. Packages et chemins UI évoluent.

Flux : démarrage serveur (command + args + env) → découverte tools → appel proposé → confirmation éventuelle (HITL) → résultat structuré. En DevOps, journalisez les tool calls (qui, quel outil, quels args sanitizés) comme vous auditez un accès bastion. Règle : un serveur = un périmètre de confiance ; ne mélangez pas « lecture runbooks » et « write cluster » sans allowlist.

Étape 3 — Panorama serveurs utiles DevOps 2026

Noms npm / packages évolutifs — famille indicative :

Famille	Exemples	Cas DevOps	Mode prudent
Filesystem	@modelcontextprotocol/server-filesystem	Runbooks, configs locales	Scope répertoire
GitHub	server-github / community	Issues, PR, fichiers	Token fine-grained
Postgres	server-postgres	Schéma, métriques SQL	Rôle read-only
Kubernetes	community k8s	Lister pods, describe	Read-only + NS
Docker	community	Containers locaux	Machine sandbox
Slack	community	Digests canal ops	Canal allowlist
Sentry / o11y	community	Erreurs, tendances	Lecture
Terraform / docs	docs MCP	Expliquer modules HCL	Pas d’apply auto
Browser / fetch	browser, fetch	Doc publique	Domaines restreints

Cas typiques : digérer issues ; pods read-only ; table métriques ; corpus docs (prépare RAG) ; orchestration dans un workflow. Jour 1 : filesystem + un outil lecture.

Étape 4 — Lab factice /tmp/lab-mcp-devops

mkdir -p /tmp/lab-mcp-devops/{configs,mock-server,fixtures}
cd /tmp/lab-mcp-devops

cat > fixtures/issues.json << 'EOF'
{"issues":[
  {"number":101,"title":"CI flaky api-ci","state":"open","labels":["ci"]},
  {"number":102,"title":"Disk alert staging","state":"open","labels":["ops"]},
  {"number":103,"title":"Docs runbook nginx","state":"closed","labels":["docs"]}
]}
EOF

cat > fixtures/pods-readonly.json << 'EOF'
{"pods":[
  {"name":"api-7f8c","ns":"staging","status":"Running"},
  {"name":"worker-2a1b","ns":"staging","status":"CrashLoopBackOff"},
  {"name":"web-9c0d","ns":"prod","status":"Running"}
]}
EOF

cat > configs/mcp.json << 'EOF'
{
  "mcpServers": {
    "filesystem-lab": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp/lab-mcp-devops/fixtures"],
      "env": {}
    },
    "github-lab": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_TOKEN" }
    },
    "mock-ops": {
      "command": "/tmp/lab-mcp-devops/mock-server/server-mock.sh",
      "args": [],
      "env": {}
    }
  }
}
EOF

cat > configs/allowlist-tools.json << 'EOF'
{
  "allow": ["list_issues_open", "list_pods_readonly", "read_fixture_file"],
  "deny": ["kubectl_apply", "terraform_destroy", "slack_post_any_channel", "read_dotenv", "fetch_arbitrary_url"],
  "hitl_required": ["create_pr_comment", "scale_deployment"]
}
EOF

cat > mock-server/manifest.json << 'EOF'
{
  "name": "mock-ops-lab",
  "version": "0.1.0-lab",
  "tools": [
    {"name": "list_issues_open", "description": "Issues open depuis fixtures", "readOnlyHint": true},
    {"name": "list_pods_readonly", "description": "Pods factices (pas de kubeconfig)", "readOnlyHint": true},
    {"name": "read_fixture_file", "description": "Lit sous fixtures/ uniquement", "readOnlyHint": true}
  ],
  "resources": [
    {"uri": "lab://fixtures/issues.json", "name": "Issues lab"},
    {"uri": "lab://fixtures/pods-readonly.json", "name": "Pods lab"}
  ]
}
EOF

cat > mock-server/server-mock.sh << 'EOF'
#!/usr/bin/env bash
# LAB ONLY — mock stdio (pas wire-compatible MCP complet)
set -euo pipefail
ROOT="$(cd "$(dirname "$0")/.." && pwd)"
echo "[mock-ops] ROOT=$ROOT tools: list_issues_open list_pods_readonly read_fixture_file" >&2
if command -v jq >/dev/null; then
  jq -r '.issues[]|select(.state=="open")|"#(.number) (.title)"' "$ROOT/fixtures/issues.json" >&2
  jq -r '.pods[]|select(.status!="Running")|"(.ns)/(.name) (.status)"' "$ROOT/fixtures/pods-readonly.json" >&2
fi
echo '{"ok":true,"lab":"mcp-devops"}'
EOF
chmod +x mock-server/server-mock.sh

cat > checklist-securite.md << 'EOF'
- [ ] Pas de token réel dans configs/ versionné (YOUR_TOKEN)
- [ ] mcp.json hors git ou template + .gitignore
- [ ] Allowlist tools ; deny write / fetch large
- [ ] Filesystem scoped (pas $HOME)
- [ ] Postgres / k8s : read-only + namespace limité
- [ ] HITL pour mutations (comment PR, scale, apply)
- [ ] Interdit : lire .env / id_rsa / kubeconfig prod
- [ ] Traiter sorties tools comme non fiables (injection)
- [ ] Kill switch : retirer le serveur du client < 30 s
EOF

./mock-server/server-mock.sh >/dev/null
jq empty fixtures/*.json configs/*.json mock-server/manifest.json && echo "lab OK"

Attendu : lab OK. mcp.json est un gabarit (Cursor / Claude Desktop / etc.) — jamais de vrai PAT.

Étape 5 — Sécurité & gouvernance MCP

Un tool mal scoped lit un .env, écrit hors sandbox ou exfiltre via fetch. Issues/tickets peuvent porter une prompt injection.

Risque	Mitigation
Secrets dans mcp.json	YOUR_TOKEN ; env hors git ; secrets manager
Filesystem trop large	Racine = lab / docs only
Write cluster / cloud	Deny défaut ; HITL ; least privilege
Fetch / browser	Allowlist domaines
Coût / spam tools	Budgets + audit des appels
Injection via contenu	Sorties tools = non fiables

Gouvernance : catalogue serveurs approuvés, PR pour toute entrée mcpServers, profils lecture vs mutation (deux configs client si besoin). Documentez le owner du serveur et la date de revue. Les routines planifiées qui branchent MCP héritent de la même allowlist — un cron LLM avec fetch ouvert est une porte dérobée.

Étape 6 — Quand MCP vs API directe vs skill

Approche	Force	Limite	Quand
MCP	Standard multi-clients, tools structurés	Surface sécu, maturité variable	Agent IDE récurrent
API directe	Contrôle, SLA, pas de process MCP	Glue + auth maison	CI, bots SLA, air-gap
Skill	Recette prompt versionnée	Pas d’accès système seul	Comment raisonner (+ MCP pour agir)

Heuristique Elastic Hayway : skill = procédure ; MCP = connecteurs ; workflow = orchestration (ai-agent-workflows) ; RAG = corpus (rag-docs-infra). API directe si idempotence CI stricte sans session agent. Ne remplacez pas un kubectl audité par un agent « magique » : MCP assiste sous garde-fous.

Quiz (3 questions)

1. MCP expose principalement ?
– A. Uniquement des modèles hébergés
– B. Tools, resources et prompts via serveurs standardisés
– C. Un remplacement de Kubernetes

2. Transport local le plus courant pour un lab filesystem ?
– A. SMTP
– B. stdio (processus lancé par le client)
– C. FTP anonyme

3. Première mesure sécu avant un serveur GitHub write ?
– A. Committer le PAT dans le repo
– B. Allowlist + token fine-grained + HITL mutations
– C. Donner admin org au serveur

Réponses : 1‑B · 2‑B · 3‑B

Compléments opérationnels

Standard de brief réutilisable

Pour mcp-servers-devops, adoptez un brief unique partagé par l’équipe. Il contient toujours cinq champs : objectif mesurable, contexte borné (lab/staging), liste blanche de fichiers ou ressources, interdits explicites (secrets, réseau, prod), et definition of done exécutable (commande de test ou checklist). Sans ces champs, l’outil improvisera — parfois avec élégance, souvent hors périmètre.

Stockez les briefs gagnants sous briefs/mcp-servers-devops/ dans un dépôt de documentation interne. Chaque brief cite le commit de référence et le modèle utilisé. Au troisième succès comparable, ouvrez une PR qui transforme le brief en rule, Skill ou slash command. Voir ai-skills-concept, claude-skills-instructions et evaluer-qualite-skill.

Revue de diff comme compétence P0

La vitesse d’un agent n’a aucune valeur si personne ne sait lire un diff. Instituez une règle simple : aucun apply massif sans parcours hunk par hunk. Posez-vous trois questions : ce changement est-il demandé ? est-il testé ? est-il réversible ? Si une réponse est non, refusez ou exigez un plan plus petit.

En atelier, faites commenter un diff à voix haute pendant cinq minutes. Les juniors apprennent ainsi le vocabulaire du refus. Reliez cette pratique à ai-code-review-pr et aux workflows ai-agent-workflows.

Sécurité continue

Les surfaces mcp-servers-devops multiplient les occasions d’injection et de fuite. Traitez tickets, README upstream, logs et ressources MCP comme des données non fiables. Séparez instructions et données. Allowlist tools. Confirmation humaine avant mutation. Guide : ai-prompt-injection-securite, mcp-servers-devops, claude-code-mcp.

Secrets : variables d’environnement de session, gestionnaire d’équipe, rotation, jamais de commit. Si un secret fuit dans un chat vendor, supposez-le compromis et rotatez.

Coûts, modèles et mode dégradé

Documentez un mapping fast/strong et un soft-cap mensuel dans la stack perso. OpenRouter peut aider à basculer — openrouter-multi-modeles. Le local (ollama-llm-locaux + continue-dev) sert de mode dégradé ou de bac à sable confidentialité.

Surveillez les changements silencieux de modèle par défaut : une régression de qualité est souvent un routing vendor, pas « l’équipe qui a oublié comment prompter ».

Ancrage parcours

mcp-servers-devops n’est qu’une étape du parcours IA DevOps 2026. Tronc commun d’abord (prompts, injection, skills), puis surface spécialisée, puis industrialisation (routines, MCP, RAG). Hub de navigation : /ia/. Comparatifs utiles : claude-vs-gpt-code, codex-vs-claude-code, claude-vs-cursor-vs-copilot.

Rituals hebdomadaires

Hebdo : promouvoir un brief en Skill/rule ; archiver un échec instructif ; vérifier le budget tokens. Mensuel : revoir la stack (retirer l’inutile) ; rejouer un lab gold ; mettre à jour les versions d’outils. Ces rituals valent mieux que d’ajouter un cinquième abonnement.

FAQ

MCP = proprietary Anthropic only ?
Protocole ouvert ; clients/serveurs multi-éditeurs. Vérifiez la compatibilité de votre client 2026.

Où mettre mcp.json ?
Selon l’outil (Cursor, Claude Desktop, Claude Code). Gabarit lab sous /tmp — pas de secrets versionnés. CLI : claude-code-mcp.

Kubernetes en écriture ?
Possible via community ; déconseillé jour 1. Read-only + NS staging + HITL pour scale/apply.

MCP remplace les skills Cursor ?
Non. Un skill encode la méthode ; MCP fournit les outils (ai-skills-concept).

Éviter l’exfiltration ?
Pas de fetch large ; filesystem scoped ; deny .env/clés ; HITL ; prompt injection.

Lab sans Node / npx ?
Mock bash + fixtures suffisent. Packages officiels souvent Node — optionnel ici.

Lien avec RAG docs ?
MCP peut exposer des resources ; retrieval + citations : rag-docs-infra.

Pour aller plus loin

• Spec MCP (modelcontextprotocol.io) · registres community · docs Claude / Cursor (UI évolutive)
• Hub : IA parcours DevOps 2026
• Module D : ai-skills-concept · cursor-skills-creer · ai-agent-workflows · claude-code-mcp · rag-docs-infra · ai-routines-agents · ai-prompt-injection-securite

Maillage série IA Outils 2026 — Skills & agents

← Précédent	Agent workflows multi-outils
→ Suite	RAG pour docs infra
Hub	IA pour DevOps : parcours 2026