Vers 2022-2023, plusieurs fournisseurs de murs d'images ont parié sur un avenir géré dans le cloud — la configuration du mur, le routage des sources, parfois la vidéo elle-même, le tout transitant par un plan de contrôle SaaS. En 2026, ce pari a un verdict clair : le tout-cloud a échoué à la revue de conformité dans chaque secteur réglementé qu'il a tenté de pénétrer. Ce qui a survécu, et ce qui est désormais l'architecture par défaut, c'est le pattern hybride. Cet article expose ce qui va dans le cloud, ce qui reste sur site, et pourquoi cette répartition n'est pas un compromis mais la conception correcte.
Pourquoi le management tout-cloud des murs d'images a échoué
L'argumentaire tout-cloud était séduisant sur le papier : gérer chaque mur sur chaque site depuis un seul navigateur, pousser les mises à jour de façon centralisée, aucun serveur sur site à maintenir. Le problème est qu'un mur d'images dans une salle de contrôle, un NOC ou un SOC véhicule du contenu que les régulateurs n'autorisent pas à quitter le bâtiment.
Un mur NOC affiche la topologie réseau en direct et des données de panne impactant les clients. Un mur SOC affiche des flux de caméras de sécurité en direct et des alertes SIEM. Une salle de contrôle d'énergéticien affiche de la télémétrie SCADA d'infrastructure critique. Faire transiter l'un de ces éléments par un cloud tiers — ne serait-ce que comme un signal de contrôle qui implique les données sous-jacentes — déclenche une revue de conformité que les architectures tout-cloud ne peuvent pas franchir.
Les quatre murs de conformité
- RGPD (UE). Les flux de caméras en direct contenant des personnes identifiables sont des données à caractère personnel au sens de l'article 4(1). Traiter ces données via un plan de contrôle hébergé hors de l'UE — ou par un fournisseur cloud dont le siège est aux États-Unis et soumis au CLOUD Act américain — exige des garanties de niveau Schrems II que la plupart des sites ne peuvent établir.
- FZ-152 et FZ-187 (Russie). La localisation des données personnelles impose que les données des citoyens russes soient traitées sur des serveurs en Russie. La FZ-187 ajoute des règles relatives à l'infrastructure d'information critique — l'énergie, le transport, la finance et les opérations gouvernementales doivent conserver la couche opérationnelle dans le pays, et souvent en air-gap.
- FedRAMP et niveaux d'impact du DoD (fédéral américain). Un mur d'images dans un établissement fédéral traitant des informations contrôlées ou classifiées ne peut pas transiter par un plan de contrôle SaaS commercial sans une autorisation que l'équipe d'achat n'obtient presque jamais.
- BSI C5 (Allemagne). Le catalogue fédéral allemand de critères de sécurité du cloud fixe un seuil que la plupart des plans de contrôle SaaS généralistes n'atteignent pas, poussant les déploiements du secteur public allemand vers des conceptions sur site ou cloud souverain.
L'un quelconque de ces points suffit à disqualifier un mur d'images tout-cloud d'un déploiement réglementé. En pratique, la plupart des grands acheteurs de salles de contrôle en affrontent au moins un.
Le pattern hybride — ce qui va où
L'architecture hybride scinde le système selon une ligne nette : le plan de contrôle peut vivre dans le cloud ; le plan de données reste sur site. Mersive a formulé cette séparation tôt, et c'est désormais la norme de la catégorie.
Ce qui peut vivre dans le cloud
- L'interface de gestion elle-même — l'application navigateur qu'un administrateur utilise pour configurer les murs, hébergée en tant qu'application SaaS
- Les métadonnées de configuration — définitions de dispositions, scènes nommées, comptes utilisateurs et permissions, catalogues de sources (l'adresse d'une source, pas son contenu)
- La télémétrie de parc — quels murs sont en ligne, versions logicielles, état de santé sur l'ensemble des sites
- Les journaux d'audit — le relevé de qui a modifié quoi et quand (les métadonnées des modifications, pas le contenu affiché)
Ce qui doit rester sur site
- La vidéo elle-même — chaque pixel de chaque flux source. Les flux de caméras, les rendus de tableaux de bord, les sessions KVM ne quittent jamais le réseau local
- Le compositeur — le moteur qui dispose les sources sur le mur tourne sur le serveur sur site, à côté des écrans qu'il pilote
- L'ingestion des sources — les points d'extrémité NDI, RTSP, IPMX, KVM se connectent au serveur sur site, pas à un point d'extrémité cloud
- Le chemin de repli — si le plan de contrôle cloud est injoignable, le serveur sur site doit maintenir le mur en fonctionnement avec sa dernière configuration connue. Le mur ne peut pas dépendre de la connectivité cloud pour afficher.
Le plan de contrôle dans le cloud
La valeur que le plan de contrôle cloud apporte véritablement, une fois que le plan de données est correctement conservé en local :
- Gestion multi-sites — une seule interface pour un opérateur NOC gérant des murs répartis sur une douzaine de sites
- Déploiement de configuration centralisé — pousser une nouvelle scène nommée vers tous les sites à la fois
- Visibilité du parc — état de santé et de version sur l'ensemble du parc sans toucher à chaque serveur
La contrainte qui rend cela sûr : le plan de contrôle gère des adresses et des définitions, jamais du contenu. Un plan de contrôle cloud qui dit « place la source 10.20.30.40 dans la tuile 3 » est conforme. Un plan de contrôle cloud qui relaie la vidéo de 10.20.30.40 ne l'est pas. L'architecture doit faire respecter cette ligne, pas seulement la documenter.
Le plan vidéo sur site
Le serveur sur site effectue le travail qui ne peut pas quitter le bâtiment : il ingère chaque source, exécute le compositeur, pilote les écrans, et conserve une copie locale complète de la configuration pour survivre à une panne du cloud. Pour un déploiement réglementé, le serveur sur site est aussi la frontière d'air-gap — il peut fonctionner sans aucune connexion Internet sortante, le plan de contrôle cloud étant simplement indisponible et le mur géré localement.
C'est le test pour tout fournisseur revendiquant l'« hybride » : débranchez Internet, et le mur doit continuer de fonctionner et rester gérable localement. Si le mur se dégrade ou que l'interface de gestion devient injoignable, l'architecture est dépendante du cloud, pas hybride.
Le KVM dans le modèle hybride
L'IP-KVM est le cas où la frontière sur site compte le plus. Une session KVM, c'est un opérateur prenant le contrôle en direct d'un ordinateur source — le trafic le plus sensible du mur. Dans une architecture hybride, la session KVM est strictement sur site : le plan de contrôle cloud peut savoir qu'une route KVM existe et qui est autorisé à l'utiliser, mais le trafic clavier, vidéo et souris circule entièrement sur le réseau local. Tout fournisseur dont le chemin KVM touche le cloud n'a pas construit un système hybride conforme.
Où se place Craft Wall
Craft Wall est sur-site d'abord par conception. Le compositeur, l'ingestion des sources et la configuration complète tournent sur un serveur Linux standard à l'intérieur du site. L'interface de pilotage par navigateur est servie par défaut depuis ce même serveur sur site — ce qui signifie que le déploiement de base est le cas air-gap, sans aucune dépendance au cloud.
Un plan de contrôle cloud est la couche optionnelle au-dessus, pour les acheteurs qui exploitent plusieurs sites et veulent une gestion centralisée — et il respecte la répartition stricte ci-dessus : métadonnées et gestion uniquement, jamais de vidéo, le serveur sur site restant pleinement fonctionnel si la couche cloud est retirée. Pour un déploiement réglementé, la couche cloud n'est tout simplement pas activée. Voir l'architecture de référence NOC pour la conception sur site et le comparatif des huit plateformes pour la façon dont les fournisseurs diffèrent sur la question de la dépendance au cloud — c'est l'une des lignes de démarcation les plus nettes de la catégorie.
Conclusion
Le mur d'images tout-cloud était un pari raisonnable que l'environnement de conformité a tué. L'hybride n'est pas une demi-mesure — c'est l'architecture correcte : le cloud fait ce que le cloud sait faire (gestion multi-sites, déploiement centralisé) et la couche sur site fait ce que la réglementation exige (chaque pixel reste dans le bâtiment). Le test de l'acheteur est simple et physique : débranchez Internet, et le mur continue de fonctionner. Si c'est le cas, l'architecture est hybride. Sinon, c'est une architecture dépendante du cloud portant une étiquette hybride.
À lire ensuite : l'architecture de référence NOC pour la conception sur site, les murs d'images augmentés par l'IA pour comprendre pourquoi l'inférence sur site suit la même logique de conformité, et le comparatif Craft Wall vs Userful pour le contraste de dépendance au cloud dans une évaluation réelle.