MCP (Model Context Protocol) : guide entreprise 2026

MCP en bref : pourquoi un standard maintenant

Le Model Context Protocol (MCP) est un standard ouvert publié par Anthropic en novembre 2024 et adopté en 2025-2026 par l'essentiel de l'écosystème IA (Anthropic, OpenAI, Google DeepMind, Microsoft, Cursor, Zed, Replit, Sourcegraph). Son objectif est simple : remplacer le patchwork d'intégrations propriétaires entre les LLM et les outils d'entreprise par un protocole unique, ouvert et auditable.

Avant MCP, chaque éditeur d'IA exposait sa propre API : function calling côté OpenAI, tool use côté Anthropic, plugins côté ChatGPT, extensions côté Gemini. Connecter un copilot à Slack, Notion, Gmail, GitHub et une base PostgreSQL impliquait d'écrire N x M intégrations — une par couple (modèle, outil) — et de les maintenir à chaque changement d'API. MCP réduit ce problème à N + M : chaque outil expose un serveur MCP une fois, chaque LLM implémente un client MCP une fois, et l'écosystème devient interopérable.

Concrètement, MCP joue pour l'IA agentique le rôle que LSP (Language Server Protocol) a joué pour les IDE en 2016 : un protocole JSON-RPC standardisé, indépendant du fournisseur, que tout le monde a fini par adopter parce qu'il résolvait un vrai problème d'intégration. La spécification est versionnée, publiée sur GitHub sous licence MIT, et gouvernée par un groupe de travail multi-éditeur.

Pour un DSI ou un CTO, MCP n'est pas un gadget de plus : c'est la couche d'intégration manquante entre les LLM et le SI. Il devient possible de brancher Claude, GPT-5 ou Gemini sur les mêmes outils internes sans réécrire la moitié du code, et de garder le contrôle sur ce qui est exposé, à qui, et avec quels droits.

Architecture : hôte, client, serveur

MCP repose sur trois rôles distincts. Comprendre cette séparation est indispensable pour concevoir une architecture saine.

L'hôte (host)

L'hôte est l'application qui embarque le LLM et orchestre les interactions utilisateur : Claude Desktop, Claude Code, Cursor, Zed, ChatGPT Desktop (depuis mars 2025), Continue.dev, votre propre copilot interne. L'hôte gère l'interface, la mémoire conversationnelle et la politique de sécurité (consentement utilisateur, journalisation).

Le client (client)

À l'intérieur de l'hôte, un client MCP est instancié par serveur connecté. Le client maintient la connexion, négocie les capacités (capabilities) avec le serveur au handshake, et expose les tools, resources et prompts au modèle. Un hôte peut gérer dizaines de clients en parallèle — un par serveur MCP actif.

Le serveur (server)

Le serveur MCP encapsule un service externe (Slack, Postgres, GitHub, un fichier local, une API maison) et expose ses capacités via le protocole. C'est un processus indépendant, écrit dans n'importe quel langage qui dispose d'un SDK : Python, TypeScript, Go, Rust, Java, C#, Kotlin, Swift. Le serveur ne sait rien du LLM ni de l'utilisateur : il ne reçoit que des appels structurés JSON-RPC.

Cette architecture en trois couches a deux conséquences importantes. D'abord, le serveur est réutilisable : un serveur MCP Postgres bien écrit fonctionnera demain avec Claude, après-demain avec GPT-5, et l'année prochaine avec un modèle open source non encore publié. Ensuite, la responsabilité de la sécurité reste côté hôte et serveur : le LLM ne fait qu'émettre des intentions, c'est le couple hôte/serveur qui décide ce qui est autorisé.

Transports : stdio, SSE et HTTP streamable

MCP définit les messages (JSON-RPC 2.0) indépendamment de la couche de transport. Trois transports sont supportés en 2026.

stdio (standard input/output)

Le serveur est lancé comme un sous-processus de l'hôte et communique sur ses flux stdin/stdout. C'est le transport le plus simple, idéal pour les serveurs locaux qui accèdent au système de fichiers, à un Git local, à une base de données embarquée, ou à des outils CLI. C'est le mode utilisé par défaut dans Claude Desktop et Claude Code pour la quasi-totalité des serveurs community. Pas de port à ouvrir, pas de réseau, pas d'authentification réseau à gérer.

SSE (Server-Sent Events)

