Mur d'images open source : ce qui existe

Pourquoi les gens cherchent « mur d'images open source »

Trois types d'acheteurs aboutissent à cette recherche et attendent des réponses très différentes :

• L'acheteur de principe. Veut un logiciel à code accessible pour des raisons d'audit, de souveraineté de la chaîne d'approvisionnement ou de politique institutionnelle (universités, certains échelons gouvernementaux, défense). Il acceptera une construction DIY si aucun produit open source de qualité production n'existe.
• Le constructeur à budget contraint. Veut un logiciel gratuit parce que la tarification commerciale (2 500 € en perpétuel par serveur pour Craft Wall ; environ 504 $ par écran et par an, plus des frais de mise en service, pour un abonnement Userful dans le cadre du contrat de la ville d'Austin ; comparable pour les autres) dépasse le budget du projet. Généralement un petit déploiement — 2 à 6 écrans, un opérateur, en laboratoire ou en salle de classe.
• L'intégrateur qui évalue les options. Veut savoir si un prétendant open source concurrence vraiment les éditeurs commerciaux qu'il vend actuellement. La réponse honnête compte, car si un stack DIY couvre le besoin, son client n'aura peut-être pas besoin de la licence du tout.

La suite de cet article est écrite pour répondre honnêtement à ces trois cas.

La réponse honnête : aucun stack de mur d'images entièrement open source en 2026

Une plateforme de mur d'images complète combine cinq couches : l'ingestion de sources (NDI, RTSP, capture HDMI, IP-KVM, tableaux de bord rendus en web), un compositeur qui dispose les sources sur les écrans à la bonne échelle et au bon rafraîchissement, une interface opérateur pour le changement de disposition et la gestion des sources, un plan de gestion des utilisateurs / rôles / audit, et une surface d'intégration pour les systèmes externes (Genetec, Splunk, ServiceNow, MQTT, REST). Aucun projet de l'écosystème open source ne livre les cinq sous la forme d'un stack intégré de qualité production sous une licence approuvée par l'OSI, à la mi-2026.

Ce n'est pas un constat moral ni technique — c'est un constat de marché. Les murs d'images forment un marché restreint, B2B, à fiabilité 24/7. Les modèles de financement open source qui fonctionnent pour les outils de développeurs (dons, montée en gamme d'hébergement cloud, services) n'ont historiquement pas soutenu l'intensité d'ingénierie qu'exige un logiciel de salle de contrôle 24/7. Chaque projet qui s'y est essayé — et il y en a eu plusieurs depuis 2015 — a soit basculé vers le code fermé, soit fini en abandonware, soit stagné au seuil de la qualité démo.

Ce qui existe à peu près

Des composants open source utiles que vous pouvez réellement assembler si vous partez de zéro :

Composants de pipeline de sources

• GStreamer. Le cheval de trait. RTSP, fichier, capture HDMI via v4l2, capture d'écran, sources réseau, audio. L'écosystème de plugins couvre la plupart des formats d'entrée. L'entrée NDI est disponible via le plugin gst-plugin-ndi, qui fait désormais partie des plugins Rust officiels de GStreamer (gst-plugins-rs), mais il nécessite le runtime NDI propriétaire : vérifiez donc les conditions de licence du SDK NDI (Vizrt) avant tout déploiement commercial.
• FFmpeg. Transcodage, capture, protocoles réseau. Souvent placé derrière GStreamer ou à ses côtés. Indispensable comme couteau suisse.
• v4l2-ctl + uvcvideo. Prise en charge au niveau du noyau Linux des cartes de capture HDMI USB et PCIe (Magewell, anciens modèles Elgato, Blackmagic avec le SDK Linux officiel).

Disposition et rendu

