Transports : stdio, HTTP et SSE

Pourquoi le transport n'est pas un détail

Dans les chapitres précédents, vous avez vu que MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire définit un protocole d'échange entre un client (l'hôte qui embarque le modèle) et un serveur (qui expose des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire, des ressources ou des invites). Ce protocole repose sur JSON-RPC : des messages structurés, des requêtes, des réponses, des notifications. Mais JSON-RPC ne dit rien sur la façon dont ces messages voyagent physiquement d'un processus à l'autre. C'est le rôle du transport.

Ce choix n'est pas cosmétique. Il détermine si votre serveur MCP peut tourner derrière le pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire d'entreprise sans ouvrir de portportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire, s'il peut être partagé par plusieurs utilisateurs simultanément, s'il survit à une coupure réseau de quelques secondes, ou s'il doit être ré-authentifié à chaque appel d'outil. Deux équipes qui implémentent le même serveur métier avec deux transports différents obtiennent des systèmes aux propriétés opérationnelles radicalement différentes, alors que la logique des outils exposés est identique.

Le transport MCP répond à une question d'infrastructure (comment les octets circulent), pas à une question de logique métier (ce que fait l'outil). Confondre les deux est la source la plus fréquente de mauvais choix d'architecture en phase de cadrage.

MCP normalise aujourd'hui trois façons de faire circuler ces messages : stdio, HTTP+SSE (la version historique, aujourd'hui dépréciée mais encore largement déployée) et streamable HTTP (la version actuelle, qui remplace progressivement la précédente). Comprendre les trois est nécessaire, parce que vous croiserez les trois en environnement réel : de la documentation qui date d'avant la dépréciation, des serveurs tiers qui n'ont pas encore migré, et de nouveaux serveurs qui n'implémentent que la version récente.

stdio : le transport du poste de travail

Principe

Avec le transport stdio (standard input / standard output), le client MCP lance le serveur comme un sous-processus local. Les messages JSON-RPC circulent par les flux standards du processus : le client écrit sur l'entrée standard du serveur, le serveur répond sur sa sortie standard. Chaque ligne transmise est un message JSON complet, délimité par un retour à la ligne.

C'est le mécanisme utilisé par la quasi-totalité des intégrations MCP dans les IDE et les clients de bureau (Claude Desktop, les extensions d'éditeurs de code, les CLI). Le fichier de configuration typique ressemble à ceci :

{
  "mcpServers": {
    "fichiers-projet": {
      "command": "node",
      "args": ["./mcp-server-fs.js", "--root", "/home/utilisateur/projets"]
    }
  }
}

L'hôte se charge de démarrer le processus, de lui parler par les flux standards, et de l'arrêter en fin de session. Il n'y a ni port réseau, ni certificat, ni serveur HTTP à administrer : le serveur MCP est un exécutable comme un autre.

Ce que cela implique

• Pas de traversée réseau : aucune règle de pare-feu à ouvrir, puisque tout se passe en local sur la machine de l'utilisateur.
• Pas d'authentification au sens propre : la confiance repose entièrement sur les permissions du système d'exploitation. Si l'utilisateur peut exécuter le binaire, il peut l'utiliser — c'est identique à n'importe quel outil en ligne de commande.
• Une session, un processus : chaque client qui a besoin du serveur en démarre sa propre instance. Il n'y a pas de partage naturel entre plusieurs utilisateurs.
• Cycle de vie couplé au client : quand l'hôte se ferme, il termine généralement le sous-processus.

Dès que le serveur agit sur des ressources locales à la machine de l'utilisateur — système de fichiers, dépôt Git local, outils de build, IDE — stdio est le choix naturel. Il n'a aucun sens de faire transiter par le réseau un accès qui est, par nature, local.

Le piège du buffering

Le piège le plus fréquent avec stdio n'est pas protocolaire, il est lié aux runtimes. De nombreux langages bufferisent la sortie standard par défaut lorsqu'elle n'est pas connectée à un terminal interactif (un « TTY ») — ce qui est précisément le cas quand un processus est piloté par un autre processus, comme ici. Le serveur écrit sa réponse, mais elle reste dans un tampon mémoire au lieu d'être envoyée immédiatement au client, qui attend indéfiniment.

Un serveur MCP en stdio qui « ne répond jamais » alors que les logs montrent que la réponse a bien été construite est, dans l'immense majorité des cas, un problème de buffering de la sortie standard — pas un bug de logique. Pensez à désactiver le buffering ou à forcer un flush explicite après chaque message (process.stdout en mode non bufferisé pour Node.js, flush=True ou un flux non tamponné pour Python, -u pour l'interpréteur Python en ligne de commande).

Autre piège lié : n'importe quelle ligne écrite sur la sortie standard par erreur — un print de debug oublié, une bibliothèque tierce qui journalise sur stdout — casse le flux JSON-RPC, puisque le client s'attend à ce que chaque ligne de stdout soit un message JSON valide. Les logs applicatifs doivent systématiquement partir sur l'entrée d'erreur (stderr), jamais sur stdout.

HTTP+SSE : le transport réseau historique

