MCP, c’est quoi ? Comprendre le Model Context Protocol

MCP signifie Model Context Protocol. C’est un protocole ouvert qui définit une manière structurée de connecter une application d’IA à des outils, des ressources et des modèles de prompts fournis par un serveur. L’idée est de remplacer une succession d’intégrations ad hoc par une interface commune : un client peut découvrir les capacités d’un serveur, demander une ressource ou appeler un outil selon des règles définies.

MCP ne donne pas à une IA un accès magique à vos données. Un serveur MCP doit être installé, configuré et autorisé. Les permissions, les secrets et le choix des outils restent sous le contrôle de la personne ou de l’organisation qui l’exécute. Cette frontière est essentielle : un protocole d’intégration n’est pas une garantie de sécurité ni une autorisation générale sur un système.

Cette page est la référence d’architecture : concepts, rôles, différence avec une API et risques. Si vous cherchez plutôt un parcours pratique sans jargon, commencez par MCP pour débutants : tester en environnement contrôlé.

Le problème que MCP cherche à résoudre

Une application d’IA devient plus utile lorsqu’elle peut s’appuyer sur du contexte actuel : documentation interne, système de tickets, base de connaissances ou outil de développement. Sans protocole commun, chaque connexion demande souvent une intégration spécifique, avec son propre format, ses erreurs et ses règles d’authentification.

MCP définit des concepts communs pour réduire cette fragmentation. Au lieu de demander à chaque client d’inventer la manière de lister des outils ou de lire une ressource, le protocole décrit des messages et capacités standardisés. Cela peut faciliter l’interopérabilité, mais ne supprime pas le travail de conception : il faut toujours décider quelles données exposer et quelles actions autoriser.

Les principaux éléments d’une architecture MCP

Le client

Le client est l’application qui se connecte à un serveur MCP. Il peut s’agir d’un environnement de développement, d’un assistant conversationnel ou d’une application interne. Le client découvre les capacités proposées et présente ou exécute les interactions selon son propre modèle de permission.

Le client n’est pas nécessairement le modèle d’IA lui-même. C’est la couche qui orchestre l’échange, gère le contexte et décide comment les résultats sont montrés. Cette distinction aide à comprendre pourquoi deux applications peuvent utiliser le même serveur MCP tout en proposant une expérience différente.

Le serveur

Le serveur expose des capacités : outils, ressources ou prompts. Il peut être local, connecté à un service web ou hébergé par une organisation. Sa provenance et son exécution comptent énormément. Un serveur qui lit un dossier local, envoie un message ou interroge une base n’a pas le même niveau de risque.

Avant d’utiliser un serveur, vérifiez son éditeur, son code ou sa documentation, les données auxquelles il accède, les variables d’environnement attendues et la manière dont il journalise les appels. Une liste communautaire est un point de départ, pas une validation de sécurité.

Les outils

Un outil est une action qu’un serveur peut mettre à disposition. Conceptuellement, un outil pourrait rechercher une documentation, créer un ticket ou lancer une requête. Un bon outil décrit ses paramètres et son résultat, ce qui permet au client de demander une confirmation ou de détecter une entrée invalide.

Les outils d’écriture méritent une attention spéciale. Un outil capable de modifier une issue, publier un fichier ou exécuter une commande ne doit pas être activé dans un premier essai sans cible de test, journalisation et procédure de retour arrière.

Les ressources et prompts

Une ressource représente généralement une information que le serveur peut fournir, comme un document ou une donnée structurée. Les prompts peuvent proposer des modèles d’interaction. Dans les deux cas, le contenu reçu est une donnée externe : il ne doit pas pouvoir modifier les règles de sécurité du client ni imposer une action hors périmètre.

Exemple conceptuel

Imaginez une équipe qui possède une base de documentation technique. Un serveur MCP en lecture seule expose une recherche sur cette documentation. Un client peut demander « trouve la procédure de rotation des clés » et recevoir des extraits pertinents. Le serveur ne doit pas pour autant donner le droit de faire tourner une clé, de lire un coffre de secrets ou de déployer un service.

Ce scénario fonctionne parce que le périmètre est clair : données de documentation, recherche uniquement, aucun effet de bord. Il est beaucoup plus facile à auditer qu’un serveur générique qui peut parcourir tous les fichiers, appeler toutes les APIs et exécuter des commandes arbitraires.

