MCP : comment l’intégrer et ce que ça change

Table des matières

MCP : le connecteur standard pour agents et outils

MCP s’impose comme le connecteur générique entre modèles et systèmes métier. Conçu par Anthropic et open-sourcé fin 2024, il standardise la façon dont un assistant IA découvre des outils, sollicite des autorisations, exécute des actions et reçoit des résultats structurés. L’adoption s’accélère en 2025, poussée par OpenAI, des IDE et des éditeurs d’outils. L’enjeu business est direct : industrialiser vos agents IA sans écrire des intégrations ad hoc pour chaque application.

Un protocole client-serveur pour brancher modèles et systèmes

Techniquement, MCP reprend une architecture client‑serveur inspirée du Language Server Protocol : une application hôte (l’assistant IA) charge un client MCP qui se connecte à un ou plusieurs serveurs MCP. Chaque serveur expose des capacités normalisées : liste d’outils exécutables, prompts préparés, ressources, éventuellement accès à des fichiers ou bases. Les échanges utilisent JSON-RPC 2.0 comme standard de message, ce qui garantit une interface cohérente et testable. Côté transport, le protocole supporte STDIO pour les exécutions locales, HTTP avec Server-Sent Events (SSE) et un mode Streamable HTTP pour le streaming d’événements et de sorties, utile pour les opérations interactives et l’observation en temps réel. Voir la description synthétique du protocole et des transports dans la documentation de Descope et l’Agents SDK d’OpenAI ( récap technique, référence SDK ).

La séquence type se déroule ainsi : l’assistant produit une intention d’outil après le raisonnement du modèle ; le client MCP traduit cette intention en appel JSON-RPC vers le serveur ciblé ; le serveur authentifie la requête, exécute l’action sur l’API métier sous-jacente et renvoie un résultat structuré (souvent avec un canal de streaming pour la progression ou des sorties partielles). MCP définit également le concept d’élicitation, où un serveur peut initier une interaction utilisateur pour obtenir un consentement ou des paramètres manquants ; la spécification inclut un schéma d’autorisation OAuth, bien que des ajustements soient en cours pour aligner les détails d’implémentation avec les pratiques d’entreprise. Anthropic présente MCP comme une sorte de USB-C pour les assistants : un port universel pour brancher n’importe quelle app ou donnée de manière sécurisée et bidirectionnelle ( introduction officielle ).

Par rapport aux intégrations « plugins » historiques ou aux appels API directs depuis un orchestrateur d’agents, MCP apporte une normalisation au niveau du contrat d’échange, de l’élicitation et de la surface de sécurité. Au lieu de développer des connecteurs spécifiques à un LLM ou à un framework d’agents, l’équipe platform écrit un serveur MCP une fois, puis l’expose à plusieurs hôtes compatibles (Claude Desktop, Agents OpenAI, IDE, etc.). Cette couche de compatibilité limite le verrouillage technologique et facilite la gouvernance, notamment via un registre. Un MCP Registry ouvert est en préview depuis septembre 2025 pour indexer et découvrir des serveurs, avec un modèle de gouvernance formel et un processus SEP (Specification Enhancement Proposal) pour faire évoluer la spécification.

Au niveau des capacités opérationnelles, la spécification évolue vers des opérations asynchrones, la statelessness pour mieux scaler, l’identité serveur robuste et des extensions officielles. La roadmap confirme le support des opérations longues avec reconnexion, des guides de sécurité et des alternatives à l’enregistrement dynamique d’applications OAuth, ainsi que la multimodalité (vidéo, messages multipart, communication bidirectionnelle) ( feuille de route publique ). Cela signifie que des cas d’usage plus lourds, comme des traitements de build longs ou des analyses data différées, seront nativement supportés, sans bricolages côté transport.

Pratiquement, les serveurs MCP peuvent aussi exposer des prompts préconfigurés (list_prompts et get_prompt) et des options de cache côté client (cache_tools_list) pour réduire la latence sur des serveurs distants, comme documenté par l’Agents SDK d’OpenAI ( fonctions « prompts » et cache ). Ces détails sont importants pour la performance perçue par l’utilisateur final et la stabilité des expériences.

