Model Context Protocol (MCP) : connecter l'IA aux outils métier

Qu'est-ce que le Model Context Protocol (MCP) ?

Le Model Context Protocol (MCP) est un standard ouvert et open source, introduit par Anthropic en novembre 2024. Il normalise la façon dont les applications d'IA, notamment les grands modèles de langage (LLM), se connectent à des outils, des systèmes et des sources de données externes [11].

Une couche de standardisation entre l'IA et les services

IBM décrit le MCP comme une couche de standardisation. Elle permet aux applications d'IA de communiquer avec des services externes : outils, bases de données, modèles prédéfinis [12]. Le MCP n'est ni un modèle d'IA ni un logiciel métier. C'est un protocole, c'est-à-dire une convention d'échange commune entre l'assistant et les systèmes qu'il doit utiliser.

Mendix, éditeur de plateforme de développement, le définit de façon proche : un protocole open source qui permet aux applications d'IA de se connecter à des sources de données et à des outils externes, avec une promesse de sécurité [19]. Cette promesse est avancée par l'éditeur. Elle suppose une vérification dans chaque déploiement.

L'image de l'USB-C

Pour illustrer ce rôle, plusieurs acteurs commerciaux reprennent la comparaison avec l'USB-C.

• Red Hat présente le MCP comme un protocole unique et standardisé pour connecter une application d'IA à un système externe, et le compare à un câble USB-C qui relie un appareil à différents accessoires [1].
• NextStart.AI parle du « port USB-C de l'IA d'entreprise » [30].

L'analogie s'appuie sur la situation antérieure. Avant le MCP, chaque éditeur devait développer son propre connecteur pour chaque modèle, et chaque entreprise devait maintenir ces intégrations au fil des mises à jour [30]. Avec un port commun, un même outil peut en principe être branché à différents assistants sans développement spécifique.

L'image a ses limites : l'USB-C est une norme matérielle, alors que le MCP est un protocole logiciel. Les sections suivantes détaillent son fonctionnement, ses différences avec une API classique et les précautions à prendre pour un déploiement en entreprise.

Quel problème le MCP résout-il pour une entreprise ?

Le MCP résout d'abord un problème d'intégration : relier un modèle d'IA aux outils d'une entreprise exigeait autant de connecteurs sur mesure que de combinaisons modèle/outil. Avant le protocole, chaque éditeur devait développer son propre connecteur pour chaque modèle, et chaque entreprise devait maintenir ces intégrations à chaque mise à jour [30].

La « plomberie » qui se multiplie

La difficulté ne tenait pas tant à la capacité de raisonnement des modèles qu'à la plomberie nécessaire pour les brancher au système d'information. Cette plomberie se démultipliait à chaque nouvelle combinaison assistant/outil [21]. Beaucoup de projets d'IA reposaient jusque-là sur des intégrations faites à la main pour chaque couple modèle + outil [27]. Le calcul est simple : dix outils et trois assistants représentent potentiellement trente intégrations distinctes, à développer puis à maintenir. Le MCP répond à cet obstacle d'interopérabilité en proposant un protocole universel [10].

Des modèles qui ne connaissent que leur entraînement

Le second problème tient aux modèles eux-mêmes. Un grand modèle de langage (LLM) ne connaît en général que les données sur lesquelles il a été entraîné, et ces données peuvent vite devenir obsolètes [8]. Pour un usage professionnel, c'est une limite directe : un modèle seul ne sait rien de l'état d'un dossier client, d'un stock ou d'un ticket ouvert ce matin.

Le MCP s'attaque à cette limite en donnant aux modèles un accès structuré et évolutif aux données et aux outils dont ils ont besoin. Le contexte, issu des systèmes d'entreprise, est alors en temps réel et vérifiable [18]. Les réponses de l'IA s'appuient ainsi sur l'état courant des systèmes, et non plus seulement sur ce que le modèle a appris.

Ce que cela change pour une DSI

Le protocole ne rend pas les modèles plus « intelligents ». Il déplace l'effort : au lieu de réécrire des intégrations, les équipes techniques s'appuient sur une interface partagée entre l'IA et les outils.

