Que sont les WebSockets ?

Un WebSocket est une connexion persistante et bidirectionnelle entre client et serveur : chaque côté peut pousser un message à l’instant où il survient. HTTP a bâti le web en demandant ; les WebSockets l’ont rendu vivant en écoutant — un upgrade normalisé (RFC 6455) transforme une requête en canal ouvert, et tout ce qui est temps réel sur le web — chat, présence, tickers, curseurs collaboratifs — circule dessus.

Points clés

Comment fonctionne le handshake d’upgrade WebSocket (HTTP 101)

GET /chat HTTP/1.1                      ← commence comme du HTTP ordinaire
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols        ← et cesse d'être du HTTP ici
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# Désormais : de minuscules frames (2–14 octets d'overhead), dans les deux sens,
# vs ~500+ octets de headers pour chaque poll HTTP individuel.

La plupart des applications ne devraient pas écrire à la main ce qui vient ensuite — l’idiome de production est une couche temps réel gérée où le socket, les heartbeats et la reconnexion sont le code de quelqu’un d’autre :

// JavaScript / Node.js — Back4app JS SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
const query = new Parse.Query('Message');
query.equalTo('room', 'general');

const subscription = await query.subscribe();  // wss:// under the hood
subscription.on('create', (msg) => appendToChat(msg));
subscription.on('open', () => setStatus('live'));
// Later: subscription.unsubscribe();

// Flutter / Dart — Back4app Flutter SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Message'))
  ..whereEqualTo('room', 'general');

final sub = await liveQuery.client.subscribe(query); // wss:// under the hood
sub.on(LiveQueryEvent.create, (msg) => appendToChat(msg));

// iOS / Swift — Back4app Swift SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
let query = Message.query("room" == "general")

let subscription = query.subscribeCallback   // wss:// under the hood
subscription?.handleEvent { _, event in
  if case .created(let msg) = event { appendToChat(msg) }
}

// Android / Kotlin — Back4app Android SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Message")
query.whereEqualTo("room", "general")

val handling = client.subscribe(query)       // wss:// under the hood
handling.handleEvent(SubscriptionHandling.Event.CREATE) { _, msg ->
  appendToChat(msg)
}

WebSockets vs. tout le reste qui déplace des données

Exploiter des sockets en production

Quatre concepts portent la charge opérationnelle. Affinité de session : les connexions ont un état, donc les load balancers doivent maintenir chaque client épinglé à son nœud. Fan-out : diffuser un message à dix mille abonnés répartis sur de nombreux nœuds exige un backplane pub/sub entre serveurs — le message voyage de serveur à serveur avant de voyager de serveur à client. Backpressure : on ne peut pas laisser un téléphone lent sur un mauvais réseau accumuler des messages sans limite dans la mémoire de votre serveur ; il faut jeter, fusionner ou déconnecter. Vivacité : les frames ping/pong et les heartbeats applicatifs détectent les connexions à moitié mortes, et les clients se reconnectent avec un backoff exponentiel et du jitter, puis se réabonnent à leur état — l’étape que les implémentations naïves oublient. Rien de tout cela n’est exotique ; tout cela explique pourquoi « on va juste ouvrir un socket » devient une décision de plateforme.

Des messages à la synchronisation : la couche du dessus

Les WebSockets bruts déplacent des octets ; les applications veulent de l’état. L’étage au-dessus, c’est la synchronisation temps réel : au lieu d’inventer à la main des types de messages et une comptabilité côté client, vous vous abonnez à des données — une requête, un document, un canal — et la couche livre des événements de changement précis, gère la reconnexion avec rattrapage et applique les permissions côté serveur par abonné. C’est le modèle des live queries : les WebSockets comme transport, un moteur de requêtes comme cerveau. Si votre code WebSocket accumule des switch sur des types de messages, vous êtes en train de reconstruire cette couche à la main.

Cas d’usage courants

• Chat et messagerie — le cas canonique : les deux côtés parlent, instantanément.
• Présence — qui est en ligne, qui est en train d’écrire : de minuscules messages, à haute fréquence, dans les deux sens.
• Édition collaborative — documents et tableaux blancs partagés, où les positions de curseur et les modifications circulent en continu.
• Dashboards en direct et tickers — push serveur de chiffres qui bougent ; SSE convient aussi quand c’est à sens unique.
• Multijoueur et géolocalisation — état de jeu et marqueurs de carte en mouvement, là où la latence est le produit.

Avez-vous besoin d’un socket ? Matrice de décision

Et la voie médiane que la matrice cache : les cas serveur-vers-client uniquement (flux, notifications) conviennent à SSE avec moins de machinerie — la comparaison complète des transports a sa propre entrée dans le registre de ce glossaire.

Limites et trade-offs

• L’état est le prix du push. Chaque connexion ouverte est de la mémoire serveur et une contrainte de répartition de charge ; l’absence d’état de HTTP portait plus de poids qu’il n’y paraissait.
• Les réseaux détestent les connexions de longue durée. Proxies, radios mobiles et portables qu’on referme coupent des sockets en permanence — la logique de reconnexion n’est pas un cas limite, c’est la boucle principale.
• La sécurité déménage vers la connexion. Authentifiez à la connexion, validez chaque message, appliquez l’autorisation par abonnement — et toujours wss.
• Le cache n’existe pas ici. Tout ce qui est poussé est calculé et livré par client ; le CDN ne peut rien pour vous.
• La synchronisation écrite à la main est un piège. L’écart entre « j’ai ouvert un socket » et « une synchronisation d’état correcte, avec reconnexion et permissions » est là où vit la vraie ingénierie — c’est précisément la couche qui vaut la peine d’être louée.

WebSockets sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Sa couche temps réel est Live Query : le transport WebSocket, les heartbeats, la reconnexion et le fan-out multi-nœuds tournent comme une infrastructure gérée (avec le protocole ouvert LiveQuery en dessous), tandis que votre code s’abonne à des requêtes et reçoit des événements de changement typés — avec des ACL appliquées par abonné, pour que le temps réel ne contourne jamais le modèle de permissions. Les onglets de code ci-dessus sont toute l’histoire côté client.