Initialement défini comme transport réseau, SSE permet à un serveur MCP distant d'envoyer un flux d'événements vers l'hôte en HTTP long-polling. C'est utile quand le serveur tourne sur une autre machine ou dans un conteneur — typiquement un serveur MCP hébergé en cluster Kubernetes. Le mode SSE reste supporté mais a été progressivement remplacé par HTTP streamable dans la révision de spec de 2025.

HTTP streamable

Introduit en 2025 pour simplifier les déploiements cloud, le transport HTTP streamable utilise une seule URL HTTP supportant des réponses en streaming (chunked transfer ou SSE selon la requête). C'est le format recommandé pour les serveurs MCP exposés en SaaS ou hébergés derrière un API Gateway, parce qu'il s'intègre nativement avec les load balancers, les WAF et l'authentification OAuth standard.

En pratique, un déploiement entreprise typique mélange les trois : stdio pour les serveurs sensibles qui doivent rester sur la machine du collaborateur (filesystem, accès SSH, secrets locaux), HTTP streamable pour les serveurs centralisés (Slack, Notion, base de données métier) hébergés dans le cloud privé.

Les trois primitives : tools, resources, prompts

Un serveur MCP peut exposer trois types d'objets au LLM. Bien distinguer ces primitives est la clé d'une bonne conception.

Tools (outils)

Les tools sont des fonctions invocables par le modèle, avec un schéma d'entrée JSON Schema typé. C'est l'équivalent du function calling classique : send_slack_message, create_github_issue, query_database. Le modèle décide quand appeler un outil, l'hôte demande (ou non) confirmation à l'utilisateur, le serveur exécute et renvoie un résultat structuré.

Resources (ressources)

Les resources sont des contenus lisibles identifiés par URI : un fichier, une page Notion, un ticket Jira, une ligne de base de données. Contrairement aux tools, les resources sont pilotées par l'application, pas par le modèle : c'est l'hôte qui décide de charger une ressource dans le contexte (par exemple via une mention @ ou un menu d'attachement). Cette séparation évite que le LLM puisse aspirer toute la base documentaire de sa propre initiative.

Prompts

Les prompts sont des modèles d'invite paramétrables exposés par le serveur : « Résume ce ticket Jira », « Génère un message de release notes à partir de ces commits ». Ils sont déclenchés explicitement par l'utilisateur (slash command, palette de commandes) et permettent au serveur de fournir des workflows pré-pensés sans que l'utilisateur ait à les rédiger.

Cette tripartition reflète une intuition d'architecture importante : tout ne doit pas être exposé comme un tool. Un serveur MCP bien conçu expose les écritures dangereuses comme tools (avec confirmation), les lectures contextuelles comme resources (chargées par l'utilisateur), et les workflows récurrents comme prompts.

Cas d'usage entreprise

L'intérêt de MCP n'apparaît vraiment qu'en environnement multi-outils. Voici les cas d'usage les plus courants observés en mission chez nos clients PME et ETI.

Copilot interne sur Slack + Notion + Gmail + GitHub + base SQL

C'est le cas canonique. Une équipe produit veut un assistant Claude qui peut : lire les threads Slack du canal #produit, consulter les pages Notion de la roadmap, ouvrir un mail de support Gmail, créer une issue GitHub avec le contexte, et interroger une base PostgreSQL pour vérifier qu'un bug est réel. Sans MCP, c'est cinq intégrations propriétaires à coder. Avec MCP, on assemble cinq serveurs (dont quatre déjà open source) et on configure les scopes OAuth.

Agent IA pour le support client

Un agent qui lit le ticket Zendesk entrant, recherche dans Confluence la procédure correspondante, vérifie le statut du compte client dans la base SQL, et propose une réponse au support humain. MCP permet d'isoler chaque source : si demain on change Confluence pour Notion, on remplace un seul serveur MCP au lieu de réécrire l'agent.

Code agent (développement)

Cursor, Claude Code et Continue.dev exploitent massivement MCP en 2026 : serveur Filesystem pour lire le code, serveur Git/GitHub pour ouvrir des PR, serveur Postgres pour valider les requêtes générées sur un schéma réel, serveur Sentry pour récupérer la stack trace d'un crash en production. C'est l'usage qui a le plus tiré l'adoption du protocole.

Reporting et BI conversationnel

Brancher un copilot sur un data warehouse (Snowflake, BigQuery, Postgres) via un serveur MCP en lecture seule, plus un serveur MCP qui expose le catalogue dbt comme resources. L'utilisateur métier pose ses questions en langage naturel, le LLM choisit la bonne table, écrit la requête SQL, et l'exécute via le tool exposé. La gouvernance est centralisée dans le serveur (politiques de masquage, lignes par utilisateur).