Dès que le serveur MCP doit être accessible depuis une autre machine que celle du client — un serveur d'entreprise mutualisé, un service SaaS, une API interne — stdio ne convient plus : il n'y a pas de notion de sous-processus distant. La première spécification de transport réseau de MCP a introduit une combinaison HTTP + Server-Sent Events (SSE).

Fonctionnement

Ce transport repose sur deux canaux distincts :

1. Le client ouvre une connexion SSE vers un endpoint du serveur (typiquement /sse). Ce canal reste ouvert en permanence et sert exclusivement à ce que le serveur envoie des messages au client — les réponses aux requêtes, les notifications.
2. Pour envoyer un message au serveur, le client fait une requête HTTP POST classique vers un autre endpoint. Le serveur traite la requête et pousse sa réponse via le canal SSE ouvert précédemment, plutôt que dans la réponse HTTP du POST lui-même.

Cette asymétrie — un canal descendant permanent, des requêtes montantes ponctuelles — permet au serveur de notifier le client de façon proactive, ce que le HTTP classique en requête-réponse ne permet pas nativement.

Les limites qui ont motivé sa dépréciation

• Deux connexions à corréler : le client doit maintenir la connexion SSE et savoir l'associer à ses requêtes POST, ce qui complique la gestion de session côté serveur comme côté client.
• Fragilité derrière les proxys et load balancers : une connexion SSE est une connexion HTTP longue durée. Beaucoup d'infrastructures réseau d'entreprise (proxys, reverse-proxies, passerelles applicatives) ferment silencieusement les connexions inactives au-delà d'un certain délai, ou ne savent pas répartir correctement une connexion SSE entre plusieurs instances d'un service.
• Scaling horizontal difficile : si le serveur tourne sur plusieurs instances derrière un répartiteur de charge, la requête POST du client peut atterrir sur une instance différente de celle qui détient la connexion SSE ouverte — auquel cas la réponse ne peut jamais être livrée sans un mécanisme de routage ou d'état partagé supplémentaire.

Bien que remplacé dans la spécification actuelle par streamable HTTP, HTTP+SSE reste implémenté par de nombreux serveurs et bibliothèques clientes existants. Vous le croiserez encore régulièrement, en particulier dans des intégrations écrites avant la dépréciation. Vérifier la version du SDK MCP utilisée par un serveur tiers avant de l'intégrer évite de mauvaises surprises.

Streamable HTTP : le transport réseau actuel

La spécification actuelle de MCP remplace HTTP+SSE par un transport appelé streamable HTTP, conçu pour corriger précisément les faiblesses ci-dessus.

Ce qui change

• Un seul endpoint HTTP, qui accepte à la fois les requêtes POST du client et peut, selon le besoin, répondre soit par une réponse HTTP classique immédiate, soit par un flux de type SSE pour les cas où plusieurs messages doivent être renvoyés (par exemple des notifications de progression avant la réponse finale).
• Sessions explicites : le serveur peut attribuer un identifiant de session lors du premier échange, que le client renvoie ensuite dans ses en-têtes. Cela découple la notion de session logique de la notion de connexion réseau : une session peut survivre à la fermeture et à la réouverture d'une connexion TCPTCPRéseauxProtocole de transport qui garantit que les données arrivent complètes, dans l'ordre et sans doublon. Il établit une connexion, numérote chaque segment et retransmet ce qui manque.Voir dans le glossaire.
• Compatibilité avec l'infrastructure HTTP standard : reverse-proxies, load balancers, passerelles d'API, pare-feux applicatifs — tout ce qui sait gérer du HTTP/1.1 ou HTTP/2 classique fonctionne sans configuration particulière, puisqu'il n'y a plus de connexion permanente obligatoire.
• Reprise possible : un client peut, sous conditions, rouvrir un flux et demander à reprendre à partir du dernier message reçu, ce qui limite l'impact d'une coupure réseau brève.

Un client envoie une requête tools/call en POST JSON vers https://mcp.entreprise.fr/mcp, avec l'en-tête Mcp-Session-Id s'il a déjà une session active. Si l'outil appelé s'exécute rapidement, le serveur répond directement en JSON dans la réponse HTTP. Si l'outil doit signaler une progression (par exemple un traitement de plusieurs minutes), le serveur répond avec un flux SSE contenant plusieurs événements de progression, terminé par le résultat final.

Ce que cela implique en entreprise

Côté pare-feu, streamable HTTP se comporte comme n'importe quel service web moderne : un port HTTPSHTTPSRéseauxHTTP sécurisé par TLS : chiffre les échanges entre client et serveur et authentifie le serveur via un certificat.Voir dans le glossaire sortant (443) suffit côté client, ce qui est presque toujours déjà ouvert. Côté serveur, il s'expose comme une API HTTP classique, ce qui permet de réutiliser l'outillage existant : passerellePasserelleRéseauxÉquipement réseau reliant deux réseaux de couches différentes ou traduisant des protocoles ; en TCP/IP, route les paquets entre sous-réseaux.Voir dans le glossaire d'API, supervision, limitation de débit, journalisation centralisée.

