WebSocket : quand le serveur a le droit de parler en premier
Ou : Le protocole qui a résolu le problème « le serveur a quelque chose à vous dire mais doit attendre que vous demandiez »
Le protocole HTTP fonctionne en requête-réponse. Le client demande, le serveur répond. Toujours dans cet ordre. Le serveur ne peut pas initier une communication — il attend qu’on lui parle. Pour un site web classique, c’est parfait. Pour un chat en temps réel, une notification push, ou un cours de bourse qui se met à jour en direct — c’est un problème.
Le WebSocket résout ce problème en ouvrant un canal de communication bidirectionnel et persistant entre le client et le serveur. Une fois la connexion établie, les deux côtés peuvent envoyer des messages à tout moment, sans attendre l’autre. C’est une conversation, pas un interrogatoire.
HTTP vs WebSocket : requête-réponse vs conversation
Comment ça fonctionne
La connexion WebSocket commence par un handshake HTTP classique — le client envoie une requête spéciale (Upgrade: websocket) et le serveur accepte. À partir de là, la connexion TCP reste ouverte et les deux parties peuvent s’envoyer des messages sous forme de frames — des paquets de données légers, sans les en-têtes HTTP à chaque échange.
C’est la différence fondamentale : en HTTP, chaque échange nécessite une nouvelle requête avec ses en-têtes, son handshake TLS, sa négociation. En WebSocket, la connexion est établie une fois, et les messages circulent avec un overhead minimal.
Les cas d’usage
| Application | Pourquoi WebSocket |
|---|---|
| Chat en temps réel | Les messages doivent apparaître instantanément, dans les deux sens |
| Notifications live | Le serveur doit pouvoir notifier le client sans que le client ne demande |
| Jeux multijoueurs | Échanges fréquents et rapides entre client et serveur |
| Cours de bourse | Mises à jour continues poussées par le serveur |
| Édition collaborative | Synchronisation en temps réel entre plusieurs utilisateurs |
Avant WebSocket : les hacks
Avant WebSocket (standardisé en 2011), les développeurs simulaient le temps réel avec des hacks HTTP :
Polling — le client demande « des nouveautés ? » toutes les secondes. Le serveur répond « non » 99% du temps. Gaspillage de bande passante et de ressources serveur.
Long polling — le client demande « des nouveautés ? » et le serveur garde la connexion ouverte jusqu’à ce qu’il ait quelque chose à dire. Mieux que le polling, mais chaque message nécessite quand même de rétablir la connexion.
Server-Sent Events (SSE) — le serveur peut pousser des messages vers le client sur une connexion HTTP persistante. Mais c’est unidirectionnel — le client ne peut pas répondre sur le même canal.
WebSocket a rendu tout ça obsolète pour les cas d’usage bidirectionnels.
Le dialogue du temps réel
DevOps Dave : Le chat de support fonctionne en polling. Le client envoie une requête toutes les 2 secondes.
Security Sarah : Tu as 500 utilisateurs connectés en même temps ?
DevOps Dave : Oui.
Security Sarah : Ça fait 250 requêtes HTTP par seconde. Pour la plupart, la réponse est « rien de nouveau ». En WebSocket, tu aurais 500 connexions ouvertes et zéro requête inutile. Tu n’envoies des données que quand il y a réellement un message.
Tableau récapitulatif
| Concept | En une phrase |
|---|---|
| WebSocket | Protocole de communication bidirectionnelle et persistante entre client et serveur. |
| Handshake | La connexion commence par un upgrade HTTP, puis bascule en WebSocket. |
| Bidirectionnel | Client et serveur peuvent envoyer des messages à tout moment. |
| Polling | Le client demande répétitivement s’il y a du nouveau — le hack pré-WebSocket. |
| SSE | Server-Sent Events — push unidirectionnel du serveur vers le client. |
Le mot de la fin
Le WebSocket est un outil puissant qui est souvent surutilisé. Si votre application n’a pas besoin de temps réel — si un rafraîchissement toutes les 30 secondes suffit — HTTP classique est plus simple, plus fiable, et plus facile à scaler. Le WebSocket brille quand la latence compte : chat, jeux, collaboration en direct. Pour le reste, c’est une complexité ajoutée sans bénéfice réel.