Qu'est-ce qu'un serveur MCP ? Le protocole MCP expliqué simplement

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. 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.

Le protocole n’appartient plus à un seul éditeur. Le 9 décembre 2025, MCP a rejoint l’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 :

• 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, 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. La spécification définit deux transports standard :

• 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 : 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.

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. 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 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.

Questions fréquentes

Qu'est-ce qu'un serveur MCP, en une phrase ? +

Un serveur MCP est un programme qui expose des outils (des actions), des ressources (des données) et des prompts (des modèles de consigne) à un agent IA, selon le Model Context Protocol. L'agent s'y connecte par un client MCP et peut ensuite lire ou agir dans le système que le serveur représente, par exemple un CRM, un ERP ou un espace documentaire.

Quelle est la différence entre le protocole MCP et un serveur MCP ? +

Le protocole MCP est la spécification : le format des messages (JSON-RPC), les transports, le cycle de vie, l'autorisation. Un serveur MCP est une implémentation de ce protocole pour un système donné. Il existe un seul protocole et des milliers de serveurs, un peu comme il existe un seul protocole HTTP et d'innombrables sites web.

Qui a créé MCP, et qui le maintient aujourd'hui ? +

Anthropic a publié le Model Context Protocol comme standard ouvert le 25 novembre 2024. Le 9 décembre 2025, le protocole est devenu un projet fondateur de l'Agentic AI Foundation, un fonds dirigé sous l'égide de la Linux Foundation, cofondé par Anthropic, Block et OpenAI. La gouvernance du protocole est donc neutre vis-à-vis des éditeurs.

Un serveur MCP est-il sécurisé par défaut ? +

Non. La spécification rend l'autorisation optionnelle et précise que le protocole ne peut pas imposer lui-même ses principes de sécurité : c'est aux implémentations de prévoir consentement, contrôle d'accès et journalisation. Un serveur distant devrait exiger une authentification OAuth, n'accorder que les permissions nécessaires et être validé avant d'être mis à disposition des équipes.

Faut-il un serveur MCP par outil métier ? +

Souvent, oui : chaque système (CRM, ERP, base documentaire) est exposé par son propre serveur. Mais brancher tous ces serveurs directement sur chaque agent déverse toutes leurs définitions d'outils dans le contexte du modèle. Une couche intermédiaire, qui regroupe les outils par rôle et les charge à la demande, évite cette saturation et centralise les autorisations.

skilder est-il un annuaire public de serveurs MCP ? +

Non. Le registre de serveurs MCP de skilder est interne à chaque workspace et curé : il ne contient que des serveurs vérifiés, configurés et cadrés pour l'organisation. Ajouter un serveur au registre est l'étape d'autorisation centrale ; un rôle ne peut ensuite atteindre que des serveurs déjà présents dans ce registre.