Après avoir passé du temps à connecter des modèles de langage à mes propres outils et bases de données, j’ai réuni les concepts essentiels du protocole MCP. Voici ce qu’il faut retenir de son architecture :
- Une structure client-serveur robuste : Le système s’appuie sur une hiérarchie stricte entre un Hôte, un Client et un Serveur pour sécuriser l’accès aux données.
- La fin de la dette d’intégration en N×M : Au lieu d’écrire un connecteur spécifique pour chaque couple outil/modèle, un seul serveur MCP suffit pour rendre une source de données accessible à n’importe quel client compatible.
- La triade de capacités (les primitives de base) : Les serveurs exposent leurs fonctionnalités à travers trois piliers : les Ressources, les Outils et les Prompts.
- Deux couches bien distinctes : Le protocole sépare le contenu (la couche de Données) du contenant (la couche de Transport).
Pourquoi le serveur MCP résout un vrai problème d’intégration
Par nature, les grands modèles de langage sont isolés du monde réel. Ils ne peuvent pas accéder à mes données privées, manipuler mes fichiers locaux ou interroger des API sans une aide externe. Pendant longtemps, la seule solution consistait à coder des connecteurs sur mesure pour chaque fonctionnalité. (C’était, je dois l’avouer, un travail particulièrement fastidieux et répétitif).
Imaginez la scène : si je souhaite connecter 5 assistants IA différents (comme Claude, ChatGPT, Cursor ou Copilot) à 5 sources de données d’entreprise (comme GitHub, Jira, PostgreSQL et Slack), je devais auparavant développer et maintenir pas moins de 25 intégrations distinctes. C’est ce qu’on appelle la dette d’intégration en N×M. Le protocole MCP résout ce problème de plusieurs manières :
- La standardisation : On écrit un seul serveur MCP pour une source de données spécifique. N’importe quelle application compatible avec le protocole peut alors s’y connecter instantanément, créant un véritable écosystème modulaire.
- Un cadrage strict du contexte : Les modèles de langage ont parfois du mal à formuler des requêtes complexes sans se tromper. Le serveur MCP publie explicitement ses outils, ses ressources et ses prompts via un schéma JSON-RPC 2.0 clair. En indiquant précisément à l’IA les paramètres attendus, on réduit drastiquement les risques d’hallucinations et d’erreurs d’exécution.
- Une barrière de sécurité indispensable : Laisser une IA exécuter des commandes directement sur une machine de production est impensable. Le serveur MCP agit comme un intermédiaire sécurisé. L’utilisateur ou l’application hôte garde le contrôle pour valider, limiter ou rejeter n’importe quelle requête générée par le modèle.
- Le découplage des données : Dans un cadre professionnel, la confidentialité est cruciale. Le serveur MCP permet de nettoyer, filtrer et tronquer les informations sensibles en local ou au sein d’un réseau privé virtuel (VPC). Seul le contexte textuel strictement nécessaire à la réponse est transmis à l’IA, évitant ainsi toute fuite de données massives vers le cloud.
Les trois rôles de l’architecture MCP
Le fonctionnement du protocole repose sur une hiérarchie claire et descendante :
L’Hôte MCP : C’est l’environnement ou l’application de travail de l’utilisateur où tourne concrètement le modèle ou l’agent IA. Dans mon quotidien de développeur, cela correspond par exemple à des éditeurs de code ou des applications de bureau comme Cursor, VS Code ou Claude Desktop.
Le Client MCP : Il s’agit de la couche logicielle située à l’intérieur de l’application hôte. Ce client a pour rôle d’établir la session, de maintenir la connexion et de traduire nos requêtes de haut niveau en instructions standardisées compréhensibles par le protocole.
Le Serveur MCP : Ce sont des programmes légers et hautement modulaires qui exposent des compétences externes spécifiques. Le serveur s’interface directement avec la ressource physique sous-jacente — un système de fichiers local, une base de données ou une API web — pour la mettre à disposition du client.
Les deux couches du protocole : le “Quoi” et le “Comment”
Comment s’y retrouver dans les échanges entre clients et serveurs ? Le protocole sépare intelligemment la logique métier des détails physiques de la communication grâce à deux couches indépendantes :
1. La couche de Données (Le “Quoi”) : Elle gère la sémantique, la structure et le formatage de tous les messages échangés.
- Elle s’appuie sur le protocole JSON-RPC 2.0 pour structurer les requêtes, les réponses et les notifications de manière standardisée.
- Elle définit les trois primitives de base (Outils, Ressources, Prompts) présentées au modèle.
- Elle prend en charge la phase de négociation lors de la connexion initiale pour vérifier la compatibilité des versions et des fonctionnalités.
2. La couche de Transport (Le “Comment”) : Elle se charge d’établir, de sécuriser et de maintenir la connexion physique entre le client et le serveur.
- Elle s’occupe de la mise en paquets, de l’analyse et du multiplexage des flux sans jamais modifier le contenu des messages.
- Elle gère l’authentification et la sécurité des sessions en supportant des standards comme OAuth, les clés API ou les jetons d’accès.
- Elle propose deux modes de transport natifs : le protocole STDIO (Standard Input/Output) pour les communications locales et le couple SSE (Server-Sent Events) / HTTP pour les liaisons réseau distantes.
La triade de capacités (les trois piliers)
Pour fournir un contexte exploitable et des capacités d’action à l’IA, le serveur MCP expose trois types d’abstractions structurelles :
Les Ressources : C’est le pilier du contexte. Il s’agit de données textuelles en lecture seule qui permettent de nourrir la réflexion du modèle de langage et de limiter les erreurs de raisonnement. Cela englobe le contenu de fichiers locaux, des enregistrements de bases de données, des journaux système (logs) ou des retours d’API statiques.
Les Outils : C’est le pilier de l’action. Ce sont des fonctions exécutables dotées de paramètres précis, que l’IA peut choisir de déclencher après approbation du client. Cela permet au modèle d’agir sur son environnement en écrivant un fichier sur le disque, en exécutant un script bash, en lançant une recherche sur le web ou en mettant à jour un dépôt GitHub.
Les Prompts : C’est le pilier de l’orientation. Le serveur expose ici des modèles d’instructions préconfigurés et des raccourcis textuels pour simplifier les tâches courantes. Un exemple classique est un prompt de revue de code qui formate automatiquement les instructions système en y injectant directement le résultat d’un différentiel git récent.
Trois schémas d’architecture à la loupe
Il n’existe pas une unique “meilleure” architecture pour le MCP. D’après mes tests et mes observations, le choix du déploiement dépend principalement de la sécurité requise, du nombre d’utilisateurs et des contraintes d’infrastructure.
1. L’architecture locale directe
C’est la configuration la plus simple et la plus courante pour un développeur indépendant. Tout s’exécute sur une seule et même machine locale. L’application hôte (par exemple Claude Desktop) lance directement le serveur MCP sous la forme d’un processus enfant.
- Transport : STDIO (Standard Input/Output). Les échanges passent directement par les flux d’entrée et de sortie standard (stdin et stdout).
- Usage idéal : L’accès aux fichiers locaux, l’analyse d’une base de données locale, le monitoring système ou le prototypage rapide.
- Points forts : Latence quasi nulle, aucune dépendance réseau et un excellent niveau de sécurité puisque aucune donnée ne quitte le poste de travail.
- Points faibles : La configuration reste prisonnière de la machine hôte ; elle ne peut pas être partagée facilement avec d’autres collaborateurs.
2. L’architecture distante SSE
Ce schéma permet de découpler l’application hôte de l’accès aux données en hébergeant les serveurs MCP dans le cloud, sur des serveurs privés ou dans des conteneurs isolés. C’est l’architecture privilégiée pour le travail en équipe.
- Transport : Un modèle hybride combinant SSE (Server-Sent Events) pour la transmission en continu du serveur vers le client, et des requêtes HTTP POST classiques pour les messages du client vers le serveur.
- Usage idéal : L’interrogation de bases de données d’entreprise centralisées, l’appel d’API privées ou l’accès à une base de connaissances partagée.
- Points forts : Gestion centralisée des serveurs, mises à jour transparentes sans intervention sur les postes des utilisateurs et scalabilité simplifiée.
- Points faibles : Nécessite une infrastructure réseau robuste, impose la mise en place de mécanismes d’authentification (comme OAuth) et introduit une légère latence réseau.
3. L’architecture Passerelle / Multiplexeur
Dès que le nombre d’outils et de services augmente, configurer des dizaines de serveurs MCP indépendants sur chaque poste devient rapidement ingérable. Cette architecture introduit un intermédiaire pour centraliser le trafic.
- Transport : Hybride (généralement SSE en amont avec le client, et STDIO ou SSE en aval avec les serveurs d’arrière-plan).
- Fonctionnement : Le client IA se connecte à un routeur unique (la passerelle MCP). C’est cette passerelle qui se charge ensuite de rediriger de manière dynamique les requêtes vers les micro-serveurs appropriés selon les outils ou les ressources demandés.
- Usage idéal : Les plateformes d’agents complexes, les grandes équipes exploitant des dizaines d’outils spécialisés et les environnements multi-locataires.
- Points forts : Simplification majeure de la configuration des clients, centralisation de la sécurité (pare-feu unique) et découverte dynamique des outils disponibles.
- Points faibles : Complexité d’infrastructure accrue et création d’un point d’échec unique si la passerelle ne dispose pas d’une répartition de charge adéquate.