Du support client à la R&D : déploiements réels

L’écosystème des serveurs MCP est déjà riche et couvre de nombreux outils du quotidien. On trouve des connecteurs pour Slack, GitHub, Gmail, Google Drive, PostgreSQL, Docker, Discord ou HubSpot, ainsi que des moteurs de recherche vectorielle comme Chroma et des bases comme ClickHouse. Le top 10 de 2025 recense notamment Chroma, GreptimeDB, Semgrep pour le scan de code, Octagon pour les données financières, Appwrite, JFrog, Gmail et Terraform, témoignant de la diversité des cas couverts dans l’ingénierie, la sécurité et les opérations ( panorama serveurs ). Certains serveurs communautaires très utilisés, comme Slack, affichent des indicateurs d’adoption notables : plus de 30 000 ingénieurs visitent chaque mois le dépôt GitHub d’un des serveurs populaires et plus de 9 000 utilisateurs actifs s’y connectent régulièrement ( statistiques projet ).

Côté entreprises, les cas d’usage déjà documentés montrent des gains significatifs. Block a bâti un agent interne « Goose » reposant sur MCP qui réduit jusqu’à 75 % le temps passé sur des tâches d’ingénierie quotidiennes. Bloomberg rapporte une accélération du déploiement d’agents, passée de quelques jours à quelques minutes. Amazon tire parti de MCP à large échelle grâce à une culture API-first : la plupart de ses outils internes ont déjà ajouté un support MCP, facilitant la construction d’agents transverses ( retours d’expérience ). Dans l’ingénierie logicielle, l’intégration avec les IDE simplifie la revue de code, la navigation de bases, l’exécution de commandes CI/CD et le débogage assisté. VS Code, GitHub, Zapier et des services CI/CD comme Bitrise et CircleCI ont annoncé leur support entre janvier et avril 2025, tandis que Cursor, Windsurf, Zed, Neovim et Cline intègrent également MCP ; JetBrains a communiqué sur un support à venir, ce qui ouvre la voie à une quasi-omniprésence dans les outils de développement ( panorama adoption ).

Dans les fonctions support, des agents connectés via MCP peuvent consulter un dossier client dans le CRM, résumer un échange Slack et créer un ticket Jira en une seule conversation, sans multiplier les intégrations spécifiques. En data, l’accès unifié à une base vectorielle pour le RAG, à une base analytique et à un stockage d’objets permet d’industrialiser les assistants d’analyse. En finance, des connecteurs comme Octagon pour les données de marché et ClickHouse pour l’analytique facilitent la création d’agents de recherche et de surveillance. Dans l’IT, le pilotage d’infrastructures via Terraform et Docker, associé à des gardes fous, devient opérationnel au sein d’un protocole unique. Et pour des cas plus éditoriaux ou marketing, Gmail et Drive simplifient la création de contenus, le résumé d’échanges et l’orchestration de campagnes, avec la possibilité de mettre sous contrôle la diffusion via OAuth.

L’écosystème outillage s’étoffe aussi côté « builders ». L’Agent Builder d’OpenAI propose des nœuds visuels « Agent », « MCP » et « Guardrail » pour assembler un agent et le connecter à des serveurs MCP en drag-and-drop ( guide pas à pas ). Des agrégateurs comme Rube MCP annoncent des connexions dynamiques vers des centaines d’applications. Côté desktop, Claude Desktop inclut un environnement Node.js embarqué pour exécuter des serveurs MCP locaux sans prérequis système additionnel, et la mécanique d’extensions desktop facilite l’installation en un clic pour les cas personnels ou « team sandbox » ( documentation Claude Desktop ).

Réduction des coûts d’intégration et gains de vélocité mesurés

