Le 9 décembre 2025, Anthropic a fait quelque chose d'inhabituel pour l'éditeur d'un protocole qui portait encore son nom un an plus tôt : il l'a donné. Le Model Context Protocol a rejoint l'Agentic AI Foundation, un fonds dédié hébergé par la Linux Foundation et cofondé avec Block et OpenAI. Ce n'est plus la brique d'un seul éditeur, c'est une infrastructure partagée, dans la même catégorie que HTTP ou TCP/IP pour ceux qui construisent des agents IA aujourd'hui.
Le terme circule depuis fin 2024, mais la plupart des articles qui l'expliquent restent au niveau de la définition. Ici, l'objectif est différent : comprendre ce que MCP change concrètement pour une équipe qui pilote des agents IA en entreprise, comment le configurer sans y perdre une soirée, et surtout, à partir de quel moment ça vaut vraiment le coût de le mettre en place plutôt que de garder une intégration API classique.
Le problème que MCP résout : la fragmentation N fois M
Avant MCP, chaque assistant IA qui devait lire un CRM, une base Postgres ou un espace Notion nécessitait son propre connecteur, écrit et maintenu séparément. Avec M modèles ou applications IA et N outils à connecter, une équipe se retrouvait à maintenir un nombre de connecteurs qui grimpe vite : dix outils et trois assistants, c'est déjà potentiellement trente intégrations différentes à faire évoluer à chaque changement d'API.
Anthropic a ouvert MCP en open source le 25 novembre 2024, conçu par David Soria Parra et Justin Spahr-Summers, avec une idée simple : remplacer cette fragmentation par un protocole unique. La spécification officielle définit trois rôles distincts : le Host (l'application qui embarque le modèle, par exemple Claude Desktop ou un IDE), le Client (le connecteur intégré à l'Host) et le Server (le service qui expose des données ou des capacités). Les messages transitent en JSON-RPC 2.0, un format déjà utilisé par le Language Server Protocol dont MCP s'inspire directement pour l'architecture.
Trois primitives suffisent à décrire ce qu'un serveur MCP peut exposer : des Tools (des fonctions que le modèle peut exécuter), des Resources (des données consultables) et des Prompts (des modèles de conversation réutilisables). Un modèle qui sait parler MCP peut donc se connecter à n'importe quel serveur MCP sans code spécifique, exactement comme un navigateur qui affiche n'importe quel site sans plugin par domaine. C'est ce changement d'échelle, plus que la technique elle-même, qui explique l'adoption rapide du protocole. Pour aller plus loin sur le principe de connecter un modèle à des systèmes tiers, notre article sur la façon de connecter ChatGPT à des outils métier sans coder détaille une approche complémentaire, sans passer par MCP.
Configurer un serveur MCP en pratique
La théorie se vérifie vite en pratique. Dans Claude Desktop, la configuration vit dans un fichier claude_desktop_config.json (dans ~/Library/Application Support/Claude/ sur Mac). Ajouter un serveur qui donne accès à un système de fichiers local ressemble à ceci :
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/vous/Documents"]
}
}
}Le piège le plus fréquent : des chemins relatifs au lieu de chemins absolus, qui font échouer le serveur silencieusement au redémarrage de l'application. Toujours vérifier avec un chemin complet, puis relancer Claude Desktop entièrement (pas juste rafraîchir la fenêtre).
Pour un usage en ligne de commande, Claude Code propose une commande dédiée qui évite d'éditer le JSON à la main : claude mcp add --transport http notion https://mcp.notion.com/mcp connecte un serveur distant en une ligne. Trois portées existent et se confondent souvent en projet : local (par défaut, privé au projet courant), project (partagé via un fichier .mcp.json versionné, pratique pour une équipe qui doit toutes disposer des mêmes outils) et user (disponible sur tous vos projets, mais privé à votre compte). Sur un projet client, le choix par défaut local laisse souvent une équipe se demander pourquoi le serveur MCP configuré par un développeur n'apparaît pas chez les autres : c'est le comportement normal de cette portée, pas un bug. Notre comparatif sur Claude Code, Cursor et GitHub Copilot détaille par ailleurs comment chacun de ces outils gère les serveurs MCP différemment.
MCP en chiffres : d'un standard Anthropic à une infrastructure neutre
Le rythme d'adoption a surpris jusqu'aux équipes d'Anthropic elles-mêmes. Au moment de la donation à la Linux Foundation en décembre 2025, Anthropic recensait 97 millions de téléchargements mensuels des SDK MCP (Python et TypeScript combinés), plus de 10 000 serveurs MCP actifs et 75 connecteurs référencés dans l'annuaire de Claude, un an seulement après l'ouverture du protocole en open source.
La bascule concurrentielle a été rapide. En mars 2025, OpenAI a ajouté le support de MCP dans son Agents SDK, avec trois types de serveurs pris en charge (hébergés, HTTP en streaming, et stdio). Quelques semaines plus tard, Google a annoncé un support officiel de MCP pour ses services, avec des serveurs gérés couvrant l'infrastructure Google Cloud et l'API Gemini. Trois éditeurs qui se livrent une concurrence frontale sur les modèles adoptent le même protocole de connexion : c'est ce point de convergence, plus que l'annonce initiale d'Anthropic, qui a fait basculer MCP de "protocole intéressant" à "standard qu'on ne peut plus ignorer" pour quiconque construit des agents IA en 2026.
La faille que les pages marketing ne mentionnent jamais
Aucune page produit ne le dira spontanément, mais MCP a ouvert une nouvelle surface d'attaque, documentée noir sur blanc par l'OWASP sous le nom de Tool Poisoning Attack. Le mécanisme est simple à comprendre et donc difficile à ignorer une fois qu'on l'a vu : un serveur MCP malveillant expose un outil au nom parfaitement légitime, mais sa description contient des instructions cachées, invisibles pour l'utilisateur mais lues par le modèle. Quand l'agent invoque cet outil, la réponse du serveur atterrit dans le contexte du modèle sans validation, et les instructions injectées sont traitées comme du contenu de confiance : elles peuvent pousser l'agent à appeler des outils restreints ou à exfiltrer des données.
La racine du problème, selon l'OWASP, tient en une phrase : les descriptions d'outils sont validées à la connexion, mais les réponses des outils ne le sont pas ensuite. Les mitigations recommandées restent accessibles à n'importe quelle équipe technique : exiger des schémas structurés plutôt que du texte libre en retour d'outil, isoler les outils à privilège élevé (accès fichiers, bases de données) dans un contexte d'agent séparé, appliquer les contrôles d'accès côté serveur plutôt que de compter uniquement sur les instructions du prompt système, et maintenir une liste blanche des serveurs MCP autorisés plutôt que d'accepter des connexions arbitraires. Sur les projets d'agents IA que nous livrons, cette liste blanche est systématiquement le premier réflexe qu'on impose avant même de discuter des outils à connecter.
Quand ne pas construire un serveur MCP
C'est le passage que la plupart des guides évitent parce qu'il va à contre-courant de l'enthousiasme ambiant : construire un serveur MCP maison n'est pas toujours la bonne réponse, même quand le besoin est réel. Le critère qu'on applique en projet est simple et rarement mis en avant ailleurs : un serveur MCP se justifie à partir du moment où au moins deux clients IA différents (Claude, un agent interne, un futur outil Copilot) doivent consommer les mêmes données ou les mêmes actions. En dessous de ce seuil, un connecteur API classique fait le travail avec moins de code à maintenir, moins de surface d'attaque à surveiller, et sans la couche de négociation de capacités du protocole.
Un exemple illustratif rencontré sur un projet client (scénario anonymisé, pas un cas nommé) : une PME voulait un serveur MCP pour que "son IA" consulte son ERP. En creusant, un seul client consommait ces données, un assistant interne développé sur mesure. Construire un serveur MCP complet aurait ajouté une couche d'authentification, de gestion de session et de validation de schéma pour un bénéfice nul tant qu'un deuxième client ne se présentait pas. La solution retenue a été un point d'accès API classique, connecté directement à l'agent, avec une trajectoire claire pour migrer vers MCP le jour où un deuxième outil IA aurait besoin des mêmes données. Notre article sur les agents IA sur mesure en entreprise détaille ce type d'arbitrage architecture par architecture. À l'inverse, dès qu'une entreprise expose ses données à plusieurs assistants IA du marché en parallèle, exposer un serveur MCP devient la solution la moins coûteuse à long terme, précisément parce qu'elle évite de réécrire le même connecteur trois fois.
MCP et l'automatisation no-code : ce qui change pour votre stack
MCP n'est plus réservé aux équipes qui écrivent du code. En avril 2026, n8n a livré un serveur MCP au niveau de l'instance, avec deux nœuds distincts : le nœud MCP Server Trigger, qui transforme un workflow n8n entier en serveur consommable par n'importe quel client MCP, et le nœud MCP Client Tool, qui permet à un agent construit dans n8n d'appeler les outils exposés par un serveur MCP externe. Concrètement, un client Claude Desktop ou un agent Cursor peut désormais créer, tester et déployer un workflow n8n à partir d'une instruction en langage naturel, sans qu'un développeur écrive de connecteur dédié.
Pour une équipe qui pilote déjà son automatisation sur n8n, c'est un changement de nature plus que de degré : le workflow devient à la fois consommateur et fournisseur de contexte IA, sans code supplémentaire pour l'exposer. C'est aussi là que la tendance plus large de l'IA agentique en entreprise prend une forme concrète, au-delà du chatbot qui répond à des questions : un agent qui déclenche réellement des actions dans les systèmes de l'entreprise, avec une gouvernance des accès qui doit suivre.
Questions fréquentes
MCP remplace-t-il les API classiques ?
Non. MCP est une couche de standardisation par-dessus des systèmes qui exposent déjà des API ou des bases de données. Un serveur MCP appelle en général une API existante en coulisses. La question n'est pas API contre MCP, mais si la standardisation supplémentaire apporte un bénéfice réel pour votre nombre de clients IA à connecter.
MCP est-il gratuit à utiliser ?
Le protocole lui-même est open source et gratuit, sous la gouvernance de l'Agentic AI Foundation. Le coût réel se situe dans le développement et la maintenance du serveur MCP (ou dans l'abonnement à un serveur MCP hébergé par un éditeur tiers), pas dans une licence du protocole.
Quels risques de sécurité faut-il vraiment anticiper ?
Le principal, documenté par l'OWASP, est le tool poisoning : un serveur MCP tiers dont les descriptions d'outils cachent des instructions malveillantes. La parade de base est de n'autoriser que des serveurs sur liste blanche et d'exiger une validation humaine avant toute action sensible, plutôt que de faire confiance par défaut à un serveur externe.
MCP fonctionne-t-il uniquement avec Claude ?
Non, même s'il a été créé par Anthropic. OpenAI l'a intégré à son Agents SDK dès mars 2025, Google le supporte nativement dans ses services cloud et son API Gemini, et des outils no-code comme n8n exposent désormais des serveurs et clients MCP en natif.
Comment savoir si mon entreprise a besoin d'un serveur MCP ?
Comptez le nombre d'assistants ou agents IA différents qui doivent accéder aux mêmes données ou actions. Un seul client : un connecteur API direct reste plus simple à maintenir. Deux clients ou plus, ou une volonté de rendre vos données accessibles à l'écosystème IA au sens large : un serveur MCP devient la solution la plus économique à moyen terme.
