MCP (Model Context Protocol) : le standard qui unifie les agents IA en 2026

#Qu'est-ce que MCP et pourquoi tout le monde en parle

Anthropique a publié le Model Context Protocol (MCP) en novembre 2024 avec un objectif précis : mettre fin à la fragmentation des intégrations entre agents IA et systèmes d'entreprise. Avant MCP, chaque fournisseur de modèle de langage (LLM) avait son propre mécanisme de connexion aux outils externes. OpenAI proposait le function calling, LangChain ses propres abstractions de tools, LlamaIndex ses query engines — et les connecteurs n'étaient pas interopérables.

Le résultat : une équipe qui migrait d'un modèle à un autre devait réécrire tous ses connecteurs. Une équipe qui testait plusieurs modèles en parallèle maintenait plusieurs bases de code d'intégration. C'est le problème que MCP résout à la racine en définissant un protocole de communication universel, indépendant du modèle.

L'adoption a été rapide. En mars 2025, OpenAI a annoncé le support natif de MCP dans son API et ses SDK. Google a intégré MCP dans Gemini API. Mistral a suivi pour son écosystème d'outils. En juin 2026, MCP est le standard sur lequel s'alignent tous les frameworks d'orchestration d'agents IA majeurs — LangChain, LlamaIndex, AutoGen, CrewAI.

#Architecture MCP : Host, Client, Server, Transport

#Les trois rôles fondamentaux

L'architecture MCP distingue trois rôles avec des responsabilités précises :

Host : c'est l'application qui contient ou pilote l'agent IA. L'IDE de développement, le chatbot d'entreprise, la plateforme d'automatisation. Le Host crée et gère des Clients MCP, et c'est lui qui contrôle les permissions accordées aux Servers.

Client : composant à l'intérieur du Host qui maintient une connexion 1:1 avec un Server MCP. Le Client envoie des requêtes (liste des outils disponibles, exécution d'un outil, lecture d'une ressource) et reçoit les réponses.

Server : processus exposant des capacités via le protocole MCP. Un Server peut exposer trois types de primitives :