L’intérêt économique de MCP repose sur trois leviers. Le premier concerne les coûts de développement : on écrit un serveur MCP une fois, puis on le réutilise dans plusieurs hôtes et avec différents LLMs. Cela réduit la dispersion des connecteurs et l’entretien de wrappers spécifiques à chaque plateforme. Le second levier est la vélocité de déploiement : les retours de Bloomberg indiquent un passage de quelques jours à quelques minutes pour mettre en ligne de nouveaux agents, grâce à l’uniformisation du contrat d’intégration ( témoignages entreprise ). Le troisième levier concerne la qualité opérationnelle : Block annonce jusqu’à 75 % de temps gagné sur des tâches d’ingénierie quotidiennes avec un agent interne à architecture MCP, ce qui se traduit en réduction des lead times et du temps de cycle.

Au-delà des gains directs, MCP améliore la gouvernance. Un registre central des serveurs MCP, public et privé, permet de contrôler à qui on expose quoi, avec versionnement, signatures et règles d’admission. La préview du MCP Registry prévoit d’ailleurs des sous-registres pour isoler les périmètres et distribuer la propriété des connecteurs dans l’organisation ( annonce registre et gouvernance ). Sur la sécurité, l’uniformisation du flux d’autorisation et des élicitation interactions rend auditable la prise de décision d’un agent et diminue les « zones grises » entre l’assistant et les API métiers. Les clients MCP peuvent exposer à l’utilisateur les requêtes de complétion, permettre de modifier ou rejeter les propositions, filtrer des sorties, imposer des timeouts et un contrôle de coûts, et choisir les modèles utilisés pour l’exécution, autant de leviers de « guardrails » indispensables en contexte entreprise ( analyse sécurité Red Hat ).

Déployer MCP : du POC à la production en 3 phases

La mise en œuvre réussie de MCP suit une trajectoire claire. La phase POC vise à valider la valeur métier avec un setup minimal. Choisissez un hôte compatible (Claude Desktop ou l’Agent Builder d’OpenAI) pour illustrer une chaîne de bout en bout ; installez un serveur MCP pour un outil très fréquent (Slack, GitHub, CRM) et implémentez deux ou trois scénarios « heure » ciblant une équipe pilote. Côté développement, l’environnement Node embarqué de Claude Desktop supprime les frictions locales et permet de tester rapidement, tandis que les nœuds visuels de l’Agent Builder accélèrent la mise en scène. Mesurez des indicateurs simples : temps de réalisation d’une tâche, taux de succès, feedback qualité, coûts de tokens.

La phase « service MCP » consiste à passer du plugin de bureau à un service multi-locataires géré par l’équipe plateforme. Le serveur MCP doit être stateless autant que possible, s’exécuter derrière une passerelle API d’entreprise, s’authentifier via OAuth et implémenter des journaux centralisés. Le transport HTTP SSE convient bien à l’observabilité et au déploiement cloud. Définissez un modèle d’entitlements qui relie scopes OAuth, actions et ressources internes, avec un moteur d’autorisation externe pour éviter le code spaghetti dans les serveurs MCP. Cerbos, par exemple, permet de combiner RBAC, ABAC et PBAC pour exprimer des permissions contextuelles (un manager approuve les dépenses de son équipe, un auditeur lit sans écrire, un bot ne peut agir que dans un espace Slack précis) et évite le piège de règles codées en dur peu évolutives ( guide Cerbos sur MCP ). Prévoyez en parallèle un inventaire des serveurs approuvés, avec vérification d’intégrité et signature, la possibilité d’épingler des versions et des alertes en cas de changement.

La phase « production gouvernée » généralise la pratique et la met sous contrôle. Déployez un registre interne (ou sous-registre) pour référencer les serveurs autorisés, associez chaque serveur à un dossier technique (C4, menaces, scopes, points de contrôle), et à des métriques d’usage. Élaborez des playbooks de sécurité MCP : principe de moindre privilège, tokens de courte durée, scopes minimaux, consentement explicite lors de l’enregistrement dynamique, secrets centralisés et scannés, limite de taux et timeouts, budget coûts par serveur, comme le recommande la littérature de bonnes pratiques ( synthèse sécurité MCP ). Côté vulnérabilités, intégrez serveurs et clients MCP dans le cycle standard de patch management, exigez la possibilité d’émettre des logs vers votre SIEM et de fixer des versions, et donnez à l’utilisateur un contrôle visible sur les complétions et les modèles utilisés, conformément aux recommandations de Red Hat ( contrôles de sampling et gouvernance ).

