Définition · La Semaine IA
MCP (Model Context Protocol) : c'est quoi, concrètement ?
Tu as un modèle brillant et un produit plein de données utiles — ton CRM, tes tickets de support, ton Postgres, ton Drive — et entre les deux, un mur. Pendant deux ans, brancher un LLM sur un outil voulait dire coder un connecteur maison à chaque fois : un pour Slack, un pour GitHub, un pour ta base, et tout recommencer pour le modèle suivant. Le MCP (Model Context Protocol) existe pour faire tomber ce mur.
Annoncé par Anthropic le 25 novembre 2024, c’est un protocole ouvert qui standardise la façon dont un modèle ou un agent va chercher des données et déclenche des actions dans le monde extérieur. La formule qui colle, et qu’Anthropic emploie elle-même : le MCP, c’est le « USB-C de l’IA ». Voici ce que ça veut dire vraiment, pourquoi ça compte si tu intègres l’IA dans ton produit, et où le truc est encore vert.
La définition courte (et honnête)
MCP = Model Context Protocol : une norme ouverte qui définit comment un modèle ou un agent IA dialogue avec des sources externes — fichiers, bases de données, API, outils métier — pour lire des données et exécuter des actions.
Techniquement, le MCP s’appuie sur JSON-RPC 2.0 pour les échanges de messages, et son architecture est ouvertement inspirée du Language Server Protocol (LSP) — la norme qui a réglé, côté éditeurs de code, le même genre de chaos d’intégrations. Il y a trois rôles :
- L’hôte : l’application IA que tu utilises (Claude Desktop, un IDE, ton propre agent).
- Le client : le connecteur, intégré à l’hôte, qui parle MCP.
- Le serveur : un petit programme qui expose un outil ou une source de données (ton GitHub, ton Postgres, ta doc) via le protocole.
Un serveur MCP expose trois types de capacités : des tools (des actions que le modèle peut appeler), des resources (des données qu’il peut lire) et des prompts (des gabarits réutilisables). Ce que le MCP n’est pas : ce n’est pas un modèle, pas une base vectorielle, pas du RAG. C’est la plomberie standardisée — la prise, pas l’électricité.
Le problème que ça règle : le casse-tête « N×M »
Imagine N applications IA d’un côté (Claude, un agent maison, ton IDE) et M outils de l’autre (Slack, GitHub, ton CRM, ta base). Sans norme commune, le pire des cas, c’est N × M intégrations à écrire et à maintenir. Chaque nouveau modèle ou outil multiplie la dette.
Le MCP transforme ce N×M en N+M. Tu écris un serveur MCP pour ton outil, et tous les hôtes compatibles MCP peuvent s’y connecter — sans que tu touches à leur code. Symétriquement, un hôte qui parle MCP accède d’un coup à tout l’écosystème de serveurs existants.
C’est exactement la logique de l’USB-C : avant, un câble propriétaire par appareil ; après, un seul port et tout se branche. Pour une équipe produit, ça change le calcul : intégrer un nouvel outil à ton agent passe de « un sprint de dev connecteur » à « pointer vers un serveur MCP existant ».
Pourquoi ça compte pour brancher l’IA à ton produit
Si tu construis avec l’IA — et pas juste un chatbot qui répond à côté — le MCP touche trois décisions concrètes.
1. Tu ne réinventes plus les connecteurs. Un agent utile doit agir : lire un ticket, ouvrir une PR, requêter une base. Le MCP te donne une interface stable pour ça, au lieu d’un patchwork d’appels d’outils faits maison qui casse à chaque montée de version de l’API.
2. Tu réduis le couplage à un fournisseur. Comme le protocole est ouvert et désormais multi-éditeurs (Anthropic, OpenAI, Google), tes serveurs MCP survivent à un changement de modèle. Tu peux passer de Claude à un modèle open source sans réécrire ta couche d’intégration.
3. Tu sépares proprement le modèle et les données. Le MCP gère l’accès aux données fraîches et privées au moment de la requête — un cousin architectural du RAG, mais côté actions et connexions plutôt que côté récupération de passages. Les deux se combinent très bien : un serveur MCP peut justement exposer une base de vecteurs d’embeddings.
Le bon réflexe : avant d’écrire un connecteur maison, vérifie s’il existe déjà un serveur MCP officiel pour l’outil visé. Souvent, oui.
Honnête sur la maturité : ce qui marche, ce qui est encore vert
Le MCP n’a pas encore deux ans. Présenter ça comme un standard figé et bétonné serait mentir.
Ce qui est solide : la spécification de base, les SDK officiels (Python, TypeScript, et d’autres langages) et un écosystème déjà énorme — des milliers de serveurs communautaires et des centaines de clients en circulation. L’adoption par les trois grands labos rend un retour en arrière improbable.
Ce qui demande de la prudence :
- Authentification et permissions. Donner à un agent les clés de tes outils ouvre une surface d’attaque. Brancher un serveur MCP tiers non audité, c’est exécuter du code étranger dans ton contexte. Les attaques de type prompt injection via un serveur malveillant ou des données empoisonnées sont une menace réelle, pas théorique.
- Hétérogénéité. Tous les serveurs ne se valent pas : qualité, maintenance et couverture varient énormément d’un projet communautaire à l’autre.
- Standard mouvant. La spec évolue vite ; ce qui est vrai sur l’auth ou le transport aujourd’hui peut bouger d’une révision à l’autre.
La règle de prod : traite un serveur MCP comme une dépendance sensible. Audite-le, restreins ses permissions au minimum, et garde un humain dans la boucle sur les actions destructrices. La même prudence que pour toute hallucination potentielle d’un modèle qui décide d’agir.
Le MCP en une phrase pour ton board
Si tu dois le pitcher à quelqu’un qui ne code pas : « C’est la prise standard qui permet à notre IA de se brancher en sécurité sur nos outils et nos données — une fois, au lieu d’un connecteur sur mesure par outil et par modèle. »
Le MCP ne rend pas l’IA plus intelligente. Il rend son intégration raisonnable. C’est la différence entre un démo qui impressionne et un système que tu peux faire évoluer sans tout recâbler à chaque nouveau modèle. Le fait qu’Anthropic l’ait donné à une fondation neutre en décembre 2025 — avec OpenAI et Google autour de la table — est le meilleur signal que ce n’est pas un standard captif, mais une infrastructure commune.
Pour creuser comment ces briques s’assemblent dans un produit réel, va voir notre guide pour comprendre l’IA.
Le MCP, c'est le port USB-C de l'IA : tu câbles ton agent une fois, et n'importe quel outil compatible se branche dessus sans recâbler tout le tableau.
Questions fréquentes
Quand le MCP a-t-il été annoncé, et par qui ?
Le Model Context Protocol a été annoncé et open-sourcé par Anthropic le 25 novembre 2024 (version de spec 2024-11-05), accompagné des premiers SDK en Python et TypeScript. Ce n'est donc pas un standard ancien : il a un peu plus d'un an et demi de recul à la mi-2026. Sa diffusion, en revanche, a été fulgurante grâce à l'adoption par les autres grands labos.
Quelle est la différence entre MCP et RAG ?
Ce sont deux briques complémentaires, pas des concurrentes. Le RAG (Retrieval-Augmented Generation) est une architecture qui va chercher des passages pertinents dans une base pour les injecter dans le prompt — il répond à la question « sur quelles données le modèle s'appuie-t-il ? ». Le MCP est un protocole de connexion : il standardise comment un agent se branche à des outils et des sources pour lire des données et déclencher des actions. En pratique, un serveur MCP peut très bien exposer la base de recherche d'un système RAG. Le MCP, c'est la tuyauterie ; le RAG, l'usage.
Pourquoi appelle-t-on le MCP le « USB-C de l'IA » ?
Parce qu'il joue le même rôle qu'un port universel. Avant l'USB-C, chaque appareil avait son câble propriétaire ; avant le MCP, chaque couple (modèle, outil) demandait son connecteur maison. Le MCP fournit une prise unique : tu écris un serveur une fois, et tout hôte compatible peut s'y brancher. Anthropic emploie elle-même cette analogie. Elle est juste tant qu'on garde en tête qu'un standard de protocole reste plus complexe qu'un câble — l'auth et la sécurité, notamment, n'ont pas d'équivalent dans un port USB.
Ai-je besoin du MCP pour construire un agent IA ?
Non, ce n'est pas obligatoire : tu peux donner des outils à un agent via des appels de fonctions classiques (function calling). Mais dès que ton agent doit se connecter à plusieurs outils, ou que tu veux pouvoir changer de modèle sans réécrire tes intégrations, le MCP devient le choix pragmatique. Il t'évite de maintenir un connecteur sur mesure par outil et par fournisseur. Pour un seul outil et un seul modèle figé, c'est de l'ingénierie probablement inutile.
Est-ce que le MCP fonctionne avec autre chose que les modèles d'Anthropic ?
Oui, et c'est tout l'intérêt. Le protocole est ouvert et a été adopté au-delà d'Anthropic : OpenAI l'a intégré en mars 2025 (Agents SDK, API Responses, ChatGPT desktop), et Google DeepMind a confirmé son support pour Gemini en avril 2025. En décembre 2025, Anthropic a donné le MCP à l'Agentic AI Foundation, une fondation sous l'égide de la Linux Foundation co-fondée avec OpenAI et Block. Tes serveurs MCP ne sont donc pas liés à un seul fournisseur de modèle.
Le MCP est-il sûr pour la production ?
La spec et les SDK sont stables, mais la sécurité reste le point de vigilance numéro un. Brancher un serveur MCP tiers, c'est exécuter du code dans ton contexte, avec des risques d'injection de prompt et de fuite de données si le serveur est malveillant ou mal conçu. En production : n'utilise que des serveurs audités, applique le principe du moindre privilège sur les permissions, isole les serveurs sensibles, et garde un humain dans la boucle pour toute action destructrice. Traite chaque serveur MCP comme une dépendance critique de ta chaîne d'approvisionnement logicielle.
Sources
- Anthropic, « Introducing the Model Context Protocol », 25 novembre 2024
- Spécification officielle du Model Context Protocol (modelcontextprotocol.io)
- Anthropic, « Donating the Model Context Protocol and establishing the Agentic AI Foundation », décembre 2025
- « Model Context Protocol », Wikipedia (historique, JSON-RPC, adoption OpenAI/Google)