Temps réel, hors connexion, écrans anciens : comment c'est construit

La façon habituelle de mettre un écran à jour consiste à lui faire interroger le serveur à intervalle fixe : toutes les cinq minutes, toutes les quinze minutes. Le contenu finit par arriver, mais avec le retard du cycle en cours, et chaque écran consomme du réseau même lorsque rien n'a changé.

Smart-Signage fonctionne dans l'autre sens. La plateforme maintient un canal permanent vers chaque écran, en Server-Sent Events, et y pousse l'événement au moment où il se produit. Vous modifiez une playlist ou un planning : la modification part immédiatement et l'écran l'applique en quelques secondes. Il n'y a pas de cycle de rafraîchissement à attendre, et rien ne circule tant que rien ne bouge.

Ce choix engage l'infrastructure. Il faut tenir un grand nombre de connexions ouvertes en permanence, ce qui n'est pas le régime de fonctionnement pour lequel un serveur web est réglé par défaut. Le reverse-proxy Caddy a notamment été retenu pour sa tenue sur ces connexions longues.

Le canal sert dans les deux sens, et c'est ce qui rend la supervision honnête :

• chaque écran émet un battement de cœur régulier, qui signale qu'il est vivant ;
• la plateforme affiche l'état réel du parc, écran par écran : en ligne, silencieux, et ce que chacun diffuse à cet instant ;
• un écran qui cesse d'émettre devient visible immédiatement, sans que personne ait à se déplacer pour le constater.

Un écran qui dépend du réseau est un écran noir en puissance. Les contenus sont donc mis en cache localement par un Service Worker : si la connexion disparaît, la diffusion se poursuit avec ce qui est déjà sur place, et l'écran se resynchronise dès le retour du réseau. Personne n'a à intervenir sur site.

Une contrainte de terrain impose ici une précaution qu'il vaut mieux nommer : les WebView Android plafonnent la taille des fichiers qu'elles acceptent de conserver en cache. Une vidéo lourde chargée d'un seul bloc dépasse ce plafond et ne serait jamais mise en cache, donc jamais disponible hors connexion. Les gros médias sont pour cette raison lus par plages successives plutôt qu'en une fois. C'est ce découpage qui rend le mode hors connexion réellement fiable sur ce matériel.

Le second risque n'est pas la panne réseau, c'est la mise à jour elle-même. Un superviseur écrit en JavaScript ES5 s'exécute avant le code applicatif et pilote le Service Worker. Si trois démarrages consécutifs ne sont pas sains, l'écran revient de lui-même à la dernière version saine connue. Un garde-fou limite par ailleurs les rechargements automatiques à deux par minute, pour écarter le scénario de l'écran qui clignote en boucle. Conséquence concrète : un déploiement raté ne bloque pas un parc installé, il se répare seul.

C'est le point sur lequel nous cédons le moins : le logiciel s'adapte au matériel en place, pas l'inverse. Le player est livré en deux versions issues du même code source, une version moderne pour les appareils récents et une version ES5 pour les navigateurs embarqués anciens. Mêmes fonctions, même produit ; ce qui change est la manière dont le code est compilé et servi.

Le parc réel de l'affichage dynamique n'est pas un parc récent. Beaucoup d'écrans installés il y a cinq, huit ou dix ans embarquent un navigateur figé à sa version d'origine, que personne ne mettra jamais à jour. Chrome 44 et les versions suivantes sont pris en charge. LG webOS 4 embarque un moteur équivalent à Chromium 53, qui ne connaît pas CSS Grid : ces appareils reçoivent des mises en page de repli écrites pour eux, afin que la composition tienne au lieu de s'empiler au hasard.

Ce travail a un coût, et nous l'assumons : chaque évolution d'interface doit être vérifiée sur le socle ancien avant d'être livrée. En échange, changer de logiciel d'affichage n'oblige pas à changer les écrans, et le budget matériel sort de l'équation au moment de la décision.

Ce qui est pris en charge :

• le Web, sur tout appareil doté d'un navigateur ;
• Android, avec une application dédiée, y compris sur de vieilles WebView ;
• LG webOS, générations anciennes comprises ;
• aucun matériel propriétaire imposé : le choix du fournisseur d'écrans reste le vôtre.

L'hébergement est assuré chez OVH, sur des serveurs situés dans l'Union européenne. Aucune donnée n'est hébergée hors UE, et la conformité au RGPD est documentée.

Côté réseau, l'écran n'a besoin que d'un accès sortant vers la plateforme. Le canal permanent est une connexion ordinaire initiée par l'écran lui-même : il n'y a pas de flux entrant à autoriser vers vos locaux, ni de serveur à installer sur votre infrastructure.

Reste le compromis, puisqu'il y en a un. Viser des navigateurs anciens interdit d'utiliser les nouveautés du Web dès leur sortie, et oblige à valider deux socles au lieu d'un : le développement est plus lent, et certaines finesses d'interface sont écartées parce qu'elles ne passeraient pas partout. Nous préférons une interface un peu plus sobre qui s'affiche sur tous les écrans à une interface brillante qui en laisse une partie dehors. Un acheteur d'affichage dynamique change de logiciel bien plus souvent qu'il ne change de matériel, et c'est ce rapport-là que l'architecture protège.