Quand utiliseriez-vous les WebSockets, SSE ou le long-polling plutôt que du HTTP classique ?

Question

IT Interview Practice · Accepted Answer

Le HTTP classique fonctionne en **requête/réponse** : le client demande, le serveur répond, fini. C'est peu adapté aux fonctionnalités **temps réel** (chat, dashboards live, notifications, édition collaborative) où le *serveur* doit pousser des données dès qu'il a du nouveau. Les options sont des façons de contourner le modèle initié par le client du HTTP, le long d'un spectre de complexité :

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

Le **long-polling** est la solution de repli qui fonctionne partout : le client fait une requête normale que le serveur garde ouverte jusqu'à ce qu'il ait des données, puis le client refait immédiatement une requête. Il approxime le push sur du HTTP classique mais gaspille un cycle de requête par message et ajoute de la latence.

Le **SSE (Server-Sent Events)** est un flux **unidirectionnel** (serveur → client) léger et standardisé, sur une unique réponse HTTP longue durée. Il est idéal quand seul le serveur pousse — feeds live, notifications, progression, streaming de tokens LLM. Il est simple, tourne sur du HTTP/2 normal (aucune infrastructure spéciale) et se reconnecte automatiquement. La limite : il est unidirectionnel et texte uniquement.

Les **WebSockets** transforment une seule connexion HTTP en un canal TCP persistant et **full-duplex** où les deux côtés envoient à tout moment avec un overhead par message minimal. Utilisez-les pour une interaction réellement bidirectionnelle et à faible latence : chat, jeux multijoueurs, éditeurs collaboratifs, trading. Le coût est opérationnel — c'est une connexion à état pour laquelle les proxies, load balancers et autoscalers doivent être configurés, et vous devez construire vous-même la reconnexion, les heartbeats et la backpressure.

**Règle empirique :** par défaut, du HTTP classique ; utilisez **SSE** pour le streaming serveur→client ; ne recourez aux **WebSockets** que lorsque vous avez vraiment besoin de temps réel bidirectionnel ; gardez le **long-polling** comme solution de repli universelle.

## Pourquoi c'est important

Choisir un transport temps réel est une décision de conception senior classique, où la réponse naïve (« utilisons juste des WebSockets pour tout ») est généralement fausse. Les recruteurs veulent voir que vous adaptez l'outil au *modèle de communication* — unidirectionnel vs bidirectionnel, besoins de latence, volume de messages — et que vous pesez le **coût opérationnel** des connexions à état, longue durée : sticky sessions, scaling, timeouts de proxy et logique de reconnexion. Reconnaître que le SSE couvre souvent « le serveur pousse des mises à jour » plus simplement que les WebSockets, et que le long-polling reste une solution de repli robuste, signale une vraie expérience de production plutôt qu'un réflexe vers l'option la plus tape-à-l'œil.

Pourquoi c'est important

Questions connexes