Architecture MCP : analyse technique complète avec diagrammes

Une analyse technique de l’architecture MCP qui couvre les hôtes, les clients et les serveurs, la couche de données JSON-RPC, les options de transport, les configurations multilocataires, les risques de sécurité et une présentation en huit étapes d’une requête, avec diagrammes.

Diagram of MCP architecture: an AI application exchanges requests with an MCP server, which provides tools, resources, and prompts.

L’architecture MCP est l’ensemble fondamental de composants et de règles de communication qui rendent possible le MCP (Model Context Protocol). Le MCP est une norme à code source ouvert, et l’architecture MCP est l’infrastructure sous-jacente sur laquelle il repose.

Toute architecture MCP comprend trois composants essentiels, autour desquels elle est construite : un hôte, un client et un serveur. On décrit souvent le cadre de communication du MCP comme étant composé d’une couche de données et d’une couche de transport. La couche de données est l’ensemble des règles qui régissent le format des messages (les requêtes MCP sont envoyées en JSON-RPC 2.0). La couche de transport achemine ces messages, au moyen de Streaming HTTP pour les connexions externes.

Qu’est-ce que l’architecture MCP?

L’architecture MCP est un cadre de serveur qui met en œuvre le Model Context Protocol, une norme ouverte permettant de connecter des modèles d’IA à des outils, à des ressources comme des bases de données et à des invites qui enrichissent le contexte d’entrée. On les appelle collectivement des « primitives ». En fin de compte, l’architecture MCP permet aux LLM de découvrir les outils disponibles et d’exécuter des flux de travail, sans nécessiter de mises à jour régulières côté client.

Depuis son lancement par Anthropic, l’architecture MCP est devenue largement utilisée dans les flux de travail d’IA. C’est en grande partie parce qu’elle remplace des systèmes plus exigeants en maintenance, comme ceux bâtis autour de multiples connexions API, sans sacrifier la performance. Comme toutes les fonctionnalités disponibles se trouvent derrière le serveur MCP, une seule connexion est nécessaire, et les mises à jour et les ajouts sont immédiatement accessibles à l’application cliente.

Composants de l’architecture MCP : hôtes, clients et serveurs

Le MCP permet aux LLM de découvrir et d’appeler les outils, les invites et les ressources qui leur sont accessibles, soit sur le système local de l’application hôte, soit auprès d’un fournisseur externe.

Dans le cas des outils, qui donnent accès à des fonctionnalités externes, la découverte consiste pour l’hôte à effectuer un appel tools/list au serveur MCP afin de savoir quels outils sont disponibles. Le LLM (ou, dans certains cas, l’hôte) peut ensuite lire les descriptions des outils disponibles et les demander au besoin. Les invites et les ressources suivent un processus semblable.

Cela contraste avec l’architecture sur mesure fondée sur des API, qui a été la norme en développement logiciel, et dans laquelle les fonctionnalités externes à l’application devaient être appelées au moyen de connexions dédiées et de requêtes au format précis.

Hôte

L’application hôte est la plateforme d’orchestration centrale et se connecte à un LLM. Des outils bien connus comme Perplexity et Claude Desktop peuvent jouer le rôle d’hôtes au sein d’un système MCP.

Dans un flux de travail simple, l’utilisateur pose une question au moyen de l’interface de clavardage. Le composant orchestrateur de l’hôte ajoute ensuite du contexte à la question, en indiquant au LLM quelles primitives MCP sont disponibles, accompagnées d’une description de leurs capacités.

Client

Le client est un composant logiciel de l’application d’IA. Le MCP fournit une interface standard qui permet au client de communiquer avec des serveurs MCP internes et externes selon les instructions de l’hôte ou du LLM. Son rôle consiste à établir une connexion, à formater les messages JSON-RPC, à envoyer des requêtes et à recevoir des réponses.

Les termes « hôte MCP » et « client MCP » sont parfois employés de façon interchangeable. La distinction est pourtant utile, car un hôte, comme Perplexity, peut orchestrer plusieurs clients MCP à la fois. Un flux de travail d’IA complexe pourrait nécessiter l’accès à des dizaines, voire des centaines de serveurs MCP distincts, et chacun utilisera une connexion distincte.

