Un assistant IA peut rédiger une réponse, mais il ne connaît pas forcément les informations présentes dans votre base de données et ne peut pas, par défaut, agir dans vos applications. Pour lui donner accès à des ressources ou à des opérations précises, une intégration doit relier l’application à ces services. Le Model Context Protocol, abrégé MCP, standardise une partie de cet échange.
Le serveur MCP est le programme qui met à disposition ces ressources ou opérations. Voici comment il s’insère dans l’architecture, ce qu’il faut choisir pour le faire fonctionner et comment vérifier qu’une connexion répond au besoin sans accorder des accès excessifs.
Que fait concrètement un serveur MCP ?
MCP signifie « Model Context Protocol », soit protocole de contexte pour les modèles. Il définit une façon structurée pour une application hôte, son client MCP et un serveur MCP d’échanger des messages. L’application hôte est, par exemple, un assistant ou un environnement de développement ; le client est la partie qui se connecte au serveur ; le serveur expose les capacités d’un système, comme des documents ou des opérations. La spécification officielle présente MCP comme un protocole ouvert reposant sur des messages JSON-RPC 2.0 : il normalise l’échange, mais ne décide pas à lui seul de ce que l’application autorise.
Un serveur peut proposer trois familles de capacités, selon ce qu’il implémente :
- Des ressources, c’est-à-dire des données que l’application peut consulter comme contexte, par exemple un fichier ou une structure de base de données.
- Des outils, qui correspondent à des opérations exécutables, comme rechercher un dossier ou créer un ticket.
- Des modèles de consigne, appelés prompts dans la spécification, qui fournissent des instructions réutilisables.
Ces familles ne sont pas interchangeables. Une ressource sert à apporter des informations ; un outil permet une action ; un modèle de consigne structure une demande. Selon la documentation officielle MCP, chaque ressource possède un identifiant URI et le serveur indique les capacités qu’il prend effectivement en charge. Il est donc préférable de vérifier ce qu’un serveur expose plutôt que de déduire ses pouvoirs de son nom.
MCP ne signifie pas non plus qu’un modèle se connecte librement à vos systèmes. L’application hôte contrôle l’expérience et peut appliquer des choix d’autorisation ou demander une confirmation avant l’exécution d’un outil. En pratique, les droits réels dépendent aussi du compte, de la configuration et du code du serveur.
Pour situer MCP parmi les services d’infrastructure, un serveur MCP ne remplit pas la même fonction qu’un service de transfert de fichiers. Si votre besoin porte sur l’échange de documents entre machines, les critères décrits pour choisir un serveur de transfert de fichiers relèvent d’un autre usage. De même, le mot « serveur » recouvre plusieurs rôles dans la rubrique technologie : MCP désigne ici un rôle dans un protocole d’intégration avec des applications d’IA.
Quels critères regarder avant de choisir ?
Commencez par le besoin métier, puis examinez quatre critères concrets.
Les capacités nécessaires. Écrivez les tâches attendues en termes simples : lire une documentation, chercher dans un catalogue, ou créer un enregistrement. Vérifiez ensuite que les ressources ou outils annoncés correspondent bien à ces tâches. Une description d’outil doit préciser son action et ses entrées ; des paramètres clairement définis facilitent leur validation par le client.
Le lieu d’exécution. Un serveur local peut être lancé comme un processus sur le même environnement que l’application cliente. Un serveur distant est hébergé et joint par le réseau. Le premier peut réduire le périmètre de déploiement, tandis que le second peut convenir à un service partagé. Dans les deux cas, les accès aux données et les secrets utilisés par le serveur doivent être maîtrisés.
Le transport. La spécification MCP définit notamment le transport par entrée-sortie standard, souvent noté stdio, et Streamable HTTP, un transport HTTP conçu pour des échanges MCP. Avec stdio, l’application cliente lance ou pilote le processus et échange des messages via ses flux d’entrée et de sortie. Streamable HTTP vise les serveurs accessibles par réseau. Ce ne sont pas deux produits différents, mais deux façons de transporter les messages ; l’hébergement, la gestion des identifiants et le fonctionnement de l’application déterminent le choix.
La sécurité et l’exploitation. Déterminez quels comptes et données le serveur peut atteindre, qui peut l’utiliser et comment révoquer un accès. Pour un serveur HTTP, prévoyez une authentification et des autorisations adaptées au service exposé. Limitez les permissions à ce qui est nécessaire et évitez d’inscrire des secrets dans une configuration partagée ou dans des journaux. Pour les outils capables de modifier des données, prévoyez une confirmation ou une règle de validation appropriée au risque.
Comment MCP se distingue-t-il d’une intégration dédiée ?
Une intégration dédiée relie souvent une application à un service selon une interface conçue spécialement pour eux. MCP fournit une interface partagée : un client compatible peut découvrir les capacités exposées par différents serveurs et les appeler selon les règles du protocole. Cela peut simplifier l’interopérabilité, mais ne garantit pas que tous les clients prennent en charge toutes les fonctions, ni que deux serveurs offrent les mêmes outils.
Il faut également distinguer MCP d’une API. Une API est l’interface du service sous-jacent ; le serveur MCP peut s’y connecter et traduire des requêtes entre cette API et le protocole MCP. Il peut aussi lire des fichiers ou communiquer avec une autre source. L’existence d’un serveur MCP ne rend donc pas inutile l’API, et n’implique pas que l’ensemble du service soit accessible.
Enfin, une intégration par MCP n’est pas à elle seule une garantie de sécurité ou de qualité. Les descriptions d’outils, les contrôles de paramètres, les identités utilisées et les autorisations restent déterminants. Pour comparer deux options, demandez quelles ressources et quels outils chacune expose, sur quelles données, avec quels droits, et si les opérations modifiant des données peuvent être limitées ou confirmées.
Comment le mettre en pratique et vérifier le résultat ?
Procédez par étapes, en partant d’un cas d’usage limité.
- Décrivez une tâche précise. Par exemple : consulter un ensemble de documents, sans les modifier. Choisissez une tâche que vous pourrez tester avec un résultat attendu identifiable.
- Sélectionnez un serveur adapté à la source de données. Consultez sa documentation et repérez les capacités annoncées, les prérequis, le mode d’installation et les permissions requises. Vérifiez que le serveur provient d’une source que vous pouvez examiner et maintenir.
- Choisissez un transport et configurez l’accès. En environnement local, vérifiez comment l’application lance le processus et transmet sa configuration. Pour une instance distante, vérifiez le point de terminaison réseau, l’authentification et les autorisations. La spécification MCP décrit Streamable HTTP comme un transport distinct de stdio et impose, pour ses requêtes HTTP, la cohérence entre l’en-tête de version et la métadonnée de version du message.
- Testez la découverte avant un usage réel. Le client doit pouvoir identifier les capacités déclarées. Essayez ensuite une lecture ou un outil non destructif avec des données sans enjeu, puis confrontez la réponse à une source connue.
- Vérifiez les limites et les erreurs. Testez un paramètre manquant, une demande non autorisée et une source indisponible. Confirmez qu’un échec est signalé clairement et qu’il ne déclenche pas une action inattendue. Contrôlez aussi que le serveur n’expose pas une ressource ou un outil au-delà du périmètre prévu.
Le protocole évolue : la révision actuelle est datée du 28 juillet 2026. La spécification distingue des révisions et des mécanismes de compatibilité ; vérifiez donc la version effectivement prise en charge par le client et le serveur que vous déployez, plutôt que de supposer qu’ils parlent tous la même révision. Pour le transport Streamable HTTP, les requêtes POST MCP incluent un en-tête de version, et la spécification prévoit une réponse HTTP 400 en cas de version non prise en charge ou d’incohérence de version. Ce comportement est utile pour diagnostiquer un problème de compatibilité, mais ne remplace pas les tests fonctionnels.
Après le test, contrôlez le résultat dans l’application et, lorsque c’est possible, dans la source d’origine : le contenu lu correspond-il aux données attendues ? Une action a-t-elle créé ou changé exactement l’élément prévu ? Vérifiez les journaux sans y laisser de secrets ou de contenus sensibles. Conservez la configuration et les permissions minimales nécessaires, et répétez les vérifications lorsque vous changez de version, de compte ou de serveur. Un serveur MCP est utile lorsque son périmètre est clair, ses capacités comprises et ses accès contrôlés.
Questions fréquentes
Un serveur MCP est-il un serveur web classique ?
Pas nécessairement. « Serveur » désigne ici le rôle du programme dans le protocole, pas une machine dédiée ni obligatoirement un site web. Il peut tourner comme un processus local lancé par l’application cliente, communiquer par entrée-sortie standard, ou être hébergé à distance et joindre par HTTP en flux continu. Le choix dépend du lieu d’exécution, des utilisateurs concernés et de la manière de gérer les accès.
Quelle différence entre un serveur MCP et une API ?
Une API expose des opérations propres à un service, souvent au moyen de ses propres routes et formats. Un serveur MCP peut s’appuyer sur ces API, mais présente les capacités à un client compatible avec une interface définie par MCP : découverte des outils, description des paramètres et appels normalisés. MCP ne remplace donc pas nécessairement l’API sous-jacente ; il fournit une manière commune de la rendre utilisable par une application d’IA.
Un serveur MCP peut-il modifier ou supprimer des données ?
Oui, si son implémentation expose des outils qui effectuent ces actions et si le système connecté les autorise. Le protocole ne rend pas une opération automatiquement sans risque. Avant d’activer un outil, vérifiez ses paramètres, les droits du compte utilisé, les confirmations nécessaires et les journaux disponibles. Pour commencer, privilégiez un accès limité et des opérations de lecture, puis élargissez les droits seulement si le besoin est établi.
Faut-il utiliser un serveur MCP distant pour une PME ?
Non. Un serveur local peut convenir lorsque l’usage reste limité à une application et à un poste ou environnement maîtrisé. Une instance distante est pertinente lorsque plusieurs utilisateurs ou services doivent y accéder, mais elle demande de traiter l’authentification, les autorisations, la disponibilité et la protection des données. La décision dépend du périmètre d’usage, pas de la taille de l’entreprise à elle seule.
