WebSockets vs SSE vs Long Polling — La communication en temps réel sans panique

La plupart des développeurs optent par défaut pour les WebSockets. Cela est généralement erroné.

Ce n’est pas parce que les WebSockets sont mauvais — ils sont excellents dans ce qu’ils font. Mais ils entraînent un surcoût d’infrastructure réel : des sessions collantes sur les chargeurs, une logique personnalisée de cœur de battement, des contournements d’authentification, et une configuration de proxy qui fonctionne bien jusqu’à ce que quelqu’un ouvre votre application dans un bureau d’entreprise. Pour la majorité des besoins « en temps réel », ce surcoût n’est pas justifié.

La version courte : si les données circulent uniquement du serveur vers le client, utilisez les Événements envoyés par le serveur (SSE). Si le client doit envoyer des données en retour avec une latence faible, utilisez les WebSockets. Si votre fréquence de rafraîchissement est mesurée en secondes et que vous souhaitez une déploiement le plus simple possible, le long polling fonctionne encore — et il n’y a pas de honte à cela.

La comparaison

Polling longue durée

Le long polling est une version de polling HTTP où le serveur tient la requête ouverte jusqu’à ce qu’il ait quelque chose à retourner — ou qu’un délai expire. Le client envoie une requête, le serveur attend, retourne la réponse quand des données sont disponibles, puis le client envoie immédiatement la prochaine requête. C’est un cycle masqué par une appel réseau.

Cela est vraiment approprié pour une variété d’utilisations :

• Indicateurs de notifications — les comptes non lus qui se mettent à jour toutes les 30 secondes n’ont pas besoin d’une connexion persistante.
• Tableaux de bord administratifs avec une fraîcheur relaxée — les métriques qui se mettent à jour toutes les 15 à 60 secondes fonctionnent bien avec le polling.
• Applications mobiles sur des connexions instables — les connexions persistantes sont supprimées par la gestion réseau agressive ; le polling se reconnecte proprement à chaque requête.
• Derrière des proxies corporatifs — de nombreux proxies d’entreprise retiennent ou terminent des connexions non standard. Le polling HTTP fonctionne partout, sans exception.

La limitation en matière d’échelle est réelle. Chaque requête maintenue ouverte occupe une place de connexion. Sur des serveurs à threads, cela devient coûteux ; sur des serveurs à boucle d’événements (Node.js, Tornado, Go avec goroutines), cela est gérable mais pas gratuit. À des dizaines de milliers d’utilisateurs simultanés, les calculs sur les ressources du serveur deviennent significatifs.

Événements envoyés par le serveur (SSE)

L’option SSE est celle que la plupart des développeurs laissent de côté lorsqu’ils se dirigent vers les WebSockets. C’est une erreur pour tout cas d’utilisation où les données circulent dans une seule direction : du serveur au client.

Elle fonctionne sur HTTP standard. Le serveur définit Content-Type: text/event-stream et écrit des messages séparés par des retours à la ligne dans le corps de la réponse indéfiniment. L’API native du navigateur EventSource gère la reconnexion automatiquement — y compris un Last-Event-ID en-tête afin que le serveur puisse reprendre le flux après une perte. Vous obtenez des types d’événements nommés, des intervalles de reconnexion configurables, et aucune bibliothèque requise.

const source = new EventSource('/api/events');

source.addEventListener('priceUpdate', (e) => {
  const { price, symbol } = JSON.parse(e.data);
  updateTicker(symbol, price);
});

source.onerror = () => {
  // EventSource reconnects automatically — nothing to do here
};

Ce que SSE fait bien :

• HTTP standard — fonctionne à travers les chargeurs, les reverse proxies et les CDNs sans configuration particulière. Aucune session collante.
• Reconnexion automatique — intégrée dans la spécification. Définissez le retry: dans le flux pour configurer l’intervalle ; le client gère le reste.
• Multiplexage HTTP/2 — élimine la limite ancienne de 6 connexions par domaine d’HTTP/1.1. Si vous êtes sur HTTP/2 (vous devriez l’être), ce n’est pas un problème.
• Implémentation simplifiée du serveur — maintenez une connexion ouverte et écrivez dedans. Aucun handshake de protocole, aucune analyse de cadre, aucune logique de cœur de battement.

La seule limitation réelle : SSE est unidirectionnel. Les clients ne peuvent pas envoyer de données à travers une connexion SSE. En pratique, cela ne pose rarement de problème — utilisez des requêtes POST régulières pour tout ce que le client doit envoyer, en parallèle avec le flux SSE pour les événements du serveur. Les deux coexistent sans problème.

La limite d’HTTP/1.1 est à connaître. Les navigateurs limitent à 6 connexions simultanées par domaine sur tous les onglets. Trois onglets de navigateur chacun consommant deux flux SSE = limite atteinte. HTTP/2 élimine cela grâce au multiplexage. Si vous ne pouvez pas garantir la livraison d’HTTP/2 (certains configurations anciennes de CDN, certains proxies d’entreprise), gardez cela à l’esprit.

