Visio-Display transforme l'affichage dynamique en infrastructure self-hosted

Visio-Display est parti d'un besoin classique : centraliser des contenus et les diffuser sur plusieurs écrans. Le projet présenté par Eric Tomas le 27 août 2026 a depuis changé d'échelle. Il associe désormais gestion de médias, campagnes temporaires, création graphique, déploiement de clients Linux et supervision dans une plateforme open source auto-hébergée.

L'intérêt du projet ne tient donc plus seulement à la lecture d'un diaporama. Il réside dans la volonté de traiter l'affichage dynamique comme un petit système d'information, avec ses données, ses traitements asynchrones, ses droits d'accès, ses sauvegardes et son parc de terminaux.

La réponse rapide

Quand un gestionnaire de médias devient une plateforme

Un outil d'affichage dynamique minimal stocke des fichiers, définit un ordre de passage et fournit une page plein écran. Visio-Display ajoute les briques nécessaires lorsque le nombre d'écrans et d'utilisateurs augmente.

Chaque écran peut disposer de sa propre liste, de ses durées et de ses plages de diffusion. Les médias peuvent être regroupés, activés pour une période donnée ou remplacés temporairement par une campagne prioritaire. Une alerte peut aussi prendre la main sur l'ensemble du parc. Ce modèle répond aussi bien à un hall d'accueil qu'à un réfectoire, une salle de réunion ou un réseau de points de vente.

Les imports couvrent les images JPEG et PNG, plusieurs formats vidéo ainsi que les PDF. Les vidéos sont réencodées en tâche de fond et les documents sont convertis en images. Redis et RQ évitent ainsi de bloquer l'interface pendant les traitements les plus longs.

Une architecture lisible pour les équipes techniques

Le serveur repose sur Flask et Gunicorn pour l'application web, PostgreSQL pour la configuration et les journaux, puis Redis et RQ pour les travaux asynchrones. Docker Compose orchestre l'ensemble et des volumes hôte conservent séparément les médias publics et les données privées.

Cette architecture utilise des composants connus, faciles à observer et à sauvegarder. Elle implique néanmoins une vraie exploitation : suivi des volumes, mises à jour des images, disponibilité de PostgreSQL, file de travaux et capacité disque. L'auto-hébergement rend la donnée locale, mais il transfère aussi la responsabilité de disponibilité à l'organisation.

Le dépôt propose une installation rapide et un script interactif en français ou en anglais. Une commande qui télécharge puis exécute un script distant est pratique pour un laboratoire. En production, il est préférable de cloner une version identifiée, d'inspecter le script, de vérifier les changements et de conserver une procédure de retour arrière.

Créer le contenu sans changer d'outil

Visio-Display veut réduire la dépendance à PowerPoint, Canva ou un studio graphique externe pour les besoins courants. Son éditeur 16:9 gère textes, images, formes, icônes et calques, puis exporte un PNG en 1920 x 1080 vers la médiathèque.

La publication d'Eric Tomas présente aussi un générateur de QR codes pour des usages comme une URL, un accès Wi-Fi, une fiche de contact ou un itinéraire. Un créateur de menus produit quant à lui une composition quotidienne ou hebdomadaire, avec dates, horaires et écrans cibles.

Ces fonctions sont importantes pour l'adoption. Dans de nombreuses structures, la difficulté n'est pas d'allumer l'écran, mais de permettre à une équipe non technique de produire rapidement une information cohérente. Un éditeur intégré raccourcit ce circuit, à condition de prévoir des modèles, une charte et une validation éditoriale.

Administrer aussi les écrans Linux

La partie la plus différenciante concerne les clients distants. Depuis l'administration, la plateforme peut préparer une machine Linux par SSH, installer Chromium en mode kiosque, configurer l'ouverture de session automatique et associer le terminal à un écran logique.

Les clients envoient ensuite un heartbeat accompagné d'informations comme la charge, la mémoire, la température, l'espace disque, la résolution ou la version installée. L'administrateur peut identifier un lecteur déconnecté et lancer certaines opérations à distance, dont un redémarrage ou une réinstallation.

Cette centralisation évite de traiter chaque mini-PC comme un poste isolé. Elle agrandit aussi le périmètre de confiance : le compte SSH, les jetons de heartbeat et les commandes distantes deviennent des actifs sensibles. Des clés dédiées, un utilisateur limité et un réseau d'administration séparé sont préférables à un compte généraliste disposant de privilèges permanents.

Des choix de sécurité intéressants, à éprouver

Le projet documente des rôles personnalisés, des permissions granulaires, des restrictions par écran et un journal des actions. Les pages d'affichage utilisent un jeton dédié, le heartbeat en possède un autre, et les opérations internes passent par leur propre secret. Les protections HTTP annoncées incluent CSRF, cookies configurables en mode sécurisé, filtrage des hôtes et plusieurs en-têtes de sécurité.

Le service chargé des mises à jour est séparé de l'application web. Cette isolation limite l'exposition directe du démon Docker à l'interface principale, un point essentiel dès qu'une fonction web peut reconstruire ou redémarrer des conteneurs. Elle ne dispense pas d'auditer les volumes, les droits du service privilégié et les commandes réellement autorisées.

Les sauvegardes peuvent être planifiées et restaurées depuis l'interface, avec une copie SMB optionnelle. Une sauvegarde n'est pourtant acquise qu'après un test de restauration sur une machine distincte. Les archives pouvant contenir une copie du fichier d'environnement, leur chiffrement et leur contrôle d'accès méritent la même attention que les secrets du serveur.

Les vérifications à mener avant un déploiement

Une preuve de concept sur deux écrans permet de mesurer plus que la qualité de l'interface :

• couper volontairement le réseau pour vérifier ce qu'un client continue réellement à afficher ;
• interrompre PostgreSQL ou Redis et observer le retour à un état stable ;
• tester une restauration complète, médias compris, sur une nouvelle instance ;
• placer l'administration derrière HTTPS et limiter son exposition réseau ;
• faire tourner les jetons et confirmer que les anciens clients sont bien refusés ;
• simuler une vidéo volumineuse, une file bloquée et un disque presque plein ;
• documenter la mise à jour, le gel de version et le retour arrière.

Le comportement hors ligne est particulièrement important. Le dépôt décrit un watchdog et le rafraîchissement régulier des listes, mais la persistance locale des médias pendant une longue coupure doit être confirmée selon le client et la version testés. Dans un hall critique, une page vide après une perte de liaison n'est pas acceptable.

Pour quels usages ?

Visio-Display paraît adapté aux associations, établissements, commerces, collectivités et équipes internes qui veulent conserver leurs contenus sur leur propre infrastructure. Il intéressera surtout les organisations déjà à l'aise avec Linux, Docker, un reverse proxy et la sauvegarde de services stateful.

Une entreprise qui recherche un contrat de disponibilité, un support permanent et un boîtier préconfiguré trouvera probablement un service SaaS plus simple. L'open source ne supprime ni le coût du matériel ni celui de l'exploitation. Il apporte en échange la maîtrise du code, des données et du rythme de déploiement.

Visio-Display illustre une évolution utile : l'affichage dynamique n'est plus seulement une succession de fichiers, mais un parc distribué à administrer. Le projet réunit déjà de nombreuses briques cohérentes. Sa valeur en production dépendra désormais de la robustesse des clients hors ligne, de la discipline d'exploitation et de la capacité de sa communauté à maintenir cette surface fonctionnelle ambitieuse.