Côté authentification, streamable HTTP s'intègre naturellement avec les mécanismes HTTP standards : en-tête Authorization porteur d'un jeton, OAuth 2.1 (la spécification MCP recommande explicitement ce schéma pour les serveurs distants), ou clé d'API selon le niveau de sensibilité. C'est une différence structurante avec stdio, où la notion même d'authentification réseau n'existe pas.

Côté scaling, comme chaque requête peut en théorie être traitée par une instance différente du serveur (sous réserve que l'état de session soit correctement partagé ou réattaché), streamable HTTP se prête bien à un déploiement derrière un load balancer classique, avec plusieurs réplicas.

Comparatif synthétique

Schéma des trois transports

Pièges de timeouts et de proxys en environnement d'entreprise

Même avec streamable HTTP, plusieurs pièges reviennent systématiquement lors des déploiements en entreprise.

Timeouts trop courts sur les passerelles intermédiaires

Les reverse-proxies et passerelles d'API appliquent souvent un timeout par défaut (30 à 60 secondes typiquement) pensé pour des API REST classiques à réponse rapide. Un outil MCP qui effectue un traitement long — génération de rapport, appel à un système legacy lent, traitement par lots — peut dépasser ce délai, entraînant une coupure de connexion côté proxy alors que le serveur MCP travaille toujours.

Un déploiement MCP réseau traverse en général plusieurs étages : client, éventuel VPNVPNRéseauxRéseau privé virtuel qui chiffre le trafic entre deux points sur un réseau public. Il crée un tunnel sécurisé permettant d'accéder à des ressources distantes comme si on était sur le réseau local.Voir dans le glossaire ou tunnel, reverse-proxy, passerelle d'API, serveur applicatif. Chacun peut avoir son propre timeout, indépendant des autres. Le symptôme typique est un outil qui fonctionne en test direct sur le serveur mais échoue systématiquement une fois passé par la chaîne complète de production — signe presque certain d'un timeout intermédiaire, pas d'un bug applicatif.

Buffering des proxys sur les flux SSE

Certains proxys et serveurs web bufferisent également les réponses HTTP par défaut, y compris les flux SSE, en attendant d'avoir accumulé une certaine quantité de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire avant de les transmettre au client. Résultat : les événements de progression censés arriver au fil de l'eau arrivent tous d'un coup, à la fin — cassant l'intérêt même du streaming. Ce comportement se configure généralement (désactivation du buffering pour les réponses text/event-stream, en-tête X-Accel-Buffering: no pour nginx, par exemple), mais il est rarement désactivé par défaut.

Confusion entre session applicative et connexion TCP

Avec streamable HTTP, une session MCP (identifiée par Mcp-Session-Id) n'est pas liée à une connexion réseau particulière. Un client mal implémenté qui suppose l'inverse — par exemple en réutilisant une connexion TCP comme identifiant implicite de session — perdra le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire de session dès que cette connexion est recyclée par le pool de connexions HTTP sous-jacent, un comportement normal et attendu côté infrastructure.

Grille de décision

Pour choisir rapidement le transport adapté à un contexte de déploiement :

• Le serveur accède uniquement à des ressources de la machine locale de l'utilisateur (fichiers, IDE, outils CLI) → stdio.
• Le serveur doit être partagé par plusieurs utilisateurs ou accessible depuis d'autres machines, et vous démarrez un nouveau projet → streamable HTTP.
• Le serveur doit être partagé par plusieurs utilisateurs, mais vous intégrez un serveur tiers existant qui n'implémente que l'ancienne spécification → HTTP+SSE, en gardant en tête sa dépréciation et en planifiant une migration.
• Le serveur doit gérer des traitements longs avec retour de progression, exposé au réseau → streamable HTTP, avec une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire particulière aux timeouts de chaque étage réseau intermédiaire.
• Le serveur doit être accessible sans que l'utilisateur installe quoi que ce soit sur son poste → transport réseau obligatoire, donc streamable HTTP en priorité.

Avant d'intégrer un serveur MCP externe, vérifiez explicitement quel transport et quelle version de spécification il implémente. Un serveur documenté « SSE » sans plus de précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire date probablement d'avant la dépréciation ; un serveur qui expose un unique endpoint /mcp acceptant du POST implémente vraisemblablement streamable HTTP.

Ce qu'il faut retenir

Le choix du transport n'est pas une question purement technique reléguée à l'implémentation : c'est une décision d'architecture qui conditionne la sécurité, la disponibilité et la capacité de montée en charge d'une intégration MCP. stdio reste imbattable pour les outils locaux, sans configuration réseau ni authentification à gérer. Streamable HTTP est aujourd'hui le choix par défaut pour tout ce qui doit traverser un réseau d'entreprise, en s'appuyant sur l'infrastructure HTTP existante plutôt qu'en la contournant. HTTP+SSE ne doit plus être un choix de conception pour un nouveau projet, mais reste une réalité à gérer tant que l'écosystème n'a pas fini sa migration.

Le chapitre suivant s'appuie sur ces bases pour détailler la sécurisation effective d'un serveur MCP distant : authentification, autorisation par outil, et limites de confiance à poser face à un client.