MCP (Model Context Protocol) : connecter l’IA à vos outils métier

MCP (Model Context Protocol) est un standard ouvert qui définit comment une application d’IA se connecte à des outils et à des données externes : grâce à lui, un assistant comme Claude, ChatGPT ou Microsoft Copilot, ou un agent développé sur mesure, peut interroger votre CRM, votre base documentaire ou votre outil de tickets par un connecteur commun. Publié par Anthropic en novembre 2024, adopté depuis par les principaux éditeurs, il est aujourd’hui placé sous l’égide d’une fondation neutre. Pour une entreprise, MCP change une chose essentielle : un connecteur IA écrit une fois fonctionne avec toutes les applications d’IA compatibles.

Ce guide explique d’où vient le protocole et qui le gouverne, comment il fonctionne, ce qu’il change par rapport à une intégration par API, à quoi il sert en entreprise, quels risques il ouvre et comment démarrer.

D’où vient MCP et qui le gouverne ?

Anthropic, l’éditeur de Claude, a publié MCP en open source en novembre 2024, avec une spécification, des kits de développement et une première série de serveurs. Le constat de départ : chaque nouvelle source de données exigeait sa propre intégration, et les assistants restaient coupés des systèmes où vivent les données de l’entreprise.

Le 9 décembre 2025, la Linux Foundation a annoncé la création de l’Agentic AI Foundation, lancée avec les contributions d’Anthropic, de Block et d’OpenAI, et dont Google, Microsoft et AWS figurent parmi les membres. Le communiqué, qui rappelle l’ouverture du protocole par Anthropic en novembre 2024, recensait alors plus de 10 000 serveurs MCP publiés (Linux Foundation, 2025). Les décisions techniques restent prises par les mainteneurs du protocole, à partir de propositions d’évolution publiques. Aucun éditeur ne contrôle seul la spécification : c’est une garantie pour les entreprises qui investissent dans des connecteurs.

Comment fonctionne MCP : hôte, client et serveur

MCP s’inspire d’un standard bien connu des développeurs, le Language Server Protocol, et répartit les rôles entre trois composants.

• L’hôte : l’application d’IA qu’utilise la personne, par exemple Claude, ChatGPT, Visual Studio Code ou votre agent maison. Il coordonne les connexions.
• Le client : le composant de l’hôte qui maintient la connexion avec un serveur donné. L’hôte crée un client par serveur.
• Le serveur : le programme qui met un outil ou des données à disposition de l’IA. Un serveur pour le CRM, un autre pour la gestion documentaire, un troisième pour la base de données.

Les échanges prennent la forme de messages au format JSON-RPC 2.0, transportés de deux façons : en local, par l’entrée et la sortie standard d’un programme lancé sur le poste (stdio), ou à distance, en HTTP, pour un serveur hébergé qui sert de nombreux utilisateurs.

Un serveur MCP met trois types de briques à disposition de l’IA.

• Des outils (tools) : des fonctions que le modèle peut appeler pour agir ou interroger, comme « rechercher un client » ou « créer un ticket ».
• Des ressources (resources) : des données fournies comme contexte, comme le contenu d’un fichier ou le schéma d’une base.
• Des prompts : des modèles de requêtes réutilisables, proposés à l’utilisateur, comme « préparer le compte rendu d’un rendez-vous client ».

Le serveur peut aussi demander une précision ou une confirmation à l’utilisateur en cours de route. Concrètement, l’hôte demande à chaque serveur la liste de ses outils (méthode tools/list), avec leur description et leurs paramètres. Quand un commercial demande « quels devis sont en attente pour ce client ? », le modèle choisit l’outil adapté du serveur CRM, le client MCP transmet l’appel (tools/call), le serveur interroge le CRM avec les droits du commercial et renvoie le résultat, que le modèle met en forme. La spécification officielle décrit ces échanges en détail. Sa dernière révision, datée du 28 juillet 2026, rend chaque requête autonome, ce qui simplifie l’hébergement des serveurs à grande échelle.

MCP ou intégration API classique : qu’est-ce qui change ?