Serveur

Le serveur expose tous les outils que l’outil basé sur l’IA peut utiliser. Du point de vue de l’architecture, le serveur MCP interprète la requête entrante et, au besoin, se connecte aux primitives demandées.

Les serveurs MCP peuvent donner accès à trois catégories de primitives :

  • Outils : Il s’agit essentiellement de fonctionnalités logicielles externes. Dans une approche traditionnelle fondée sur des API, une application d’analyse Web pourrait récupérer des données au moyen d’une requête formatée envoyée à un serveur externe. Dans l’architecture MCP, toutes les fonctionnalités tierces d’un fournisseur sont accessibles au moyen d’une seule connexion, et les requêtes sont créées selon des règles de formatage standard.
  • Ressources : Les ressources sont des sources de données qui fournissent du contexte en lecture seule. Les schémas de base de données en sont un bon exemple. Le serveur MCP expose les diverses sources d’information accessibles à l’hôte. Si l’hôte interroge la base de données, par exemple au moyen d’une recherche SQL générée par un LLM, on considère qu’il s’agit d’une requête d’outil.
  • Invites : Il s’agit de modèles d’invites réutilisables qui aident les LLM à accomplir des tâches précises. Un utilisateur ou un hôte appellera une invite plutôt qu’un outil parce qu’il lui faut des instructions toutes faites pour accomplir une tâche. Souvent, les tâches prédéfinies d’une application hôte, comme l’option « réviser le code » ou « analyser des données », sont stockées sous forme d’invites que l’utilisateur peut sélectionner.

Il convient aussi de noter que le MCP et les API ne sont pas des technologies mutuellement exclusives. Le serveur MCP peut exposer des appels d’API disponibles en réponse à une requête de découverte. L’essentiel, c’est qu’il revient au fournisseur MCP, et non au client, de les maintenir.

Qu’est-ce que la couche de données dans l’architecture MCP?

Dans l’architecture MCP, la couche de données est l’ensemble des règles qui définissent le format des requêtes, des réponses et des notifications. Le langage standard des messages est JSON-RPC.

Toute architecture MCP suit un processus de base : (1) initialisation et découverte par l’hôte, (2) réponse du serveur MCP et (3) appel par l’hôte (parfois décidé par le LLM), chaque étape correspondant à un message JSON distinct.

Voyons comment fonctionne la découverte d’outils à l’aide de deux exemples (qui pourraient aussi s’appliquer aux ressources ou aux invites) :

  • Découvrir les outils avant la génération par le LLM : L’hôte initialise le client MCP, qui envoie une requête tools/list (la liste des outils disponibles du serveur MCP). Le LLM examine cette liste pendant le processus de génération et détermine si un outil, une ressource ou une invite en particulier est nécessaire.
  • Offrir au LLM la possibilité de lancer une recherche : Dans un système agentique, l’hôte ajoute une option de découverte, comme search-tools, à l’entrée de contexte, et le LLM peut demander une recherche au besoin.

Les outils, qui sont en grande partie des fonctionnalités d’applications externes, sont généralement sélectionnés par le LLM ou l’hôte. Les ressources et les invites sont habituellement demandées à l’initiative de l’utilisateur ou par l’hôte.

Voici à quoi ressemble une requête tools/list envoyée à un serveur MCP par une application de notes fictive :

json
{ "jsonrpc": "2.0", "id": 101, "method": "tools/list", "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientInfo": { "name": "notes-app-client", "version": "0.1.0" }, "io.modelcontextprotocol/clientCapabilities": {} } } }

Dans cet exemple, “id”:101 identifie la requête au moyen d’un ID pour que le client puisse faire correspondre les réponses, et le champ “params” contient des renseignements supplémentaires sur le client, comme son nom (notes-app-client) et ses capacités.

