Sommaire
- Architecture
- Gestion des écrans et des contenus
- Déploiement et fonctionnement des clients
- Administration et exploitation
- Installation en une commande
- Pourquoi publier ce retour ici ?
Bonjour,
Je développe depuis quelque temps Visio-Display, une plateforme libre d’affichage dynamique distribuée sous licence GPL-3.0. Le projet est né d’un besoin simple : administrer plusieurs écrans depuis une interface centralisée, tout en conservant la maîtrise de l’hébergement, des données et des clients d’affichage.
Au fil du développement, le projet a dépassé la simple diffusion d’images et de vidéos. Il couvre maintenant une partie importante du cycle de vie d’une infrastructure d’affichage : création et planification des contenus, déploiement des clients, supervision, maintenance, sauvegardes et mises à jour.
Le dépôt est disponible sur GitHub :
https://github.com/woofix/visio_display
Architecture
Le serveur repose principalement sur :
- Python, Flask et Gunicorn pour l’application web ;
- PostgreSQL pour les données persistantes ;
- Redis et RQ pour le cache et les tâches en arrière-plan ;
- Docker Compose pour le déploiement et l’exploitation des services.
L’ensemble est auto-hébergé. Je l’exploite et le valide sur ma propre infrastructure, avec de véritables clients Linux raccordés au serveur.
Gestion des écrans et des contenus
Depuis l’interface web, il est possible de créer plusieurs écrans nommés et de gérer leur contenu indépendamment.
La bibliothèque de médias accepte notamment les images, les vidéos et les documents PDF. Les contenus peuvent être organisés dans des listes de lecture avec un ordre et une durée d’affichage propres à chaque élément.
La planification permet de définir des périodes de diffusion selon les dates et les horaires. Le projet dispose également de groupes de médias et de campagnes prioritaires temporaires permettant de remplacer momentanément la programmation normale avant de revenir automatiquement à la liste de lecture habituelle.
Un éditeur d’annonces au format 16:9 est intégré. Il permet de préparer rapidement un visuel depuis l’interface puis de l’exporter directement vers la bibliothèque de médias.
Un générateur de QR codes permet aussi de créer des contenus pour différents usages : réseau Wi-Fi, URL, contact, emplacement cartographique, messagerie ou texte libre.
Déploiement et fonctionnement des clients
Visio-Display peut préparer et déployer à distance des clients Linux configurés en mode kiosque, notamment via SSH.
Chaque client conserve localement sa configuration et son jeton de heartbeat. Un service systemd assure ensuite la communication avec le serveur. Le premier heartbeat est envoyé environ quinze secondes après le démarrage, puis toutes les trente secondes.
Si un client perd son alimentation ou sa connexion réseau, le serveur le considère simplement comme hors ligne après cinq minutes sans heartbeat. Aucun nouvel appairage manuel n’est nécessaire : lorsque la machine redémarre ou retrouve le réseau, le service reprend ses communications et le serveur reconnaît le même client.
L’interface permet de consulter l’état des clients, leurs informations système et leurs captures d’écran. Des opérations de maintenance à distance sont également présentes : redémarrage, arrêt, réinstallation et mise à jour.
Administration et exploitation
La plateforme intègre notamment :
- la gestion des utilisateurs, rôles et permissions ;
- des journaux d’activité ;
- des jetons distincts selon les usages ;
- des sauvegardes manuelles ou planifiées ;
- une restauration depuis l’interface web ;
- des copies SMB optionnelles ;
- un mécanisme contrôlé de mise à jour du serveur ;
- une API utilisée pour les communications et certaines opérations d’administration.
L’objectif n’est pas seulement d’afficher un média, mais de disposer d’un ensemble exploitable au quotidien : savoir quels écrans sont disponibles, intervenir à distance et restaurer le service sans devoir se connecter manuellement à chaque machine.
Installation en une commande
Pour simplifier les essais et les nouveaux déploiements, un installateur guidé est disponible. Sur un serveur Linux disposant de Docker, Docker Compose et Git, l’installation peut être lancée avec :
L’installateur est proposé en français et en anglais. Il vérifie les prérequis, clone le dépôt, génère les secrets, prépare l’environnement, crée le compte administrateur, construit les conteneurs et démarre les services.
bash <(curl -fsSL https://raw.githubusercontent.com/woofix/visio_display/main/server-install.sh)
Une installation manuelle avec Docker Compose reste documentée pour celles et ceux qui préfèrent contrôler chaque étape.
Pourquoi publier ce retour ici ?
Visio-Display est pour moi un projet concret à la croisée du développement web, de Linux, de Docker, du réseau, de l’automatisation et de l’exploitation système.
J’ai utilisé ChatGPT/Codex comme assistant pour certaines suggestions de code, revues, tests et tâches de documentation. Je reste le mainteneur du projet : je définis l’architecture, réalise les déploiements et valide les fonctionnalités sur l’instance en fonctionnement. Ce journal a également été préparé avec cette assistance, puis vérifié par rapport au code et à l’application déployée.
Je serais intéressé par les retours de personnes exploitant déjà des écrans d’information ou des bornes interactives : quels matériels et environnements vous sembleraient les plus pertinents à tester ? Les rapports de bogues, essais et contributions sont naturellement bienvenus.
# C'est lassant à la longue...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 7 (+8/-3).
Pourquoi tous les slopwares soit-disant "libre" qui débarquent ici depuis quelques mois sont-ils tous hébergés chez Microsoft ?
[^] # Re: C'est lassant à la longue...
Posté par Misc (site web personnel) . Évalué à 10 (+12/-1).
Parce que c'est gratuit avec des quotas généreux et que gérer l'infra est le souci de quelqu'un d'autre. Je suis pour le self hosting, j'ai ma propre forge à mes pieds (gitea et woodpecker sur une VM Fedora), mais je fait quand même des miroirs de mon code sur et depuis Github parce que j'ai pas de registre local pour les conteneurs (j'y travaille) et que j'ai plus de stockage que ce que j'aurais en local pour mes images de conteneurs (la, va falloir attendre avant de changer le matos), parce que quelqu'un s'est fait chier à installer dependabot/renovate pour que ça marche out of the box (j'y travaille aussi) et parce que ma forge n'est qu'en IP v6 (ça, j'y travaille pas, le reste du monde doit se tirer les doigts du cul à ce niveau).
Et si je devais présenter mon code, je donnerais celui sur github pour 1) ne pas faire crever mon serveur sous la charge 2) m'assurer d'avoir plus de retour, car je pense que pas grand monde à un compte sur les autres forges à part peut être gitlab.com (même si toutes n'ont pas besoin d'un compte, genre sourcehut).
Codeberg refuse les codes fait par LLM, Sourcehut également. Framagit était surchargé il y a pas si longtemps et dans mon souvenir. Donc bon, ç'est soit github.com, soit gitlab.com
[^] # Re: C'est lassant à la longue...
Posté par devnewton 🍺 (site web personnel) . Évalué à 0 (+3/-6).
C'est gratuit parce que c'est toi le produit.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: C'est lassant à la longue...
Posté par nud . Évalué à 6 (+4/-0).
C'est intéressant comme citation mais du coup ça s'applique aussi à codeberg?
[^] # Re: C'est lassant à la longue...
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+8/-0).
À LinuxFr.org ?
[^] # Re: C'est lassant à la longue...
Posté par Christophe . Évalué à 2 (+0/-0).
Codeberg (et LinuxFr.org) étant à but non lucratif, je ne vois pas comment l'utilisateur peut devenir un produit...
[^] # Re: C'est lassant à la longue...
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Un service alors ⸮
[^] # Re: C'est lassant à la longue...
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
remboursez !
[^] # Re: C'est lassant à la longue...
Posté par Christophe . Évalué à 3 (+1/-0).
Ca ne me dérange pas de rendre service à LinuxFr :) (ou à Codeberg)
[^] # Re: C'est lassant à la longue...
Posté par devnewton 🍺 (site web personnel) . Évalué à -4 (+5/-12).
Pour Codeberg et Linuxfr, tu n'es pas un produit, tu es un collaborateur, car le premier allemand et le second est le site français du logiciel libre et du néonazisme.
Bon vendredi !
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
# ben OK
Posté par bubar🦥 . Évalué à 10 (+8/-1).
"Encore un truc généré par ia" ? mouhai visiblement en partie, mais le soft a l'air vraiment chouette, et la doc est nickel. Bon le code est parfois what the fuck, c'est du Claude (exemple : import shutil run_cmd = ( f"\chmod +x {remote_script} && bash {remote_script} : d'abord c'est pas beau parce que bin_fmt hein, et ensuite pour un truc pareil je prendrai pas la var depuis un fichier o+w) mais bon, c'est un joli soft qui réponds à un joli besoin, le tout sous gplv2, alors ben Merci Monsieur.
# Retours
Posté par devnewton 🍺 (site web personnel) . Évalué à -4 (+8/-15).
J'ai demandé un retour de chiengpt, le voici, tu le trouveras sans doute aussi passionnant que ton journal:
Wouaf waf ouaf ouaf ouaf waf waf, wouf waf waf wouf wouaf. Wouf ouaf wouaf wouaf ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
# Stop this
Posté par Doug Le Tough (site web personnel) . Évalué à 10 (+11/-0).
Il serait temps d'arrêter de diffuser cette très mauvaise pratique.
En fait, il aurait été mieux de ne pas commencer.
[^] # Re: Stop this
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 5 (+4/-1). Dernière modification le 28 août 2026 à 10:08.
Et puis, je suis allé voir ce script. OMFG, c'est vraiment d'une complexité effrayante ! Si quelqu'un envisage d'en faire une analyse complète, il devra prévoir quelques journées et une bonne provision de pain/fromage/bière.
# Après avoir lire cette prose immonde (et même sur github pour dire)...
Posté par skeespin (site web personnel) . Évalué à 5 (+4/-0).
Je ne comprends encore pas à quoi sert véritablement ton application...
Tu parles de bornes interactives mais ça a l'air d'être de simples écrans de veille qui défilent des infos, rien de plus.
Dans ces cas, tu nous parles de résolution (MAX_WIDTH/HEIGHT) alors que souvent dans une campagne de pub tu veux du contenu qui s'adapte de la tablette à un écran d'affichage en panneau 4:3.
Par contre, pour le reste... ça blablate.
C'est un peu si GIMP, nous présentait en page d'accueil les fonctionnalités de copier/coller, la couche GEGL, la courbe des couleurs, le format XCF,...
Tu confonds une documentation technique et une présentation de l'application.
# Intérêt du projet par rapport aux dégâts nécessaires pour le créer ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6 (+7/-3).
Bonjour,
Les IA génératives ont des impacts négatifs très importants, tu en trouveras une liste assez complète ici : https://davidbeck.fr/blog/pourquoi-ia-non.html
En quoi est-ce que ce projet valait la peine de provoquer autant de dégâts ?
Si tu n'étais pas au courant de ces externalités, est-ce que tu prévois de continuer à utiliser de telles IA, et si oui pourquoi ?
Bonne journée.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
# Quelques questions
Posté par Philippe F (site web personnel) . Évalué à 8 (+6/-0).
J'ai du déployer une solution dans le même esprit à mon travail, pour gérer l'affichage d'une quarantaine d'écrans, sur 7 sites différents, avec la notion de contenu global à la boite ou local au site, voire local à l'écran.
Les questions pertinentes auxquelles j'ai du faire face:
- quid de la sécurité ? Si on a accès au clavier d'un des kiosques, on peut faire ce qu'on veut dessus ? Quel mécanisme de verrouillage ?
- que se passe-t-il si l'un des kiosques est débranché du réseau ?
- quid de la sécurité des flux entre le serveur et les kiosques ?
- comment est géré le décalage horaire si un kiosque est dans un fuseau horaire différent du serveur principal ?
- est-ce qu'on peut individualiser les affichages sur un groupe d'écrans ?
- est-ce qu'on peut diffuser une présentation powerpoint (l'outil de référence de création de visuels en grande entreprise) ?
- combien de temps mettent les kiosques à se mettre à jour, et selon quelle politique lorsqu'une nouvelle compagne de diffusion est organisée ?
- quel est le matériel minimum pour gérer un kiosque ? Est-ce qu'un rapsberry Pi est suffisant pour faire un affichage ? Surtout si on veut diffuser des vidéos ?
Qu'est ce que ça donne pour ta solution ?
Dans ma boite, on a opté pour Xibo ( https://xibosignage.com/ ) qui a la gros avantage d'être entièrement libre et d'exister depuis plus de 10 ans. Autre avantage, le kiosque peut tourner sous Linux, Windows ou Android. Le seul truc que j'ai trouvé dommage, c'est que le portage sur RPi est abandonné parce qu'il est considéré comme trop faible en ressource pour un kiosque lors de la diffusion de vidéo.
Finalement, nos kiosque tournent sur des mini-PC Windows 11 qui ont l'énorme avantage d'être compatible avec la politique sécurité de la boite (mais mettent 5 minutes à booter). L'équipe sécurité aime pas trop qu'on déploie du matériel random sur leur réseau, je sais pas pourquoi.
Pourquoi ne pas être partie sur du Xibo de ton côté ?
[^] # Re: Quelques questions
Posté par Thierry Pasquier (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
Foyer, un plugin Wordpress, trop rudimentaire pour apporter des réponses pertinentes à tes questions mais qui a fait le boulot pour informer les publics de mon établissement pendant quelques années.
Il y a un bon moment déjà, il a été viré du dépôt des plugins WP pour des soucis de sécurité, et... réhabilité il y a quelques mois.
https://wordpress.org/plugins/foyer/
https://foyer.tv/
[^] # Re: Quelques questions
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
Merci pour la découverte.
"Si tous les cons volaient, il ferait nuit" F. Dard
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.