WebSocket vs SSE pour la communication des agents : pourquoi MCP n'a choisi ni l'un ni l'autre

Points clés

• La spécification MCP 2026-07-28 a déprécié HTTP+SSE et l'a remplacé par Streamable HTTP — pas WebSocket — parce que les serveurs sans état fonctionnent avec l'infrastructure HTTP standard (WAF, équilibreurs de charge, proxies d'authentification) sans gestion de connexion persistante (MCP specification).
• A2A utilise JSON-RPC 2.0 sur HTTP avec SSE pour le streaming de sortie de tâche — le transport est de la plomberie ; les sémantiques du protocole (cycle de vie des tâches, état INPUT_REQUIRED) sont ce qui fait fonctionner la communication entre agents (A2A protocol).
• CVE-2026-16496 (CVSS 10.0) dans Terraform MCP a exploité le mode de transport SSE avec état — un ID de session volé a permis à un attaquant d'exécuter des appels d'outils avec les identifiants d'un autre utilisateur. Le transport sans état élimine la surface d'attaque au niveau de l'architecture, pas au niveau du correctif (NVD).
• WebSocket est disponible comme transport MCP personnalisé mais ajoute une complexité de gestion de session que les auteurs de la spécification ont délibérément évitée — le protocole est agnostique au transport, mais les transports standard (stdio, Streamable HTTP) couvrent les cas de production (MCP specification).
• La session « Stateless: The Future of MCP Transports » à AGNTCon+MCPCon Europe le 17 septembre 2026 est la première validation en conférence de la direction du transport sans état — présentée par Google et Hugging Face, les mainteneurs du MCP Transport Working Group (Linux Foundation).

La question du transport ressemble à de la plomberie d'infrastructure, et c'en est — mais le choix a des conséquences de sécurité, d'évolutivité et opérationnelles qui apparaissent en production. Quand le Model Context Protocol a déprécié HTTP+SSE le 28 juillet 2026 et l'a remplacé par Streamable HTTP, les auteurs de la spécification ont pris une décision d'ingénierie délibérée : serveurs sans état plutôt que connexions persistantes, HTTP standard plutôt que protocoles personnalisés, et un seul endpoint plutôt que le modèle SSE à double endpoint. Ils n'ont pas choisi WebSocket, bien que WebSocket soit bidirectionnel et SSE ne le soit pas. La raison n'est pas que WebSocket est mauvais — c'est que pour la charge de travail spécifique que MCP sert (appels d'outils entre un agent et une source de données), la capacité bidirectionnelle ne vaut pas la surcharge de gestion de session.

Cet article mappe les trois options de transport — SSE, WebSocket et Streamable HTTP — contre les deux protocoles d'agents qui les utilisent (MCP et A2A), avec une matrice de décision pour les déploiements d'agents B2B. La session AGNTCon du 17 septembre rend le moment concret : le transport sans état passe de la spécification à la validation en conférence, et les équipes qui exécutent le transport SSE déprécié ont une fenêtre de migration de 12 mois dont deux mois se sont déjà écoulés.

Les trois transports, et ce que chacun fait

SSE (Server-Sent Events) — le défaut déprécié

SSE est un protocole unidirectionnel : le serveur pousse des données au client sur une connexion HTTP de longue durée, et le client ne peut pas renvoyer de messages sur la même connexion. Chaque action du client — annuler une génération, piloter un agent en cours de tâche, approuver un appel d'outil — nécessite une requête HTTP POST distincte (WebSocket.org).

MCP utilisait SSE dans sa spécification 2024-11-05 comme transport pour les serveurs distants. Le modèle nécessitait deux endpoints : un endpoint SSE pour les messages serveur-vers-client et un endpoint POST distinct pour les messages client-vers-serveur. Le serveur maintenait l'état de session à travers les deux connexions. Trois limitations ont conduit à la dépréciation : pas de support pour les flux reproductibles, l'exigence de connexions de longue durée à haute disponibilité, et les messages serveur livrés uniquement via SSE (MCP specification PR #206).

A2A utilise toujours SSE pour son mode de streaming. La méthode SendStreamingMessage livre les mises à jour de tâche comme des événements SSE — deltas de tokens, morceaux d'artefacts, transitions d'état. C'est le bon choix pour A2A parce que le streaming est unidirectionnel (serveur vers client) et les messages de contrôle du client (annuler, souscrire) passent par des appels JSON-RPC distincts (A2A protocol). SSE est simple, fonctionne sur HTTP standard, et ne nécessite pas la gestion de session de WebSocket pour une charge de travail qui est fondamentalement du push serveur.

WebSocket — l'option bidirectionnelle que MCP n'a pas standardisée

WebSocket fournit une connexion persistante et bidirectionnelle entre client et serveur. Après un handshake de mise à niveau HTTP, la connexion reste ouverte et les deux parties peuvent envoyer des messages à tout moment. C'est le bon primitif pour les applications qui nécessitent une véritable communication bidirectionnelle sur un seul canal : chat, édition collaborative, jeux multijoueur, tableaux de bord de trading (Ably).

Pour les agents IA, le cas bidirectionnel est réel. Les workflows d'agents nécessitent des messages client-vers-serveur pendant l'exécution : annuler une génération, piloter un agent en cours de tâche, approuver ou rejeter un appel d'outil, envoyer du contexte supplémentaire. Avec SSE, chacun de ces messages est une requête HTTP distincte. Avec WebSocket, ils transitent sur la même connexion que le flux de tokens (WebSocket.org).

La spécification MCP ne standardise pas WebSocket. Il est disponible comme transport personnalisé — la spécification dit que « les clients et serveurs PEUVENT implémenter des mécanismes de transport personnalisés supplémentaires » tant qu'ils préservent le format de messages JSON-RPC — mais les transports standard sont stdio (pour les serveurs locaux) et Streamable HTTP (pour les serveurs distants) (MCP specification). Une issue GitHub (#493) a proposé d'ajouter WebSocket comme transport standard pour simplifier le modèle HTTP ; elle a été fermée sans adoption, et la spécification s'est tournée vers Streamable HTTP à la place (GitHub).

La raison pour laquelle MCP n'a pas standardisé WebSocket est opérationnelle, pas technique. WebSocket nécessite que le serveur maintienne des connexions persistantes, gère la santé des sessions, gère la logique de reconnexion et traite les connexions brisées. C'est le même fardeau de connexion avec état qui a rendu SSE responsable. Les auteurs de MCP voulaient des serveurs sans état — toute instance peut traiter toute requête, pas de stockage de session partagé, simple équilibrage de charge round-robin — et le modèle de connexion persistante de WebSocket va à l'encontre de cet objectif.

Streamable HTTP — ce que MCP a choisi à la place

Streamable HTTP est la réponse de la spécification MCP à la question SSE-vs-WebSocket. Le serveur expose un seul endpoint HTTP (par exemple, https://example.com/mcp) qui gère à la fois POST et GET. Le client envoie chaque message JSON-RPC comme un POST. Le serveur peut répondre avec un corps JSON simple ou mettre à niveau la réponse en un flux SSE si le résultat est de longue durée. Le choix de conception clé : le serveur n'a pas besoin de maintenir une connexion persistante. Chaque requête est autonome (MCP specification).

Cela donne à MCP la capacité de streaming de SSE sans l'exigence de connexion de longue durée, et la capacité bidirectionnelle de WebSocket sans la surcharge de gestion de session. Le client envoie des messages via POST (HTTP standard), le serveur diffuse des réponses via SSE optionnel (HTTP standard), et le serveur peut être sans état (infrastructure HTTP standard) (Bright Data ; Auth0).

L'argument de sécurité est concret. L'analyse d'Auth0 : avec Streamable HTTP, « nous pouvons tamponner un header `Authorization: *** standard sur chaque enveloppe. Le service de courrier vérifie le tampon sur chaque message, pas seulement le premier. » Avec l'ancien transport SSE, le token d'authentification était établi une fois au moment de la connexion et la connexion persistante transportait tous les messages suivants — y compris les messages d'un attaquant qui avait volé l'ID de session (Auth0).

La matrice de décision

Critère	SSE (déprécié)	WebSocket (personnalisé)	Streamable HTTP (standard MCP)
Direction	Serveur → client seulement	Bidirectionnel	Client → serveur via POST ; serveur → client via SSE optionnel
Modèle de connexion	Longue durée, persistant	Longue durée, persistant	Par requête (sans état)
État du serveur	Avec état (session par connexion)	Avec état (session par connexion)	Sans état (pas de session entre les requêtes)
Équilibrage de charge	Sessions collantes requises	Sessions collantes requises	Simple round-robin
Scaling	Limité (connexion par client)	Limité (connexion par client)	Élevé (toute infrastructure HTTP)
Authentification	Au moment de la connexion	Au moment du handshake	Par requête (Bearer sur chaque POST)
Reproductibilité	Non	Non	Non (mais sans état signifie pas de session à reprendre)
Infrastructure	Nécessite un proxy compatible SSE	Nécessite un proxy compatible WebSocket	HTTP standard (WAF, LB, CDN, proxies d'auth)
Surface de sécurité	Vol d'ID de session (CVE-2026-16496)	Détournement de session sur connexion persistante	Aucune au niveau transport (pas de session à voler)
Statut MCP	Déprécié, crépuscule de 12 mois	Transport personnalisé (non standardisé)	Transport distant standard depuis 2026-03-26
Statut A2A	Utilisé pour le mode streaming	Non utilisé	Non utilisé (A2A utilise JSON-RPC sur HTTP + SSE)
Idéal pour	Push serveur simple (streaming de tâches A2A)	Vrai bidirectionnel (chat, collaboration)	Appels agent-vers-outil (MCP)

Le tableau répond à la question que la plupart des équipes B2B se posent : si votre agent doit appeler un outil sur un serveur MCP distant, utilisez Streamable HTTP. Si votre agent doit diffuser la sortie d'une tâche vers un autre agent, utilisez le mode de streaming SSE d'A2A. Si vous construisez une interface collaborative en temps réel où le client envoie des messages aussi souvent que le serveur, WebSocket est le bon primitif — mais c'est un transport personnalisé, pas un standard de protocole.

Les trois transports comparés :

La dimension sécurité — pourquoi le sans état compte

Le CVE qui a validé le choix du transport sans état est CVE-2026-16496, une bypass d'autorisation CVSS 10.0 dans le Terraform MCP Server de HashiCorp. La vulnérabilité affectait le mode de transport streamable-HTTP avec état : un utilisateur qui obtenait l'ID de session MCP d'un autre utilisateur pouvait voir ses appels d'outils exécutés avec les identifiants Terraform de cet utilisateur. Le vecteur d'attaque existe uniquement parce que le serveur détient un état de session qu'un attaquant peut voler et réutiliser. Un serveur sans état n'a pas de session à voler (NVD ; The Hacker News).

C'est la preuve en production que le mode de transport avec état est une responsabilité de sécurité, pas seulement une complexité opérationnelle. La fenêtre de dépréciation SSE de 12 mois est maintenant une échéance de sécurité, pas seulement opérationnelle. Les 1 227 serveurs qui exécutent encore le transport HTTP+SSE déprécié sont la population la plus affectée — et la population qui porte la surface d'attaque de détournement de session.

Pour un traitement plus approfondi du protocole sans état et du modèle de handle explicite qui remplace l'état de session côté serveur, voir MCP 2026-07-28 : ce que le protocole sans état signifie pour les déploiements d'agents B2B.

Ce qu'A2A fait différemment — et pourquoi ça marche

A2A utilise SSE pour le streaming, pas Streamable HTTP. La différence est la charge de travail. Les appels d'outils MCP sont des opérations courte requête/réponse — interroger une base de données, récupérer un enregistrement, exécuter un calcul. Le serveur traite la requête et renvoie un résultat. Le streaming est optionnel et rare. Les tâches A2A sont des opérations de longue durée avec gestion explicite du cycle de vie — une évaluation de prix qui prend deux minutes, un contrôle de conformité qui prend une heure. Le streaming, ce sont les mises à jour de progression, pas le résultat lui-même.

Le streaming SSE d'A2A est du push serveur uniquement, ce qui est la bonne direction pour la progression des tâches : l'agent qui travaille sur la tâche envoie des mises à jour à l'agent appelant. Les messages de contrôle de l'agent appelant (annuler, souscrire aux mises à jour) passent par des appels JSON-RPC distincts. Il n'y a pas besoin de communication bidirectionnelle sur le canal de streaming parce que le canal de contrôle est une requête HTTP standard distincte (A2A protocol ; Google Developers Blog).

C'est pourquoi la question du transport est de la plomberie, pas de l'architecture. MCP et A2A utilisent des transports différents parce qu'ils ont des charges de travail différentes, mais les deux sont construits sur HTTP standard. Les sémantiques du protocole — les appels d'outils sans état de MCP et le cycle de vie des tâches avec état d'A2A — sont ce qui fait fonctionner la communication entre agents. Le transport transporte les messages ; il ne les définit pas.

Pour la comparaison complète au niveau du protocole (portée, transport, auth, état, humain-dans-la-boucle), voir A2A vs MCP : choisir le bon protocole pour la communication d'agents.

Quand WebSocket est la bonne réponse

WebSocket n'est pas mauvais. C'est le bon transport pour des charges de travail spécifiques que MCP et A2A ne standardisent pas :

• Interfaces collaboratives en temps réel où le client envoie des messages aussi souvent que le serveur — un tableau de bord d'agent partagé où plusieurs opérateurs pilotent le même agent simultanément.
• Communication bidirectionnelle haute fréquence où la surcharge de requête HTTP par message est prohibitive — un agent de trading qui reçoit des données de marché et envoie des ordres sur le même canal.
• Transports MCP personnalisés où les transports standard ne conviennent pas — la spécification autorise explicitement les transports personnalisés tant qu'ils préservent le format de messages JSON-RPC et les exigences de cycle de vie (MCP specification).

Le compromis est la complexité opérationnelle. Maintenir des connexions bidirectionnelles de longue durée nécessite une logique explicite pour la santé des sessions, les retries, les connexions brisées et les protocoles de messages (Nimble Way). Pour la plupart des déploiements d'agents B2B — un agent appelant NetSuite, un agent d'approvisionnement déléguant à un agent de prix — cette complexité n'est pas justifiée par la charge de travail.

La tendance sans état

La direction de l'industrie est claire. MCP est passé au sans état le 28 juillet 2026. A2A utilise des machines à tâches avec état mais un transport sans état (HTTP + SSE, pas de session persistante sur le serveur). La session AGNTCon+MCPCon Europe du 17 septembre — « Stateless: The Future of MCP Transports », présentée par Kurtis Van Gent (Google) et Shaun Smith (Hugging Face, mainteneur du MCP Transport Working Group) — est la première session de conférence dédiée à la direction du transport sans état (Linux Foundation ; sched.com).

Shaun Smith donnera également un keynote à la même conférence : « Getting to Stateless MCP: In Production » — ce qui signale que le transport sans état passe de la spécification aux conseils de déploiement en production. Pour les équipes qui exécutent le transport SSE déprécié, la fenêtre de migration de 12 mois (se terminant en juillet 2027) est l'échéance opérationnelle. L'échéance de sécurité est plus proche : chaque jour où un serveur exécute le transport SSE avec état est un jour où il porte la surface de détournement de session que CVE-2026-16496 exploite.

La question WebSocket vs SSE, pour la communication d'agents, a une réponse claire : ni l'un ni l'autre, si vous construisez sur MCP. Utilisez Streamable HTTP. Utilisez SSE si vous diffusez la sortie de tâches A2A. Utilisez WebSocket uniquement quand la charge de travail est véritablement bidirectionnelle et que la complexité opérationnelle est justifiée. Le transport est de la plomberie. Les sémantiques du protocole — appels d'outils sans état, cycles de vie de tâches avec état, handles explicites, états humain-dans-la-boucle — sont ce qui fait fonctionner les systèmes d'agents en production.

Lectures connexes

• MCP 2026-07-28 : ce que le protocole sans état signifie pour les déploiements d'agents B2B — le traitement complet de la spécification du protocole sans état, du modèle de handle explicite et de la fenêtre de dépréciation SSE de 12 mois
• A2A vs MCP : choisir le bon protocole pour la communication d'agents — la matrice de décision au niveau du protocole couvrant la portée, le transport, l'auth, l'état et l'humain-dans-la-boucle
• Patterns d'agents longue durée : maintenir les agents en vie sur des heures et des jours — la couche de persistance au-dessus du transport : checkpoint/reprise, surveillance au niveau trajectoire et plafonds de coût pour les agents qui tournent pendant des heures

---

Un distributeur de milieu de marché utilisant NetSuite, BigCommerce et trois catalogues fournisseurs déploie un agent de devis basé sur MCP. L'agent appelle NetSuite pour les prix par paliers, vérifie les catalogues fournisseurs pour la disponibilité et réserve le stock avec une expiration. Chacun de ces appels est un appel d'outil sans état sur Streamable HTTP — pas de connexion persistante, pas de session à gérer, pas d'équilibreur de charge à sessions collantes. Quand l'agent délègue une négociation multi-fournisseurs complexe à un agent de prix, cette délégation franchit la frontière du protocole A2A comme une tâche avec streaming SSE pour les mises à jour de progression. Le choix de transport n'était pas WebSocket vs SSE — c'était Streamable HTTP pour les appels d'outils et SSE pour le streaming de tâches, avec les sémantiques du protocole faisant le travail que le transport n'a pas besoin de faire.

Demandez un build cadré. Une semaine de découverte. Vous obtenez un inventaire système, une carte des workflows et un périmètre fixé — que vous construisiez avec nous ou non.