En réponse, le serveur MCP renverra des définitions d’outils, qui comprennent les noms des outils disponibles et les détails qui s’y rattachent. Par exemple, la liste pourrait comprendre un outil add-task qui permet à l’application de notes de créer des tâches dans une application de gestion des tâches ou de calendrier connectée, en attribuant à chaque tâche un titre et une priorité.

Voici à quoi pourrait ressembler une requête :

json
{ "jsonrpc": "2.0", "id": 202, "method": "tools/call", "params": { "name": "add-task", "arguments": { "title": "Review the draft", "priority": "medium" }, "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientInfo": { "name": "notes-app-client", "version": "0.1.0" }, "io.modelcontextprotocol/clientCapabilities": {} } } }

Le champ “method” indique au serveur MCP qu’il s’agit d’un appel d’outil, “name” précise l’outil à appeler et “arguments” fournit les entrées requises.

Qu’est-ce que la couche de transport dans l’architecture MCP?

Si la couche de données est le quoi de la connexion entre un client et un serveur MCP, la couche de transport en est le comment. Elle définit la façon dont les messages circulent : le canal précis et les règles qui régissent la transmission des requêtes et des réponses.

Le MCP offre deux modes de transport :

  • Entrée/sortie standard : Ce mode est utilisé lorsque le serveur MCP s’exécute dans le même environnement local que l’application hôte. Le client écrit la requête JSON dans l’entrée standard du serveur. Le serveur la lit, effectue l’opération demandée et écrit la réponse dans la sortie standard.
  • Streamable HTTP : Lorsque le serveur MCP s’exécute à l’extérieur de l’application hôte, le client MCP envoie des requêtes au serveur au moyen de HTTP POST. Le serveur répond soit par un seul message JSON, soit par un flux Server-Sent Events (SSE), un canal « d’écoute » persistant qui lui permet de renvoyer plusieurs messages au fil du temps.

Qu’est-ce que l’architecture MCP multilocataire?

L’architecture MCP multilocataire est un type d’implémentation qui peut servir plusieurs utilisateurs (locataires) simultanément.

Ici, un locataire peut être une personne, un groupe de personnes ou une organisation. L’implémentation peut consister à exécuter un serveur MCP distinct pour chaque locataire, à donner accès à un seul serveur partagé ou à placer un ensemble de serveurs derrière une passerelle centrale. Lorsqu’une passerelle est utilisée, elle achemine les requêtes vers les bons points de terminaison en fonction de l’identité de l’utilisateur ou de la nature de la requête.

Elle fonctionne selon le même principe de base que l’architecture MCP standard, mais les requêtes de chaque utilisateur s’exécutent dans leur propre espace de travail (même si cela implique des ressources partagées) et sont authentifiées séparément. Elle est courante en entreprise, et les ressources partagées sont souvent privilégiées, car l’exécution de plusieurs serveurs MCP serait inutilement coûteuse.

Diagramme de l’architecture MCP : présentation étape par étape

À quoi ressemble concrètement une requête MCP de bout en bout? Elle comporte huit étapes principales, chacune faisant intervenir un composant distinct de l’architecture.

Voici à quoi ressemble concrètement un appel d’outil MCP, en reprenant l’exemple précédent d’une application de notes connectée à un service de gestion des tâches :

  1. Découverte des outils : L’application de notes (hôte) utilise son client MCP pour demander les outils disponibles du serveur au moyen d’une requête tools/list. Le serveur renvoie leurs noms, leurs descriptions et les entrées attendues, y compris celles de l’outil add-task. Cette étape peut avoir lieu avant que vous soumettiez une invite.
  2. Entrée de l’utilisateur : Vous soumettez une demande à l’application de notes basée sur un LLM au moyen du robot conversationnel intégré, par exemple : « Crée une tâche dans mon calendrier pour réviser ma nouvelle ébauche, avec une priorité moyenne. »
  3. Traitement par le modèle : L’hôte envoie votre demande et les définitions d’outils pertinentes au LLM.
  4. Sélection de l’outil : Le LLM génère une requête d’outil structurée qui précise l’outil et ses entrées : add-task avec title: Review the draft et priority: Medium. L’hôte vérifie si l’action est autorisée et transmet la requête au client MCP, qui envoie un message JSON-RPC.
  5. Requête : Le client MCP envoie une requête tools/call à son serveur MCP.
  6. Exécution de l’outil : Le serveur MCP appelle l’API de l’application de gestion des tâches pour créer une nouvelle tâche avec le titre et la priorité indiqués.
  7. Retour du résultat : Le serveur renvoie le résultat au client MCP, qui le transmet à l’hôte. L’hôte l’ajoute aux renseignements fournis au LLM.
  8. Génération de la réponse : Le LLM utilise le résultat pour générer une réponse destinée à l’utilisateur, par exemple : « J’ai créé une tâche pour réviser l’ébauche, avec une priorité moyenne. »

