Le MCP (Model Context Protocol) standardise la façon dont un LLM se connecte à vos outils et données internes via une architecture client/serveur. Plutôt que de recoder une intégration à chaque nouveau projet IA, on écrit un serveur MCP une fois, et tous les agents compatibles peuvent l'utiliser. Anthropic a publié le protocole en novembre 2024, l'a cédé à la Linux Foundation en décembre 2025, et en juin 2026 OpenAI, Google DeepMind et Microsoft l'ont adopté comme standard de fait.
Cet article explique ce que le MCP change concrètement en entreprise : comment fonctionne l'architecture, ce que signifient les primitives tools, resources et prompts, où passent vos données, comment gérer les permissions et les secrets, et surtout quand le MCP vaut mieux qu'une intégration custom, et quand ce n'est pas encore le bon choix.
Ce que le MCP résout vraiment : le problème de l'intégration répétée
Avant le MCP, connecter un LLM à un outil interne (base de données, CRM, API métier) signifiait coder une intégration sur mesure pour ce LLM précis. Quand on changeait de modèle ou qu'on ajoutait un deuxième agent, on recodait. Pour chaque outil, pour chaque modèle.
Le problème est connu dans les équipes produit : c'est le même problème que les APIs ont résolu dans les années 2000, ou que USB-C résout pour les connecteurs. Il faut un standard. Le MCP est ce standard pour les LLM.
Concrètement, le MCP définit un protocole basé sur JSON-RPC 2.0 avec deux rôles distincts :
- Le client MCP : l'application qui héberge le LLM (Claude Desktop, un agent LangGraph, votre propre app). Il envoie des requêtes et reçoit des résultats.
- Le serveur MCP : le composant qui expose vos outils et données. Il tourne sur votre infrastructure et répond aux requêtes du client. Un serveur MCP peut exposer votre base PostgreSQL, votre Notion, votre API de facturation, ou n'importe quoi d'autre.
La valeur de ce découplage : on écrit le serveur MCP une fois pour un outil donné, et tous les clients MCP (quel que soit le LLM) peuvent l'utiliser. En juin 2026, on compte plus de 10 000 serveurs MCP actifs en open source, dont des connecteurs GitHub, Filesystem, Slack, Notion, PostgreSQL, Jira, HubSpot et Salesforce.
Pour les entreprises qui déploient plusieurs projets IA sur la même infrastructure, c'est un gain de temps réel. Pour un premier projet unique avec un seul LLM, l'argument est moins convaincant.
Les trois primitives du MCP : tools, resources et prompts
Un serveur MCP expose trois types d'objets. La distinction n'est pas cosmétique : elle a des implications directes sur la gouvernance et la sécurité.
Les tools : des fonctions avec effets de bord
Les tools sont les fonctions que le modèle peut invoquer activement. Requête SQL sur votre base de données, envoi d'un email, création d'un ticket Jira, lecture d'un fichier sur le filesystem, appel à une API REST interne. Ce sont des actions qui modifient l'état du système.
Chaque tool est défini par un schéma JSON précis : nom, description, paramètres requis et optionnels, types. Le LLM reçoit ce schéma dans son contexte et décide quand et comment invoquer l'outil. En termes de sécurité, les tools sont la primitive la plus sensible : une mauvaise configuration peut permettre à un agent de supprimer des données ou d'envoyer des emails non souhaités.
Les resources : des données en lecture seule
Les resources sont des sources de données que le modèle peut lire sans modifier l'état du système. Contenu d'un document, enregistrements d'une base, logs applicatifs, fichiers de configuration. Elles ont une URI stable (comme file:///chemin/vers/document.pdf ou postgres://base/table) et peuvent être statiques ou dynamiques.
La distinction tools/resources est importante pour le principe du moindre privilège. Un agent de support client a besoin de lire les tickets (resource) mais pas nécessairement d'en créer (tool). Exposer les deux à tous les agents, c'est la première erreur de gouvernance.
Les prompts : des templates de workflow
Les prompts sont des templates prédéfinis qui encadrent le comportement du modèle pour des flux récurrents. Un prompt MCP peut intégrer dynamiquement des données (issues d'une resource) et des paramètres fournis par l'utilisateur. C'est utile pour standardiser les interactions : un prompt "résumer ce contrat" qui charge automatiquement le document depuis la resource correspondante.
En pratique, la majorité des implémentations MCP en entreprise commencent par les tools et les resources. Les prompts viennent ensuite quand on veut standardiser des workflows récurrents.
Où passent vos données avec le MCP
La question revient systématiquement en entretien de cadrage : "si on utilise le MCP, nos données partent où ?"
La réponse dépend de votre architecture, pas du protocole lui-même. Le MCP n'impose pas un modèle de déploiement. Voici les deux cas de figure :
Architecture cloud (LLM externe)
Le client MCP est hébergé dans le cloud (Claude.ai, API OpenAI). Quand le LLM décide d'invoquer un tool, la requête transite par le réseau vers votre serveur MCP. Le résultat remonte au LLM dans le cloud. Vos données passent donc par le réseau et sont visibles du fournisseur de LLM. Les conditions d'utilisation du fournisseur s'appliquent (traitement des données, rétention des logs API).
Architecture on-premise (LLM interne)
Le client MCP est hébergé sur votre infrastructure (un modèle Qwen, Llama ou Mistral servi via vLLM ou Ollama). Le serveur MCP est également interne. Les données ne quittent pas votre réseau. C'est l'architecture recommandée pour les entreprises soumises à des contraintes de souveraineté des données (santé, finance, défense, données RGPD strictes).
Le protocole MCP lui-même est transport-agnostique. Il supporte deux modes de transport : stdio (communication par entrée/sortie standard, pour les serveurs locaux) et Streamable HTTP (connexion HTTPS pour les serveurs distants, production-grade, avec support OAuth 2.1 et de multiples clients simultanés).
Soyons directs : si vous utilisez un LLM cloud avec un serveur MCP qui expose vos données internes, vous envoyez ces données au fournisseur. Ce n'est pas différent d'un appel API classique. La nouveauté du MCP, c'est la standardisation du mécanisme, pas la localisation des données.
Sécurité et gouvernance des serveurs MCP en entreprise
Le protocole est sécurisable. Le déploiement, lui, peut facilement ne pas l'être. En début 2026, des chercheurs en sécurité ont identifié 30 CVE critiques dans des serveurs MCP open source populaires en moins de 60 jours : injections de chemin (path traversal), injections d'arguments, fuites de secrets dans les logs. La NSA a publié en 2026 un guide de sécurité spécifique au MCP, ce qui dit quelque chose sur le niveau de maturité perçu.
La gestion des permissions : principe du moindre privilège
Chaque serveur MCP ne doit exposer que les tools et resources dont l'agent a effectivement besoin. Un agent d'analyse de tickets support n'a pas besoin d'accès en écriture à la base de données, ni d'accès à la messagerie interne. La granularité est importante : mieux vaut plusieurs serveurs MCP spécialisés qu'un seul serveur exposant tout.
Sur l'authentification, OAuth 2.1 est le mécanisme recommandé pour les serveurs MCP accessibles en réseau. Il permet d'intégrer vos IdP existants (Azure AD, Okta, Google Workspace) et d'attribuer des tokens par utilisateur ou par agent, avec des scopes précis. Les credentials ne doivent jamais être codés en dur dans le serveur MCP.
Les serveurs MCP tiers : ne pas copier-coller depuis GitHub sans audit
Le risque le plus concret en 2026 : des équipes qui déploient des serveurs MCP open source trouvés sur GitHub sans les auditer. Ces serveurs peuvent contenir des vulnérabilités (les 30 CVE identifiés en sont un exemple), mais aussi des dépendances transitives non maîtrisées.
La bonne pratique en entreprise : maintenir un registre interne des serveurs MCP autorisés. Chaque serveur tiers doit passer une revue de code, une analyse des dépendances (SBOM), et un scan des secrets avant déploiement. On version-pinne les serveurs approuvés et on répète l'audit à chaque mise à jour. C'est exactement ce que font Microsoft et les grandes organisations qui ont documenté leur approche publiquement.
Les logs d'audit : non négociables en contexte réglementé
Chaque appel d'outil via MCP doit être loggé : qui a demandé quoi, quel outil a été invoqué, avec quels paramètres, quel résultat a été retourné. C'est la condition minimale pour la traçabilité et le débogage.
En pratique, on instrumente le serveur MCP avec un middleware de logging qui capture les appels JSON-RPC avant et après exécution. Les outils d'observabilité LLM comme LangFuse ou LangSmith proposent des intégrations MCP pour centraliser ces traces avec le reste des logs d'inférence.
MCP vs intégration custom : quand choisir quoi
Le MCP n'est pas toujours la bonne réponse. Voici le tableau comparatif honnête :
| Critère | MCP | Intégration custom |
|---|---|---|
| Plusieurs LLM ou agents sur les mêmes outils | Avantage fort : un serveur, tous les clients en bénéficient | Redéveloppement par LLM |
| Périmètre d'outils stable, partagé entre projets | Idéal : investissement amorti sur tous les projets | Duplication de code |
| Projet unique, un seul LLM | Surcoût de protocole pas toujours justifié | Plus simple, plus rapide |
| Interopérabilité à long terme | Standard ouvert, gouverné par la Linux Foundation | Lock-in potentiel sur votre implémentation |
| Performance maximale (boucles très serrées) | Surcoût JSON-RPC non nul | Latence potentiellement inférieure |
| Gouvernance et audit | Protocole standard facilite l'instrumentation | À coder soi-même |
| Écosystème de serveurs existants | 10 000+ serveurs open source disponibles | Rien de réutilisable hors équipe |
La règle de décision simple : si vous construisez plusieurs agents sur la même infrastructure, ou si vous prévoyez de changer ou d'ajouter des LLM dans les 12 prochains mois, investir dans une couche MCP est rentable. Si c'est un projet ponctuel avec un périmètre d'outils très spécifique, une intégration custom peut être plus rapide à livrer.
Pour aller plus loin sur les architectures d'agents et les frameworks qui supportent nativement le MCP, l'article sur les frameworks agents IA en 2026 détaille LangGraph, OpenAI Agents SDK, Smolagents et PydanticAI, tous compatibles MCP.
Ce qui ne marche pas encore : les limites réelles du MCP en 2026
Le MCP est solide sur le papier. En production, plusieurs points de friction restent à connaître avant de s'engager.
La maturité des bonnes pratiques enterprise
Le protocole a été formalisé fin 2024. Les patterns de déploiement enterprise (MCP gateway, registre interne, audit trail, gestion des versions de serveurs) se stabilisent seulement en 2026. Si vous cherchez un guide de référence "battle-tested" avec des retours sur 12 mois de production en entreprise, il est rare. On en est encore à la phase de formalisation des best practices, pas à la phase de capitalisation.
Conséquence pratique : attendez-vous à faire vos propres arbitrages sur des sujets non encore documentés. Les équipes qui déploient le MCP en 2026 construisent la doctrine en même temps qu'elles livrent.
La sécurité des serveurs MCP tiers est un vrai risque
Les 30 CVE identifiés en début 2026 ne sont pas des cas théoriques. Des serveurs MCP populaires, repris dans des dizaines de projets par copier-coller, contenaient des failles exploitables. Le problème : la facilité d'installation des serveurs MCP (souvent un pip install ou un npx) crée l'illusion d'une livraison rapide sans qu'on ait audité quoi que ce soit.
Ce n'est pas un problème de protocole, c'est un problème de gouvernance. Mais il faut le nommer clairement : déployer un serveur MCP tiers sans audit sur des outils métier sensibles, c'est exposer potentiellement vos données à des vecteurs d'attaque connus.
La performance sur les boucles très serrées
Le protocole JSON-RPC ajoute un overhead par appel. Sur la plupart des cas d'usage (un agent qui fait 10 à 50 appels par tâche), c'est négligeable. Sur des architectures multi-agents avec des centaines d'appels de tools par minute, le surcoût de sérialisation/désérialisation JSON et de la couche HTTP commence à peser. Dans ces cas, une intégration directe dans le code de l'agent (appel de fonction Python ou TypeScript natif) garde l'avantage sur la latence.
Pour les dynamiques d'orchestration d'agents à grande échelle, l'article sur les dynamic workflows et l'orchestration multi-agents donne un cadre de référence sur les compromis de performance.
Questions fréquentes sur le MCP en entreprise
Les questions que les équipes posent systématiquement lors d'un cadrage MCP.
Qu'est-ce que le MCP (Model Context Protocol) ?
Le MCP est un protocole ouvert créé par Anthropic en novembre 2024 et cédé à la Linux Foundation en décembre 2025. Il standardise la façon dont un LLM se connecte à des outils et données externes via une architecture client/serveur JSON-RPC 2.0. Plutôt que de coder une intégration sur mesure pour chaque outil, on déploie un serveur MCP une fois, et tous les clients compatibles peuvent l'utiliser.
Quelle est la différence entre tools, resources et prompts dans le MCP ?
Les tools sont des fonctions avec effets de bord (requête SQL, envoi d'email). Les resources sont des données en lecture seule (contenu d'un document, logs). Les prompts sont des templates prédéfinis pour des workflows récurrents. La distinction tools/resources est importante pour la gouvernance : tools impliquent des actions, resources impliquent de la lecture.
Le MCP est-il sécurisé pour les données d'entreprise sensibles ?
Le protocole est sécurisable, mais la sécurité dépend du déploiement. En entreprise : déployez vos propres serveurs MCP sur votre infrastructure, gérez les credentials via OAuth 2.1, maintenez un registre interne des serveurs autorisés, et activez les logs d'audit sur chaque appel d'outil. Ne déployez pas de serveur MCP tiers sans audit de sécurité.
Quand vaut-il mieux utiliser le MCP plutôt qu'une intégration custom ?
Le MCP est préférable quand vous branchez plusieurs LLM ou agents sur les mêmes outils, quand le périmètre d'outils est stable et partagé entre plusieurs projets, et quand vous voulez un standard d'interopérabilité à long terme. L'intégration custom reste justifiée pour un projet unique avec un seul LLM.
Quels outils sont compatibles avec le MCP en 2026 ?
Claude, GPT-4o et o3, Gemini 2.x, LangGraph, OpenAI Agents SDK, Smolagents et PydanticAI supportent le MCP nativement. Plus de 10 000 serveurs MCP open source couvrent GitHub, Filesystem, Slack, Notion, PostgreSQL, Jira, HubSpot, Salesforce. Les SDKs officiels sont disponibles en Python, TypeScript et Kotlin.
Le MCP fonctionne-t-il avec des LLM hébergés on-premise ?
Oui. Le client MCP peut être un modèle hébergé sur votre infrastructure (Qwen, Llama, Mistral via vLLM ou Ollama). Les données ne quittent pas votre réseau. C'est l'architecture recommandée pour les entreprises soumises à des contraintes de souveraineté des données.
Combien coûte la mise en place d'un serveur MCP en entreprise ?
Un serveur MCP simple (3 à 5 outils, connexion à une base de données et une API interne) se développe en quelques jours avec le SDK Python ou TypeScript officiel. Un POC fonctionnel peut se monter en une à deux semaines. La complexité augmente avec le nombre d'outils, les exigences de sécurité et l'intégration au SI existant.
Quelles sont les limites du MCP en 2026 ?
Trois limites concrètes : la maturité (bonnes pratiques enterprise encore en cours de stabilisation), la sécurité des serveurs tiers (30 CVE critiques identifiés début 2026 dans des serveurs open source populaires), et la performance sur les boucles très serrées (surcoût JSON-RPC non nul à grande échelle).
Vous évaluez le MCP pour un projet ?
30 minutes pour évaluer si le MCP est la bonne architecture pour votre cas d'usage et vos contraintes de souveraineté.
En résumé : MCP, un standard à prendre au sérieux, avec méthode
Le MCP est le standard qui manquait pour connecter les LLM aux systèmes d'entreprise. L'adoption est réelle : OpenAI, Google DeepMind, Microsoft, les principaux frameworks d'agents. Ce n'est pas du hype de protocole.
Soyons honnêtes sur les nuances. Un serveur MCP simple se monte vite. Une architecture MCP enterprise sécurisée, avec registre interne, OAuth 2.1, audit trail et gouvernance des serveurs tiers, demande plus de rigueur que ce que la plupart des tutoriels suggèrent. Les 30 CVE de début 2026 sont là pour le rappeler.
Le bon réflexe : commencer par définir ce que vous exposez (tools vs resources, périmètre exact), par qui (quels agents, quels utilisateurs), et où tournent vos LLM (cloud vs on-premise). La structure du MCP force ces questions à la surface. C'est souvent le premier bénéfice, avant même d'écrire une ligne de code.
Si vous construisez plusieurs agents sur votre infrastructure ou si vous prévoyez de changer de LLM dans l'année, investir dans une couche MCP propre est rentable. Si c'est un projet ponctuel avec un périmètre figé, une intégration directe peut être plus rapide à livrer. Pour un accompagnement sur l'architecture, notre page expert IA générative et LLM détaille notre approche.
