# Qu'est-ce qu'un serveur MCP ? Le protocole MCP expliqué simplement > Un serveur MCP expose des outils, des données et des prompts à un agent IA via le Model Context Protocol. Définition, fonctionnement du protocole MCP, exemples et questions de gouvernance à se poser en entreprise. Language: fr · Category: engineering · Author: Nicolas Corod (Fondateur & CEO) · Published: 2026-09-28 Depuis fin 2024, un sigle revient dans toutes les discussions sur les agents IA : MCP. Les éditeurs annoncent leur « serveur MCP », les DSI se demandent s'il faut les autoriser, et les équipes métier veulent surtout savoir ce que cela change pour elles. **Un serveur MCP est un programme qui expose des outils, des données et des modèles de consigne à un agent IA selon le Model Context Protocol, un standard ouvert. L'agent s'y connecte, découvre ce qui est proposé, puis lit ou agit dans le système concerné : CRM, ERP ou base documentaire.** Cet article explique le protocole MCP sans jargon inutile, montre comment un serveur MCP fonctionne concrètement, et pose les questions de gouvernance qu'une entreprise doit trancher avant d'en brancher un. Il introduit aussi la notion de **rôle** : le travail qu'un poste de l'organigramme fait réellement, avec les outils auxquels ce poste a droit. C'est le bon niveau pour décider quel agent peut atteindre quel serveur. ## Le protocole MCP en bref Le Model Context Protocol a été [publié par Anthropic comme standard ouvert le 25 novembre 2024](https://www.anthropic.com/news/model-context-protocol). Son objectif : donner une manière unique de relier les applications d'IA aux sources de données et aux outils dont elles ont besoin. Avant MCP, chaque paire « agent × système » exigeait un connecteur sur mesure. Dix agents et vingt systèmes, c'était potentiellement deux cents intégrations. Avec un protocole commun, chaque système est exposé une fois, et chaque agent compatible sait s'y brancher. Ce problème d'intégration est détaillé dans [l'analyse sur la composition des skills au-dessus de MCP](/fr/blog/au-dela-de-mcp-vs-skills/). Le protocole n'appartient plus à un seul éditeur. Le 9 décembre 2025, [MCP a rejoint l'Agentic AI Foundation](https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/), un fonds dirigé hébergé par la Linux Foundation et cofondé par Anthropic, Block et OpenAI. L'annonce faisait alors état de plus de 97 millions de téléchargements mensuels des SDK et de 10 000 serveurs actifs. ## Hôte, client, serveur : qui fait quoi La [spécification décrit une architecture en trois parties](https://modelcontextprotocol.io/specification/latest/architecture) : - **L'hôte** : l'application d'IA que l'utilisateur ouvre (Claude, ChatGPT, Copilot, un IDE, un agent maison). Il gère les connexions, le consentement de l'utilisateur et l'agrégation du contexte. - **Le client** : un connecteur créé par l'hôte. Chaque client parle à exactement un serveur. - **Le serveur** : le programme qui représente un système (votre CRM, votre drive, votre base de tickets) et expose ses capacités. Un principe de conception mérite d'être retenu : un serveur ne doit pas pouvoir lire toute la conversation ni « voir » les autres serveurs. L'historique complet reste chez l'hôte, qui contrôle ce que chaque serveur reçoit. ## Ce qu'un serveur MCP expose Un serveur peut offrir [trois types de primitives](https://modelcontextprotocol.io/specification/2025-06-18/server), chacune contrôlée par un acteur différent : | Primitive | Ce que c'est | Qui la déclenche | Exemple | |---|---|---|---| | **Tools** (outils) | Des fonctions que le modèle peut appeler pour agir ou chercher une information | Le modèle | Créer un ticket, interroger une base | | **Resources** (ressources) | Des données ou contenus fournis comme contexte | L'application | Le contenu d'un fichier, un historique | | **Prompts** | Des modèles de consigne prédéfinis | L'utilisateur | Une commande « /résumer-le-dossier » | Dans la pratique, ce sont surtout les outils qui comptent : ils transforment un assistant qui répond en un agent qui agit. C'est aussi là que se concentre le risque, puisque la spécification rappelle qu'un outil représente une exécution de code arbitraire et doit être traité avec prudence. ## Comment un serveur MCP communique Les messages sont encodés en [JSON-RPC 2.0](https://modelcontextprotocol.io/specification/latest). La spécification définit [deux transports standard](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports) : - **stdio** : l'hôte lance le serveur comme un sous-processus sur la même machine. C'est le mode typique des serveurs locaux installés par un développeur. - **Streamable HTTP** : le serveur tourne à distance et expose une seule URL, par exemple `https://example.com/mcp`. C'est le mode des serveurs hébergés, partagés par une équipe ou une organisation. Pour les serveurs distants, la spécification décrit une [autorisation fondée sur OAuth 2.1](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) : le client obtient un jeton d'accès limité à ce serveur précis, avec les scopes nécessaires à l'opération. Point important, cette autorisation est **optionnelle** dans le protocole. Un serveur MCP n'est donc pas sécurisé parce qu'il est MCP ; il l'est parce que quelqu'un l'a configuré pour. ## Exemples concrets de serveurs MCP Quelques cas typiques en entreprise : - **Documentaire** : un serveur qui expose un drive ou une base de connaissances, pour que l'agent retrouve la bonne procédure au lieu de l'inventer. - **CRM** : un serveur qui permet de lire une fiche client et d'enregistrer un compte rendu de rendez-vous. - **Ticketing** : un serveur qui crée, commente et qualifie des tickets de support. - **Système interne** : un serveur développé en interne qui expose une API métier (calcul de devis, contrôle de conformité) à tous les agents compatibles. Dans chaque cas, le même serveur fonctionne avec n'importe quel client compatible MCP. C'est la promesse du standard : exposer un système une fois, le consommer partout. ## Serveur MCP et skills : deux couches complémentaires Un serveur MCP dit à l'agent **ce qu'il peut faire**. Il ne lui dit pas **comment le faire bien** dans votre contexte : quelle procédure suivre, quels contrôles appliquer, dans quel ordre appeler les outils. C'est le rôle des skills, des instructions packagées au format SKILL.md, présentées dans [l'article sur les skills, arme secrète des agents IA](/fr/blog/skills-arme-secrete-agents-ia/). Brancher beaucoup de serveurs pose aussi un problème de contexte : chaque serveur connecté déverse ses définitions d'outils dans la fenêtre du modèle avant même le premier message. Cet effet est chiffré dans [l'article sur le passage du context bloat au context load](/fr/blog/du-context-bloat-au-context-load/). La réponse consiste à charger les outils à la demande plutôt que tous d'un coup. ## Les questions de gouvernance à se poser Un serveur MCP donne à un agent un accès réel à un système réel. Avant d'en autoriser un, une organisation devrait pouvoir répondre à cinq questions : 1. **Qui l'a validé ?** Un serveur installé par un collaborateur sur son poste, sans revue, relève du [shadow AI](/fr/blog/shadow-ai/) au même titre qu'un compte ChatGPT personnel. 2. **Avec quelles permissions ?** Lecture seule ou écriture, sur quel périmètre de données, avec quels identifiants. 3. **Pour quel usage ?** Un serveur n'a pas vocation à être branché sur tous les agents de tous les collaborateurs. 4. **Que s'est-il passé ?** Chaque appel d'outil devrait être journalisé et attribuable à la personne qui l'a déclenché. 5. **Comment le retirer ?** Un accès doit pouvoir être révoqué de façon centrale, sans passer poste par poste. ## Comment skilder utilise MCP skilder s'appuie sur MCP à deux niveaux. En amont, chaque workspace dispose d'un **registre interne et curé** de serveurs MCP : on n'y trouve que des serveurs vérifiés, configurés et cadrés pour l'organisation. Ce n'est pas un annuaire public de tous les serveurs existants. L'ajout d'un serveur au registre est l'étape d'autorisation centrale. En aval, skilder expose des **rôles** par un serveur MCP unique. Un rôle regroupe des skills, les outils MCP auxquels ce poste a droit, son contexte et ses permissions. Chaque rôle part d'un blueprint et se configure sur les processus de l'équipe ; il n'est jamais livré tout fait. Le rôle est la frontière de permission : il ne peut atteindre que des serveurs déjà présents dans le registre, et skilder conserve une trace d'exécution de chaque tâche, exportable par le client. Résultat : vos équipes gardent Claude, ChatGPT ou Copilot, et chaque agent reçoit uniquement les outils de son rôle, chargés au moment utile. ## À retenir > Un serveur MCP est une prise standard entre un agent IA et un système. Le protocole règle la connexion ; il ne règle ni les droits, ni la traçabilité, ni la qualité du travail. Ces trois points restent à la charge de l'organisation. Pour voir comment un rôle assemble skills et outils MCP, consultez [la documentation skilder](https://docs.skilder.ai).