Onboarding RH et opérations internes

Un assistant qui interroge l'annuaire LDAP, crée le compte dans Workday, ouvre un ticket Jira pour la commande du laptop, et envoie un message de bienvenue Slack. MCP transforme ce qui était un script Python rigide en un agent conversationnel qui peut aussi répondre aux questions de l'employé.

Pour aller plus loin sur la conception d'agents internes, voir notre offre agent IA entreprise.

MCP vs Function Calling vs Plugins ChatGPT

Trois approches dominent la connexion LLM-outils en 2026. Elles ne sont pas équivalentes.

La distinction clé : MCP standardise l'interface entre l'hôte et l'outil, tandis que le function calling standardise l'interface entre l'application et le modèle. Les deux sont complémentaires — un hôte MCP utilise toujours du function calling en interne pour faire dialoguer le modèle avec ses outils, mais MCP ajoute une couche d'abstraction qui rend les outils portables d'un modèle à l'autre.

En pratique, en 2026, les deux coexistent. Une équipe qui développe un copilot from scratch utilisera MCP pour la couche d'intégration (et bénéficiera de l'écosystème de serveurs existants) et function calling pour les outils internes très spécifiques qui ne méritent pas un serveur MCP dédié. Pour une comparaison plus large des modèles, voir notre analyse Claude vs ChatGPT entreprise.

Sécurité : OAuth, scopes, audit

MCP a été conçu en pleine conscience des risques de l'IA agentique. Trois mécanismes constituent la base d'un déploiement sûr.

Authentification OAuth 2.1

La spécification MCP impose, pour les serveurs distants, l'utilisation d'OAuth 2.1 avec PKCE et flow d'autorisation côté hôte. L'utilisateur consent explicitement à ce que le serveur MCP accède à ses données — par exemple à son Slack ou à son Gmail — via le même flow qu'une application tierce classique. Les tokens sont stockés côté hôte, pas exposés au modèle, et révocables à tout moment.

Scopes et principe de moindre privilège

Chaque serveur MCP doit déclarer les scopes minimaux dont il a besoin. Un serveur Slack pour le support client n'a pas besoin du droit d'écrire dans tous les canaux : on l'autorise uniquement sur channels:history et chat:write pour un canal précis. Un serveur Postgres pour la BI conversationnelle utilise un compte applicatif en lecture seule avec un row-level security configuré.

Consentement utilisateur et tool gating

Les hôtes conformes affichent une fenêtre de confirmation avant l'exécution de chaque tool, surtout pour les actions qui écrivent ou envoient (publier un message Slack, créer un ticket, supprimer un fichier). L'utilisateur peut autoriser une fois, pour la session, ou définitivement pour ce serveur. C'est une protection essentielle contre les prompt injections : même si un attaquant glisse une instruction malveillante dans une page web lue par l'agent, l'utilisateur garde la main sur l'action finale.

Audit et journalisation

Tous les appels MCP doivent être journalisés : qui a appelé quel tool, avec quels arguments, à quelle heure, avec quel résultat. C'est indispensable pour la conformité (RGPD, ISO 27001, SOC 2) et pour le debug d'incident. Les implémentations enterprise (Anthropic Console, Azure AI Foundry) exposent ces logs en SIEM (Splunk, Datadog, Sentinel).

Risques spécifiques à surveiller

• Prompt injection via resources : un fichier ou une page lue par l'agent peut contenir des instructions cachées. Mitiger par tool gating systématique sur les actions sensibles.
• Confused deputy : un serveur MCP qui agit avec ses propres droits plutôt qu'avec ceux de l'utilisateur. Toujours utiliser des tokens utilisateur via OAuth, jamais un compte de service partagé.
• Exfiltration de données via tools tiers : un agent peut être convaincu d'envoyer des données sensibles vers un endpoint externe. Limiter strictement les serveurs MCP installés à ceux validés par la sécurité.
• Serveurs MCP non vérifiés : l'écosystème community est riche mais inégal. Auditer le code source avant déploiement, préférer les serveurs officiels (Anthropic, éditeur du SaaS).

Pour un déploiement entreprise, prévoyez un processus de validation de chaque serveur MCP avant mise en production, équivalent à ce qu'on fait pour un plugin Slack ou une app marketplace.

Tableau des serveurs MCP populaires en 2026

L'écosystème compte plus de 1 500 serveurs MCP publiés en avril 2026. Voici une sélection des plus utilisés en entreprise, avec leur maturité.