MCP ne remplace pas les API. Un serveur MCP s’appuie le plus souvent sur l’API d’un logiciel : il la présente simplement sous une forme qu’une IA sait découvrir et utiliser seule.

Le gain est d’abord économique. Avec trois applications d’IA et dix outils métier, il faut en théorie trente intégrations sur mesure ; avec MCP, dix serveurs suffisent, utilisables par les trois. C’est aussi un gain d’indépendance : un serveur MCP que vous possédez rend votre système d’information accessible à l’assistant de votre choix aujourd’hui, et à un autre demain, sans tout redévelopper. C’est la logique que nous défendons face à l’empilement d’abonnements (voir outil sur mesure ou SaaS).

MCP n’est pas toujours la bonne réponse. Pour un traitement fixe, comme une synchronisation de données ou un flux de factures, un appel d’API direct reste plus simple, plus rapide et plus prévisible. MCP prend son sens quand un modèle doit choisir, parmi plusieurs actions, celle qui répond à la demande.

MCP, function calling et A2A : ne pas tout confondre

Trois notions reviennent dans les projets d’agents. Elles se complètent plus qu’elles ne se concurrencent.

• Le function calling (ou tool use) est une capacité du modèle : l’API de l’éditeur permet au modèle de demander l’appel d’une fonction décrite par le développeur. Chaque application déclare ses propres fonctions, avec son propre code.
• MCP standardise la façon dont ces outils sont publiés et découverts : un serveur les décrit une fois, toute application compatible les présente à son modèle, qui les appelle ensuite par function calling.
• A2A (Agent2Agent), protocole ouvert créé par Google et lui aussi hébergé par la Linux Foundation, organise le dialogue entre agents : un agent confie une tâche à un autre, éventuellement conçu par un autre éditeur.

En résumé, MCP relie un agent à des outils et à des données, A2A relie des agents entre eux. À notre avis, pour une PME, MCP est de loin le plus utile aujourd’hui : l’essentiel des besoins consiste à brancher un assistant ou un agent sur des logiciels existants, pas à faire dialoguer des agents d’éditeurs différents.

Exemples d’usage de MCP en entreprise

Plusieurs éditeurs publient désormais leurs propres serveurs MCP, et un serveur maison permet d’exposer le reste.

Deux enseignements. D’abord, les serveurs des éditeurs sérieux respectent les droits existants : celui d’Atlassian, par exemple, agit dans les limites des permissions de l’utilisateur connecté. Ensuite, un serveur maison répond aux questions chiffrées sur vos données structurées, là où un RAG sur vos documents est mal à l’aise. Branchés sur un agent IA, ces connecteurs lui permettent d’enchaîner les actions : lire le ticket, consulter le client dans le CRM, proposer une réponse. Les agents de code peuvent s’en servir de la même façon pour accéder aux tickets ou à la documentation (voir notre article sur le développement assisté par IA).

Quels risques de sécurité avec MCP ?

Brancher une IA sur vos outils, c’est lui donner la main sur vos données. La spécification le dit sans détour : les outils représentent une exécution de code arbitraire, et l’hôte doit obtenir le consentement explicite de l’utilisateur avant d’en invoquer un. Elle recommande qu’un humain puisse toujours refuser un appel d’outil. Cinq risques demandent une attention particulière.

1. L’injection de prompt par les outils. Le contenu renvoyé par un outil (un e-mail, un ticket, une page web), voire la description d’un outil, peut contenir des instructions cachées que le modèle exécute. La spécification demande de considérer ces descriptions comme non fiables, sauf si elles proviennent d’un serveur de confiance.
2. Des permissions trop larges. Un serveur connecté avec un compte administrateur donne à l’IA tous les droits de ce compte.
3. Des serveurs tiers non vérifiés. Un serveur local s’exécute avec les droits de l’utilisateur : il peut faire sur les fichiers tout ce que l’utilisateur peut faire lui-même, rappelle la documentation officielle. Un paquet malveillant ou compromis peut exfiltrer des données. Le registre officiel des serveurs est d’ailleurs encore en préversion.
4. Une authentification bâclée. Pour les serveurs distants, le protocole prévoit une autorisation fondée sur OAuth 2.1, facultative, donc à exiger, et interdit à un serveur d’accepter des jetons qui ne lui ont pas été délivrés.
5. Les combinaisons dangereuses. Un assistant qui lit des contenus externes et peut envoyer des données vers l’extérieur réunit tous les ingrédients d’une fuite.

