Model Context Protocol: brancher un agent à tes outils sans chaos
MCP (standard ouvert, Anthropic fin 2024): host, client, serveur, tools JSON-RPC. Allowlist, tokens des schémas, sécu. Computer use en section. Guide PME.
MCP: un standard d'outils, pas une magie
Le Model Context Protocol (MCP) est un standard ouvert introduit par Anthropic en novembre 2024 pour brancher des applications IA sur des sources de données et des outils de façon homogène. L'analogie courante: un port USB-C pour les apps IA.
Architecture typique: un host (agent / app) crée des clients MCP; chaque client parle à un serveur qui expose tools et resources. Client et serveur communiquent souvent en JSON-RPC. Le modèle découvre les outils via des descriptions en langage naturel et des schémas d'appel.
MCP ne remplace pas ton API métier. Il la rend consommable par plusieurs clients (Claude, d'autres assistants, IDE agentiques) avec un contrat commun. Sans API stable, MCP formalise le chaos.
Écosystème: serveurs préconstruits (Drive, Slack, GitHub, Postgres, navigateurs, etc.) et SDKs. L'adoption multi-clients est le vrai argument « build once ».
Ce que tu exposes (et ce que tu caches)
Chaque outil a un nom, une description pour le modèle, un schéma de paramètres. Moins d'outils au début: 3 à 7 bien testés. Lecture avant écriture.
Utiles en PME: search_docs, get_ticket, draft_reply, create_task. Dangereux sans garde-fous: delete_*, send_email_unattended, update_price, export_all_customers.
Les schémas d'outils consomment des tokens avant toute requête utilisateur. Si tu branches plusieurs serveurs MCP, audite ce coût d'entrée (lien context engineering).
Sécurité et gouvernance
Traite un serveur MCP comme un microservice privilégié: auth client, autorisation par outil, rate limiting, logs structurés, environnements séparés.
Menaces: prompt injection qui détourne un outil, exfiltration via une lecture trop large, chaînage d'outils non prévu, confusion multi-tenant.
Mitigations: allowlist, validation de schémas, sandbox, HITL sur écritures, filtrage PII en sortie, tests de prompts adverses.
Secrets jamais dans le prompt. Vault ou variables d'environnement. Owner par serveur (qui ajoute un outil, qui review).
Computer use et navigateurs
Quand il n'y a pas d'API propre, computer use / contrôle navigateur élargit l'intégration. Puissant, fragile, sensible sécu. Réserve-le aux écrans legacy et aux POC isolés (VM, privilèges minimaux, enregistrement de session).
Pour les chemins critiques, préfère API + MCP. Même discipline que pour un agent headless en CI.
Feuille de route PME
1) Un cas d'usage. 2) Serveur MCP lecture seule. 3) Une écriture + HITL. 4) Métriques tokens et erreurs. 5) Élargir.
Côté Claude Code: un MCP de build ou de tickets change la boucle, mais chaque serveur actif gonfle le contexte de session (voir article Claude Code).
Si vous voulez une allowlist et une audit trail propres, on peut cadrer en 20-40 minutes.
FAQ
- MCP est-il obligatoire ?
- Non. Une API REST bien conçue suffit souvent. MCP devient rentable quand plusieurs clients IA partagent les mêmes outils.
- Qui a créé MCP ?
- Anthropic a open-sourcé le protocole en novembre 2024. Spécification, SDKs et serveurs d'exemple sont publics; l'écosystème multi-clients s'élargit.
- Self-host d'un serveur MCP ?
- Oui, et recommandé pour données internes. Isoler le réseau, moniter comme un service prod.
- MCP et données personnelles ?
- Chaque outil de lecture peut exposer de la PII à un LLM. Minimisation, masquage, bases légales. Pas tout le Drive par défaut.
- Combien d'outils au début ?
- 3 à 7. Au-delà, non-régression et coût de schémas explosent avant d'avoir prouvé le cas d'usage.
- Lien multi-agent ?
- MCP outille un ou plusieurs agents. L'architecture multi-agent (routeur, spécialistes) est un autre article.
Cadrez votre premier agent IA
20 minutes pour vérifier vos outils, vos données et le premier cas utile. Sans jargon, sans engagement.