En quoi l’architecture MCP diffère-t-elle de l’architecture API traditionnelle?

On confond souvent le MCP et l’architecture API traditionnelle, mais ce sont des technologies complémentaires. Le MCP a été conçu spécifiquement pour les applications basées sur l’IA. Il élimine le lourd fardeau de maintenance lié à la mise en œuvre et à la gestion de multiples connexions API codées en dur.

En fournissant à une application hôte une seule connexion par fournisseur de fonctionnalités ou par ressource interne, le MCP aide à remédier au problème d’une entrée de contexte surchargée (qui énumère toutes les API) ou de scripts d’application limités fondés sur des API.

Les serveurs MCP peuvent plutôt exposer des API (ou, plus exactement, les fonctionnalités qui appellent des API) dans leur liste d’outils. Chaque fois qu’un fournisseur met à jour son application et qu’il y a une nouvelle API, ou si la documentation change, il lui suffit de mettre à jour le serveur MCP. Aucune modification du code n’est requise du côté de l’application hôte.

L’architecture MCP est-elle sécurisée?

La sécurité du MCP fait l’objet de nombreux débats depuis son lancement. Bien qu’il soit généralement considéré comme une technologie sûre, il comporte plusieurs risques de sécurité, dont bon nombre sont plus marqués dans les implémentations d’architecture complexes.

L’architecture MCP présente les faiblesses potentielles suivantes :

  • Injection d’invite : Un utilisateur insère une invite malveillante dans des données externes, que le modèle d’IA interprète à tort comme une instruction.
  • Accès à privilèges excessifs : Les serveurs MCP peuvent exposer un grand nombre d’outils à un modèle d’IA, ce qui peut accroître le risque de problèmes de sécurité (le rayon d’impact).
  • Fuites de données accidentelles : Des implémentations mal configurées peuvent entraîner la transmission à un LLM de renseignements sensibles, comme des clés API ou des identifiants de base de données.
  • Manipulation du système local : Les serveurs MCP locaux sont tout aussi vulnérables aux problèmes du système local, comme les scripts malveillants, que n’importe quelle autre application, avec le problème supplémentaire qu’ils peuvent avoir des effets néfastes en aval sur les systèmes d’IA agentique.

Aucun de ces problèmes n’est insurmontable. Souvent, des mesures éprouvées suffisent pour assurer la sécurité du système. Des mesures comme la présence d’un humain dans la boucle, l’application de contrôles stricts sur les données sensibles et la protection contre les attaques visant les serveurs sont toutes des pratiques courantes.

Quel avenir pour l’architecture MCP?

Le MCP s’est révélé une norme ouverte utile et populaire auprès des développeurs. Il résout bon nombre des problèmes liés aux API codées en dur dans les applications basées sur des LLM et réduit considérablement la charge de programmation des développeurs.

À l’avenir, l’architecture hôte-serveur sous-jacente du MCP restera presque certainement la même. Les innovations futures porteront sur des capacités agentiques avancées dans les flux de travail à plusieurs étapes.

De plus, il faudra des mesures de protection plus robustes à mesure que ces fonctionnalités agentiques seront mises en œuvre, ainsi qu’une architecture évolutive, en particulier dans la couche de transport, à mesure que les systèmes d’IA deviendront plus étendus et complexes.