Diagramme d'architecture MCP : hôtes, clients, serveurs et transports

Votre agent de code lit le dépôt, vérifie le build et crée des tickets dans votre outil de suivi. Un diagramme typique de ce montage montre une seule boîte intitulée « MCP » entre le modèle et les outils. Puis un relecteur sécurité demande quel processus peut lire votre répertoire personnel, quel token atteint l'outil de suivi et qui a approuvé l'appel qui a créé un ticket. La boîte n'a pas de réponse.

Le Model Context Protocol (MCP) a une architecture précise, et sa révision 2026-07-28 en a modifié une partie. Cet article couvre les participants, les couches du protocole, les transports, les fonctionnalités, un appel d'outil, l'autorisation distante et les frontières de confiance, avec un diagramme à copier.

Hôtes, clients et serveurs

Avant MCP, chaque application d'IA avait besoin de son propre adaptateur pour chaque outil : cinq applications et vingt outils représentaient jusqu'à 100 intégrations. Avec MCP, 25 implémentations (un client par application, un serveur par outil) couvrent toutes les combinaisons.

Un hôte crée un client par serveur, et chaque client parle à un seul serveur. Le modèle n'appelle jamais un serveur lui-même : il demande un appel d'outil, et l'hôte décide s'il l'exécute et quel client l'envoie. Les serveurs restent isolés : ils ne devraient voir ni toute la conversation ni les autres serveurs.

Deux couches, et ce que 2026-07-28 a changé

La couche de données est du JSON-RPC 2.0 : requêtes (avec un id jamais nul), résultats, erreurs et notifications à sens unique. La couche de transport achemine ces messages et gère le cadrage, l'annulation et l'autorisation.

La spécification 2026-07-28, publiée le 28 juillet 2026, a rendu MCP sans état. Les révisions précédentes ouvraient chaque connexion par un handshake initialize qui fixait la version et les capacités, et les serveurs HTTP pouvaient épingler une session avec Mcp-Session-Id. Désormais, chaque requête porte sa version de protocole et les capacités du client dans _meta, si bien qu'elle peut atterrir sur n'importe quelle instance de serveur derrière un simple répartiteur de charge round-robin.

Les serveurs construits sur d'anciens SDK attendent encore le handshake ; les clients des deux époques sondent donc d'abord et reviennent à initialize. Un client qui ne parle que 2026-07-28 ne peut pas utiliser un serveur uniquement hérité. Le journal des modifications liste chaque changement incompatible.

Transports : stdio et Streamable HTTP

Streamable HTTP a remplacé le transport HTTP+SSE (un flux GET plus un endpoint POST séparé) dans 2025-03-26 ; HTTP+SSE est désormais officiellement déprécié. Les passerelles peuvent router et limiter le débit selon Mcp-Method et Mcp-Name sans analyser les corps, et les serveurs rejettent les requêtes dont les en-têtes contredisent le corps. Les serveurs HTTP doivent valider l'en-tête Origin contre le DNS rebinding, et les serveurs locaux devraient se lier à 127.0.0.1.

Fonctionnalités des serveurs et des clients

Le mode formulaire de l'elicitation ne doit jamais demander de mots de passe, de clés d'API ni de tokens ; le mode URL envoie plutôt l'utilisateur vers une page extérieure au client. Sampling, roots et la journalisation du serveur ont été dépréciés dans 2026-07-28 et ne peuvent être supprimés au plus tôt qu'à la première révision publiée à partir du 28 juillet 2027.

Un appel d'outil, pas à pas

Le modèle crée un ticket via un serveur distant :

1. Facultativement, le client appelle server/discover pour les versions et les capacités.
2. Le client appelle tools/list. L'hôte fusionne les listes de tous les serveurs, préfixe les noms en collision et les donne au modèle.
3. Le modèle demande create_issue. L'hôte affiche l'appel, et l'utilisateur l'approuve.
4. Le client envoie tools/call, présenté ci-dessous.
5. Si le serveur a besoin d'une confirmation, il renvoie input_required avec une demande d'elicitation. Le client interroge l'utilisateur et réessaie avec la réponse et le requestState opaque du serveur.
6. Le résultat arrive sous la forme complete. Un échec d'outil positionne isError: true, pour que le modèle puisse se corriger.
7. Sur un flux subscriptions/listen, notifications/tools/list_changed indique au client de lister à nouveau les outils.

POST /mcp HTTP/1.1
Host: mcp.tracker.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "create_issue",
  "arguments": {"title": "Login fails on Safari"},
  "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
   "io.modelcontextprotocol/clientInfo": {"name": "my-ide", "version": "1.4.0"},
   "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}}}}}

{"jsonrpc": "2.0", "id": 7, "result": {"resultType": "complete",
 "content": [{"type": "text", "text": "Created issue #482"}], "isError": false}}

Serveurs distants et autorisation

Un serveur MCP distant est un serveur de ressources OAuth ; ses tokens proviennent d'un serveur d'autorisation exploité par le même éditeur ou par un fournisseur d'identité distinct. À la première connexion :

1. Le client appelle sans token et reçoit 401, généralement avec un en-tête WWW-Authenticate pointant vers les métadonnées de ressource protégée du serveur (RFC 9728).
2. Ce document, ou à défaut /.well-known/oauth-protected-resource, nomme le serveur d'autorisation, dont le client lit les métadonnées ; il s'arrête si PKCE n'est pas annoncé.
3. Le client utilise un identifiant client préenregistré, un Client ID Metadata Document (une URL HTTPS comme identifiant client) ou l'enregistrement dynamique de client, que 2026-07-28 déprécie.
4. Le client exécute le flux de code d'autorisation avec PKCE (S256) et un paramètre resource nommant le serveur MCP (RFC 8707). L'utilisateur se connecte et consent dans le navigateur, et le client vérifie l'iss de la réponse (RFC 9207).
5. Chaque requête porte Authorization: Bearer. Un 403 avec insufficient_scope déclenche l'autorisation par paliers (step-up).