• Tools : fonctions exécutables par le LLM (rechercher un contact dans Salesforce, créer un ticket Jira, lire une métrique Datadog)
• Resources : données accessibles en lecture (un fichier, une entrée de base de données, un flux d'événements)
• Prompts : templates de prompt prédéfinis que le LLM peut appeler pour des tâches récurrentes

#Les deux modes de transport

MCP définit deux mécanismes de transport :

stdio (Standard Input/Output) : le Client lance le Server comme un sous-processus local et communique via stdin/stdout. C'est le mode privilégié pour les outils locaux — accès au système de fichiers, exécution de commandes, interaction avec des SDK installés localement. Simple à déployer, sans configuration réseau, mais limité à la même machine.

SSE (Server-Sent Events) : communication HTTP où le Server pousse des événements au Client via une connexion persistante. Adapté aux Servers distants accessibles via réseau — API SaaS, services cloud, microservices d'entreprise. Permet le déploiement de MCP Servers centralisés accessibles par plusieurs Hosts en parallèle.

La spécification officielle prévoit également Streamable HTTP, une évolution de SSE pour les déploiements à grande échelle avec reconnexion automatique et multiplexage de sessions.

#Comment MCP résout le problème des intégrations agent IA en entreprise

Avant MCP, connecter un agent IA à un système d'entreprise nécessitait :

1. Écrire des wrappers spécifiques au format du LLM utilisé (OpenAI function definitions, Anthropic tool use, Gemini function calling)
2. Maintenir ces wrappers synchronisés avec les évolutions de l'API du LLM
3. Réécrire si on changeait de modèle ou si on testait plusieurs modèles en A/B
4. Gérer manuellement la sérialisation des données, la gestion des erreurs et les timeouts

Avec MCP, le schéma devient :

1. Un MCP Server est écrit une fois pour un système donné (Salesforce, SAP, Jira...)
2. Ce Server est réutilisable par n'importe quel Host MCP-compatible, quel que soit le LLM
3. La maintenance se concentre sur le Server (interface avec le système cible), pas sur les connecteurs modèle

C'est l'équivalent de ce qu'USB a fait pour les périphériques : un standard unique qui rend l'infrastructure d'intégration indépendante du fournisseur de modèle.

#MCP vs OpenAPI, LangChain tools et function calling classique

#MCP vs Function Calling natif

Le function calling (OpenAI, Anthropic, Gemini) permet à un LLM d'appeler des fonctions définies dans le prompt. C'est efficace pour des cas simples, mais chaque fonction est définie dans le format propriétaire du fournisseur et les définitions ne sont pas portables. MCP standardise ces définitions dans un protocole universel avec un mécanisme de découverte dynamique : le Client interroge le Server pour obtenir la liste de ses outils à la volée, sans configuration statique.

#MCP vs OpenAPI

OpenAPI décrit des APIs HTTP de manière standardisée — mais c'est une spécification de documentation, pas un protocole de runtime. OpenAPI ne gère pas la découverte dynamique, ne définit pas le cycle de vie des sessions, et n'inclut pas de mécanisme de sécurité pour les agents. Un MCP Server peut être généré automatiquement depuis un schema OpenAPI (des outils comme openapi-mcp-server le font), mais MCP va plus loin avec la gestion des ressources, des prompts et des sessions persistantes.

#MCP vs LangChain Tools

Les tools LangChain sont des objets Python avec une méthode run() et une description textuelle. Ils fonctionnent uniquement dans l'écosystème LangChain, ne sont pas accessibles à des Hosts externes, et n'ont pas de mécanisme de transport réseau standardisé. Un MCP Server exposé en SSE est accessible depuis n'importe quel Host compatible — Claude Desktop, un agent LangChain, un agent AutoGen — sans modification du Server.

#Cas d'usage B2B : MCP dans les systèmes d'entreprise

#CRM : Salesforce et HubSpot

Les MCP Servers pour CRM exposent les objets Salesforce (Account, Contact, Opportunity, Case) et HubSpot (Companies, Contacts, Deals) comme des primitives Tools et Resources. Un agent IA peut :

• Récupérer le pipeline commercial d'un commercial pour préparer un compte-rendu de réunion
• Créer ou mettre à jour des opportunités à partir d'emails analysés
• Interroger l'historique client pour contextualiser une réponse support

Le MCP Server Salesforce officiel (disponible sur le registre GitHub MCP) gère l'authentification OAuth2 et expose les objets via SOQL. Les permissions sont granulaires : un agent de support peut lire les Cases sans avoir accès aux données financières.

#ERP : SAP et Oracle

Les ERP sont historiquement les systèmes les plus difficiles à intégrer. MCP ne supprime pas la complexité fonctionnelle, mais standardise la couche d'accès. Un MCP Server SAP peut exposer :

• Les stocks et disponibilités produit (pour un agent commercial)
• Les statuts de commandes (pour un agent support)
• Les données fournisseurs (pour un agent achats)

L'architecture recommandée pour SAP est un MCP Server intermédiaire qui appelle les APIs OData SAP (S/4HANA expose des OData nativement depuis la version 1909), avec un layer de contrôle d'accès calqué sur les rôles SAP existants.

#Ticketing : Jira et ServiceNow

Jira est l'un des MCP Servers les plus déployés en entreprise. Les cas d'usage sont nombreux : créer des tickets depuis des logs d'erreur détectés par un agent de monitoring, enrichir des issues avec des analyses de code, faire des rapports de sprint en langage naturel. Le MCP Server Jira officiel expose les Boards, Sprints, Issues et Transitions comme Tools — y compris la création et la mise à jour d'issues avec assignee et priority.

#Monitoring et observabilité

Datadog, Grafana et PagerDuty ont publié des MCP Servers qui exposent les métriques, les alertes et les runbooks. Un agent IA de niveau 1 peut interroger ces Servers pour diagnostiquer automatiquement une alerte : récupérer les métriques des 30 dernières minutes, croiser avec les déploiements récents, et décider d'escalader ou de résoudre automatiquement selon un arbre de décision.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Créer son propre MCP Server en entreprise : les étapes techniques

Le SDK officiel MCP est disponible en TypeScript et Python. Voici les étapes d'un déploiement MCP Server d'entreprise :

Étape 1 — Définir le périmètre fonctionnel. Quels outils le Server doit-il exposer ? Quelle granularité ? La règle : un Tool par action atomique, pas de Tools monolithiques qui font «tout». Exemple pour un CRM : un Tool get_contact, un Tool list_opportunities, un Tool create_note — pas un Tool crm_query fourre-tout.

Étape 2 — Implémenter le Server avec le SDK. En Python, le SDK mcp permet de déclarer des Tools avec le décorateur @server.tool() et des Resources avec @server.resource(). Chaque Tool a un nom, une description (texte que le LLM utilise pour décider quand l'appeler), et un schema JSON des paramètres d'entrée.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

Étape 3 — Choisir le mode de transport. stdio pour un Server local (script Python lancé par le Host), SSE pour un microservice déployé sur Kubernetes, Cloudflare Workers ou AWS Lambda. Pour les déploiements d'entreprise multi-utilisateurs, SSE avec authentification OAuth2/OIDC est le standard.

Étape 4 — Sécuriser le Server. Un MCP Server doit valider chaque requête : authentification du Host, vérification des permissions par Tool, logging de chaque appel. Ne jamais exposer un MCP Server sans authentification — c'est un vecteur d'attaque direct sur les systèmes qu'il connecte.

Étape 5 — Référencer dans le registre interne. Les Hosts MCP (Claude Desktop, les IDEs, les plateformes d'agents) maintiennent un fichier de configuration listant les Servers disponibles. En entreprise, un registre MCP centralisé (fichier JSON ou service de découverte) évite la configuration manuelle sur chaque poste.

#Le registre MCP : découverte et gouvernance des Servers disponibles

Le registre officiel GitHub (modelcontextprotocol/servers) recense les MCP Servers validés par Anthropic et la communauté. On y trouve des Servers pour : filesystem local, Git, GitHub, GitLab, Slack, Google Drive, Postgres, SQLite, Brave Search, Puppeteer, AWS, et des dizaines d'autres.

En entreprise, ce registre public est un point de départ, pas une fin. Les organisations qui déploient MCP à grande échelle ont besoin d'un registre interne qui :

• Répertorie les MCP Servers internes (connecteurs aux systèmes propriétaires)
• Documente les permissions accordées par Server et par profil utilisateur
• Maintient les versions déployées et les changelogs
• Centralise les configurations d'authentification

Plusieurs éditeurs (y compris Cloudflare avec son Workers AI MCP Registry) proposent des solutions de registre managé. Pour les entreprises avec des contraintes de souveraineté, un registre self-hosted (fichier JSON versionné dans Git ou service de configuration type Vault) est préférable.

#Sécurité et gouvernance : les enjeux critiques en production

#Permissions granulaires

Chaque MCP Server doit implémenter un modèle de permissions calqué sur le principe du moindre privilège. Un agent de support client ne doit pas avoir accès aux Tools financiers du MCP Server ERP. Les permissions se définissent à deux niveaux : au niveau du Server (quels Tools sont exposés selon le profil d'authentification) et au niveau du Host (quels Servers sont accessibles à quel agent).

#Sandboxing des Servers

Un MCP Server malveillant ou compromis peut exécuter des actions arbitraires sur les systèmes connectés. Le sandboxing est critique : les Servers doivent s'exécuter dans des contextes isolés (containers, processus avec capabilities restreintes). Les Servers stdio doivent tourner avec les permissions minimales nécessaires. Les Servers SSE doivent être déployés derrière une API Gateway qui valide les tokens avant de router les requêtes.

#Audit trail

Chaque appel à un Tool MCP doit être loggé : quel Host, quel utilisateur, quel Tool, quels paramètres, quel résultat, à quelle heure. Ce n'est pas seulement une bonne pratique — c'est une exigence réglementaire pour les secteurs soumis à NIS2, DORA ou RGPD. Un audit trail MCP permettre de répondre à la question «quelle action un agent IA a-t-il effectuée sur quel système, à quelle heure, sur instruction de qui ?»

#Prompt injection via MCP

Une surface d'attaque spécifique à MCP : les Resources (contenu retourné par un Server) peuvent contenir des instructions malveillantes qui tentent de détourner le comportement de l'agent LLM — c'est la prompt injection via contexte externe. La mitigation passe par la validation du contenu des Resources avant injection dans le contexte du LLM, et par des instructions système qui interdisent au modèle de suivre des instructions trouvées dans les données récupérées.

#La position Nehos : MCP comme infrastructure d'intégration agents IA

Nehos considère MCP non pas comme un outil de plus à évaluer, mais comme l'infrastructure d'intégration de référence pour tout projet d'agents IA autonomes en 2026. La raison est simple : un agent IA qui ne peut pas accéder aux données et systèmes de l'entreprise ne crée pas de valeur.

Le vrai risque n'est pas d'adopter MCP trop tôt — c'est de construire des connecteurs propriétaires aujourd'hui qui seront à réécrire dans six mois quand l'entreprise voudra changer de modèle ou passer à un framework d'agents différent.

Pour les clients Nehos en phase de design d'architecture agent, notre recommandation systématique est de modéliser les intégrations comme des MCP Servers dès le départ. Cela prend légèrement plus de temps en phase initiale, mais réduit drastiquement le coût de maintenance et de migration sur 18 à 36 mois.

Cette approche s'articule avec notre stack LLMOps et gouvernance IA : un registre MCP versionné, des pipelines CI/CD pour les Servers, un monitoring des appels et une gestion des permissions calquée sur l'annuaire Active Directory de l'entreprise.

Pour les entreprises qui cherchent à enrichir leurs agents avec des données documentaires internes, MCP et Retrieval-Augmented Generation sont complémentaires : MCP gère l'accès aux systèmes transactionnels (actions, données structurées), RAG gère la recherche dans les corpus documentaires non structurés. Consultez notre article sur l'architecture RAG pour les données internes pour voir comment les deux s'articulent.

Vous trouverez des exemples concrets de déploiement MCP en production dans nos cas clients Nehos sur les agents IA.