• X11 + xrandr. La voie classique. Configurez un seul écran X couvrant toutes les sorties d'un ou plusieurs GPU, utilisez des gestionnaires de fenêtres (i3, awesome, herbstluftwm) pour placer les fenêtres avec précision. Cela fonctionne, mais les performances multi-GPU de X11 se dégradent au-delà d'environ 4 sorties et le tearing sur la vidéo à cadence élevée est un problème de réglage permanent.
• Wayland avec sway ou Hyprland. La meilleure voie en 2026. Sway (bâti sur wlroots) et Hyprland (sur son propre backend Aquamarine depuis la version 0.42, en 2024) gèrent proprement le multi-sortie et prennent en charge le rafraîchissement et la mise à l'échelle par sortie. Le pilote propriétaire de NVIDIA s'est nettement amélioré sous Wayland depuis l'arrivée de la synchronisation explicite (explicit sync) en 2024, mais sway le considère toujours comme non pris en charge : testez avant de vous engager. Le plafond pratique est fixé par les sorties du GPU : jusqu'à quatre écrans par carte grand public, davantage avec plusieurs GPU ou des cartes professionnelles multi-sorties.
• WebGPU / basé navigateur. Un navigateur en plein écran sur tout le mur, rendant les sources dans une grille de canevas, peut vous mener étonnamment loin. Les plateformes commerciales fonctionnent autrement : Craft Wall, par exemple, compose l'image du mur sur le GPU du serveur et utilise le navigateur comme console opérateur.

Détournement d'outils de production

• OBS Studio. Conçu pour le streaming, mais son modèle de composition de scènes se mappe à 1:1 sur les dispositions de mur d'images. Piloter OBS via WebSocket depuis un script planifié, chaque « scène » étant une disposition de mur, constitue une configuration mono-opérateur viable. Le multi-sortie exige le plugin multi-output et devient fragile au-delà de 4 sorties.
• MagicMirror² et similaires. Des frameworks de tableau de bord mono-écran. Juxtaposez-en quelques-uns et vous obtenez un mur passif — utile pour les halls d'accueil et la signalétique numérique, pas pour les salles de contrôle avec interaction d'un opérateur.

Choses souvent classées à tort comme « mur d'images open source »

• Hyperion. Contrôleur d'éclairage d'ambiance open source pour téléviseurs. Pilote des bandeaux LED derrière un écran. Pas un mur d'images.
• Stacks de signalétique basés sur Pi (Anthias, anciennement Screenly OSE). Des planificateurs de signalétique numérique open source pour la lecture sur écran unique. Assemblables en un mur en mosaïque statique, pas en un mur opérateur interactif multi-source.
• OpenScreens, OpenWalls, et d'autres projets GitHub aux noms prometteurs — la plupart sont des preuves de concept abandonnées (dernier commit 2018-2020). Vérifiez toujours l'activité récente des commits avant de supposer qu'un projet est vivant.

Là où les plateformes commerciales justifient encore leur licence

Construire un mur de laboratoire de 4 écrans avec les composants ci-dessus est un projet de week-end pour un ingénieur Linux compétent. Construire un mur NOC de 16 écrans, 24 sources, 24/7, multi-opérateur avec les mêmes composants est un projet d'ingénierie de plusieurs mois qui produit un stack sur mesure non supporté dont l'équipe informatique du client hérite pour toujours. Le seuil de rentabilité entre le coût d'ingénierie DIY et le prix de licence commerciale penche fortement vers « acheter » dès que l'un de ces points entre en jeu :

• Plus de 6 écrans pilotés depuis un seul nœud, ou toute configuration multi-nœud
• Plus de 8 flux de sources simultanés, surtout avec des transports mixtes (NDI + RTSP + HDMI + web)
• Deux opérateurs ou plus avec accès basé sur les rôles et piste d'audit
• Auto-rétablissement en cas de panne de source sans intervention de l'opérateur
• Un éditeur responsable du support pendant un incident de production
• Une posture de conformité ou d'audit exigeant un historique des modifications documenté et un éditeur de référence nommé

Voir la décomposition du TCO sur 5 ans pour la comparaison chiffrée entre un mois-ingénieur DIY + la maintenance continue et une licence commerciale perpétuelle. Pour la plupart des déploiements de production au-dessus des seuils ci-dessus, le DIY finit par coûter plus cher une fois le temps d'ingénierie chiffré honnêtement.

Quand le DIY open source est le bon choix

Il existe de vrais cas où la construire soi-même est la bonne réponse :

• Murs de laboratoire et de R&D. 2 à 4 écrans, un ingénieur, aucun SLA de disponibilité, le travail se déroule en heures ouvrées. Un stack basé sur sway avec des sources GStreamer et un script de changement de disposition convient.
• Environnements pédagogiques. Universités et écoles techniques où le mur lui-même est la matière enseignée. Les composants open source sont pédagogiquement plus utiles qu'un produit commercial dont les étudiants ne peuvent inspecter les rouages.
• Prototypes avant acquisition. Un mur DIY jetable qui valide les exigences de sources et de disposition avant un appel d'offres commercial complet. Économise un argent réel sur l'acquisition finale.
• Signalétique purement passive. Aucune interaction d'opérateur, programmation fixe, contenu à faible enjeu (hall, cafétéria, panneau d'information). Anthias ou une session Wayland avec un diaporama scripté gère cela sans peine.
• Petits NOC en poste unique. Un opérateur, 4 à 6 écrans, en journée seulement, récupération manuelle acceptable. Cas limite — une petite licence commerciale perpétuelle reste généralement le choix rationnel sur un horizon de 5 ans, mais le DIY se défend.

