Switch cloud managed : une fausse bonne idée en vidéoprotection ?

Un switch qui a besoin d’Internet pour être administré est un switch qu’Internet peut atteindre. C’est toute la contradiction du cloud management appliqué à la vidéoprotection : la fonction qui vous fait gagner dix minutes de maintenance vous impose une topologie réseau que vous auriez refusée en phase d’étude.

L’argument est pourtant mis en avant par plusieurs acteurs du marché : administration à distance, pas de VPN, pas de configuration. Sur le papier, c’est séduisant. Sur un site de vidéoprotection réellement exploité, ça déplace le problème, et pas dans le bon sens.

Ce que le cloud management impose à votre architecture

Un switch cloud managed n’a pas d’interface d’administration locale exploitable : il se pilote depuis un portail hébergé par le constructeur. Pour cela, il doit pouvoir sortir vers Internet en permanence. Concrètement, il ne peut donc pas être placé sur un sous-réseau vidéo isolé : il doit être raccordé au réseau du client, celui de la box ou du routeur Internet.

Et comme le switch est la nourrice PoE de l’installation, tout ce qui est en dessous suit : les caméras se retrouvent sur ce même réseau, et bien souvent l’enregistreur ou le serveur également. Vous n’avez pas ajouté une fonction d’administration à distance, vous avez déplacé l’intégralité du parc vidéo depuis un réseau dédié vers le réseau général du client.

Deux conséquences immédiates sur le terrain

La surface d’exposition change d’échelle. Sur un sous-réseau vidéo dédié, une caméra n’est joignable que par l’enregistreur. Sur le réseau du client, elle est joignable par tout ce qui s’y trouve : les postes bureautiques, l’imprimante multifonction, le poste de l’intérimaire, l’objet connecté installé par un autre prestataire, et tout ce qui aura été mal configuré au niveau du routeur. C’est l’inverse de ce que demandent les référentiels de durcissement, et un point que vous aurez à défendre par écrit à l’approche des obligations issues de la directive NIS2, comme nous le détaillons dans notre dossier NIS2 et sûreté vidéo.

La box devient le cœur de réseau de l’installation vidéo. C’est la conséquence la moins visible en phase d’étude, et elle mérite d’être formulée avec précision, parce que tout ne tombe pas au même moment ni pour les mêmes raisons. Deux situations sont à distinguer.

• La ligne Internet tombe, la box reste sous tension. Vous perdez l’administration du switch, puisque le portail du constructeur n’est plus joignable, mais le réseau local continue de fonctionner : la box assure toujours la commutation entre les équipements qui lui sont raccordés. Les caméras et l’enregistreur se voient, l’enregistrement se poursuit.
• La box elle-même est hors service. Vous perdez les deux. Plus d’administration, et plus de réseau local non plus : c’est elle qui sert de cœur de réseau, donc sans elle les périphériques qui y sont branchés ne communiquent plus. Le transit vidéo s’arrête, et l’enregistrement avec.

S’y ajoutent les incidents qui ne coupent ni la ligne ni l’alimentation mais produisent le même effet : remplacement de la box par l’opérateur, changement de plan d’adressage, bail DHCP qui part de travers. Dans une architecture où le switch est placé sous l’enregistreur ou le serveur, aucun de ces événements n’atteint le segment vidéo : la coupure Internet fait perdre l’accès distant, pas l’enregistrement.

Les angles morts du modèle cloud

Au-delà de la topologie, le modèle introduit trois dépendances qu’il faut assumer devant le client.

• Le compte du portail devient la clé de tous les sites. Un tenant cloud compromis, c’est un accès d’administration sur l’ensemble des parcs rattachés, pas sur un seul site.
• La durée de vie du service n’est pas celle du matériel. Une installation s’amortit sur sept à dix ans ; un portail peut changer de modèle tarifaire, passer sur abonnement ou fermer bien avant.
• La télémétrie sort du site. Topologie, adresses, ports actifs, équipements raccordés : ce sont des informations d’infrastructure qu’il faut savoir localiser et documenter, même si aucune image vidéo n’est concernée.

L’architecture que nous recommandons

Le principe n’a pas changé : le switch et les caméras vivent sur un sous-réseau dédié, placé derrière l’enregistreur ou le serveur. Ce dernier dispose de deux interfaces réseau, une côté client et une côté vidéo. Les caméras n’ont pas de route par défaut vers Internet, le switch n’est pas joignable depuis l’extérieur, et le plan d’adressage du client peut évoluer sans toucher à l’installation.

Le gain n’est pas seulement sécuritaire, il est aussi opérationnel : plus de conflit d’adresses avec l’informatique du client, pas de multicast qui pollue le réseau bureautique, et un périmètre clair en cas d’incident. C’est la logique que nous appliquons également aux sujets de firmware et de comptes, détaillés dans notre article sur la cybersécurité de la vidéoprotection.

Administrer à distance sans exposer le switch