Deux aspects méritent une attention particulière. Le premier est l’élicitation sécurisée, où un serveur initie une demande de consentement ou de paramètres directement auprès de l’utilisateur : pour l’éviter d’ouvrir la porte à des abus, prévoyez un filtrage et des modèles d’UI établis, avec vérification de l’identité serveur et des scopes demandés. Le second est le risque de confused deputy : un utilisateur pourrait obtenir, via un serveur MCP, un accès qu’il ne possède pas en direct. Mitigez avec une liaison stricte du token utilisateur au serveur et à l’audience cible, un contrôle d’autorisations au niveau ressource et des preuves d’autorisation attachées aux appels sortants, comme le recommandent les analyses de risques ( analyse Red Hat et risques top 10, synthèse risques ).

Maturité du protocole et dépendances : les angles morts

Le protocole évolue encore : une release candidate est planifiée au 11 novembre 2025 avec une période de validation de 14 jours et une version finale au 25 novembre ; certains aspects (opérations asynchrones, identité serveur, extensions officielles) sont en cours de stabilisation, ce qui impose un suivi de version rigoureux ( roadmap et calendrier ).
Le schéma d’autorisation OAuth dans la spécification comporte des divergences avec les pratiques d’entreprise ; des correctifs sont en discussion et l’adoption passera par des choix d’implémentation prudents, voire des alternatives à l’enregistrement dynamique (DCR) ( défis d’entreprise ).
La découverte et l’onboarding des serveurs MCP restent un point de friction : le registre public est en préview ; prévoyez un registre privé et des processus d’admission si vous déployez à l’échelle ( gouvernance du registre ).
Les « serveurs » communautaires sont souvent conçus pour des cas desktop ; en entreprise, il faut des « services MCP » multi-locataires, observables et sécurisés, avec une chaîne CI/CD et du support.
Surface d’attaque accrue : prompt injection, tool poisoning, privilege abuse, SQL/command injection, rug pull, denial of wallet/service et contournement d’authentification nécessitent des contrôles systématiques (validation d’entrées, sandbox, politiques d’autorisation, limite de taux) ( top 10 risques ).
Les environnements réglementés très sensibles peuvent exiger des garanties que MCP n’apporte pas encore nativement (vérification forte de l’identité serveur, évidences d’audit signées, contrôles offline). Dans ces cas, des intégrations API directes fortement contraintes peuvent rester préférables.
Le support multimodal et des opérations longues est en chantier ; si vos parcours dépendent fortement de ces capacités, cadrez des workarounds à court terme et évaluez les risques de dette technique.

MCP en production : ce qu’il faut retenir pour décider

Pour les organisations avec plusieurs LLMs, des dizaines d’outils SaaS et une volonté de déployer des agents de façon gouvernée, MCP apporte une réponse structurante : un contrat unique qui réduit le coût d’intégration, augmente la vélocité et améliore la sécurité par la standardisation. L’adoption par OpenAI dans son Agents SDK et l’écosystème d’IDEs conforte sa pérennité, tandis que les études de cas d’entreprise valident les gains d’efficacité. La démarche recommandée consiste à prototyper rapidement des scénarios à forte valeur, à élever un « service MCP » multi-locataires avec une autorisation fine-grained et une observabilité standard, puis à industrialiser via un registre privé et des playbooks sécurité. Enfin, compte tenu de la dynamique de la spécification, prévoyez un pilotage de versions et un monitoring des évolutions de la roadmap. Si votre priorité est la vitesse de déploiement d’agents connectés avec gouvernance centrale, MCP est aujourd’hui le candidat le plus pragmatico-opérationnel.