AI & LLMChecklist
Sécuriser un serveur MCP : la checklist avant connexion
Une checklist pratique pour évaluer un serveur MCP : provenance, droits, OAuth, outils, prompt injection, isolation, validation et journalisation.
AI & LLMGuide pratique
MCP : à quoi sert le Model Context Protocol ?
Comprendre MCP : hôte, client, serveur, outils, ressources, prompts et ce que change la spécification 2026-07-28 pour les agents IA.
LA RÉPONSE UTILE
MCP, ou Model Context Protocol, définit une manière commune pour une application d’IA de découvrir et d’utiliser des capacités externes. Un serveur MCP peut exposer des outils exécutables, des ressources à lire et des prompts réutilisables. Le protocole ne remplace ni le modèle, ni l’agent, ni les autorisations : il normalise surtout la connexion entre eux.
- MCP standardise l’échange entre une application d’IA et des capacités externes ; il ne crée pas à lui seul un agent.
- Les primitives principales sont les outils, les ressources et les prompts, avec des responsabilités différentes.
- La révision 2026-07-28 introduit notamment un cœur sans session au niveau protocolaire et renforce l’autorisation.
MCP relie l’IA au reste du système
Un modèle de langage sait produire du texte à partir de son contexte, mais il ne possède pas automatiquement l’accès à vos fichiers, vos API, vos bases de données ou vos outils internes. MCP fournit un protocole commun pour décrire ces capacités et permettre à une application d’IA de les découvrir puis de les utiliser selon les règles du client et du serveur.
Le point important est le mot « protocole ». MCP ne remplace pas le modèle, l’interface de chat ou la logique métier. Il définit plutôt des messages, des capacités et des conventions entre un client et un serveur. Cela permet à des intégrations différentes de partager un langage commun au lieu de réinventer une interface spécifique pour chaque outil.
Hôte, client, serveur : qui fait quoi ?
Dans une architecture MCP, l’hôte est l’application qui porte l’expérience IA : par exemple un environnement de développement ou un assistant. Cette application utilise un client MCP pour communiquer avec un ou plusieurs serveurs. Le serveur expose ensuite des capacités vers des services réels : fichiers, bases de données, API, moteurs de recherche, outils de développement ou systèmes internes.
Cette séparation est utile parce qu’elle évite de confondre décision et exécution. Le modèle peut proposer d’appeler un outil, mais le client conserve la responsabilité d’appliquer ses politiques, d’obtenir une autorisation lorsqu’elle est nécessaire et d’afficher les informations utiles à l’utilisateur.
| Élément | Rôle | Exemple |
|---|---|---|
| Hôte | Porte l’application et l’expérience utilisateur | Assistant ou IDE |
| Client MCP | Échange avec un serveur selon le protocole | Connexion intégrée à l’hôte |
| Serveur MCP | Expose des capacités structurées | Serveur fichiers, données ou API |
| Service cible | Effectue réellement le travail ou stocke les données | Git, base SQL, API métier |
Outils, ressources et prompts : trois usages distincts
Les serveurs MCP peuvent publier plusieurs primitives. Les outils sont conçus pour exécuter une action ou effectuer un calcul. Les ressources exposent du contenu que le client peut lire. Les prompts fournissent des modèles d’instructions réutilisables. Les SDK officiels documentent ces trois familles avec leurs opérations de liste et d’appel ou de lecture.
Cette distinction aide à réduire les ambiguïtés. Une documentation de projet n’a pas besoin d’être présentée comme un outil qui modifie quelque chose. À l’inverse, une opération qui crée un ticket, modifie un fichier ou déclenche un déploiement doit être traitée comme une action avec des contrôles adaptés.
| Primitive | But principal | Question à poser |
|---|---|---|
| Tool | Exécuter une action ou récupérer un résultat actif | Que peut réellement modifier cet appel ? |
| Resource | Fournir du contexte ou des données à lire | Quelles données sont exposées et à qui ? |
| Prompt | Réutiliser une structure d’instructions | Qui choisit ce modèle et avec quelles entrées ? |
MCP ne remplace pas vos API
Un serveur MCP peut très bien appeler une API REST, GraphQL ou interne derrière lui. L’API reste alors l’interface métier de votre service ; MCP devient une couche adaptée aux applications d’IA. Pour une intégration unique et parfaitement contrôlée, une API directe peut rester plus simple. MCP devient surtout intéressant lorsqu’un même ensemble de capacités doit être découvert et utilisé par plusieurs clients compatibles.
Il ne faut pas non plus confondre MCP avec le « function calling » d’un modèle. Le function calling décrit généralement la manière dont un modèle sélectionne une fonction disponible dans un produit donné. MCP couvre une couche d’intégration plus large : découverte des capacités, échanges client-serveur, ressources, prompts et conventions de transport. Un futur comparatif dédié pourra traiter cette frontière sans les présenter comme des synonymes.
Local ou distant : le transport change le risque
Un serveur local peut être lancé comme un processus et communiquer par entrée-sortie standard. Un serveur distant peut utiliser le transport HTTP prévu par l’écosystème. Dans les deux cas, la simple compatibilité MCP ne garantit aucune sécurité. Un processus local peut avoir beaucoup trop de droits sur votre machine ; un serveur distant peut recevoir des données sensibles ou disposer d’autorisations excessives.
Avant de connecter un serveur, identifiez donc le chemin complet des données : application, serveur MCP, service cible et éventuels sous-traitants. Cette vérification rejoint les questions déjà posées dans IA locale ou cloud : emplacement des données, maintenance, contrôle des accès et responsabilité.
Ce que change la spécification 2026-07-28
La révision publiée le 28 juillet 2026 apporte un changement architectural important : le cœur moderne du protocole devient sans session au niveau protocolaire. Elle ajoute aussi des mécanismes de découverte, des indications de cache sur certaines listes et lectures, des en-têtes de routage, des requêtes multi-allers-retours et plusieurs durcissements autour de l’autorisation.
Cela signifie qu’un article MCP datant de 2024 ou du début de 2025 peut décrire un cycle de connexion différent. Lorsque vous implémentez un client ou un serveur, vérifiez la version négociée ou supportée par votre SDK au lieu de recopier un exemple ancien. Les SDK officiels conservent parfois une compatibilité avec plusieurs générations du protocole, ce qui explique que deux exemples valides puissent ne pas avoir la même structure.
Un exemple concret : un agent de développement
Imaginez un agent de développement qui doit analyser un dépôt, lire une documentation puis créer une issue. Un serveur peut exposer la lecture des fichiers comme ressource ou outil contrôlé, un autre peut fournir des opérations sur le gestionnaire de tickets, et l’hôte peut présenter ces capacités au modèle. Le modèle propose alors les appels nécessaires, tandis que l’application décide ce qui peut être exécuté automatiquement et ce qui nécessite une confirmation.
L’intérêt n’est pas de donner « tous les pouvoirs » au modèle. Au contraire, une intégration bien conçue réduit le périmètre : uniquement les dépôts concernés, uniquement les opérations nécessaires et, pour les actions sensibles, une validation explicite. La qualité d’un agent dépend donc autant de son environnement et de ses garde-fous que du modèle choisi.
Quand MCP est un bon choix
MCP mérite d’être étudié si vous voulez connecter plusieurs outils à différents assistants, standardiser la découverte des capacités ou séparer clairement l’application IA des services qu’elle utilise. Pour un script interne qui appelle une seule API stable, ajouter un serveur MCP peut en revanche créer une couche supplémentaire sans bénéfice immédiat.
Notre règle pratique est de partir du besoin : combien de clients doivent utiliser la capacité, faut-il une découverte dynamique, quelles autorisations sont nécessaires et quel niveau d’isolation est attendu ? Ensuite seulement, choisissez le protocole. Comme pour l’évaluation d’un outil IA, une architecture doit être jugée sur une tâche réelle, pas uniquement sur sa popularité.
La compatibilité n’est pas une autorisation
Un serveur MCP peut exposer des actions puissantes et des descriptions d’outils qui entrent dans le contexte du modèle. OWASP recommande notamment le moindre privilège, la validation des entrées et sorties, l’isolation des serveurs, la vérification des sources et une confirmation humaine pour les opérations sensibles.
Avant d’installer un serveur inconnu ou de lui donner des jetons d’accès, lisez notre checklist de sécurité MCP. Le protocole facilite la connexion ; il ne décide pas à votre place de ce qui doit être digne de confiance.
Une dernière question ?
MCP est-il une API ?
MCP est un protocole d’intégration. Un serveur MCP peut s’appuyer sur une API existante, mais il ajoute des conventions destinées aux clients et applications d’IA.
MCP remplace-t-il le function calling ?
Non. Le function calling décrit généralement la sélection de fonctions par un modèle dans un produit donné ; MCP standardise l’échange entre clients et serveurs et couvre aussi des ressources et des prompts.
Faut-il utiliser MCP pour chaque intégration IA ?
Non. Pour une intégration unique et simple, une API directe peut être plus légère. MCP devient plus intéressant lorsque plusieurs clients doivent découvrir et utiliser les mêmes capacités.