WebSockets

Les WebSockets sont l’outil approprié lorsque vous avez vraiment besoin de communication bidirectionnelle à faible latence. Les cas d’utilisation qui justifient cette complexité :

• Chat — les messages de chaque utilisateur doivent atteindre les autres en temps réel. Les WebSockets sont la norme ici, pour une bonne raison.
• Jeux multijoueurs — l’état du jeu s’actualise constamment entre les clients, souvent à 20 à 60 mises à jour par seconde. Aucune autre approche ne s’approche de l’efficacité par frame.
• Édition collaborative — l’édition en temps réel basée sur CRDT ou OT (Notion, Figma, style Google Docs) exige que chaque touche soit propagée avec une latence minimale.
• Termes de trading — des flux de prix sous 100 ms avec des soumissions d’ordres sur la même connexion. Les WebSockets ont été conçus pour cela.

Les coûts d’infrastructure évités par SSE et le polling :

• Sessions collantes — les connexions WebSockets sont étatiques et liées à un seul processus de serveur. Les chargeurs nécessitent une affinité de session (hachage IP ou basé sur les cookies) pour router correctement les reconnexions. Sans cela, un client reconnectant peut se connecter à un serveur sans connaître sa session.
• Configuration du proxy et du CDN — Nginx, HAProxy et Cloudflare prennent en charge les WebSockets mais exigent une configuration explicite (Upgrade et Connection en-têtes, proxy_http_version 1.1 dans Nginx). Certains pare-feux d’entreprise bloquent 101 Switching Protocols. Vous apprendrez cela dans les tickets de support des utilisateurs dans des bureaux spécifiques.
• Complexité d’authentification — les WebSockets ne peuvent pas définir des en-têtes personnalisées après le handshake initial. L’authentification par jeton implique généralement de passer le jeton dans la chaîne de requête (mauvais, courant) ou dans le premier message après la connexion (meilleur, mais nécessite une logique de filtrage côté serveur).
• Cœurs de battement — la spécification ne requiert pas de keepalives. Sans logique personnalisée de ping/pong, vous ne détectez pas les connexions mortes jusqu’à l’échec de la prochaine message. Soit implémentez des cœurs de battement, soit acceptez les connexions périmées accumulées sans action.

Aucun de ces points n’est un blocage — ils sont résolubles. Ils sont des complexités qui n’existent pas avec SSE ou le polling HTTP. Si vous choisissez les WebSockets pour un flux de notifications ou un tableau de bord en temps réel, vous payez ce coût sans raison.

Comment choisir

Travaillez à travers ces points dans l’ordre :

1. Le client a-t-il besoin d’envoyer des données au serveur à haute fréquence, ou la latence sous 200 ms est-elle cruciale ? Non → passez au WebSockets.
2. Les données circulent-elles uniquement du serveur au client ? Oui → SSE est presque certainement la bonne solution.
3. Êtes-vous sur HTTP/2 ? Si oui, SSE n’a pas de limitations significatives pour la plupart des cas d’utilisation. Si non, prenez en compte la limite de 6 connexions.
4. Votre déploiement est-il sans serveur ou derrière une infrastructure ne supportant pas les connexions persistantes ? SSE fonctionne sur la plupart des plateformes sans serveur (Vercel, Cloudflare Workers via l’API Streams) ; les WebSockets sur sans serveur nécessitent un ajout de configuration.
5. Votre fréquence de rafraîchissement est-elle de 15 secondes ou plus ? Polling longue durée. Gardez-le simple.

Si vous avez passé par ces étapes et que la réponse est encore WebSockets — excellent. Vous les utilisez maintenant pour la bonne raison, au lieu de l’option par défaut.

Débogage des charges d’événements

SSE data: Les champs et les messages de WebSocket contiennent presque toujours du JSON. Lorsque vous déboguez un flux mal fonctionnant, coller le payload brut dans IO Tools’ JSON Formatter est la méthode la plus rapide pour voir la structure d’un coup d’œil — surtout pour les objets d’événements imbriqués où une parenthèse manquante ou une virgule en trop fait planter la lecture sans avertissement.

Vous aimerez peut-être aussi

Nouveau

Validation du spécificateur OpenAPI : Gérez les erreurs dans votre fichier Swagger avant que les clients ne soient affectés

En savoir plus "

Mis à jour le 9 juin 2026

Nouveau

Journaux d'accès serveur — L'histoire de chaque requête que votre application a reçue

En savoir plus "

Mis à jour le 9 juin 2026

Nouveau

Codes HTTP qui vous piquent vraiment — 301 vs 302, 401 vs 403, et le champ de 5xx

En savoir plus "

Publié le 8 juin 2026

Nouveau

Limitation de vitesse : Comment éviter de recevoir des erreurs 429 avec chaque API que vous utilisez

En savoir plus "

Publié le 8 juin 2026