Le serveur n'accepte que les tokens émis pour lui et ne les transmet jamais : les appels à une API en amont utilisent un token distinct. Le diagramme du flux OAuth 2.0 explique PKCE, et la spécification d'autorisation contient toutes les règles, bâties sur le brouillon OAuth 2.1.

Où se trouvent les frontières de confiance

Le transport stdio n'est pas un bac à sable : le guide de sécurité des serveurs locaux de MCP indique qu'un serveur stdio s'exécute avec les privilèges du client et que l'isolation relève de l'hôte et de celui qui exploite la machine. Un handle d'état émis par un serveur sans état n'est pas non plus un identifiant ; liez-le à l'utilisateur authentifié. Le diagramme de flux de données pour la modélisation des menaces montre comment parcourir de telles frontières avec STRIDE.

Le diagramme d'architecture MCP

Comment le lire :

• Le cadre vert est un domaine de confiance : l'hôte, ses trois clients et les deux serveurs stdio s'exécutent sous l'utilisateur OS du développeur.
• Un client par serveur. Les clients 1 et 2 utilisent stdin et stdout ; le client 3 utilise Streamable HTTP.
• Les arêtes grises depuis le modèle sont des appels d'outil que l'hôte achemine ; les serveurs n'atteignent jamais directement le modèle.
• Le bleu traverse le réseau avec un bearer token. Le violet en pointillés est le flux OAuth, qui ne s'exécute que lorsque le client n'a pas de token valide.
• Le turquoise représente le serveur distant qui appelle son API avec son propre token : pas de transmission.
• Le bloc Markdown résume la révision 2026-07-28.

Dessiner clairement des diagrammes d'architecture MCP

• Un client par serveur. Une seule boîte « MCP » cache ce que chaque serveur peut voir.
• Étiquetez les arêtes avec le transport et la charge utile : stdin et stdout, un POST avec bearer token, un flux OAuth, des exemples de noms d'outils.
• Dessinez les frontières de confiance comme des cadres : la machine, l'hôte, chaque éditeur. Signalez les serveurs isolés.
• Donnez au serveur d'autorisation et aux API en amont leurs propres nœuds, pour que les sources de tokens et la règle de non-transmission soient visibles.
• Indiquez la révision du protocole. Un diagramme 2026-07-28 n'a ni handshake ni identifiants de session.
• Omettez les détails internes des SDK, les listes complètes d'outils et l'infrastructure du fournisseur du modèle.

Le diagramme d'architecture d'agent IA couvre la boucle d'agent autour de ces appels.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un Cadre du pack Base pour la machine du développeur et, à l'intérieur, une Frontière du conteneur du pack C4 Model pour l'hôte.
3. Dans la frontière, ajoutez un Modèle du pack ML et trois nœuds Composant du pack C4 Model pour les clients, avec la technologie stdio, stdio et Streamable HTTP.
4. Ajoutez deux nœuds Conteneur du pack C4 Model pour les serveurs locaux, reliés par des arêtes « stdin / stdout », et une Personne du même pack reliée au modèle.
5. À l'extérieur du cadre, ajoutez une Frontière du système du pack C4 Model contenant un Conteneur pour le serveur distant, un Système externe pour son API et un Fournisseur d'identité du pack Sécurité, puis tracez les arêtes du bearer token, de l'OAuth en pointillés et de « own token ».
6. Ajoutez un bloc Markdown du pack Base avec les faits du protocole, et des notes Texte de Base pour les frontières.

Aucun outil gratuit ne lit les fichiers de configuration des clients MCP : dessinez donc les serveurs vous-même, ou collez un organigramme Mermaid, comme celui de la spécification MCP, dans l'outil de conversion Mermaid en diagramme modifiable.

Au moment de la rédaction (novembre 2026), Archboard est lui-même un serveur MCP distant à l'adresse https://getarchboard.app/mcp : Streamable HTTP, OAuth 2.1 depuis son propre serveur d'autorisation avec PKCE (S256) et cette URL comme indicateur de ressource, et enregistrement du client par Client ID Metadata Document ou par enregistrement dynamique de client. La documentation du serveur MCP liste ses outils, et la page des agents IA montre comment connecter votre application.

L'exemple utilise 14 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle est la différence entre un hôte, un client et un serveur MCP ? L'hôte est l'application d'IA, par exemple un IDE. Il crée un client par serveur, et chaque client tient une connexion dédiée avec un serveur, qui expose des outils, des ressources et des prompts.

MCP est-il désormais sans état ? Oui, depuis la révision 2026-07-28 : pas de handshake initialize, pas d'identifiant de session, et chaque requête porte sa propre version et ses capacités. Les serveurs sur des révisions plus anciennes utilisent encore le handshake.

Quels transports MCP prend-il en charge ? Deux standards : stdio pour les serveurs locaux et Streamable HTTP pour les serveurs distants. HTTP+SSE est déprécié, et les transports personnalisés doivent conserver le format de message JSON-RPC.

Les serveurs MCP locaux ont-ils besoin d'OAuth ? Non. La spécification indique que les serveurs stdio devraient prendre leurs identifiants dans l'environnement. Donnez à chacun un token à portée étroite et isolez les serveurs tiers dans un bac à sable.

Qu'est-ce que la transmission de token (token passthrough) dans MCP ? Un serveur MCP qui accepte un token qui n'a pas été émis pour lui, ou qui transmet le token du client à une autre API. La spécification l'interdit ; les appels en amont exigent le token propre du serveur.

Commencez gratuitement — un siège, sans carte bancaire.