# WebSocket : quand le serveur a le droit de parler en premier

> Le WebSocket ouvre un canal permanent entre le navigateur et le serveur. Les deux peuvent parler quand ils veulent, sans attendre l'autre. C'est HTTP, mais en conversation.


*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](/glossaire/developpement-web/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

{.subtitle}

### 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.