Construire des fonctionnalités en temps réel

Le « temps réel » recouvre des réalités très différentes : une application de chat, un tableau de bord live, des indicateurs de présence et des curseurs collaboratifs n'ont pas les mêmes besoins. Choisir le mauvais transport ou la mauvaise architecture donne des fonctionnalités qui fonctionnent en démo et s'effondrent sous une charge réelle. La bonne nouvelle : la plupart des besoins temps réel correspondent à quelques patterns bien connus. Voici comment choisir.

Adapter le transport au besoin

Commencez par vous poser la question : les données circulent-elles dans un seul sens (serveur vers client) ou dans les deux ?

• Server-Sent Events (SSE) : un flux unidirectionnel simple du serveur vers le client, sur HTTP classique. Idéal pour les notifications, les flux en direct, les fils d'activité et les tableaux de bord. La reconnexion est automatique, ça fonctionne à travers la plupart des proxies, et c'est bien plus simple que les WebSockets. Sous-utilisé, et souvent la bonne réponse.
• WebSockets : une connexion persistante full-duplex pour une communication bidirectionnelle à faible latence. Le bon choix pour le chat, le multijoueur, l'édition collaborative et les curseurs live — tout ce où le client émet fréquemment lui aussi.
• Polling / long-polling : interroger le serveur en boucle. Rudimentaire, mais parfois le choix pragmatique pour des mises à jour peu fréquentes ou dans des environnements contraints. Ne pas en faire le réflexe par défaut.

La règle simple : si les clients ne font que recevoir, utilisez SSE ; s'ils émettent aussi en continu, utilisez les WebSockets.

Ne pas construire de zéro si ce n'est pas nécessaire

Les connexions persistantes sont faciles à démarrer et difficiles à opérer. Avant d'écrire votre propre serveur WebSocket, envisagez des couches managées qui résolvent les problèmes complexes (scalabilité, présence, fan-out, reconnexion) :

• Supabase Realtime : si vous êtes déjà sur Postgres, il diffuse les changements de base de données et la présence via WebSockets avec presque aucun code serveur
• Les services pub/sub managés (Pusher, Ably et équivalents) gèrent pour vous la scalabilité des connexions et les garanties de livraison
• Votre framework dispose peut-être d'une option tout-en-un qui vaut la peine d'être utilisée

Construire sa propre solution se justifie lorsque vous avez des exigences très spécifiques ou des contraintes économiques d'échelle — pas par défaut.

L'architecture qui passe à l'échelle

La difficulté du temps réel n'est pas une connexion, c'est dix mille. Un seul serveur supporte un nombre limité de connexions, et dès que vous en faites tourner plusieurs, un client connecté au serveur A doit recevoir les messages publiés sur le serveur B.

La solution standard repose sur un backbone pub/sub (souvent Redis) placé en amont de vos serveurs de connexion :

1. Les serveurs de connexion maintiennent les connexions WebSocket/SSE des clients
2. Lorsqu'un événement se produit, il est publié sur un canal de la couche pub/sub
3. Chaque serveur de connexion s'abonne et pousse les messages vers ses clients concernés

Cela découple « qui est connecté où » de « ce qui doit être diffusé », et permet de scaler les serveurs de connexion horizontalement. Les services temps réel managés implémentent ce pattern à votre place.

Gérer les réalités difficiles

Les fonctionnalités temps réel tiennent ou tombent à la façon dont elles gèrent les défaillances :

• Reconnexion. Les connexions se coupent en permanence (réseaux mobiles, mise en veille, proxies). Les clients doivent se reconnecter automatiquement avec un backoff.
• Messages manqués. Après une reconnexion, le client a pu rater des mises à jour. Prévoyez un mécanisme de rattrapage — renvoi depuis un curseur ou un timestamp, ou rechargement de l'état à la reconnexion.
• Présence. « Qui est en ligne » nécessite des heartbeats et des timeouts pour détecter les déconnexions silencieuses.
• Ordre et conflits. Pour la collaboration, définissez comment résoudre les éditions simultanées (last-write-wins, ou CRDTs/OT pour l'édition collaborative de texte réelle).
• Authentification. Authentifiez la connexion au moment du handshake et autorisez chaque abonnement — ne faites pas confiance aux déclarations de canal du client.

La voie pragmatique

Utilisez le transport le plus simple qui répond au besoin (SSE bien plus souvent que les équipes ne le supposent), appuyez-vous sur une couche temps réel managée sauf raison contraire solide, et concevez dès le départ pour la reconnexion et les messages manqués. La plupart des histoires d'horreur autour du « temps réel, c'est compliqué » viennent précisément de l'omission de ce dernier point.

Si vous intégrez des fonctionnalités temps réel et souhaitez une architecture fiable au-delà de la démo, parlons-en.