La distinction officiel vs communauté est cruciale : un serveur officiel publié par l'éditeur du SaaS est généralement maintenu, signé et audité. Un serveur communautaire peut être excellent — beaucoup le sont — mais doit être validé avant production. Le registre mcp.so et le dépôt GitHub modelcontextprotocol/servers centralisent les serveurs de référence.

Roadmap et écosystème 2026

La gouvernance de MCP a basculé en 2025 d'un projet Anthropic à un groupe de travail multi-éditeur (Anthropic, OpenAI, Google, Microsoft, communauté open source). Plusieurs chantiers structurent la feuille de route pour 2026.

Sampling et agents nested

La primitive sampling, prévue dans la spec, permet à un serveur MCP de demander à l'hôte de faire générer du texte par le LLM principal. Ouvrant la voie à des agents imbriqués : un serveur peut décomposer une tâche en sous-tâches déléguées au modèle. Encore expérimental, attendu en stable au troisième trimestre 2026.

Élicitation (elicitation)

Mécanisme standardisé pour qu'un serveur demande des informations à l'utilisateur en cours d'exécution (« Quelle adresse de livraison ? »). Évite les workflows qui échouent au milieu faute de paramètre. Stable depuis début 2026.

Registres officiels et signatures

Un registre officiel des serveurs MCP avec signatures cryptographiques (équivalent aux extensions VS Code signées) est en cours de spécification. Objectif : rassurer les équipes sécurité qui hésitent à autoriser l'installation de serveurs depuis npm ou GitHub directement.

SDK enterprise

Les SDK Java (Spring AI), C# (.NET), et Kotlin sont arrivés en 2025-2026 et étendent la couverture aux SI traditionnels. Le SDK Java en particulier débloque l'adoption dans les grandes banques et les ETI industrielles.

Convergence avec l'A2A (Agent-to-Agent)

Google a publié en 2025 le protocole A2A pour la communication entre agents. Les deux protocoles sont complémentaires : MCP standardise l'accès d'un agent à des outils, A2A standardise la collaboration entre agents. La convergence (passerelles, vocabulaire commun) est attendue en 2026-2027.

L'inflexion stratégique majeure de 2026 est l'adoption par OpenAI du protocole côté ChatGPT Desktop et Responses API, annoncée fin 2025. Combinée à l'adoption par Microsoft Copilot et Google Gemini, elle scelle le statut de standard de fait du protocole, là où le risque de fragmentation existait encore en 2024.

Mise en oeuvre dans une PME ou ETI

Pour une équipe qui veut déployer MCP en production en 2026, voici l'approche recommandée par notre équipe.

Phase 1 — Pilote interne (2 à 4 semaines)

Choisir un cas d'usage à fort ROI et faible risque : par exemple un copilot Claude Desktop pour l'équipe support, branché sur Zendesk en lecture, Confluence en lecture, et un canal Slack en écriture après confirmation. Utiliser des serveurs officiels existants, pas de développement custom. Mesurer le temps gagné sur les premiers tickets traités.

Phase 2 — Sécurisation et gouvernance (4 à 8 semaines)

Mettre en place : un processus de validation des serveurs MCP par l'équipe sécurité, un compte applicatif dédié par serveur (jamais de compte personnel admin), OAuth utilisateur systématique, journalisation centralisée vers le SIEM, politique de scopes minimaux documentée. C'est la phase qui décide si l'usage scale ou reste un PoC.

Phase 3 — Serveurs MCP custom (selon besoin)

Quand un outil interne (ERP maison, base PIM, application métier) doit être exposé au copilot, développer un serveur MCP dédié. Compter 5 à 15 jours.homme pour un serveur de complexité moyenne, en utilisant le SDK Python ou TypeScript. La spec étant stable, le risque d'obsolescence est faible.

Phase 4 — Déploiement multi-équipe

