Cinquante écrans, une seule URL : comment fonctionne réellement la synchronisation en temps réel

Le plus grand déploiement dont j'ai personnellement été témoin impliquait 47 écrans répartis sur trois étages d'un centre de conventions. Des confidence monitors dans chaque salle de sous-commission, des affichages de compte à rebours dans les couloirs, une horloge maître dans la grande salle de bal, des tableaux d'agenda à chaque entrée et une surface de contrôle sur tablette au pupitre de production. Chacun de ces écrans affichait le même état de timer, mis à jour dans la même frame d'animation, à partir d'une seule URL de navigateur. En régie broadcast, on appelle cela la distribution de signal multipoint. Timers Studio y parvient sans un seul câble SDI ni matrice de routage. C'est le scénario qui fait flancher la plupart des outils web de timer. Pas deux écrans. Pas cinq. Quarante sept, connectés via le WiFi d'un lieu qui desservait simultanément 2 000 participants en train de naviguer, consulter leurs emails et télécharger des présentations. Pour comprendre pourquoi Timers Studio gère ce scénario de manière fiable, il faut comprendre l'architecture de transport de signal qui le sous-tend. Le système utilise une approche à double chemin pour la synchronisation des données, un peu comme une régie sépare le bus de commande du bus de signal. Le premier chemin gère les données d'état : configurations de timer, réglages de thème, métadonnées du conducteur, noms de speakers, durées de segments. Ces données changent peu fréquemment et tolèrent une latence modérée. Elles se synchronisent via la couche d'abonnement temps réel de Supabase, qui utilise le mécanisme listen/notify de PostgreSQL pour propager les changements aux clients connectés. Quand vous renommez un timer ou changez une couleur de thème, chaque écran connecté reçoit cette mise à jour en quelques centaines de millisecondes. Pour les données d'état, cette vitesse est largement suffisante. Le second chemin gère les commandes de transport : play, pause, stop, next, previous, rewind et ajustements temporels. Comme les signaux tally d'une régie qui doivent allumer instantanément le voyant rouge sur la bonne caméra, ces commandes doivent arriver aussi vite que physiquement possible. Les commandes de transport contournent entièrement la base de données. Elles transitent par un canal WebSocket broadcast dédié que le serveur relaye simultanément à tous les clients connectés. Le serveur ne stocke pas ces commandes. Il les reçoit et les redistribue immédiatement. C'est pourquoi la latence de transport reste sous les 10 millisecondes indépendamment de la charge de la base de données, de la congestion réseau sur le canal d'état ou du nombre d'écrans connectés [Tester la synchronisation multi-écrans]. La synchronisation initiale est l'autre pièce critique. Quand un nouvel écran Player se connecte à une session, il ne peut pas simplement commencer à recevoir des mises à jour incrémentales. Il a besoin de l'état complet et actuel : quel timer est actif, combien de temps reste, à quoi ressemble la configuration d'affichage, si un message est actuellement affiché. Timers Studio délivre ce snapshot complet en moins de 50 millisecondes, ce que les ingénieurs broadcast compareraient au « lock time » d'un signal de référence. Le serveur maintient une représentation compressée de l'état actuel de la session en mémoire, et quand un nouveau client se connecte, il envoie ce snapshot comme premier message WebSocket avant que les mises à jour incrémentales ne commencent. L'importance pratique d'une synchronisation initiale rapide est facile à sous estimer tant qu'on ne se trouve pas dans un environnement de production. Les écrans se déconnectent et se reconnectent tout au long d'un show. Un technicien du lieu redémarre un écran pour résoudre un problème de résolution. Quelqu'un ferme accidentellement un onglet de navigateur et le rouvre. Un point d'accès WiFi redémarre. Dans tous ces cas, l'écran qui se reconnecte doit afficher l'état correct immédiatement, pas après un spinner de chargement, pas après une barre de progression, pas après un intervalle de polling de cinq secondes. Moins de 50 millisecondes signifie que l'écran passe d'un état vide à l'état correct si rapidement qu'un observateur ne peut pas dire qu'il a été déconnecté. La montée en charge à cinquante écrans simultanés introduit des défis que la plupart des tutoriels sur les WebSockets survolent. L'approche naïve consiste à faire envoyer par le serveur des messages individuels à chaque client, ce qui signifie cinquante messages pour chaque commande de transport. Cela évolue linéairement et crée une rafale de trafic sortant qui peut submerger le tampon réseau du serveur. Timers Studio utilise un pattern de broadcast, le même principe que les matrices de distribution utilisées en régie pour envoyer un signal unique vers de multiples destinations. Le serveur écrit le message une seule fois sur un canal et l'infrastructure WebSocket gère la distribution au niveau de la couche transport. Le coût CPU du serveur n'augmente pas de manière significative que dix ou cinquante clients soient connectés. Il y a aussi la question des tempêtes de reconnexion. Si le WiFi d'un lieu tombe pendant 30 secondes puis revient, les cinquante écrans tenteront de se reconnecter simultanément. Sans ingénierie soigneuse, cette vague peut faire planter le serveur WebSocket ou créer un effet de troupeau qui dégrade les performances pendant plusieurs minutes. La logique de reconnexion de Timers Studio utilise un backoff exponentiel avec jitter, ce qui signifie que chaque client attend un intervalle aléatoire légèrement différent avant de se reconnecter. Cela répartit la charge de reconnexion sur plusieurs secondes au lieu de la concentrer en un seul instant. La console de modération transforme n'importe quelle tablette en pupitre professionnel, même en pleine tempête de reconnexion [Découvrir la console]. Je souhaite aborder une question que les équipes de production posent fréquemment : que se passe t il si la connexion internet tombe complètement ? Les écrans Player continuent d'afficher le dernier état connu. Un compte à rebours qui était en cours continue de compter localement parce que le Player maintient sa propre boucle d'animation pilotée par le dernier horodatage serveur reçu. Cela signifie que même pendant une interruption réseau, le public voit un timer qui continue de compter, toujours précis dans la tolérance de dérive d'un seul appareil sur une courte période. Quand la connectivité reprend, le Player se resynchronise automatiquement avec l'horloge maître, corrigeant toute dérive accumulée sans saut visible. L'architecture gère également les conditions réseau hétérogènes avec grâce. Dans un vrai lieu, tous les écrans n'ont pas le même chemin réseau. Certains sont en ethernet, certains en WiFi 5 GHz, certains en 2,4 GHz. Les écrans sur les connexions les plus rapides reçoivent les mises à jour quelques millisecondes avant les écrans sur des connexions plus lentes, mais la différence est imperceptible parce que la latence absolue pour tous les chemins reste bien en dessous du seuil de perception humaine. Pour les producteurs d'événements qui évaluent si un outil web peut gérer leur échelle, la question pertinente n'est pas « combien d'écrans peut il supporter » dans l'abstrait. La question pertinente est de savoir si l'architecture a été conçue pour la diffusion simultanée en temps réel ou si elle a été conçue pour un seul utilisateur puis mise à l'échelle après coup avec du polling et du cache. Le déploiement au centre de conventions que j'ai décrit au début de cet article a fonctionné sans accroc pendant trois jours. Aucune resynchronisation manuelle n'a jamais été nécessaire. Aucun écran n'a affiché un état incorrect. L'équipe de production a complètement oublié l'infrastructure de timer, ce qui est exactement ce à quoi une infrastructure de transport de signal devrait aspirer [Ouvrir un Player multi-écrans maintenant].