MCP est-il une API classique ?

MCP et une API classique sont complémentaires. Une API décrit souvent les opérations d’un service métier : créer une commande, lire un client, mettre à jour un dossier. MCP fournit un protocole pour qu’un client d’IA découvre et utilise des capacités via un serveur. Un serveur MCP peut s’appuyer sur une API existante, mais il ajoute une couche de description, d’orchestration et de contexte.

La différence pratique est dans la cible. Une API est construite pour les applications qui connaissent son contrat. MCP est conçu pour standardiser la connexion entre applications d’IA et fournisseurs de contexte ou d’outils. Les mêmes exigences restent valables : authentification, autorisation, validation d’entrée, journalisation et gestion d’erreur.

Question	API métier	Serveur MCP
Objectif principal	Fonctionnalités d’un service	Contextes et outils pour client d’IA
Contrat	Endpoints et schémas du service	Capacités, outils, ressources et messages MCP
Risque à contrôler	Authentification, données, effets de bord	Les mêmes, plus contexte transmis au client IA
Bon premier usage	Une fonction applicative bien définie	Une ressource ou recherche en lecture seule

Les risques à connaître

Le premier risque est le surpérimètre. Installer un serveur qui voit tout le disque ou utilise un token à droits étendus rend une erreur plus coûteuse. Commencez toujours avec le dossier, compte ou base de démonstration minimum.

Le deuxième risque est l’injection de prompt. Une ressource, une issue ou un document retourné par un serveur peut contenir des instructions malveillantes. Traitez son texte comme des données non fiables. Les règles du projet et les confirmations du client priment sur ce que le contenu demande.

Le troisième risque est la confusion entre test local et production. Un appel MCP vers une API réelle peut créer une donnée, envoyer un message ou déclencher un coût. Les essais doivent être isolés, observables et réversibles.

Comment commencer sans danger

Définissez une seule question à résoudre, par exemple rechercher une page de documentation.
Choisissez un serveur officiel ou audité, avec une capacité lecture seule si possible.
Vérifiez sa configuration et retirez toute valeur secrète des fichiers partagés.
Testez une ressource sur un environnement de démonstration.
Journalisez l’outil appelé, la donnée lue et le résultat avant d’envisager une action d’écriture.

Après chaque étape, vérifiez que le périmètre n’a pas grandi : pas de nouveau dossier, pas de nouvelle permission, pas de donnée de production. Si une étape demande un accès qui n’était pas prévu, arrêtez le pilote et faites valider le besoin.

FAQ

MCP est-il réservé à Claude ?

Non. MCP est un protocole ouvert ; son utilisation dépend toutefois des clients et serveurs qui le prennent en charge.

Faut-il coder un serveur MCP pour l’utiliser ?

Non. Vous pouvez utiliser un serveur existant après avoir vérifié sa provenance et son périmètre. Écrire votre propre serveur demande des compétences de développement et de sécurité.

MCP rend-il mon assistant plus intelligent ?

Il peut lui fournir du contexte ou des outils, mais la qualité dépend toujours des données, du client, des permissions et de la vérification humaine.

Un serveur MCP est-il sûr par défaut ?

Non. Évaluez chaque serveur, ses dépendances, ses identifiants et les capacités qu’il expose.

Peut-on connecter MCP à une base de production ?

Ce n’est pas un bon premier usage. Utilisez une copie anonymisée ou un environnement de test avec un compte limité, puis faites une revue dédiée avant tout élargissement.

Conclusion

MCP est une façon standardisée de relier un client d’IA à du contexte et des outils. Son intérêt vient de l’interopérabilité ; sa sécurité dépend de la discipline appliquée autour : source vérifiée, permissions minimales, données limitées et actions toujours contrôlées.

Parcours MCP et sécurité des agents

Commencez par les notions du protocole présentées plus haut, puis voyez comment comprendre MCP sans exécuter de code, connecter MCP à PostgreSQL, sécuriser un serveur MCP, auditer MCP et les skills et utiliser MCP avec Claude Code.

Sources et limites

Model Context Protocol — introduction : concepts officiels du protocole.
Model Context Protocol — specification : spécification à consulter selon la version mise en œuvre.
Model Context Protocol — security best practices : considérations de sécurité.

Les versions du protocole et les capacités des clients évoluent. Cet article décrit des concepts généraux et ne valide aucun serveur tiers.