Industrialiser : packaging des configurations MCP (fichiers de config Claude Desktop, registry interne d'équipe), formation des utilisateurs, dashboards d'usage. C'est aussi le moment d'évaluer une plateforme d'orchestration (n8n, Inngest, Temporal) pour les workflows agentiques qui dépassent la session interactive.

Pour un accompagnement de bout en bout sur ces phases, contactez l'équipe Genee.

FAQ — MCP (Model Context Protocol) : guide entreprise 2026

MCP est-il réservé à Claude et à Anthropic ?

Non. MCP est un standard ouvert publié sous licence MIT. ChatGPT Desktop, Microsoft Copilot, Google Gemini, Cursor, Zed, Replit, Continue.dev et de nombreux autres hôtes l'implémentent en 2026. Un serveur MCP écrit aujourd'hui fonctionne avec n'importe quel hôte conforme, indépendamment du modèle sous-jacent.

Quelle différence concrète entre MCP et le function calling classique ?

Le function calling est l'API entre une application et un modèle (le modèle décide d'appeler une fonction). MCP est l'API entre un hôte et un outil externe (l'hôte expose les outils au modèle). Les deux coexistent : un hôte MCP utilise le function calling en interne pour faire dialoguer le LLM avec ses tools, mais ajoute la portabilité multi-modèle et la séparation tools / resources / prompts.

Faut-il développer ses propres serveurs MCP ou utiliser les serveurs publics ?

Les deux. Pour les SaaS standards (Slack, Notion, GitHub, Postgres, Google Drive), utilisez les serveurs officiels publiés par les éditeurs ou par Anthropic, qui sont audités, signés et maintenus. Développez un serveur custom uniquement pour vos outils internes ou pour exposer une vue spécifique d'un outil (par exemple un serveur Postgres dédié à votre data warehouse avec gouvernance intégrée).

MCP est-il sécurisé pour des données sensibles ?

MCP fournit les bons primitives (OAuth 2.1, scopes, consentement utilisateur, journalisation) mais la sécurité dépend de l'implémentation. Pour des données sensibles, exigez : serveurs MCP audités, comptes applicatifs en moindre privilège, tool gating systématique sur les écritures, journalisation SIEM, et déploiement sur infrastructure interne plutôt que SaaS tiers. Le protocole ne dispense pas du travail classique de sécurisation des intégrations.

Un serveur MCP peut-il accéder à internet librement ?

Un serveur MCP est un programme normal qui peut faire ce que vous lui permettez. C'est à vous de le sandboxer si nécessaire (conteneur, network policy, firewall sortant) et de n'autoriser que les serveurs dont vous avez audité le code. Le protocole ne contraint pas les capacités du serveur, il standardise seulement l'interface avec l'hôte.

Quelle est la différence entre stdio et HTTP streamable, et lequel choisir ?

stdio convient aux serveurs locaux qui tournent sur la machine de l'utilisateur (filesystem, Git local, base SQLite, outils CLI) : pas de réseau, pas d'authentification réseau. HTTP streamable convient aux serveurs centralisés exposés en SaaS ou sur un cluster Kubernetes : accessible à toute l'équipe, intégration avec OAuth et API Gateway. Un déploiement entreprise typique combine les deux.

Combien coûte la mise en place d'un serveur MCP custom ?

Un serveur MCP de complexité moyenne (3 à 8 tools, authentification OAuth, journalisation) prend 5 à 15 jours.homme avec le SDK Python ou TypeScript. Un serveur simple en lecture seule sur une API REST existante peut être fait en 2 à 3 jours. Le ratio coût / réutilisabilité est excellent puisque le serveur fonctionnera ensuite avec tous les hôtes MCP, présents et futurs.

MCP remplace-t-il les agents et les workflows n8n ou LangChain ?

Non, ils sont complémentaires. MCP est la couche d'intégration entre LLM et outils. n8n, LangChain, LangGraph, Inngest ou Temporal sont des couches d'orchestration : ils définissent comment plusieurs étapes (incluant des appels MCP) s'enchaînent, gèrent les états longs, les retries, les humains dans la boucle. En 2026, n8n consomme nativement des serveurs MCP comme sources d'outils.

Quels sont les principaux risques avec MCP en production ?

Trois risques dominants : (1) la prompt injection via les resources lues par l'agent, mitigée par tool gating sur les écritures ; (2) le confused deputy quand un serveur agit avec ses propres droits plutôt que ceux de l'utilisateur, mitigé par OAuth utilisateur systématique ; (3) l'installation de serveurs MCP non audités depuis l'écosystème community, mitigée par un processus de validation sécurité avant mise en production.

MCP est-il stable et faut-il l'adopter dès maintenant ?

La spec a atteint la maturité production en 2025 et bénéficie en 2026 d'une adoption multi-éditeur (Anthropic, OpenAI, Microsoft, Google) qui élimine le risque de fragmentation. C'est le bon moment pour démarrer un pilote sur un cas d'usage interne à fort ROI. Les équipes qui attendent 2027 prendront du retard sur celles qui auront industrialisé leur stack MCP au cours de l'année.