Comment fonctionne le MCP concrètement ?

Le MCP repose sur une architecture client-serveur. Le client MCP émet des requêtes standardisées, et les serveurs MCP exposent les ressources de l'entreprise (bases de données, API, outils) via une interface unifiée [17].

Messages, rôles et authentification

Les échanges sont bidirectionnels [8][17] et passent par des messages JSON [17]. L'architecture s'appuie sur JSON-RPC 2.0 et sépare clairement trois rôles : l'hôte, le client et le serveur [27]. Le vocabulaire varie selon les sources. [17] désigne simplement par « client » le modèle d'IA, alors que [27] distingue l'hôte du client. Pour l'authentification, [17] indique que le protocole recourt à OAuth2. Ce point est issu d'une seule source du dossier, et il faut le confirmer dans la spécification officielle avant de figer une architecture.

Découverte dynamique des outils

Le modèle découvre lui-même les outils disponibles, sans liste codée en dur [17][26]. Cette découverte se fait à l'exécution : un outil ajouté sur un serveur devient instantanément accessible aux modèles connectés [35]. Côté DSI, enrichir un serveur suffit donc à étendre les capacités de l'assistant, sans retoucher chaque application cliente.

Workflows à plusieurs étapes

Cette architecture permet d'exécuter des workflows avec état et à plusieurs étapes, plutôt que des interactions requête-réponse isolées [9]. L'IA peut ainsi accéder aux bonnes données, au bon moment, et interagir avec les systèmes métiers comme le ferait un collaborateur [26].

Une spécification qui évolue

Une source mentionne une version de la spécification datée du 28 juillet 2026, qui introduirait un cœur « stateless » et des améliorations d'autorisation [13]. Ce point semble nuancer la notion de workflows avec état décrite plus haut [9]. Le dossier ne contient pas la spécification officielle, et [13] est un contenu de vulgarisation. Nous ne tranchons donc pas : avant tout développement, vérifiez la version en vigueur dans la documentation du protocole.

En quoi le MCP diffère-t-il d'une API ou d'un connecteur classique ?

Une API expose une fonction précise d'un outil, tandis que le MCP standardise le dialogue entre une IA et cet outil [23]. Les deux ne se situent pas au même niveau : l'API décrit ce qu'un logiciel sait faire, le protocole décrit comment un modèle d'IA y accède.

Ce que change le MCP par rapport à un connecteur classique

Un connecteur classique est écrit pour une paire précise, un modèle et un outil. Avant le MCP, chaque éditeur devait développer son propre connecteur pour chaque modèle, et chaque entreprise devait maintenir ces intégrations au fil des mises à jour [30]. Le MCP déplace ce travail à trois endroits :

• Normalisation de l'accès : le protocole uniformise la manière dont un modèle accède aux outils et aux données [5].
• Séparation des responsabilités : la logique métier, le modèle et l'infrastructure restent distincts [5].
• Réutilisation : un seul serveur MCP par outil peut servir toutes les applications d'IA de l'entreprise [15].

Selon une source éditoriale, un assistant peut alors lire et écrire dans le CRM, l'ERP, la messagerie ou l'agenda sans intégration spécifique [29]. Cette promesse est formulée par un acteur commercial et reste à valider sur chaque déploiement.

Une couche qui complète les API

Le MCP ne remplace pas les API. Dans l'architecture décrite, les serveurs MCP exposent des ressources (bases de données, API, outils) via une interface unifiée [17]. L'API reste donc le moyen d'accès à l'application, et le serveur MCP la rend exploitable par un modèle de façon standard. Pour un usage sans IA (échanges entre systèmes, traitements par lots), rien dans le dossier ne justifie de passer par le MCP.

Un point de méthode

Les formulations les plus tranchées de cette comparaison viennent de sources éditoriales ou commerciales : [23] pour la distinction entre API et MCP, [15] pour la réutilisation d'un serveur par toutes les applications d'IA. La description de la séparation entre logique métier, modèle et infrastructure [5] émane d'un éditeur de logiciels. Ces sources décrivent l'intention du protocole. Le gain réel dépend du nombre d'outils et d'assistants à relier, et la DSI doit le mesurer sur son propre périmètre.