La check-list que nous recommandons aux DSI :

• Tenir un inventaire des serveurs MCP autorisés et bloquer les installations sauvages.
• Privilégier les serveurs officiels des éditeurs ou des serveurs maison relus.
• Connecter chaque serveur avec un compte dédié aux droits minimaux, en lecture seule par défaut.
• Exiger une confirmation humaine pour toute écriture, tout envoi ou toute suppression.
• Journaliser les appels d’outils : qui, quoi, quand, avec quel résultat.
• Revoir les droits régulièrement : l’ANSSI recommande de contrôler les droits des outils d’IA générative sur les applications métier dès leur activation, puis périodiquement, par exemple tous les mois (ANSSI, 2024).

Pour une vue d’ensemble des attaques propres à l’IA générative, voir notre guide sur la sécurité de l’IA générative.

Comment démarrer : serveurs existants ou serveur maison ?

Commencez par les serveurs existants lorsque vos logiciels en publient un. Testez-le en lecture seule, avec un petit groupe pilote, sur un cas précis. Avant de l’activer, posez quatre questions : qui l’édite, quels droits demande-t-il, par où transitent les données, que garde-t-il en journal ?

Développez un serveur maison lorsque l’outil n’en propose pas (ERP spécifique, base métier, application interne) ou lorsque vous voulez contrôler précisément les actions exposées : « consulter le stock », oui ; « modifier un prix », non. Les kits de développement officiels existent notamment en Python, TypeScript, C#, Go, Rust et Ruby. Trois conseils de conception :

• exposez des actions métier (« rechercher une commande »), pas une copie de l’API brute ;
• nommez et décrivez chaque outil avec soin : c’est cette description qui guide le choix du modèle ;
• limitez le nombre d’outils : GitHub note lui-même qu’activer seulement les outils nécessaires aide le modèle à choisir et réduit le contexte.

Pour un premier essai sur un poste de travail, la documentation officielle montre comment brancher le serveur de référence « filesystem » sur Claude Desktop (ce serveur nécessite Node.js). Sur macOS, le fichier de configuration ~/Library/Application Support/Claude/claude_desktop_config.json contient :

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/username/Desktop",
        "/Users/username/Downloads"
      ]
    }
  }
}

Chaque entrée de mcpServers décrit un serveur : la commande qui le lance et ses arguments, ici les seuls dossiers auxquels il aura accès. Au redémarrage, l’application lance le serveur et propose ses outils, en demandant votre accord avant chaque action (documentation MCP).

En entreprise, un serveur maison est un logiciel comme un autre : il se développe, se teste, s’héberge et se maintient. Nous hébergeons ceux que nous développons chez Scaleway, un hébergeur français, et nos clients en sont propriétaires. C’est un volet courant de nos projets de développement sur mesure.

Les erreurs fréquentes avec MCP

• Brancher tout ce qui existe. Chaque serveur ajoute des outils que le modèle doit départager, et une surface d’attaque de plus. Partez des cas d’usage, pas du catalogue.
• Exposer l’API brute. Des dizaines d’outils calqués sur les points d’accès d’une API égarent le modèle. Quelques actions métier bien décrites fonctionnent mieux.
• Connecter un compte personnel ou administrateur. Le serveur hérite de tous ses droits, et vos journaux ne distinguent plus l’humain de l’IA.
• Installer un serveur trouvé en ligne sans l’examiner. Un serveur local exécute du code sur le poste : il mérite la même vigilance qu’un logiciel installé par la DSI.
• Oublier l’hôte. La confirmation des actions et la journalisation dépendent aussi de l’application d’IA utilisée : vérifiez ce qu’elle affiche à l’utilisateur et ce qu’elle conserve.