Le Model Context Protocol (MCP) est un standard ouvert qui permet à une application d’IA (un assistant comme ChatGPT, Claude ou Copilot, ou un agent développé sur mesure) de se connecter à des systèmes externes : bases de données, applications métier, outils, documents. Pour une PME ou une ETI, l’intérêt est direct : en exposant votre ERP, votre CRM ou votre application métier via un serveur MCP, vous les rendez utilisables par tous les assistants compatibles, sans développer un connecteur spécifique pour chacun. Le sujet n’est plus de savoir si l’IA peut accéder à vos outils, mais avec quels droits et sous quel contrôle.
Qu’est-ce que le Model Context Protocol, concrètement ?
La documentation officielle compare MCP à un port USB-C pour les applications d’IA : de la même manière que l’USB-C standardise le branchement des appareils électroniques, MCP standardise la façon dont une IA se branche sur des sources de données, des outils et des processus.
Avant MCP, chaque intégration était spécifique : un connecteur pour tel assistant, un autre pour tel outil interne, une troisième variante pour un autre fournisseur. Avec MCP, l’entreprise décrit une seule fois ce que l’IA peut consulter et faire dans son système, et tout client compatible peut l’utiliser.
Le protocole a été lancé par Anthropic. Le 9 décembre 2025, Anthropic a annoncé l’avoir confié à l’Agentic AI Foundation, un fonds hébergé par la Linux Foundation et cofondé avec Block et OpenAI. L’annonce faisait état de plus de 10 000 serveurs MCP publics actifs et d’une prise en charge par ChatGPT, Cursor, Gemini, Microsoft Copilot et Visual Studio Code. Pour une entreprise, cette gouvernance neutre réduit le risque de miser sur un format propriétaire.
Comment fonctionne MCP ?
L’architecture repose sur trois rôles, décrits dans la documentation d’architecture :
- L’hôte : l’application d’IA utilisée par la personne (un assistant de bureau, un environnement de développement, votre propre application).
- Le client MCP : le composant de l’hôte qui maintient la connexion avec un serveur donné.
- Le serveur MCP : le programme qui expose des données et des actions, par exemple « rechercher un client » ou « consulter le stock d’un article ».
Un serveur expose trois types d’éléments, appelés primitives :
| Primitive | Définition | Exemple dans une entreprise de négoce |
|---|---|---|
| Outil (tool) | Une fonction que l’IA peut appeler pour agir ou interroger | « Consulter le stock disponible d’une référence par dépôt » |
| Ressource (resource) | Une donnée de contexte que l’IA peut lire | Les conditions générales de vente, la fiche d’un client |
| Prompt | Un modèle d’interaction réutilisable | « Préparer une relance pour une facture échue » |
Chaque outil est décrit par un nom, une description et un schéma de paramètres. C’est cette description qui permet au modèle de comprendre quand et comment utiliser l’outil : sa rédaction compte autant que le code.
Côté transport, deux modes coexistent. Un serveur local s’exécute sur le poste de l’utilisateur et dialogue avec l’assistant par l’entrée et la sortie standard du programme. Un serveur distant est hébergé comme une application web, accessible en HTTP, et sert de nombreux utilisateurs ; la spécification recommande alors OAuth pour obtenir les jetons d’accès. Pour des outils d’entreprise, le serveur distant est le mode le plus simple à sécuriser, à mettre à jour et à superviser.
Que peut-on brancher en MCP dans une PME ou une ETI ?
Les cas d’usage les plus utiles sont ceux où un collaborateur passe aujourd’hui d’un écran à l’autre pour rassembler une information ou préparer une action.
| Cas d’usage | Outils exposés | Niveau de risque | Contrôle recommandé |
|---|---|---|---|
| Répondre à « où en est la commande de ce client ? » | Recherche client, statut de commande, suivi de livraison | Faible (lecture) | Droits de l’utilisateur appliqués |
| Préparer un rendez-vous commercial | Fiche CRM, historique des achats, tickets ouverts | Faible (lecture) | Filtrage par portefeuille du commercial |
| Rechercher une procédure ou un contrat | Recherche dans la gestion documentaire | Moyen (confidentialité) | Respect des droits d’accès aux documents |
| Créer un ticket de support ou une tâche | Création de ticket | Moyen (écriture) | Confirmation explicite avant envoi |
| Préparer un devis | Tarifs, remises, création de brouillon | Élevé (engagement commercial) | Brouillon uniquement, validation humaine |
Le serveur MCP devient ainsi une couche d’accès métier pour l’IA, au même titre qu’une API l’est pour les autres applications. Il se branche aussi bien sur un outil du marché (un ERP comme Odoo, un CRM, une suite bureautique) que sur une application développée sur mesure.
MCP, API, RAG : quelle différence ?
Ces trois notions sont complémentaires, pas concurrentes.
- Une API est une interface technique qui permet à une application d’en interroger une autre. Elle est conçue pour des développeurs. Nous détaillons les choix d’intégration dans notre guide sur les API, webhooks et échanges de fichiers.
- Un serveur MCP s’appuie en général sur une API existante et la présente sous forme d’outils décrits en langage naturel, compréhensibles par un modèle. Il ajoute la découverte automatique des outils, l’authentification de l’utilisateur et un format d’échange commun.
- Le RAG (génération augmentée par récupération) consiste à retrouver des extraits de documents pertinents pour les fournir au modèle avant qu’il réponde. Une recherche documentaire de type RAG peut d’ailleurs être exposée comme un outil MCP parmi d’autres.
Conséquence pratique : si votre application métier n’a pas d’API propre et documentée, c’est le premier chantier. Un serveur MCP construit directement sur la base de données, sans couche métier, contourne les règles de gestion et les contrôles d’accès.
Quels risques de sécurité faut-il traiter ?
Donner à une IA la capacité d’agir dans vos systèmes crée une nouvelle surface d’attaque. La documentation officielle consacre une page entière aux bonnes pratiques de sécurité. Les points qui concernent directement une entreprise sont les suivants.
Des droits au plus juste. La spécification décrit le risque de jetons d’accès aux droits trop larges : un jeton volé donnant accès à tout permet d’agir partout. Elle recommande un modèle progressif, avec un jeu de droits minimal au départ (lecture, découverte) et une élévation au moment où une action sensible est demandée. C’est l’application du principe de moindre privilège, que nous détaillons dans l’article sur la gestion des droits et des rôles.
Des jetons émis pour le bon destinataire. Un serveur MCP ne doit accepter que des jetons émis pour lui, et ne doit pas les retransmettre tels quels aux API en aval. La spécification interdit explicitement cette pratique, qui brouille les responsabilités et les journaux d’audit.
Des serveurs tiers vérifiés. Installer un serveur MCP local revient à exécuter un programme sur le poste de l’utilisateur, avec ses droits. La documentation impose aux clients d’afficher la commande exacte et de demander une approbation explicite. En entreprise, on tient une liste des serveurs autorisés, comme pour toute extension.
Une IA qui ne décide pas seule. L’OWASP classe parmi les risques majeurs des applications à base de modèles de langage l’« agentivité excessive » : des fonctions, des permissions ou une autonomie trop larges. Les parades recommandées sont des outils étroits plutôt que génériques, l’exécution des actions sous l’identité de l’utilisateur, la validation humaine des actions à fort impact et le contrôle des autorisations dans le système cible, pas dans le modèle. L’injection de prompt, qui consiste à glisser des instructions malveillantes dans un document ou un e-mail lu par l’IA, est traitée dans notre article sur la sécurité de l’IA générative.
Comment construire un serveur MCP pour son application ?
La démarche ressemble à celle de toute intégration, avec une attention particulière à la description des outils.
- Partir de trois à cinq questions ou actions fréquentes des équipes, pas de l’ensemble du système.
- Vérifier l’API existante : couvre-t-elle ces besoins, avec les bons contrôles d’accès ?
- Rédiger les outils : un nom explicite, une description qui dit quand l’utiliser, des paramètres typés et limités. Un outil « rechercher_commande(numéro) » vaut mieux qu’un outil « exécuter_requête(sql) ».
- Brancher l’authentification sur l’annuaire de l’entreprise, pour que l’IA agisse avec les droits de la personne connectée, par exemple via une authentification unique (SSO).
- Commencer en lecture seule, puis ajouter des écritures limitées avec confirmation.
- Journaliser chaque appel d’outil : qui, quand, quels paramètres, quel résultat.
- Tester avec des cas réels, y compris des demandes ambiguës ou malveillantes, et suivre les évolutions de la spécification, publiée en versions datées.
Faut-il s’y mettre maintenant ?
Oui, si vos équipes utilisent déjà des assistants IA et passent du temps à y recopier des informations issues de vos outils : un serveur MCP limité à quelques outils de consultation apporte vite de la valeur, avec un risque maîtrisé. C’est aussi la voie la plus durable pour un éditeur de SaaS qui veut que son produit soit utilisable depuis les assistants de ses clients.
Mieux vaut attendre, en revanche, si vos données sont dispersées dans des tableurs sans référentiel ni API : l’IA ne fera que refléter ce désordre. Les fondations décrites dans notre article sur la préparation des données pour l’IA passent alors en premier.
Vous souhaitez rendre une application métier accessible à vos assistants IA, en gardant la main sur les droits et la traçabilité ? C’est un projet d’intégration et d’API à part entière : parlons-en.
