Architecture MCP : analyse technique complète avec schémas

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 multi-locataires, les risques de sécurité et une explication en huit étapes d’une requête, avec schémas.

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 open source, et l’architecture MCP est l’infrastructure sous-jacente sur laquelle il repose.

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

Qu’est-ce que l’architecture MCP ?

L’architecture MCP est un framework serveur qui implémente 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 prompts qui enrichissent le contexte d’entrée. On les appelle collectivement des « primitives ». En définitive, l’architecture MCP permet aux LLM de découvrir quels outils sont disponibles et d’exécuter des flux de travail, sans nécessiter de mises à jour régulières côté client.

Depuis son introduction par Anthropic, l’architecture MCP est devenue largement utilisée dans les flux de travail d’IA. Cela s’explique en grande partie par le fait qu’elle remplace des systèmes plus exigeants en maintenance, comme ceux construits autour de multiples connexions API, sans sacrifier les performances. Comme toutes les fonctionnalités disponibles se trouvent derrière le serveur MCP, une seule connexion est nécessaire, et les mises à jour et 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, prompts et ressources à leur disposition, 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 auprès du serveur MCP afin de savoir quels outils sont disponibles. Le LLM (ou, dans certains cas, l’hôte) peut alors lire les descriptions des outils disponibles et les demander selon les besoins. Les prompts et les ressources suivent un processus similaire.

Cela contraste avec l’architecture sur mesure fondée sur des API, qui a longtemps été la norme en développement logiciel et dans laquelle les fonctionnalités extérieures à l’application devaient être appelées via des connexions dédiées, avec des 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 via l’interface de chat. 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 permettant au client de communiquer avec des serveurs MCP internes et externes en fonction des 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 manière 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 peut nécessiter l’accès à des dizaines, voire des centaines de serveurs MCP distincts, chacun utilisant sa propre connexion.

Serveur

Le serveur expose tous les outils que l’outil basé sur l’IA peut utiliser. D’un point de vue architectural, le serveur MCP interprète la requête entrante et, si nécessaire, 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 via 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 un contexte en lecture seule. Les schémas de base de données en sont un bon exemple. Le serveur MCP expose les différentes sources d’information mises à la disposition de 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, il s’agit d’une requête d’outil.
  • Prompts : il s’agit de modèles de prompts réutilisables qui aident les LLM à effectuer des tâches spécifiques. Un utilisateur ou un hôte appelle un prompt plutôt qu’un outil lorsqu’il a besoin d’instructions prêtes à l’emploi pour accomplir une tâche. Souvent, les tâches prédéfinies d’une application hôte, comme l’option « examiner le code » ou « analyser des données », sont stockées sous forme de prompts que l’utilisateur peut sélectionner.

Il convient également 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 est que c’est au fournisseur MCP, et non au client, d’en assurer la maintenance.

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

La couche de données de l’architecture MCP 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 de l’hôte (parfois décidé par le LLM), chaque étape correspondant à un message JSON distinct.

Voyons comment fonctionne la découverte d’outils à travers deux exemples (qui pourraient s’appliquer aux ressources ou aux prompts) :

  • Découvrir les outils avant la génération du LLM : l’hôte lance le client MCP, qui envoie une requête tools/list (la liste des outils disponibles du serveur MCP). Le LLM l’examine pendant le processus de génération et détermine si un outil, une ressource ou un prompt particulier est nécessaire.
  • Donner 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, au contexte d’entrée, et le LLM peut demander une recherche si nécessaire.

Les outils, qui sont pour l’essentiel des fonctionnalités d’applications externes, sont généralement sélectionnés par le LLM ou par l’hôte. Les ressources et les prompts sont le plus souvent demandés à 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 prise 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 afin que le client puisse faire correspondre les réponses, et le champ “params” contient des informations supplémentaires sur le client, comme le nom du client (notes-app-client) et ses capacités.

En réponse, le serveur MCP renvoie les définitions des outils, qui comprennent les noms des outils disponibles et leurs détails associés. Par exemple, la liste peut inclure un outil add-task qui permet à l’application de prise de notes de créer des tâches dans une application de gestion de 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 quel 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 représente le quoi de la connexion entre un client et un serveur MCP, la couche de transport en est le comment. Elle définit la manière dont les messages circulent : le canal spécifique et les règles qui régissent la transmission des requêtes et des réponses.

Le MCP dispose de 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 sur l’entrée standard du serveur. Le serveur la lit, effectue l’opération demandée et écrit la réponse sur la sortie standard.
  • Streamable HTTP : lorsque le serveur MCP s’exécute en dehors de l’application hôte, le client MCP envoie des requêtes au serveur via HTTP POST. Le serveur répond soit par un message JSON unique, 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 capable de 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, à fournir l’accès à un serveur partagé unique ou à placer un ensemble de serveurs derrière une passerelle centrale. Lorsqu’une passerelle est utilisée, elle achemine les requêtes vers les points de terminaison appropriés en fonction de l’identité de l’utilisateur ou de la nature de la requête.

Elle repose sur 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 exécuter plusieurs serveurs MCP serait inutilement coûteux.

Schéma de l’architecture MCP : explication é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 prise de notes connectée à un service de gestion de tâches :

  1. Découverte des outils : l’application de prise de notes (hôte) utilise son client MCP pour demander au serveur ses outils disponibles 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. Cela peut se produire avant même que vous ne soumettiez un prompt.
  2. Saisie de l’utilisateur : vous soumettez une demande à l’application de prise de notes basée sur un LLM via le chatbot intégré, par exemple : « Crée une tâche dans mon calendrier pour relire mon nouveau brouillon, 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, précisant l’outil et ses entrées : add-task avec title: Relire le brouillon 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 de 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 informations fournies au LLM.
  8. Génération de la réponse : le LLM utilise le résultat pour générer une réponse à l’utilisateur, par exemple : « J’ai créé une tâche pour relire le brouillon, avec une priorité moyenne. »

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

Le MCP et l’architecture API traditionnelle sont souvent confondus, mais ce sont des technologies complémentaires. Le MCP a été spécialement conçu pour les applications basées sur l’IA. Il élimine la lourde charge de maintenance liée à 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 à résoudre le problème d’un contexte d’entrée surchargé (qui liste toutes les API) ou de scripts d’application limités, fondés sur des API.

Les 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’une nouvelle API apparaît, ou si la documentation change, il lui suffit de mettre à jour le serveur MCP. Aucune modification de 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 introduction. Bien qu’il soit généralement considéré comme une technologie sûre, il présente plusieurs risques de sécurité, dont beaucoup sont plus marqués dans les implémentations d’architectures complexes.

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

  • Injection de prompt : un utilisateur insère un prompt malveillant dans des données externes, que le modèle d’IA interprète à tort comme une instruction.
  • Accès excessivement privilégié : 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 d’informations sensibles, comme des clés API ou des identifiants de base de données, à un LLM.
  • 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 en plus le risque d’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 à garantir la sécurité du système. Des mesures comme le maintien d’un humain dans la boucle, l’application de contrôles stricts sur les données sensibles et la protection contre les attaques de serveur sont toutes des pratiques courantes.

Quel avenir pour l’architecture MCP ?

Le MCP s’est imposé comme 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 allège considérablement le travail de codage des développeurs.

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

En outre, il faudra des garde-fous de sécurité plus solides à mesure que ces fonctionnalités agentiques seront mises en œuvre, ainsi qu’une architecture évolutive, notamment au niveau de la couche de transport, alors que les systèmes d’IA gagnent en ampleur et en complexité.