C’est la seule objection sérieuse au sous-réseau isolé, et elle a une réponse. Le serveur Nx Witness embarque un proxy : il sait relayer vers le client Nx les interfaces web des équipements qu’il voit sur son propre réseau. Vous ajoutez l’interface du switch comme ressource web dans le système, en activant le proxy par le serveur, et elle devient accessible depuis le client Desktop, le navigateur ou le mobile, exactement comme une caméra.

Ce que ça change, point par point : le switch conserve une simple adresse IP privée sur le sous-réseau vidéo ; il n’a besoin d’aucune route vers Internet, d’aucune redirection de port, d’aucun tunnel à maintenir ; l’accès transite par le serveur, donc par l’authentification et les rôles utilisateurs de Nx, ce qui vous permet de décider qui voit l’interface du switch. Et vous restez libre du choix du matériel : n’importe quel switch managé classique fonctionne, y compris les modèles PoE d’entrée de gamme.

En pratique, l’exploitant se connecte à son système comme d’habitude, ouvre l’onglet du switch, vérifie l’état des ports et la consommation PoE, puis redémarre le port d’une caméra figée sans se déplacer. Vous obtenez le bénéfice réel du cloud management, la main à distance, sans en payer le prix architectural.

Critère	Switch cloud managed sur le réseau client	Switch managé classique + proxy Nx
Exposition du switch depuis Internet	Nécessaire au fonctionnement	Aucune
Segmentation du parc vidéo	Impossible sur le segment caméras	Sous-réseau dédié conservé
Coupure de la ligne Internet	Administration perdue, réseau local maintenu	Accès distant perdu, enregistrement intact
Box hors service	Plus de cœur de réseau : transit vidéo et enregistrement interrompus	Segment vidéo autonome, enregistrement maintenu
Accès distant à l’administration	Portail du constructeur	Serveur Nx, avec les rôles en place
Dépendance à un service tiers	Compte, abonnement, fin de service	Aucune au-delà du VMS déployé
Choix du matériel	Gammes cloud du constructeur	Ouvert, tout switch managé

Health Monitoring : savoir avant de se connecter

Le proxy résout l’accès. Reste la question d’avant : sur quel équipement faut-il intervenir, et sur quel site ?

C’est le rôle d’un logiciel de Health Monitoring. Le nôtre, David Ker, est développé en interne : il donne une vue web consolidée de l’état des périphériques sur l’ensemble des sites exploités, équipements joignables ou non, ruptures, anomalies. Vous identifiez le site et la caméra concernés depuis une seule interface, puis vous basculez sur le système du client et le proxy pour agir : redémarrer le port PoE, vérifier la configuration, contrôler la remise en ligne.

Pour un intégrateur qui exploite un parc multi-clients, l’intérêt est direct : la détection ne dépend plus de l’appel du client, et l’intervention ne dépend plus d’un déplacement. C’est aussi ce qui permet de contractualiser une supervision sur des bases mesurables.

Quand le cloud garde du sens

Il serait malhonnête de le nier : sur un réseau purement informatique, sans caméra derrière, la question de la segmentation vidéo ne se pose pas. Sur de très petits sites, sans serveur ni enregistreur capable de faire proxy, l’administration par le portail peut être la seule option raisonnable. Et pour un parc de dizaines de sites identiques, la valeur du provisionnement de masse est réelle.

Le point de bascule est simple : dès qu’il y a un serveur sur le site, la fonction cloud n’apporte plus rien que le proxy ne fasse déjà, et elle coûte la segmentation. Dès que le site est critique, la question ne se pose pas.

Quatre questions à poser avant de valider un switch

1. Où sera-t-il raccordé : sous le serveur, ou sur le réseau du client ?
2. A-t-il besoin d’une sortie Internet pour rester administrable ?
3. Que se passe-t-il si la box tombe en panne pendant trois jours, et que devient l’enregistrement pendant ce temps ?
4. Qui détiendra, dans cinq ans, les comptes du portail sur lequel repose l’administration ?

Si l’une de ces réponses vous met mal à l’aise en phase d’étude, elle vous mettra en difficulté en phase d’exploitation. Sur les sites industriels et les plateformes logistiques, où la disponibilité et la traçabilité sont contractuelles, c’est un sujet que nous traitons systématiquement en amont.

Discutons de votre architecture

Nous concevons ce type de topologie tous les jours, avec des contraintes variables : sites multiples, informatique cliente présente ou absente, exigences documentaires NIS2, parcs existants à reprendre. Notre service technique peut valider le schéma réseau d’un projet en cours, la mise en place du proxy sur un serveur Nx Witness, ou l’intégration du Health Monitoring dans votre offre de maintenance.

Pour aller plus loin

• Nx Witness : sécurisation des données et cybersécurité
• Cybersécurité et vidéoprotection : pourquoi c’est un enjeu crucial
• Gestion multi-sites : superviser 3 à 200 points de vente
• NIS2 et sûreté vidéo : ce que la directive change pour vos installations