Quels outils et cas d'usage peut-on connecter via MCP ?

Le Model Context Protocol vise en priorité les outils d'entreprise : CRM, Slack, Google Drive et bases de données [3]. Concrètement, un assistant IA peut lire et écrire dans ces outils, y compris l'ERP, la messagerie et l'agenda, sans intégration spécifique [29]. Cette capacité d'écriture, qui permet d'agir et pas seulement de consulter, appelle des précautions de droits d'accès, traitées plus bas dans cet article.

Les catégories d'outils concernées

Cas d'usage : une collectivité

Dans un assistant documentaire d'administration ou de collectivité, le MCP peut connecter un agent conversationnel à plusieurs sources internes [33]. La source en cite quatre types :

• les répertoires de fichiers ;
• les bases documentaires ;
• les outils de ticketing ;
• les bases de connaissances [33].

L'agent interroge ainsi ces ressources depuis une seule interface conversationnelle, au lieu que chacune exige son propre développement. Le texte, publié par la Banque des Territoires, présente le protocole comme une pièce de l'architecture d'IA d'entreprise, et non comme un simple détail technique [33].

Cas d'usage : l'industrie

Dans la fabrication, le MCP fournit aux modèles de langage le contexte dont ils ont besoin à partir des outils et systèmes que les fabricants utilisent déjà [6]. Le modèle n'a donc pas à s'appuyer sur un jeu de données séparé : il travaille avec les systèmes qui font tourner l'atelier. Cette source émane d'un acteur commercial, et ses formulations décrivent un potentiel plutôt qu'un résultat mesuré.

Ce qu'il faut retenir pour le cadrage

Ces deux cas partent du même principe : l'IA se branche sur des systèmes existants au lieu de les remplacer. Pour une DSI, la question de départ est donc moins « quel modèle choisir ? » que « quelles sources internes exposer, avec quels droits en lecture et en écriture ? ».

Le MCP est-il un standard réellement adopté ?

Le MCP est présenté comme adopté par les principaux fournisseurs d'IA, mais le dossier ne contient aucune source primaire (communiqué d'éditeur ou spécification officielle). Les faits ci-dessous viennent de sources secondaires, souvent commerciales, et certains restent à confirmer.

Ce que les sources recoupent

• Origine : le MCP est un standard ouvert introduit par Anthropic en novembre 2024 [11].
• OpenAI : l'adoption date de mars 2025 [29].
• Google et Microsoft : une agence de conseil indique que le MCP a été adopté par OpenAI, Google et Microsoft en 2025 [16]. Le dossier ne donne pas de date précise pour Google ni pour Microsoft.
• Écosystème : le projet publie des serveurs de référence (systèmes de fichiers, bases PostgreSQL, recherche web) et un registre officiel recense les serveurs disponibles. Des annuaires communautaires en listent des milliers d'autres, du connecteur de base de données aux outils métier de niche [31]. Cette description vient d'un guide pratique rédigé par une agence, sans décompte précis.

Ce qui reste à vérifier

Sur la spécification, la source n'indique que ces deux évolutions [13]. Si elles se confirment, elles concerneront la gestion de l'état et l'autorisation, deux points à examiner avant tout déploiement. Il faut donc lire la version en vigueur sur la spécification officielle avant de fixer une architecture.

Sur la prévision Gartner, la chaîne de transmission compte deux intermédiaires. Elle porte aussi sur les agents IA et non sur le MCP lui-même : c'est Divalto qui affirme que le MCP est le protocole sur lequel ces agents s'appuient pour accéder aux données [32]. Elle donne un ordre de grandeur, pas une mesure de l'adoption du protocole.

En pratique, l'adoption par les grands fournisseurs et la taille de l'écosystème sont bien attestées. Les versions précises de la spécification et les chiffres de marché doivent être vérifiés auprès des sources primaires.

Le MCP est-il sûr ? Quelles précautions pour la DSI ?

Le MCP est présenté comme un moyen sûr de connecter l'IA aux systèmes d'entreprise, mais les sources disponibles décrivent cette promesse sans la démontrer. La sécurité d'un déploiement dépend donc de sa propre analyse de risques.

