Quand HTTP ne suffit plus
Pourquoi les apps temps réel ont besoin d'une autre connexion
⏱ Estim. ~7 min
01 · Lire
Tu as construit un serveur qui répond à des requêtes. Le navigateur demande une page, le serveur la renvoie. Le formulaire envoie des données, le serveur les traite. Ce cycle requête-réponse, c'est comme ça que marche la majeure partie du web.
Mais si le serveur doit parler à toi en premier, sans que tu aies demandé ?
L'adversaire d'échecs joue un coup. Un message de chat arrive. Le prix d'une action change. Avec HTTP classique, le serveur ne peut pas prendre l'initiative — il doit attendre que tu demandes. C'est le problème dès qu'on veut construire quelque chose en temps réel.
💡 Imagine çaHTTP, c'est comme s'envoyer des lettres par la poste. Tu écris, tu envoies, tu attends la réponse. Ça marche, mais il y a un délai à chaque échange. WebSocket, c'est comme un appel téléphonique — la connexion reste ouverte et les deux côtés peuvent parler à tout moment. Pas besoin d'attendre une lettre.
Points clés
- HTTP, c'est requête-réponse : le client a toujours l'initiative
- Avec HTTP, le serveur ne peut jamais pousser de données vers le client
- Les fonctionnalités temps réel — jeu, chat, mises à jour live — ont besoin d'autre chose
- WebSocket résout ça avec une connexion persistante et bidirectionnelle
02 · Lire
Avant l'existence de WebSocket, les devs bricolaient le temps réel avec une technique appelée polling. Le navigateur demandait au serveur toutes les une ou deux secondes : « Y a du nouveau ? ». S'il y avait du nouveau, le serveur envoyait ; sinon, il renvoyait une réponse vide.
Le polling marche, techniquement. Mais c'est du gaspillage. Imagine appeler la pizzeria toutes les 30 secondes pour demander « ma commande est prête ? ». La plupart du temps la réponse est non, et tu perds ton temps et le leur.
WebSocket a remplacé ce hack par une vraie solution : une connexion persistante où les deux côtés peuvent envoyer des messages à tout moment, sans rien demander.
Points clés
- Polling : le client demande « y a du nouveau ? » sur un timer — c'est du gaspillage
- La plupart des polls renvoient du vide — bande passante et charge serveur gâchées
- WebSocket : une seule connexion, qui reste ouverte, les deux côtés envoient librement
- Toutes les grandes apps temps réel utilisent WebSocket : Slack, Discord, Google Docs, jeux multijoueurs
03 · Étape par étape
Voici comment une connexion WebSocket s'établit — elle commence par une requête HTTP classique, puis upgrade.
1. Le client envoie une requête HTTP
Le navigateur envoie une requête HTTP normale au serveur, mais avec un header spécial : 'Upgrade: websocket'. Ça dit au serveur : « je veux passer de HTTP à WebSocket ».
2. Le serveur accepte l'upgrade
Si le serveur supporte WebSocket, il répond avec le code de statut 101 (Switching Protocols). La connexion HTTP est désormais transformée en connexion WebSocket.
3. La connexion persistante est ouverte
Les deux côtés peuvent maintenant envoyer des messages à tout moment. Le serveur peut pousser des données vers le client sans qu'on lui demande. Le client peut envoyer des données sans attendre de réponse.
4. Les messages circulent librement
Chaque côté envoie de petits paquets de données appelés 'frames'. Pas de schéma requête-réponse — juste des messages qui vont et viennent au besoin. C'est comme ça qu'un coup aux échecs apparaît instantanément sur l'écran de l'adversaire.
5. Fermer la connexion quand c'est fini
Chaque côté peut fermer la connexion quand il veut. Le navigateur ferme quand tu quittes la page. Le serveur ferme quand tu te déconnectes. Avant ça, elle reste ouverte.
04 · Glisser pour trier
Classe chaque fonctionnalité : HTTP ou WebSocket ?
(Cette section est interactive — active JavaScript pour l'utiliser.)
05 · Quiz
Quel est le principal avantage de WebSocket sur HTTP pour un jeu multijoueur ?
- Le serveur peut pousser des mises à jour aux joueurs instantanément, sans qu'ils aient à demander
- WebSocket est plus sécurisé que HTTP
- WebSocket utilise moins de bande passante au chargement initial de la page
- WebSocket n'a pas du tout besoin de serveur
06 · Compléter
Contrairement au cycle requête-réponse de HTTP, WebSocket établit une connexion _____ où les deux côtés peuvent envoyer des messages à tout moment.
Autres leçons de ce chapitre
⚠ L'expérience interactive complète nécessite JavaScript. Active-le et recharge la page.
※ Ce site est un projet éducatif indépendant — pas un produit officiel d'Anthropic. Claude™ est une marque déposée d'Anthropic, PBC.