Où se situe Craft Wall dans ce tableau

Craft Wall est à code fermé. On nous a posé la question de l'open source assez souvent pour que nous y répondions directement plutôt que de la laisser implicite sur une page marketing.

Nous avons choisi le code fermé à licence perpétuelle pour trois raisons. Premièrement, l'intensité d'ingénierie nécessaire à une fiabilité 24/7 n'est soutenue que par un engagement de support et de feuille de route rémunéré, et le modèle à licence perpétuelle le finance plus fiablement que ne le font les modèles économiques open source pour un marché B2B de niche comme les murs d'images. Deuxièmement, le perpétuel plutôt que l'abonnement protège le client du genre de cycle de migration forcée que traversent actuellement les clients Userful v11.x — une fois que vous avez acheté une licence Craft Wall, elle reste valide indéfiniment. Troisièmement, nous voulions un récit d'acquisition qui n'oblige pas le client à devenir lui aussi éditeur de la plateforme qu'il a achetée, ce que les modèles commerciaux uniquement open source / services impliquent souvent en pratique.

Ce que nous faisons pour éviter tout verrouillage, malgré le code fermé : nous tournons sur du Linux standard (Ubuntu LTS, RHEL, Debian — aucun verrouillage sur un OS propriétaire), nous ingérons les sources via des protocoles et interfaces largement utilisés (NDI, sans redevance mais propriétaire, ainsi que RTSP et les cartes de capture HDMI ; les flux IPMX arrivent via un décodeur certifié et une capture HDMI/SDI), nous n'avons aucun plan de contrôle cloud et n'envoyons aucune télémétrie, et l'interface opérateur est un navigateur qui interroge un serveur à l'intérieur de votre périmètre — vos données, votre réseau, votre contrôle d'accès. Le binaire du compositeur est propriétaire ; l'infrastructure qui l'entoure est la vôtre.

Si votre exigence est « l'ensemble du stack doit être open source en tant que ligne d'acquisition », Craft Wall n'est honnêtement pas le bon produit et une construction DIY GStreamer + Wayland, étroitement cadrée sur le déploiement, est votre voie. Si votre exigence est « pas de verrouillage propriétaire, sur site, pas de télémétrie, propriété perpétuelle », Craft Wall y répond sans être open source.

Ce qu'il faut demander avant de choisir

Trois questions diagnostiques couvrent la plupart des décisions dans ce domaine :

• L'« open source » est-il une exigence d'acquisition stricte, ou une préférence ? Exigence stricte → DIY, aucun produit commercial ne se qualifie en 2026. Préférence motivée par des préoccupations de verrouillage / coût / souveraineté → les produits commerciaux à licence perpétuelle qui tournent sur une infrastructure ouverte répondent à la plupart des mêmes objectifs.
• Quelle est l'échelle du déploiement et le modèle opérateur ? ≤4 écrans / un seul opérateur / heures ouvrées → le DIY est viable. ≥8 écrans / plusieurs opérateurs / 24/7 → plateforme commerciale, le point de bascule du coût d'ingénierie joue en votre faveur.
• Qui portera la charge du support dans trois ans ? Équipe informatique interne assez étoffée pour hériter d'un stack sur mesure → le DIY est jouable. Équipe informatique réduite qui a besoin d'un éditeur engagé → commercial, idéalement perpétuel plutôt qu'abonnement.

À lire ensuite

Pour le face-à-face avec les huit plateformes commerciales les plus susceptibles d'apparaître dans la même évaluation, voir le meilleur logiciel de mur d'images en 2026. Pour le calcul de prix derrière les voies DIY vs commerciale vs contrôleur matériel, la décomposition du TCO déroule un NOC de 16 écrans sur cinq ans. Pour l'architecture opérationnelle d'un vrai mur NOC — DIY ou commercial — voir l' architecture de référence NOC.