Ce que disent les sources

Plusieurs sources associent le MCP à une connexion sécurisée. Proofpoint le décrit comme une norme ouverte permettant aux modèles de se connecter « en toute sécurité » à des sources de données et des systèmes externes [2]. Mendix parle de connexion « de manière sécurisée » [19]. Digitalkin le qualifie de standard « fiable, portable et traçable » [34]. Kiteworks, éditeur spécialisé en sécurité, fait de la sécurité de l'IA un enjeu central du protocole [7].

Ces affirmations sont majoritairement éditoriales. Elles émanent d'acteurs commerciaux, dont certains vendent des produits de sécurité ou de développement. Il faut les lire comme des positionnements, pas comme des résultats d'audit.

Ce que le dossier ne permet pas d'affirmer

Le dossier ne détaille aucun risque précis du MCP, ne chiffre aucune vulnérabilité et ne documente aucun incident. On ne peut donc ni conclure que le protocole est sûr par construction, ni dresser un inventaire de ses failles. Une source décrit des échanges en messages JSON avec une authentification OAuth2 [17]. Une autre mentionne des « améliorations d'autorisation » dans une version de la spécification datée 2026-07-28 [13]. Cette date est surprenante et doit être vérifiée dans la spécification officielle avant toute décision.

Trois points à instruire avant chaque déploiement

La DSI peut cadrer l'analyse autour de trois axes :

• Authentification : comment le client MCP et chaque serveur s'identifient, et comment les accès sont accordés et révoqués.
• Périmètre des droits : ce que l'assistant peut lire et, surtout, écrire dans chaque outil. Les sources indiquent qu'un assistant peut agir dans des outils métier comme un CRM ou un ERP [29], ce qui rend ce périmètre déterminant.
• Traçabilité : la capacité à reconstituer quelles actions ont été déclenchées, par qui et avec quelles données. La mention de traçabilité reste à vérifier sur le déploiement réel [34].

Cette analyse doit porter sur chaque serveur MCP retenu, qu'il vienne d'un éditeur, d'un annuaire communautaire ou d'un développement interne.

Comment mettre en œuvre le MCP, et où se situe Oupi ?

Une entreprise dispose de trois voies pour mettre en œuvre le MCP : réutiliser des serveurs existants, développer ses propres serveurs, ou s'appuyer sur une agence ou une formation. Ces voies peuvent se combiner.

1. Utiliser des serveurs existants. Le projet MCP publie des serveurs de référence (systèmes de fichiers, bases PostgreSQL, recherche web). Un registre officiel recense les serveurs disponibles, et des annuaires communautaires en listent des milliers d'autres, du connecteur de base de données au pilotage d'outils métier de niche [31]. C'est le point de départ le plus rapide pour les outils courants. Le dossier ne précise pas comment les annuaires communautaires sont vérifiés : une revue technique et de sécurité avant tout usage s'impose.

2. Développer des serveurs maison. Les systèmes propres à l'entreprise (ERP sur mesure, intranet, base tarifaire) relèvent des serveurs maison [31]. Ce développement reste à la charge de l'équipe interne, qui expose ses propres données et fonctions via le protocole.

3. Passer par une agence ou une formation. Des agences proposent de développer des serveurs MCP sur mesure et de les intégrer aux workflows existants [24]. Côté formation, un organisme propose d'apprendre à concevoir des architectures composables à base de serveurs MCP et à connecter des LLM à des outils et données exposés via le protocole [25]. Un autre propose une formation en inter ou en intra, en France ou à distance, dès 1 700 € HT et éligible OPCO [4]. Ces offres viennent d'acteurs commerciaux : contenus et tarifs sont ceux des prestataires.

En pratique, on peut commencer par les serveurs existants pour les outils standards. On réserve le développement spécifique aux systèmes internes, et on monte en compétence en parallèle.

Où se situe Oupi

Oupi est une plateforme d'IA conçue, développée et hébergée en France. Elle se connecte à des centaines d'applications externes via MCP et des connecteurs.