Category "Hôtellerie"

16Mar

Comment séparer les équipements du bâtiment du réseau informatique des bureaux ?

by Domocasa
Hôtellerie Réseaux et Wi-Fi Smart Building et GTB

Illustration générée par IA — visuel conceptuel.

Dans un hôtel (ou un site tertiaire), les systèmes « bâtiment » (GTB/BMS, KNX‑IP, GRMS, vidéosurveillance…) cohabitent de plus en plus avec le SI bureautique et l’accès Internet sur un socle IP convergé. Sans séparation claire, un incident côté IT (poste compromis, mouvement latéral, mauvaise configuration) peut impacter l’OT, et inversement un équipement OT trop exposé peut devenir un point d’entrée.

Une segmentation OT/IT utile vise un objectif très concret : définir des flux minimaux (principe allow‑list) entre zones, puis les traduire en règles firewall compréhensibles, traçables et recettables. Pour replacer la segmentation dans une architecture globale d’établissement, voir aussi l’architecture réseau IP d’un hôtel.

Pourquoi la segmentation OT/IT est devenue incontournable en hospitality

En hôtellerie, la convergence IP apporte de la valeur (supervision, services numériques, exploitation), mais elle crée aussi des dépendances :

  • Des équipements OT pilotent des fonctions physiques (CVC, éclairage, accès, alarmes techniques). Une exposition ou une propagation non maîtrisée n’a pas les mêmes conséquences qu’un incident sur un poste bureautique.
  • Les cycles de vie et les pratiques de mise à jour diffèrent entre IT et OT. Certains contrôleurs, passerelles ou caméras restent en place longtemps et ne suivent pas toujours les mêmes rythmes de patching.
  • Les interfaces inter‑systèmes se multiplient (PMS↔GRMS, GTB↔compteurs, CCTV↔postes opérateurs), et ce sont souvent ces « conduits » qui ouvrent trop large si l’architecture n’est pas cadrée.

Si vous cherchez d’abord une mise à plat « réseau » (segmentation, ports, trunks, SSID), notre guide VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ? pose les bases. Ici, on va un cran plus loin : quels flux autoriser, entre quels rôles, et comment le recetter.

Le principe qui marche : zones et conduits (penser flux avant ports)

Une méthode robuste consiste à raisonner en zones (groupes cohérents d’équipements) et en conduits (communications autorisées entre zones), dans l’esprit « zones & conduits » souvent associé aux approches OT (ex. ISA/IEC 62443). L’intérêt opérationnel est simple : on ne discute pas d’abord « numéros de VLAN », mais qui doit parler à qui, et pour quoi, puis on ouvre le strict nécessaire.

Dans un hôtel, on retrouve généralement les zones suivantes (à adapter au périmètre réel) :

  • Zone IT (bureautique) : postes, imprimantes, back‑office, Internet.
  • Zone OT “bâtiment” : GTB/BMS, passerelles d’intégration, contrôleurs CVC, interfaces KNX‑IP.
  • Zone OT “chambres / GRMS” : contrôleurs de chambre, serveur GRMS, passerelles associées.
  • Zone CCTV : caméras, NVR/VMS, postes opérateurs (si dédiés).
  • Zone Administration / supervision : postes d’admin, outils de maintenance, supervision réseau/OT.
  • Zone DMZ OT/IT (recommandée) : zone tampon pour les intégrations nécessaires (API, bastion, accès distant, relais), afin d’éviter les ouvertures directes IT↔OT.

Cette logique rejoint la notion clé rappelée dans notre dossier Cybersécurité d’un hôtel connecté : segmenter, puis contrôler les échanges.

Deux architectures de segmentation fréquentes (et efficaces) en hôtels et bâtiments tertiaires

Architecture A — Segmentation inter‑VLAN + firewall central (site unique)

Quand l’utiliser : établissement de taille moyenne, IT/OT sur un même site, intégrations limitées ou simples.

Principe : le firewall est le point de passage inter‑zones. L’OT est lui-même découpé en sous‑zones (GTB/KNX, GRMS, CCTV, admin). On garde une politique simple : deny par défaut entre zones, allow‑list sur les flux utiles.

  • IT ↔ Firewall ↔ OT‑GTB/KNX
  • IT ↔ Firewall ↔ OT‑GRMS
  • IT ↔ Firewall ↔ CCTV
  • Admin ↔ Firewall ↔ toutes zones (mais uniquement via règles explicites)

Architecture B — DMZ OT/IT (la plus confortable dès qu’il y a des intégrations et du support)

Quand l’utiliser : hôtel avec de multiples intégrations (PMS/GRMS/GTB, plateformes cloud, support distant), ou site tertiaire où IT et mainteneurs OT doivent coexister proprement.

Principe : on évite l’accumulation d’exceptions IT→OT en forçant les échanges « transverses » vers une DMZ. La DMZ héberge typiquement :

  • un bastion / jump server (poste d’administration contrôlé),
  • des connecteurs d’intégration (API/middleware, selon les solutions),
  • éventuellement un proxy de mises à jour (si le projet le justifie),
  • des services d’authentification/traçabilité, selon la gouvernance IT.

Cette approche simplifie la gouvernance des accès (comptes, journaux, révocation) et réduit le risque de « ports ouverts pour dépanner » qui restent actifs. Sur l’accès distant, voir aussi KNX IP, routage, interfaces et exposition Internet.

Matrice de flux minimaux (allow‑list) : exemples concrets par système

Important : une matrice de flux n’est pas une liste universelle de ports. Elle doit être adaptée aux fabricants (GTB, GRMS, VMS, passerelles), au mode d’exploitation et aux options activées. L’objectif est d’identifier les flux socles, puis de compléter avec les flux spécifiques documentés par les éditeurs retenus.

GTB/BMS : cadrer les échanges de supervision (ex. BACnet/IP)

BACnet/IP est très courant en GTB. Pour démarrer une matrice, un repère utile est le port 47808 (0xBAC0) associé au service bacnet dans le registre IANA.

Point cybersécurité (à ne pas simplifier) : le registre IANA associe ce port à bacnet en TCP et UDP, mais cela ne doit pas être interprété comme “ouvrir les deux”. Côté BACnet/IP, le point de départ opérationnel est généralement UDP 47808 (valeur par défaut fréquemment utilisée, et potentiellement configurable selon les équipements). La décision d’ouvrir autre chose doit donc être justifiée par la documentation fabricant et validée en recette, pas “au cas où”.

Source (zone) Destination (zone) Proto / port Sens Pourquoi on l’ouvre
Serveur supervision GTB (OT‑GTB ou OT‑Admin) Contrôleurs / équipements BACnet (OT‑GTB) BACnet/IP (généralement UDP 47808 — valeur par défaut à vérifier) → Superviser/échanger les points GTB, sans exposer OT‑GTB au SI bureautique.

À valider au projet : la découverte, les mécanismes multi‑sous‑réseaux (selon topologie) et les éventuels composants intermédiaires. L’idée reste la même : OT‑GTB ne parle pas “librement” au LAN IT, et la supervision doit être positionnée dans la zone prévue.

KNX‑IP : séparer la maintenance (ETS) du reste, et éviter l’exposition

Pour KNXnet/IP, un repère important pour les règles firewall est le port UDP 3671, associé à KNXnet/IP (valeur par défaut usuelle). Sur le plan cybersécurité, l’erreur classique est de rendre une interface KNX‑IP « joignable partout » (voire exposée via NAT/port‑forward). Pour la logique globale (réduction d’exposition, accès distant, comptes), voir KNX Secure : comment sécuriser une installation domotique professionnelle ?.

Exemple de flux minimal (à adapter à votre topologie KNX) :

Source (zone) Destination (zone) Proto / port Sens Bon réflexe
Bastion / poste ingénierie (OT‑Admin ou DMZ) Interface / routeur KNX‑IP (OT‑GTB/KNX) KNXnet/IP (UDP 3671 — valeur par défaut à vérifier) → Ouvrir uniquement depuis une zone d’admin contrôlée (pas depuis le LAN bureautique, pas depuis Wi‑Fi invités).

Si le projet active des mécanismes de sécurité KNX (Data Secure / IP Secure), cela renforce la protection des communications KNX, mais ne remplace pas la segmentation, la gouvernance d’accès et la recette des flux. La stratégie reste donc : qui a le droit de parler à KNX‑IP, et par quel chemin.

GRMS : privilégier un point d’intégration unique (et contrôlé) vers l’IT

Le GRMS se situe au carrefour OT/IT : d’un côté des contrôleurs de chambre et des automatismes, de l’autre des interfaces vers le PMS, des outils d’exploitation, parfois des services applicatifs. Plutôt que d’ouvrir « le réseau chambres » vers le SI, une approche robuste consiste à :

  • maintenir chambres & terrain dans une zone OT‑GRMS dédiée,
  • positionner le serveur GRMS / middleware comme seul point d’intégration vers l’IT (idéalement via DMZ),
  • n’autoriser que les flux applicatifs nécessaires (et documentés) entre PMS et GRMS.

Pour cadrer les responsabilités (qui échange quoi) côté hôtel, voir PMS, GRMS, GTB, serrures et contrôle d’accès : qui échange quoi dans un hôtel ?.

CCTV : isoler les caméras, contrôler l’ingestion, limiter la gestion

En vidéosurveillance, le découpage qui évite beaucoup de dérives est : caméras (edge) ↔ NVR/VMS (collecte/stockage) ↔ postes opérateurs (consultation). On évite de rendre les caméras « administrables » depuis le LAN bureautique.

Un repère utile côté streaming : dans la spécification ONVIF Streaming, RTSP utilise TCP et le port TCP par défaut est 554.

Point de cadrage essentiel (pour éviter le “copier‑coller” de règles incomplètes) : 554/TCP correspond au contrôle RTSP (session, SETUP, PLAY, etc.). Ensuite, selon le mode de transport retenu par la caméra et le VMS (RTP sur UDP vs RTP interleavé dans la session RTSP/TCP), le média peut nécessiter des ports supplémentaires (souvent UDP) négociés lors du SETUP (notamment via les paramètres de ports RTP/RTCP). Conclusion opérationnelle : documenter au projet le mode retenu (RTP/UDP vs interleavé TCP) et, si UDP est retenu, documenter/recetter la plage de ports média à autoriser — puis n’ouvrir ces flux que entre VMS↔caméras (allow‑list IP + journalisation).

Point de vigilance (à placer au moment où l’on parle ports) : 554/TCP est un défaut, pas une garantie universelle. Selon les marques, le durcissement appliqué (désactivation RTSP, RTSP sur un autre port, activation d’HTTPS, profils ONVIF, événements, audio, découverte, etc.) et l’architecture VMS, les flux nécessaires peuvent changer. On n’ouvre donc que ce qui est documenté par le constructeur/éditeur et recetté.

Source (zone) Destination (zone) Proto / port Sens Pourquoi on l’ouvre
NVR/VMS (zone CCTV) Caméras (zone CCTV‑EDGE) RTSP (TCP 554, par défaut — à vérifier) → Permettre l’ingestion vidéo vers l’enregistreur sans exposer les caméras à d’autres zones.

Pour replacer la segmentation dans une conception vidéo complète (réseau, stockage, exploitation), voir Vidéosurveillance IP : comment concevoir un système réellement efficace ?.

Exemple de politique firewall « lisible » (à adapter, mais structurante)

Un bon objectif projet est de produire une politique qui reste compréhensible dans un DOE, et maintenable lors d’une évolution (ajout de caméras, extension GTB, nouveau prestataire). Un exemple de structure :

  • Règle 0 : deny par défaut entre zones (inter‑VLAN / inter‑VRF / inter‑segments).
  • Règles OT :
    • Autoriser uniquement les flux de supervision/maintenance nécessaires (ex. supervision GTB→BACnet, bastion→KNX‑IP), et documenter chaque ouverture.
    • Empêcher tout accès « large » depuis le LAN IT vers les contrôleurs OT.
  • Règles CCTV :
    • NVR/VMS → caméras : ouvrir l’ingestion/streaming requis (ex. RTSP 554 par défaut), puis compléter au projet selon le mode RTP (UDP vs interleavé TCP) recetté ;
    • Postes opérateurs → VMS : préférer une consultation via la plateforme VMS (et non en direct sur les caméras) ;
    • Administration caméras : limiter à une zone OT‑Admin dédiée.
  • DMZ (si présente) : toutes les intégrations transverses passent par la DMZ (connecteurs, bastion, accès distant), avec journalisation.
  • Accès distant : privilégier VPN + bastion, éviter les redirections de ports « de confort ». Le sujet est détaillé dans notre guide KNX IP et exposition Internet.

Ce qui accélère vraiment les projets : livrables, recette et responsabilités

Livrable n°1 : matrice de flux (par zones, pas par VLAN)

La matrice doit préciser, pour chaque flux : source/destination, protocole, port (si applicable), sens, justification, et test de recette associé. C’est le document qui évite les « ouvertures au fil de l’eau » en fin de chantier.

Livrable n°2 : plan d’adressage et nomenclature maintenable

Sans nomenclature (VLAN/SSID/DHCP/réservations), une segmentation devient difficile à exploiter et à dépanner. Pour structurer ce livrable côté bâtiment, voir Plan d’adressage IP & nomenclature : méthode orientée exploitation.

Livrable n°3 : recette des flux (autoriser ce qu’il faut, bloquer le reste)

Une règle firewall n’a de valeur que si elle est testée :

  • Tests “positifs” : chaque flux autorisé doit fonctionner dans les conditions prévues (supervision GTB, ingestion CCTV, maintenance KNX/GRMS).
  • Tests “négatifs” : vérifier explicitement que les flux interdits restent bloqués (ex. poste IT → caméras, Wi‑Fi invités → interfaces d’admin OT, etc.).
  • Modes dégradés : ce qui doit continuer localement si une interface IT tombe (principe clé en bâtiment). Sur ce point, notre dossier Cybersécurité d’un hôtel connecté rappelle l’importance de limiter les dépendances inutiles.

Points de vigilance (à ne pas “deviner”)

  • GRMS et intégrations PMS : ports et protocoles dépendent fortement des éditeurs. La matrice doit être construite à partir des documentations des solutions retenues (et recettée).
  • ONVIF / gestion caméra : au‑delà du streaming RTSP, les fonctions d’événements, découverte, administration web et analytics varient selon marques et configurations.
  • GTB multi‑sous‑réseaux : certaines architectures BACnet/GTB peuvent exiger des composants ou flux additionnels (à cadrer dans le design, pas en urgence en fin de chantier).

Conclusion : la bonne segmentation OT/IT, c’est une matrice de flux minimaliste

En hospitality, une segmentation OT/IT efficace n’est pas un empilement de VLAN : c’est une architecture de zones, une matrice de flux minimaux (allow‑list) et des règles firewall qui restent exploitables. Les repères de ports et de flux « socles » (BACnet, KNXnet/IP, RTSP) permettent de démarrer vite, mais le vrai gain projet vient de la méthode : responsabilités claires, DMZ quand nécessaire, et recette systématique des conduits.

Si vous préparez un projet hôtelier (neuf ou rénovation), Domocasa intervient en interface IT/technique pour cadrer l’architecture, la matrice de flux et la recette. Vous pouvez commencer par relire notre guide sur l’architecture réseau IP d’un hôtel puis structurer un cahier de flux par lots (GRMS, CCTV, GTB) avant consultation.

Références (sources externes)

12Mar

Caméras, accès et Wi-Fi invités : les points de protection des données à vérifier au Maroc

by Domocasa
Hôtellerie Sûreté et Sécurité

Illustration générée par IA — visuel conceptuel.

Pourquoi ce “hub” CNDP ? (et ce qu’il n’est pas)

Dans les projets de sûreté et d’infrastructure (hôtels, commerces, sièges, immeubles, résidences), les lots vidéosurveillance, contrôle d’accès, LPR/ANPR et Wi‑Fi invités finissent souvent par manipuler des données à caractère personnel. Au Maroc, cela renvoie à la loi n° 09‑08 et aux publications/positions de la CNDP (Commission Nationale de Contrôle de la Protection des Données à Caractère Personnel).

Objectif de cet article : proposer des repères opérationnels (côté maîtrise d’ouvrage, architecte, BET, exploitant, intégrateur) pour structurer un projet et éviter les erreurs classiques (finalité floue, zones filmées trop larges, droits d’accès mal cadrés, conservation non maîtrisée, sous‑traitance non encadrée, etc.).

Ce que cet article n’est pas

  • Ce n’est pas un avis juridique ni une consultation CNDP.
  • Ce n’est pas une promesse de conformité : la conformité se décide au cas par cas selon la finalité, le périmètre, les lieux, l’exploitation, l’hébergement, les sous‑traitants, etc.
  • Ce n’est pas un guide exhaustif de toutes les délibérations CNDP.

Le point de départ (loi 09‑08) : image, son, plaque, identifiants réseau…

La loi 09‑08 définit la donnée à caractère personnel comme toute information concernant une personne identifiée ou identifiable, y compris le son et l’image. Cela signifie que, dès qu’un dispositif permet d’identifier directement ou indirectement une personne (visage, voix, silhouette, journal d’accès nominatif, etc.), le projet doit être cadré comme un traitement au sens de la loi. (bdj.mmsp.gov.ma)

La CNDP rappelle aussi, dans sa FAQ, que des éléments très courants en courant faible peuvent être des données personnelles : plaque d’immatriculation, photo, empreinte digitale, adresse IP, etc. (cndp.ma)

Conséquence projet (pratique)

  • Un projet LPR/ANPR est rarement « uniquement technique » : il traite des plaques (et souvent des images + horodatage + événement).
  • Un portail captif Wi‑Fi peut traiter des identifiants (IP, appareil, email/téléphone, numéro de chambre/voucher, logs) : il faut cadrer précisément quelles données et pourquoi.
  • Un contrôle d’accès génère des identifiants et des journaux (badges, événements d’ouverture, profils), et la biométrie introduit un niveau d’exigence plus élevé.

Les invariants à valider traitement par traitement (checklist “MOA / BET / exploitant”)

Quel que soit le lot (CCTV, accès, LPR, Wi‑Fi), les mêmes questions reviennent. L’intérêt d’un “hub” est de les poser avant de choisir les caméras, le VMS, le contrôleur d’accès ou la plateforme Wi‑Fi.

Finalité : pourquoi collecte‑t‑on ces données ?

Documentez une finalité explicite par traitement (ex. sécurité des biens et des personnes, gestion d’accès, gestion des visiteurs, protection de zones sensibles). Pour la vidéosurveillance en lieux de travail et lieux privés communs, la CNDP a publié la délibération n°350‑2013 (cadre de référence). (cndp.ma)

Bon réflexe : si la finalité est floue, le périmètre technique dérive (caméras “au cas où”, conservation “par défaut”, extraction “pour tout le monde”, etc.).

Information des personnes : rendre le dispositif lisible

La loi 09‑08 impose une information préalable lors de la collecte directe, incluant notamment l’identité du responsable, la finalité, et les références de récépissé/d’autorisation CNDP (selon le régime applicable). (bdj.mmsp.gov.ma)

En vidéosurveillance (lieux de travail / lieux privés communs), la délibération CNDP n°350‑2013 prévoit une information « au moyen d’une affiche ou d’un pictogramme » et liste les mentions attendues (dont le numéro du récépissé de déclaration). (cndp.ma)

Pour un point de départ “prêt à utiliser”, la CNDP met également à disposition des mentions types (modèles de formulation à adapter au site et au régime applicable).

Minimisation : filmer/collecter ce qui est nécessaire, pas ce qui est facile

  • Caméras : cadrer chaque caméra “par objectif” (accès, circulation, caisse, zone technique…), et matérialiser les zones exclues (intimité, zones sans rapport avec la finalité).
  • Contrôle d’accès : limiter les données du registre visiteurs et les champs obligatoires au strict besoin (à définir avec l’exploitant et le cadre applicable).
  • LPR : décider ce qui est réellement requis (texte plaque, image du véhicule, horodatage, voie, etc.) et qui peut rechercher/exporter.
  • Wi‑Fi invités : ne pas collecter “par défaut” (ex. identité complète) si un accès par voucher suffit au besoin opérationnel.

Conservation : durée justifiée + purge maîtrisée

Dans la logique de la loi 09‑08, la durée de conservation (et les règles associées) fait partie des éléments à cadrer et à déclarer selon le régime applicable au traitement. (bdj.mmsp.gov.ma)

Pour la vidéosurveillance dans le champ « lieux de travail / lieux privés communs », la délibération CNDP n°350‑2013 donne un repère explicite : la conservation des images ne doit pas dépasser trois mois (dans ce cadre). (cndp.ma)

Selon les contextes, la CNDP publie aussi des fiches pratiques (par exemple pour l’habitation privée) qui apportent des rappels et des conditions d’orientation des caméras. Ces documents sont à lire comme des repères de contexte, à confirmer projet par projet. (cndp.ma)

Sécurité : accès, comptes, traçabilité, cloisonnement

La loi 09‑08 prévoit que le responsable du traitement met en œuvre des mesures techniques et organisationnelles appropriées pour protéger les données (notamment contre l’accès non autorisé), et que ces mesures doivent assurer un niveau de sécurité approprié au regard des risques (voir art. 23). (bdj.mmsp.gov.ma)

Traduction projet (pratique) :

  • Comptes nominatifs (éviter les comptes partagés) et droits minimaux.
  • Journalisation des actions sensibles (visionnage, export, suppression, modifications de droits) lorsque la solution le permet.
  • Architecture réseau : prévoir une séparation claire entre usages (invités / métiers / vidéo / systèmes techniques / administration) et un contrôle strict des accès distants (procédures, comptes, révocation).

Sous‑traitance et support : cadrer l’accès des prestataires

Au sens de la loi 09‑08, un sous‑traitant est un organisme qui traite des données pour le compte du responsable du traitement (définition, art. 1). La loi précise aussi que la réalisation de traitements en sous‑traitance doit être régie par un contrat ou un acte juridique et que le sous‑traitant agit sur instruction du responsable (voir art. 23, notamment). (bdj.mmsp.gov.ma)

En pratique, ce point devient critique dès qu’il y a :

  • maintenance à distance (VMS, contrôleur d’accès, contrôleur Wi‑Fi) ;
  • hébergement cloud (logs Wi‑Fi, VMS cloud, sauvegardes) ;
  • infogérance réseau / sécurité.

Quatre cas d’usage : ce qu’il faut vérifier “avant devis”

Vidéosurveillance (CCTV) : cadrage minimal avant implantation

La CNDP publie un ensemble de ressources sur la vidéosurveillance, dont une page dédiée mentionnant notamment la délibération de référence pour les lieux de travail et lieux privés communs. (cndp.ma)

La CNDP a également publié un communiqué daté du 21 mars 2025 sur la vidéosurveillance et la protection des données, soulignant le besoin de cadrage et l’évolution des technologies (dont reconnaissance faciale). (cndp.ma)

Checklist CCTV (à adapter au site)

  • Cartographie caméra par caméra : objectif, champ utile, zones exclues.
  • Accès aux images : qui visionne, qui exporte, qui administre, et comment on trace.
  • Conservation et purge : durée, déclencheurs (continu/événementiel), procédure d’extraction (incident/réquisition).
  • Affichage et contact “droits” : où, quelle mention, quel canal de contact.
  • Accès distant : méthode, responsables, et révocation.

Pour l’ingénierie (optique, réseau, stockage, recette), voir : Vidéosurveillance IP : comment concevoir un système réellement efficace ?

Contrôle d’accès : badge/smartphone/QR… et le cas particulier de la biométrie

Sur un projet, “contrôle d’accès” recouvre souvent :

  • droits d’accès (profils, zones, horaires),
  • journaux d’événements (entrées/sorties),
  • gestion des visiteurs (registre ou application),
  • et parfois biométrie.

Contrôle d’accès visiteurs : attention aux registres et dispositifs de collecte

La CNDP a publié une délibération dédiée au contrôle d’accès à des lieux professionnels privés (registre/fichier de visiteurs). Elle porte sur un modèle type de demande d’autorisation relatif au traitement de données recueillies dans ce cadre, et précise le champ d’application du dispositif (registre/fichier de visiteurs, quelle qu’en soit la forme). (cndp.ma)

Biométrie : un niveau d’exigence plus élevé

En contrôle d’accès, la biométrie n’est pas un « simple identifiant ». La CNDP encadre son usage via la délibération n°478‑2013, notamment avec une approche basée sur la proportionnalité (le caractère sensible du site et la justification du recours à la biométrie font partie des éléments déterminants). (cndp.ma)

Dans ce cadre, la délibération précise notamment, « en règle générale », que les données doivent être enregistrées sur un support exclusivement détenu par la personne concernée (par exemple carte à puce), et que le dispositif doit être utilisé à des fins d’authentification et non d’identification. (cndp.ma)

Enfin, avant de retenir une solution biométrique, vérifiez le régime CNDP applicable à votre montage et votre finalité : la CNDP publie une page « Procédures de notification » qui présente un régime d’autorisation préalable (formulaire F‑112) en lien avec la biométrie pour contrôle d’accès. (cndp.ma)

Pour la méthode de choix (usages, modes dégradés, architecture de porte), voir : Contrôle d’accès : badge, smartphone, biométrie ou code ?

LPR/ANPR (lecture de plaques) : traiter la chaîne comme un “traitement”, pas comme une caméra de plus

La CNDP cite la plaque d’immatriculation comme exemple de donnée personnelle dans sa FAQ. (cndp.ma)

Sans prétendre à une règle “unique” applicable à tous les montages, cela suffit à justifier une démarche structurée : finalité, accès, conservation, information, sous‑traitance, sécurité… doivent être documentés dans le projet.

Checklist LPR/ANPR (avant achat)

  • Décision d’accès : séparer lecture (OCR) et autorisation (règles métier, exceptions).
  • Minimisation : décider ce qui est enregistré et recherché (et par qui).
  • Recette sur site : prouver la performance sur la voie réelle (jour/nuit, véhicules réels, vitesse, éclairage).
  • Journalisation : qui recherche une plaque, qui exporte, et pourquoi.

Pour l’ingénierie technique et la recette, voir : Lecture de plaques LPR/ANPR : comment automatiser les accès véhicules ?

Wi‑Fi invités (hôtel) : l’infrastructure réseau “voit” aussi des données personnelles

La CNDP cite l’adresse IP comme exemple de donnée personnelle. (cndp.ma)

Dans un hôtel, un Wi‑Fi invités est à la fois :

  • un service client (expérience de connexion),
  • un risque technique (ne pas exposer PMS/GRMS/serrures/caméras),
  • et, selon l’architecture (portail, logs, self‑registration), un traitement à cadrer (finalité, minimisation, conservation, sous‑traitants, sécurité).

Checklist Wi‑Fi invités (cadrage)

  • Quels champs collecte le portail ? (et lesquels sont réellement nécessaires)
  • Information : qui est le responsable, quelles finalités, quel contact “droits” (à formaliser dans le parcours).
  • Isolation : séparation réseau invités / métiers / techniques + politique d’isolation inter‑clients selon le service attendu.
  • Sous‑traitance : qui héberge/supporte le portail et comment l’accès est contrôlé.

Pour aller plus loin côté architecture & exploitation : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client et, en vision globale, Architecture réseau IP d’un hôtel.

Maillage : vos guides Domocasa à lire selon le lot

Sources officielles (sélection)

  • Loi n° 09‑08 (BDJ – Banque de Données Juridiques) : bdj.mmsp.gov.ma
  • CNDP – FAQ : cndp.ma/faq
  • CNDP – Page “Caméras de surveillance / vidéosurveillance” : cndp.ma/videosurveillance
  • CNDP – Communiqué « Vidéosurveillance et protection des données à caractère personnel » (21/03/2025) : PDF CNDP
  • CNDP – Délibération n°350‑2013 (lieux de travail / lieux privés communs) : PDF CNDP
  • CNDP – Mentions types : cndp.ma/mentions-types
  • CNDP – Fiche vidéosurveillance (habitation privée) : PDF CNDP
  • CNDP – Délibération D‑943‑2025 (contrôle d’accès / visiteurs) : PDF CNDP
  • CNDP – Délibération n°478‑2013 (biométrie contrôle d’accès) : PDF CNDP
  • CNDP – Procédures de notification (dont autorisation préalable F‑112) : cndp.ma/procedures-de-notification-process

Si vous préparez un projet (hôtel, retail, immeuble), une étape souvent décisive consiste à formaliser une fiche de traitement par lot (finalité, données, accès, conservation, sous‑traitants) avant de figer l’architecture technique et le cahier des charges.

9Mar

Wi-Fi invités : quelle sécurité choisir pour garder une connexion simple ?

by Domocasa
Hôtellerie Réseaux et Wi-Fi

Illustration générée par IA — visuel conceptuel.

Dans un hôtel comme en entreprise, le Wi‑Fi est jugé sur deux critères qui s’opposent parfois : la simplicité d’accès (zéro friction, peu d’appels au support) et une sécurité crédible (au minimum limiter l’écoute radio « d’à côté », et éviter qu’un invité voie les systèmes métiers). Le troisième critère, souvent oublié, est le plus coûteux en exploitation : la résilience (que se passe-t-il quand le portail captif ou le RADIUS tombe ?).

Ce guide compare les principaux modèles de sécurité et d’authentification Wi‑Fi — portail captif, WPA2/WPA3‑Personal, WPA3‑Enterprise / 802.1X, OWE (Enhanced Open) — et propose une méthode pour choisir sans casser l’expérience client tout en préparant un mode dégradé réaliste.

Pour compléter ce dossier avec une approche “terrain” (segmentation, isolation, exploitation), vous pouvez aussi lire : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client et VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?

Clarifier l’objectif : “sécuriser le Wi‑Fi” ne veut pas dire une seule chose

Avant de comparer les options, il faut séparer trois couches qui se confondent souvent dans les discussions :

  • Sécurité radio Wi‑Fi (couche L2) : chiffrement/authentification entre le terminal et le point d’accès, sur le médium radio.
  • Contrôle d’accès (couche IP/WEB) : qui a le droit d’aller sur Internet, pendant combien de temps, via quel parcours (portail captif, vouchers, etc.).
  • Architecture réseau : segmentation (VLAN/SSID), règles firewall, isolation inter-clients, protection des réseaux métiers et techniques.

Un portail captif peut très bien exister sur un réseau Wi‑Fi non chiffré. À l’inverse, un Wi‑Fi chiffré (WPA3 ou OWE) n’implique pas automatiquement un portail captif. Dans un projet sérieux, ces couches se combinent selon le niveau de service attendu.

Les options en clair : ce que chaque modèle protège (et ce qu’il ne protège pas)

Réseau “Open” (sans chiffrement)

Le terminal s’associe au SSID et le trafic radio n’est pas chiffré au niveau Wi‑Fi. C’est simple, mais l’écoute radio opportuniste est facilitée (même si la plupart des usages sont aujourd’hui en HTTPS, cela ne règle pas tous les risques et cela ne donne aucune garantie d’isolation entre clients).

Portail captif (web authentication)

Le portail captif gère l’accès après association au Wi‑Fi : acceptation de CGU, code d’accès, voucher, authentification par email/téléphone selon les choix de l’établissement, etc. Il ne remplace pas à lui seul le chiffrement radio.

Point important : le parcours “portail” dépend de plusieurs services invisibles (DNS, DHCP, redirections HTTP/HTTPS, certificats). En hôtellerie, un incident de portail se traduit très vite par une perception “le Wi‑Fi est en panne”, même si la radio et les AP fonctionnent.

OWE / “Enhanced Open” (Wi‑Fi ouvert mais chiffré)

OWE (Opportunistic Wireless Encryption) vise à apporter un chiffrement automatique sur un réseau sans mot de passe. C’est particulièrement pertinent pour un SSID invités : expérience proche d’un réseau ouvert, mais confidentialité radio améliorée.

Limite à connaître : OWE n’apporte pas d’authentification forte (pas “d’identité” vérifiée du réseau au sens 802.1X). Il faut donc le voir comme une amélioration de confidentialité sur l’air, pas comme un mécanisme d’identité ou de conformité “entreprise”.

WPA2 / WPA3‑Personal (PSK / SAE)

Le Wi‑Fi est chiffré et l’accès se fait via un secret partagé (mot de passe). En WPA3‑Personal, l’échange de clé s’appuie sur SAE (au lieu d’un PSK “classique”), ce qui améliore la robustesse contre certains scénarios d’attaque, mais ne résout pas un problème structurel côté exploitation : un mot de passe partagé se partage (clients qui le transmettent, ancien client qui revient, sous-traitant, etc.).

Dans un hôtel, WPA‑Personal peut rester utile dans des zones “semi‑privées” ou pour certains équipements (selon compatibilités), mais ce n’est généralement pas le meilleur compromis pour un SSID invités “grand public”.

WPA3‑Enterprise / 802.1X (EAP + RADIUS)

Ici, l’enjeu principal n’est pas seulement le chiffrement : c’est l’identité. Le terminal s’authentifie via 802.1X/EAP, et l’infrastructure s’appuie sur un backend AAA (souvent RADIUS). C’est la base d’un Wi‑Fi “entreprise” : politiques par rôle, segmentation dynamique selon le profil, meilleure traçabilité, etc.

En contrepartie, ce choix introduit des dépendances d’exploitation : disponibilité RADIUS, certificats/PKI selon la méthode EAP retenue, synchronisation horaire, supervision, procédure de bascule. Ce n’est pas un défaut : c’est une discipline d’architecture à assumer, documenter et recetter.

Tableau de décision : choisir sans marketing

Le tableau ci-dessous aide à décider rapidement. Il n’existe pas de “meilleure” option universelle : le bon choix dépend de votre parc de terminaux, de votre niveau d’exigence et de votre capacité d’exploitation.

Option Confidentialité radio Identité / politiques Expérience utilisateur Dépendances critiques Quand c’est pertinent
Open + portail captif Faible (pas de chiffrement Wi‑Fi) Faible (contrôle “web” uniquement) Variable (pop-up/redirect parfois capricieux) DNS/DHCP/portail/certificats À éviter quand OWE est possible ; parfois conservé en transition/legacy
OWE / Enhanced Open (+/‑ portail) Bonne (chiffrement “sur l’air” sans mot de passe) Pas d’identité forte Très bonne (pas de mot de passe) Compatibilité terminaux à valider SSID invités d’hôtel, cafés, espaces publics (objectif : confidentialité sans friction)
WPA2/WPA3‑Personal Bonne (si mot de passe maîtrisé) Secret partagé (pas de vraie identité par utilisateur) Bonne si mot de passe simple ; moins bon si rotation fréquente Gestion du secret (diffusion, rotation, fuite) Petits sites, zones semi‑privées, certains SSID techniques cloisonnés
WPA3‑Enterprise / 802.1X Très bonne Forte (politiques par rôle/identité) Variable (profil, MDM, onboarding) RADIUS/AAA, méthodes EAP, certificats, supervision Wi‑Fi staff/back‑office, entreprise, environnements BYOD maîtrisés
Combinaisons (souvent la réalité) Dépend du mix Dépend du mix Optimisable Plusieurs couches à coordonner Hôtels : invités ≠ staff ≠ IoT ≠ admin (un seul SSID “pour tout” est rarement sain)

Scénarios recommandés (hôtel & entreprise)

Hôtel : SSID invités (priorité = simplicité + confidentialité minimale)

  • Recommandation typique : SSID invités en OWE (Enhanced Open).
  • Si CGU / voucher / parcours marketing : ajouter un portail captif (sans renoncer au chiffrement radio).
  • Si forte contrainte “legacy” : prévoir une stratégie de transition (à cadrer selon le matériel Wi‑Fi) et accepter qu’une partie des terminaux anciens ne profitent pas du chiffrement OWE.

À ne pas oublier : dans un hôtel, la sécurité “utile” ne s’arrête pas au chiffrement radio. L’isolation entre clients et la séparation stricte d’avec les réseaux métiers sont structurantes. Sur ce point, voir aussi Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?

Hôtel : SSID staff / back‑office (priorité = identité & contrôle)

  • Recommandation typique : WPA3‑Enterprise (802.1X), avec politiques par rôle.
  • Prévoir redondance RADIUS et tests de bascule.
  • Documenter l’onboarding (terminaux d’exploitation, téléphonie Wi‑Fi si utilisée, postes fixes, etc.).

Entreprise : SSID corporate + SSID invités

  • Corporate : 802.1X (WPA3‑Enterprise) dès que l’entreprise veut une identité par utilisateur/terminal et des politiques réseau cohérentes.
  • Invités : OWE + portail captif (ou portail seul si compatibilité OWE insuffisante), avec isolation stricte et règles firewall minimales.

Pour une approche globale “Wi‑Fi pro” côté conception (couverture/capacité/LAN), voir : Réseau Wi‑Fi professionnel : comment bien le concevoir en entreprise ?

Le vrai sujet : concevoir le mode dégradé (si portail ou RADIUS tombe)

En production, l’incident “qui fait mal” n’est pas le plus spectaculaire : c’est celui qui multiplie les plaintes et mobilise la réception ou le support. Deux pannes reviennent en boucle : portail captif indisponible et RADIUS indisponible. La bonne approche n’est pas d’espérer “zéro panne”, mais de choisir le comportement attendu, puis de le recetter.

Portail captif indisponible : trois comportements possibles (à décider)

  • Fail‑open (continuité) : si le portail est down, on laisse sortir vers Internet (avec isolation et filtrage maintenus). Avantage : continuité de service ; inconvénient : perte temporaire du contrôle “portail”.
  • Fail‑closed (contrôle) : si le portail est down, on bloque. Avantage : politique stricte ; inconvénient : perception client “Wi‑Fi en panne”.
  • Portail minimal de secours : page locale de repli (selon solutions) pour réduire l’impact, tout en gardant une validation minimale.

Le choix dépend du positionnement de l’établissement (loisir vs business), de l’impact sur l’exploitation, et du cadre interne de gouvernance. L’important est de le formaliser : la “bonne” décision est celle que votre équipe sait expliquer et opérer.

RADIUS indisponible (802.1X) : distinguer “nouveaux” et “déjà connectés”

Sur un SSID 802.1X, la question à trancher est souvent la suivante :

  • Que fait-on pour un terminal déjà authentifié si le RADIUS devient indisponible ?
  • Autorise-t-on de nouveaux terminaux (et si oui, selon quel mécanisme) ?

Selon les contrôleurs/passarelles, il existe des mécanismes de bascule (serveur primaire/secondaire) et, parfois, des mécanismes de cache/survivabilité. Ce n’est pas “automatique” : il faut le configurer, décider des délais, et vérifier le comportement réel en panne (et lors du retour à la normale).

Recommandation projet : éviter de découvrir le comportement 802.1X “en live” le jour d’un incident. Une recette simple (panne RADIUS simulée) permet de valider le scénario retenu et de construire un runbook exploitable.

Recette (tests) : ce qu’il faut valider avant ouverture ou réception

L’objectif d’une recette n’est pas de cocher “WPA3” sur une configuration : c’est de valider un parcours utilisateur et un comportement en panne. Voici une checklist orientée exploitation.

Tests “parcours client” (SSID invités)

  • Connexion initiale sur différents terminaux (smartphones récents, laptops, et quelques terminaux “à problème” typiques : consoles, TV, objets connectés selon le site).
  • Affichage et stabilité du portail captif (si présent) : redirection, certificat, langues, comportement en HTTPS.
  • Reconnexion : que se passe-t-il après veille du terminal, sortie/entrée de chambre, changement d’AP (roaming) ?
  • Isolement inter-clients : vérifier qu’un client ne voit pas les autres terminaux invités (et documenter les exceptions nécessaires, par exemple casting si vous l’autorisez).

Tests “RADIUS down” (SSID staff / corporate)

  • Arrêt du serveur RADIUS primaire : validation de la bascule vers le secondaire.
  • Comportement des clients déjà connectés pendant la panne (stabilité, durée, renouvellement éventuel).
  • Comportement des nouveaux clients pendant la panne (bloqués ? autorisés via mécanisme de survivabilité ?).
  • Retour à la normale : resynchronisation, stabilité, absence d’effet “yoyo”.

Tests “portail down”

  • Simuler une indisponibilité réaliste (service web arrêté, résolution DNS en défaut, certificat expiré si le scénario existe).
  • Vérifier le comportement choisi (fail‑open / fail‑closed / repli).
  • Vérifier le message utilisateur et la procédure réception/support.

Tests “infrastructure invisible” (DNS/DHCP)

  • Un terminal obtient-il une IP dans le bon VLAN ?
  • Le DNS répond-il correctement (un incident DNS peut “ressembler” à une panne Internet) ?
  • Les règles firewall sont-elles cohérentes avec le portail (si présent) et les services autorisés ?

Pour une démarche plus large “hôtel” (modes dégradés, dépendances, exploitation), la lecture de l’architecture globale est souvent déterminante : Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?

Points d’architecture à ne pas rater (sinon WPA3 ne changera rien)

Segmenter : invités ≠ staff ≠ systèmes techniques ≠ administration

Un SSID “Guest” ne doit pas voir le PMS, la GTB/GRMS, les caméras, la téléphonie ou les interfaces d’administration. La segmentation (VLAN) doit être accompagnée de règles de filtrage explicites : “séparer” sans contrôler les flux laisse une partie du risque intacte.

À lire : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?

Ne pas baser toute la sécurité sur un seul mécanisme

  • OWE améliore la confidentialité radio, mais ne remplace pas une segmentation et un filtrage cohérents.
  • Un portail captif structure l’accès, mais ne chiffre pas “magiquement” l’air.
  • 802.1X apporte l’identité, mais impose une ingénierie de résilience (RADIUS, certificats, supervision).

Superviser ce qui casse vraiment l’expérience

Sur un réseau hôtelier, la supervision ne doit pas se limiter à “les AP sont up”. Les incidents visibles côté client sont souvent liés à des services d’infrastructure (DNS/DHCP/AAA) ou à des dépendances applicatives (portail, certificats). C’est un sujet de runbook et de responsabilités, pas uniquement de matériel.

Conclusion : un modèle simple, robuste et crédible (hôtel & entreprise)

Dans la majorité des projets, l’architecture la plus rationnelle ressemble à ceci :

  • Invités : OWE (Enhanced Open) + portail captif si nécessaire (CGU/vouchers), avec isolation inter-clients et segmentation stricte.
  • Staff / corporate : WPA3‑Enterprise / 802.1X, RADIUS redondé, bascule et mode dégradé testés.
  • Exploitation : une recette qui inclut les pannes (RADIUS/portail/DNS/DHCP), et une documentation exploitable par les équipes.

Si vous souhaitez valider ce design sur votre site (hôtel, siège, clinique, resort), Domocasa peut intervenir en audit Wi‑Fi ou en redesign : l’objectif n’est pas d’ajouter des options, mais de rendre le service plus stable, plus lisible et plus maintenable.

5Mar

Wi-Fi d’hôtel en panne : vérifier les services d’adressage, de noms et d’authentification

by Domocasa
Guides techniques Hôtellerie Réseaux et Wi-Fi

Illustration générée par IA — visuel conceptuel.

Dans un hôtel, on parle souvent Wi‑Fi, VLAN, switching et couverture radio. Pourtant, une grande partie des incidents visibles côté client ou réception (“Wi‑Fi connecté mais pas d’Internet”, portail captif qui ne s’affiche pas, authentification WPA‑Enterprise/802.1X impossible, services IP instables) viennent d’une couche plus discrète : DHCP, DNS et AAA (souvent via RADIUS).

Ce guide est orienté exploitation hôtelière (runbook + conception + modes dégradés). Il complète nos dossiers sur l’architecture réseau IP d’un hôtel, le Wi‑Fi invités et le portail captif, et la supervision réseau.

La chaîne de dépendances (vue exploitation)

Parcours typique d’un client Wi‑Fi invité (avec portail captif)

  1. Association Wi‑Fi (802.11) : le terminal rejoint le SSID.
  2. Configuration IP via DHCP : sans bail DHCP, pas de service IP exploitable (DHCPv4 : RFC 2131).
  3. Paramètres réseau fournis par DHCP (au minimum) :
    • Passerelle : option DHCP 3 (“Router”).
    • DNS : option DHCP 6 (“Domain Server”).

    Références pratiques : définition des options dans RFC 2132 et registre IANA (IANA — BOOTP/DHCP Parameters).

  4. DNS fonctionnel : indispensable pour la navigation, et souvent pour la détection de connectivité/captive portal côté OS.
  5. Détection captive portal : le terminal teste la connectivité et peut ouvrir automatiquement l’écran de login (comportement variable selon OS et versions).
  6. Portail captif / politique d’accès : redirection, CGU, voucher, paiement… selon la stratégie retenue.
  7. AAA / RADIUS (si utilisé) : contrôle d’accès et/ou attributs de politique (RADIUS : RFC 2865 ; points d’attention d’implémentation : RFC 5080).

Traduction “hôtel” : si vous dimensionnez très bien la radio Wi‑Fi mais que DHCP/DNS/AAA (ou leurs dépendances IP) sont fragiles, l’expérience client restera instable. Et en exploitation, la panne “ressemble” souvent à un problème Wi‑Fi alors qu’elle est en réalité un problème de service d’infrastructure.

Qui dépend de quoi (exemples fréquents)

  • Wi‑Fi invités : DHCP + DNS + portail (HTTP/HTTPS) + éventuellement RADIUS.
  • Wi‑Fi staff : DHCP + DNS + souvent 802.1X/RADIUS.
  • Services IP convergés (VoIP, IPTV, CCTV, GRMS, contrôle d’accès, supervision) : très souvent DHCP et DNS (même si une partie des équipements est en IP fixe, de nombreux services et intégrations utilisent des noms DNS, des APIs, des certificats, etc.).

Symptômes → hypothèses → tests rapides (triage opérationnel)

L’objectif n’est pas de “tout tester”, mais de séparer très tôt un problème radio (association / roaming), un problème IP (DHCP), un problème de résolution (DNS), un problème d’accès (pare-feu, walled-garden), et un problème d’authentification (AAA/RADIUS).

Symptôme A — « Wi‑Fi connecté mais pas d’Internet »

Posez quatre questions, dans cet ordre :

  1. Le terminal a-t-il une IP valide dans le bon VLAN ?
    • Non → piste DHCP (service arrêté, relais DHCP, VLAN mal taggé, pool épuisé, ACL…).
    • Oui → continuez.
  2. La passerelle par défaut est-elle cohérente ?
  3. Le DNS fonctionne-t-il réellement ?
    • Un incident DNS peut donner exactement l’impression “pas d’Internet” alors que l’IP/routage sont corrects.
    • Sous Windows, l’état de connectivité (NCSI) s’appuie notamment sur des probes DNS/HTTP ; Microsoft documente ces probes et des cas d’échecs liés au DNS, proxy, interception, etc. (voir Microsoft — NCSI FAQ).
  4. Le portail captif se déclenche-t-il (si applicable) ?
    • Si la redirection ou les probes OS sont bloquées, l’utilisateur ne verra pas forcément l’écran de login, ou verra un message “No Internet”.

Pour remettre ce diagnostic dans l’architecture globale, voir aussi Wi‑Fi invités : portail captif, isolation et expérience client.

Symptôme B — « Portail captif en panne / ne s’affiche pas »

Vérifiez d’abord l’infrastructure (dans cet ordre) :

  • DHCP : pas d’IP = pas de portail.
  • DNS : si l’OS ne résout pas ses destinations de test ou le FQDN du portail, le parcours se dégrade (ou ne démarre pas).
  • Filtrage pré-auth (walled garden) : ACL trop restrictive (DNS, HTTP/HTTPS…).
  • Certificats et dépendances TLS (à recetter) : si vous utilisez un portail/API en HTTPS, certains terminaux peuvent avoir besoin d’accéder à des services de validation de certificats (par ex. OCSP/CRL) et à une source de temps (NTP) pour valider correctement les certificats. L’IETF explicite ce point dans l’architecture et l’API de captive portal (voir RFC 8952 et RFC 8908).
  • Interception / proxy / inspection : peut perturber les probes OS ; Microsoft cite notamment proxy/VPN/DNS/firewall comme causes de comportements NCSI inattendus (voir Microsoft — NCSI FAQ).

Symptôme C — « Échec d’authentification Wi‑Fi (WPA‑Enterprise / 802.1X) »

  • RADIUS injoignable (IP/ACL/routage) ou secret partagé erroné.
  • Timeouts / retransmissions / latence : RFC 5080 décrit des problèmes d’implémentation courants et des correctifs suggérés.
  • Hypothèse à tester (dépendances DNS) : selon votre stack AAA/NAC (annuaire, PKI, NTP, politiques…), si certains composants résolvent des noms (AD, endpoints internes…), un DNS instable peut contribuer à des lenteurs ou à des timeouts perçus. À traiter par corrélation (logs AAA/RADIUS + logs DNS + latence réseau), pas comme une règle universelle.

DHCP en hôtel : conception résiliente et modes dégradés

Pourquoi DHCP “n’est pas juste des IP”

DHCP fournit la configuration réseau (RFC 2131). Dans un hôtel, cela inclut très souvent :

  • l’adresse IP,
  • la passerelle (option 3),
  • les DNS (option 6),
  • et selon les cas, d’autres options utiles à des équipements spécifiques (options : RFC 2132 ; registre : IANA — BOOTP/DHCP Parameters).

Un DHCP “qui répond” mais qui annonce une passerelle ou des DNS erronés peut produire les mêmes symptômes qu’une panne Wi‑Fi.

Deux exemples d’approches HA documentées (à choisir selon votre stack)

  • Windows Server DHCP failover : Microsoft documente un failover DHCPv4 entre deux serveurs, avec modes hot standby et load balance, et des règles/limites (voir Microsoft Learn — DHCP failover). Point d’exploitation important : la documentation Microsoft indique que si des changements sont faits sur un scope activé en failover, il faut répliquer manuellement ces changements vers le serveur partenaire afin de synchroniser les scopes.
  • ISC Kea : ISC documente une haute disponibilité via mécanisme “HA hooks”, explicitement différent d’un “DHCP Failover” historique (voir ISC Kea — High Availability Hooks Library).

Conseil exploitation : ne traitez pas la “HA DHCP” comme une case marketing. Exigez une recette de bascule (arrêt d’un serveur, perte de lien, reprise) et un runbook de rétablissement, au même titre que le failover Internet (voir Deux connexions Internet : comment assurer le failover).

Modes dégradés DHCP (approches projet)

  • Repli DHCP “de secours” sur un équipement réseau (pare-feu/routeur) pour un VLAN critique, si votre architecture et vos règles de sécurité l’autorisent. Recommandation de projet à valider au cas par cas : l’objectif est de rétablir un service minimal, pas de “refaire toute l’architecture” en incident.
  • Baux plus longs sur des réseaux stables (terminaux fixes, certains services) : cela peut retarder l’impact d’une indisponibilité DHCP pour des clients déjà configurés, car un client peut continuer à utiliser son adresse actuelle jusqu’à l’expiration du bail (et selon son état de renouvellement) comme décrit dans RFC 2131. En contrepartie, certaines évolutions (renumérotation, changements d’options, nettoyage d’adresses “fantômes”) peuvent prendre plus de temps à se propager. À cadrer.
  • Supervision de l’épuisement de pool : le serveur attribue une adresse depuis son pool d’adresses disponibles (voir RFC 2131) ; en exploitation, si aucune adresse n’est disponible, l’attribution de nouveaux baux échoue et les clients restent sans bail. Côté client, le symptôme typique reste l’absence de bail DHCP ; selon l’OS, un poste peut aussi s’auto-attribuer une adresse IPv4 link-local en 169.254/16 (parfois appelée APIPA sous Windows) — ce mécanisme est défini par RFC 3927 et documenté côté Windows (ex. Microsoft — Automatic Private IP Addressing). Pour des pistes de dépannage APIPA (causes possibles, checks), voir aussi Cisco — Troubleshoot APIPA Address Failure.

DNS en hôtel : un scénario classique du “connecté sans Internet”

DNS : rôle opérationnel

DNS (RFC 1034/1035) conditionne la navigation, mais aussi une partie des mécanismes de détection de connectivité/captive portal des OS. En exploitation, vous devez surveiller DNS comme un service, pas seulement comme un port ouvert.

Résilience côté résolveur : “serve-stale” (à cadrer)

RFC 8767 décrit un mécanisme permettant à un résolveur récursif de servir des réponses périmées (stale) quand les autorités ne sont pas joignables, afin d’amortir certains outages. C’est un arbitrage disponibilité vs fraîcheur à décider (et à documenter), pas une “optimisation automatique”.

Modes dégradés DNS (approches projet)

  • Deux résolveurs locaux (physiques/VM séparées) et DHCP option 6 pointant vers les deux (références options : RFC 2132 ; registre : IANA — BOOTP/DHCP Parameters).
  • Repli temporaire documenté (ex. bascule vers un resolver de secours) en tenant compte des impacts sur les zones internes, le split-horizon, les intégrations et la cybersécurité.
  • Supervision DNS orientée symptômes : taux de SERVFAIL, latence de résolution, incohérences selon VLAN (invités vs staff vs technique).

RADIUS / AAA : quand l’authentification tombe, tout “a l’air réseau”

Ce qui est établi par des sources primaires

  • RADIUS est spécifié par RFC 2865.
  • Des problèmes d’implémentation courants et des recommandations sont discutés dans RFC 5080.

Décision de conception : fail-open vs fail-closed

En cas d’indisponibilité AAA, votre accès doit-il être :

  • Fail-closed (sécurité) : pas d’accès sans authentification.
  • Fail-open (continuité) : accès minimal et très filtré (ex. Internet-only), avec procédure d’incident stricte.

Important : cette décision se prend par zone (staff, administration, technique, invités) et doit être alignée avec vos objectifs de cybersécurité (voir cybersécurité d’un hôtel connecté).

Portail captif : pourquoi ça casse “sans erreur claire”

Ce que documentent les OS (exemples utiles en exploitation)

  • Windows (NCSI) : Microsoft documente le principe des probes actives et des causes d’échec (DNS, proxy, interception, VPN, etc.), ainsi que le comportement attendu de certains tests HTTP/DNS (voir Microsoft — NCSI FAQ).
  • Android : Google décrit la détection par probes et, à partir d’Android 11, la prise en charge d’un mécanisme plus explicite basé sur une option DHCP fournissant une URL d’API captive portal (voir Android 11 — Captive portal support).
  • Standard IETF : RFC 8910 formalise l’annonce d’un captive portal via DHCPv4/DHCPv6 et Router Advertisements, et clarifie notamment le passage de l’option 160 vers 114 suite à conflit.

Conséquence projet : le walled-garden “pré-auth” doit être conçu comme une liste de dépendances (DNS, HTTP/HTTPS et services associés) et recetté avec plusieurs OS représentatifs, pas seulement avec un navigateur de test.

Modes dégradés “portail captif” (approches projet)

  • Bypass temporaire contrôlé (Internet-only, limitations adaptées, traçabilité si applicable) le temps de rétablir le portail.
  • SSID “incident” (PSK) géré par une procédure interne (communication à la réception + rotation post-incident). À traiter comme une procédure d’exploitation, pas comme un SSID permanent “de confort”.
  • Réduction de dépendances (si votre solution le permet) en s’alignant sur les mécanismes normalisés, tout en conservant un comportement compatible avec les terminaux plus anciens.

Checklist « dépendances & plans de repli » (à intégrer dans le DOE exploitation)

Cette checklist vise un objectif simple : rendre vos services réseau rétablissables par l’exploitation (ou par un mainteneur) sans “réinventer l’architecture” en incident.

DHCP

  • Architecture : qui délivre DHCP sur quel VLAN ? Où sont les relais DHCP ?
  • Disponibilité : redondance ou repli défini (selon criticité).
  • Capacité : pools dimensionnés + alerte d’épuisement.
  • Options minimales : passerelle (opt 3), DNS (opt 6) cohérents (options : RFC 2132 ; registre : IANA — BOOTP/DHCP Parameters).
  • Procédures : runbook de bascule, runbook de retour arrière, et responsabilités (qui peut agir, comment tracer le changement).

DNS

  • Deux résolveurs (ou service HA) + supervision latence/SERVFAIL.
  • Scénario WAN down documenté (cache, éventuel serve-stale selon résolveur et politique).
  • Tests par VLAN : invités vs staff vs technique (symptômes parfois différents).

AAA / RADIUS

  • Redondance : au minimum deux serveurs AAA ou un mécanisme documenté de continuité.
  • Décision explicite fail-open/fail-closed par SSID/VLAN (et justification).
  • Supervision : taux d’échecs, timeouts, latence NAS↔RADIUS.

Portail captif

  • Pré-auth/walled-garden : DNS + HTTP/HTTPS nécessaires, clairement listés et versionnés.
  • Si portail/API HTTPS : inclure dans la recette (et dans la liste de dépendances) les besoins éventuels de validation de certificats (OCSP/CRL) et de synchronisation de l’heure (NTP) selon les clients ; référence IETF la plus explicite : RFC 8908 (contexte architecture captive portal : RFC 8952).
  • Recette multi-terminaux : au moins Windows + Android + un échantillon représentatif du parc réel.
  • Mode dégradé : bypass contrôlé ou SSID incident (procédure + retour à la normale).

Pour structurer les livrables, voir aussi DOE réseau : schémas et sauvegardes à remettre et DOE & maintenance d’un hôtel connecté. Et, pour la phase projet, notre checklist de pré‑ouverture hôtel aide à recetter les dépendances avant l’arrivée des premiers clients.

Runbook d’incident (structure simple, à adapter à votre hôtel)

  1. Choisir trois postes de test : un filaire (si possible), un Wi‑Fi invités, un Wi‑Fi staff.
  2. Vérifier IP / passerelle / DNS (avant de toucher aux réglages radio).
  3. Tester la résolution DNS (interne + externe selon politique).
  4. Tester HTTP/HTTPS et le comportement portail (redirection, walled-garden).
  5. Si authentification : tester AAA (NAS→RADIUS) et isoler le problème (réseau vs secret vs politiques vs dépendances).
  6. Activer le mode dégradé documenté (si nécessaire), puis documenter le retour arrière.

Point projet Domocasa (discret)

Si vous préparez une pré‑ouverture, une rénovation courant faible ou un plan directeur réseau d’hôtel, l’enjeu n’est pas seulement “un Wi‑Fi qui couvre”. C’est de concevoir des services d’infrastructure rétablissables (DNS/DHCP/AAA), avec un DOE exploitable et des modes dégradés recettés. Pour cadrer le périmètre et les dépendances, vous pouvez vous appuyer sur notre guide d’architecture IP hôtel et notre approche supervision orientée services.

Références complémentaires

26Fév

Hôtels et bureaux : tester le Wi-Fi quand de nombreux utilisateurs se connectent

by Domocasa
Guides techniques Hôtellerie Réseaux et Wi-Fi

Illustration générée par IA — visuel conceptuel.

Pourquoi la “capacité” Wi‑Fi compte autant que la couverture

Un réseau peut afficher un excellent niveau de signal et pourtant offrir une expérience médiocre dès qu’on ajoute de la simultanéité (beaucoup de clients actifs), de la voix/visioconférence (sensibles aux pertes et à la latence), ou de la mobilité (roaming). En hôtellerie, c’est typiquement ce qui se produit dans un lobby, un restaurant, une salle événementielle… et parfois même à l’étage lorsque l’occupation monte.

L’objectif d’une recette “capacité” n’est pas de produire un seul chiffre de débit. C’est de répondre à une question exploitable : à charge réaliste, le service reste-t-il stable ? Et si non : est-ce un manque de points d’accès, un réglage radio à revoir, ou un goulot d’étranglement côté LAN (uplinks, switching, PoE, pare-feu, accès Internet) ?

Ce qu’on teste réellement (et comment le relier à une décision)

Pour rester simple et actionnable, on peut structurer la recette autour de cinq axes. Chacun doit être mesuré en condition “au repos” puis sous charge.

  • Simultanéité / densité : combien de clients actifs dans une zone avant dégradation (et surtout comment la dégradation se manifeste).
  • Throughput utile : débit observé “côté application” (souvent en TCP), et comportement quand on injecte de l’UDP (puisque l’UDP révèle rapidement pertes et gigue).
  • Latence sous charge : la latence ne se juge pas seulement “réseau vide”. Elle doit rester maîtrisée quand le réseau travaille.
  • Pertes / jitter : particulièrement critique pour la voix et la vidéo temps réel.
  • Roaming : interruption lors d’un changement de point d’accès, et stabilité pendant un déplacement (data et voix).

Repère voix (utile, mais à interpréter avec prudence)

Pour les applications interactives, l’ITU‑T recommande des limites de délai aller simple (one-way) : 0 à 150 ms est indiqué comme acceptable pour la plupart des usages, et 150 à 400 ms comme acceptable sous réserve de connaître l’impact sur la qualité perçue. (ITU‑T G.114)

En pratique, dans un bâtiment (hôtel/bureaux), on n’a pas toujours un outil simple pour mesurer l’aller simple de bout en bout sur un terminal utilisateur. On suit donc souvent le RTT (ping) vers des cibles LAN puis WAN, et on observe surtout la dérive sous charge (ce qui met en évidence une saturation radio ou un goulot LAN/WAN).

Préparer la recette : ce qu’il faut figer avant de lancer les tests

1) Définir des scénarios d’usage (par zone)

Avant d’ouvrir iperf3, décrivez qui fait quoi et où. En hôtel, il est utile de distinguer (au minimum) :

  • Chambres : usage “résidentiel” dispersé, mais répété à l’échelle d’un étage.
  • Lobby / restaurant : zones denses, clients + staff + parfois TV/casting.
  • Salles de réunion / événementiel : pointes fortes et exigences élevées (visioconférence, partage d’écran, streaming).
  • Back-office / staff : outils métier, téléphonie/softphones, stabilité en journée.

Ce cadrage complète naturellement une étude radio Wi‑Fi (site survey) : la couverture “carte de chaleur” ne suffit pas si la charge n’est pas définie.

2) Figer le périmètre technique (pour des tests reproductibles)

  • Liste des AP par zone (nom, emplacement, VLAN/SSID servis).
  • Chemin LAN (switch d’accès, uplink(s), cœur, pare-feu) pour savoir où un goulot peut apparaître.
  • Paramètres Wi‑Fi majeurs : SSID, sécurité, bands activées, canaux/puissances (attention aux mécanismes d’auto-optimisation qui changent la radio pendant la recette).

Si vous êtes en phase de conception, ce travail s’inscrit dans la démarche décrite dans Wi‑Fi hôtelier et Wi‑Fi professionnel : capacité radio et infrastructure filaire doivent être dimensionnées ensemble.

Définir des KPI (sans inventer des “seuils universels”)

Les KPI doivent être liés à une décision. Un KPI utile n’est pas “un beau débit”, c’est un indicateur qui vous permet de décider : ajout d’AP, changement de plan radio, renforcement d’uplink, segmentation, ajustement de QoS, etc.

Plutôt que d’imposer des chiffres identiques à tous les projets, utilisez une matrice simple par zone :

KPI Mesure (comment) Lecture “actionnable”
Débit utile (TCP) iperf3 en TCP, itérations répétées Plafond LAN/uplink si ça sature “trop tôt” malgré une bonne radio
Pertes / jitter (UDP) iperf3 en UDP à débit cible progressif Dégradation radio (airtime/réessais/interférences) ou queues saturées
Latence RTT (idle vs charge) ping continu vers cible LAN puis WAN pendant un test charge Buffering/saturation : si le RTT “explose” sous charge, le réseau est fragile
Stabilité multi-clients plusieurs clients simultanés, trafic mixte Capacité radio insuffisante si la zone s’effondre dès que la densité monte
Roaming ping + flux léger en mouvement + appel réel Design radio/paramétrage roaming à revoir si coupures répétées

Outillage minimal (terrain) : simple, mais robuste

iperf3 (débit TCP et tests UDP)

iperf3 est un outil courant pour générer et mesurer du trafic. Il permet notamment :

  • le mode UDP (-u) ;
  • un débit cible en UDP (-b) ;
  • plusieurs flux parallèles en TCP (-P).

Ces options sont documentées dans des manpages (ex. iperf3(1)) et guides de référence. (manpage iperf3)

Ping continu (latence, dérive sous charge)

Un ping “OK” ne garantit pas une bonne expérience, mais un ping qui se dégrade sous charge est un signal très utile. L’idée est de pinguer plusieurs cibles :

  • la passerelle du VLAN (cible LAN très proche),
  • un serveur interne (si disponible),
  • puis une cible Internet (pour distinguer LAN vs WAN).

Test voix/visioconférence en conditions réelles

Le protocole doit inclure au moins un test applicatif (Teams/Zoom/softphone/VoWiFi selon le site). Le but n’est pas de “mesurer pour mesurer”, mais de valider le ressenti sur un scénario métier (ex. appel en déplacement entre réception et back-office, ou entre deux salles).

Pourquoi il faut parler roaming “côté clients”

Le roaming n’est pas seulement une décision de l’infrastructure : le terminal garde une part importante du contrôle. Sur les appareils Apple, la documentation de déploiement indique notamment la prise en charge de 802.11k/802.11r/802.11v et rappelle que l’absence de mécanismes d’aide (comme le Neighbour Report 802.11k) peut obliger l’appareil à scanner plus largement. (Apple — Wi‑Fi roaming support)

Protocole de tests en 6 étapes (capacité + voix + roaming)

Les étapes ci-dessous forment une “recette” reproductible. Elles peuvent être réalisées sur un hôtel comme sur des bureaux, en adaptant simplement la sélection des zones et le niveau de charge.

Étape A — Baseline “1 client, réseau calme” (par zone)

Objectif : vérifier que la chaîne complète (radio + LAN + cœur + pare-feu) est saine avant de parler densité.

  • TCP download / upload (plusieurs itérations).
  • UDP à débit progressif (pour observer pertes/jitter).

Exemples iperf3 (à adapter au plan IP) :

# TCP (plusieurs flux)
iperf3 -c <IP_SERVEUR> -t 20 -P 4

# UDP (débit cible)
iperf3 -c <IP_SERVEUR> -u -b 50M -t 20

Étape B — Multi-clients “sur une même zone”

Objectif : identifier le point de bascule lorsque plusieurs clients actifs partagent la même ressource radio.

  • Constituer un groupe de clients (PC/smartphones) réellement représentatif.
  • Lancer des sessions iperf3 en parallèle.
  • En parallèle, faire tourner un ping continu pour voir la latence sous charge.

Lecture : si la latence (RTT) grimpe fortement déjà vers la passerelle LAN, la saturation est proche de l’accès (radio ou uplink d’accès). Si elle grimpe surtout vers Internet, le WAN/pare-feu est suspect.

Étape C — “Zone dense” (plusieurs AP, trafic mixte)

Objectif : simuler un lobby, un restaurant, une salle de réunion : plusieurs AP couvrent la même zone et les clients doivent se répartir “naturellement”.

  • Répartir physiquement les clients (pas tous au même endroit).
  • Mélanger TCP (usage “data”) et UDP (flux sensibles).
  • Observer si un AP devient “hotspot” saturé alors que d’autres sont peu chargés.

Étape D — Test latence “sous charge” (le test qui révèle souvent les uplinks)

Objectif : différencier manque de capacité radio vs goulot LAN/uplink/pare-feu.

  • Lancer un ping continu (LAN puis WAN).
  • Injecter une charge progressive avec iperf3.
  • Comparer la dérive de latence et la stabilité (pics, pertes).

Étape E — Roaming “data” (trajet réaliste)

Objectif : mesurer les interruptions lors d’un passage d’AP à AP sur un trajet réel (couloir → chambre, accueil → bureaux, open space → salle).

  • Ping continu (intervalle court) vers une cible LAN.
  • Petit flux UDP.
  • Déplacement contrôlé (plusieurs passages) pour vérifier la répétabilité.

Étape F — Roaming “voix” (ce que l’utilisateur ressent)

Objectif : valider la continuité d’un appel en déplacement. C’est ici que la recette devient “métier”.

  • Appel réel (softphone / VoWiFi / Teams audio) + trajet identique à l’étape E.
  • Noter : coupures audio, “robotisation”, déconnexions, nécessité de rappeler.

Interpréter les résultats : diagnostiquer radio vs LAN (et décider)

Symptôme : “bon à 1 client, mauvais en multi-clients”

Hypothèse dominante : saturation radio (airtime, réessais, plan de canaux/puisances, taille de cellule). Décision typique : revoir le design radio (souvent plus d’AP, cellules mieux contenues, planification mieux maîtrisée) plutôt que “changer la box”.

Ce diagnostic s’inscrit dans la logique d’une étude radio Wi‑Fi : capacité et roaming sont des objectifs de conception, pas des “effets secondaires” de la couverture.

Symptôme : “débit plafonné” + “latence qui gonfle sous charge”

Hypothèse dominante : goulot LAN/uplink/pare-feu (ou WAN). Décision typique : audit d’uplinks et de distribution, PoE, cœur réseau, et mise en place de supervision.

En hôtel, cette lecture doit être cohérente avec l’infrastructure globale : architecture réseau IP d’un hôtel (cohabitation Wi‑Fi, VoIP, IPTV, CCTV, GRMS).

Symptôme : “roaming instable” / “appels qui décrochent”

Hypothèse dominante : combinaison de design radio (cellules, recouvrement) + choix de mécanismes d’aide au roaming. La documentation Apple mentionne la prise en charge de 802.11k/802.11r/802.11v sur plusieurs appareils et rappelle l’intérêt des informations de voisinage pour réduire la charge de scan côté client. (Apple — Wi‑Fi roaming support)

Point de vigilance : 802.11r peut améliorer… ou casser des clients

Activer 802.11r n’est pas une “case à cocher” sans recette. Cisco indique que certains clients anciens peuvent ne pas s’associer à un SSID où 802.11r est activé, même en mode mixte, ce qui amène parfois à séparer les SSID ou à utiliser des modes adaptés selon parc clients. (Cisco — 802.11r (compatibilité clients))

Conclusion pratique : dans un hôtel, on teste toujours l’activation (ou non) des mécanismes de roaming avec un panel représentatif de terminaux clients avant généralisation.

Point de vigilance : 802.11v est une “suggestion” au client

802.11v peut aider l’infrastructure à proposer des candidats de roaming, mais Cisco rappelle qu’une requête de transition BSS est une suggestion que le client peut suivre… ou ignorer. (Cisco — 802.11v (BSS Transition))

Voix et “jitter” : comprendre ce qu’on mesure

Dans un rapport, il est utile de distinguer :

  • jitter applicatif/voix (souvent RTP) : la RFC 3550 définit le jitter d’inter-arrivée comme une moyenne lissée de la variation d’espacement des paquets. (IETF RFC 3550)
  • jitter mesuré par iperf3 en UDP : très utile pour comparer des scénarios, mais ce n’est pas exactement la même chose qu’une métrique de qualité audio “de bout en bout”.

Pour décider, l’approche la plus robuste reste : métriques réseau + test voix réel (en mouvement si nécessaire).

Modèle de rapport de recette (format simple à copier-coller)

Contexte

  • Site, zones testées, date/heure, conditions (occupation réelle, événements).
  • Inventaire AP/contrôleur (modèles/versions), switches, uplinks, PoE (synthèse).
  • SSID/VLAN concernés, options roaming (si pertinentes), politiques particulières.

Hypothèses de charge

  • Scénarios par zone : simultanéité visée, profils de trafic (data/vidéo/voix).
  • Terminaux utilisés (type + OS) : l’acceptation roaming dépend aussi du client.

Résultats (table de synthèse)

Zone SSID Baseline (1 client) Sous charge (multi-clients) Latence (idle vs charge) Roaming (data/voix) Conclusion
Lobby Invités OK / À préciser OK / Limite observée Stable / Dégrade OK / À corriger Radio / LAN / mix

Plan de remédiation (lié aux symptômes)

  • Actions radio : ajustements (canaux/puissances), repositionnement, AP additionnels, stratégie de cellules.
  • Actions LAN : uplinks, switching, PoE, chemins critiques, segmentation, élimination d’un goulot identifié.
  • Actions exploitation : supervision, alertes utiles, re-tests périodiques.

Sur l’aspect exploitation/indicateurs, voir aussi : Supervision réseau : quels équipements et indicateurs faut‑il réellement surveiller ?

Où ce protocole s’insère dans une démarche Domocasa

  • Avant : conception et site survey Wi‑Fi (couverture + capacité + interférences + roaming).
  • Pendant : recette capacité (ce protocole) + tests roaming voix dans les zones où c’est un usage réel.
  • Après : remédiation ciblée (radio, LAN, uplinks, PoE) et re-recette sur les mêmes scénarios, pour prouver l’amélioration.

Besoin d’une recette “capacité” sur site (hôtel ou bureaux) ?

Si vos utilisateurs se plaignent surtout aux heures de pointe, dans les zones denses ou en déplacement, une recette orientée capacité permet généralement d’identifier rapidement si la limite vient de la radio, du LAN/uplink, ou d’une combinaison des deux. Pour cadrer une intervention (site survey, protocole de recette, remédiation et re-tests), vous pouvez aussi vous appuyer sur nos guides Wi‑Fi hôtelier et Wi‑Fi professionnel.

9Fév

Borne de recharge électrique en villa ou en hôtel : comment choisir et l’intégrer ?

by Domocasa
Énergie et CVC Hôtellerie Réseaux et Wi-Fi

Illustration générée par IA — visuel conceptuel.

Pourquoi la “borne VE” est un sujet bâtiment (pas seulement un achat)

Dans une villa haut de gamme comme dans un hôtel, une borne de recharge ne se limite pas à une prise plus puissante. Elle introduit une charge électrique importante, des enjeux d’exploitation (qui a le droit de charger, comment tracer, comment dépanner) et, très souvent, une dépendance au réseau (supervision, accès distant, mises à jour).

La bonne approche consiste à concevoir une architecture de recharge : puissance disponible, priorités, comptage, délestage, interfaces (OCPP/Modbus) et mode dégradé. Cela évite deux dérives fréquentes : surdimensionner sans raison, ou installer “comme à la maison” un système qui devient ingérable en exploitation.

1) Clarifier le cas d’usage : villa, hôtel… ou parking mixte

Villa : confort, cohérence énergétique, simplicité d’usage

En résidentiel, la recharge VE s’intègre souvent à une logique plus large : confort, gestion d’énergie, et parfois production photovoltaïque ou batterie. L’objectif est généralement une recharge “sans y penser”, avec une limitation automatique quand d’autres usages montent en puissance. Si votre projet comporte déjà PV/batterie, l’article KNX, photovoltaïque, batteries et recharge de véhicule électrique : comment optimiser les flux ? permet de recadrer “qui décide quoi” entre onduleur/EMS, batterie et bâtiment.

Hôtel : service client, pilotage multi-usagers, traçabilité

En hôtellerie, une borne est un service : elle doit être administrable, traçable, et compatible avec des usages variés (clients, navettes, personnel, prestataires). Le projet doit aussi décider si la recharge est :

  • Un service inclus (ex. avantage commercial),
  • Un service piloté (accès contrôlé + journalisation),
  • Un service facturable (si l’établissement choisit de refacturer tout ou partie).

Ce choix influence le niveau d’intégration attendu (identification, comptage, reporting), et surtout le comportement en mode dégradé (si la supervision tombe, que fait-on ?).

2) Puissance disponible : partir de la contrainte amont, pas de la borne

Avant de comparer des bornes, il faut cadrer la puissance réellement disponible au point d’alimentation de la zone (parking, sous-sol, extérieur) et comprendre les autres charges qui peuvent monter en même temps.

En pratique, une architecture robuste clarifie :

  • Le périmètre électrique : quelle armoire alimente la zone, quelles protections, quels départs “non délestables”.
  • Les usages concurrents : cuisines, CVC, pompes, laverie, événements (hôtel), ou gros consommateurs ponctuels (villa).
  • La stratégie de contrainte : limitation, délestage, ou répartition dynamique entre bornes.

Pour la méthode de conception “délestage”, voir aussi Délestage intelligent : comment piloter les charges électriques d’un bâtiment ?.

3) Délestage et priorités : éviter le ON/OFF brutal

Un bon délestage de recharge ne se résume pas à “couper la borne”. On cherche plutôt à moduler (réduire, répartir, prioriser) de manière compréhensible et stable. Deux logiques complémentaires coexistent souvent :

  • Limiter la puissance totale appelée par la recharge (priorité au bâtiment).
  • Partager la puissance entre plusieurs points (priorité à l’équité ou à certains usages).

Prioriser les charges : bâtiment d’abord, confort ensuite, recharge en dernier (souvent)

Dans beaucoup de projets, la recharge VE est une charge très flexible. Cela ne veut pas dire “à sacrifier” : cela veut dire qu’elle peut être pilotée pour éviter les dépassements et préserver les usages critiques.

Recommandation de projet : formaliser une matrice de priorités (charges non délestables, délestables, modulables) et une stratégie de rétablissement (comment on remonte progressivement sans faire osciller le site). Cette logique se conçoit avec le BET électricité et, si la GTB/KNX intervient, avec l’intégrateur.

Ne pas confondre délestage et “smart charging”

Le “smart charging” peut désigner des choses différentes selon les acteurs : répartition entre bornes, consignes venant d’un serveur, optimisation PV, ou contraintes électriques instantanées. Le cahier des charges doit donc préciser : qui calcule la limite (borne, contrôleur local, GTB/KNX, supervision OCPP), et quelles informations sont nécessaires (mesure, états, priorités).

4) Comptage, sous-comptage et “facturation éventuelle” : cadrer le niveau de preuve

Que l’on refacture ou non, la recharge devient rapidement un sujet de mesure : énergie consommée, sessions, période, utilisateur, borne. Le bâtiment gagne à séparer :

  • Le pilotage électrique (éviter les dépassements, délester),
  • La mesure énergétique (comprendre et suivre),
  • La valorisation (refacturer, ou suivre par centre de coût).

Pour structurer la mesure sans multiplier les compteurs inutiles, voir Sous-comptage énergétique : savoir précisément où part l’énergie d’un bâtiment.

Facturer n’est pas juste “lire un kWh”

Si l’hôtel souhaite facturer la recharge, il faut cadrer dès l’étude :

  • Quelle donnée fait foi (compteur interne de la borne, compteur externe dédié, mesure d’armoire, données OCPP, etc.).
  • Le niveau de traçabilité attendu (session, utilisateur, véhicule, chambre, facture interne… selon l’exploitation visée).
  • Les limites acceptables : selon les bornes, les mesures existent mais ne sont pas toujours conçues comme un “outil de facturation” au sens strict. Cela se vérifie sur la documentation du fabricant et en recette.

Au Maroc, les exigences exactes (si vous cherchez une refacturation formelle avec un certain niveau de preuve) doivent être confirmées au cas par cas avec vos conseils et fournisseurs. L’article vise ici à structurer le besoin et les tests, sans imposer un cadre réglementaire qui dépend du contexte.

Hôtel : relier la recharge au “parcours client” (sans surcompliquer)

En exploitation, le sujet n’est pas seulement “combien d’énergie a été consommée”, mais comment le service est opéré :

  • Qui autorise une session : réception, application, badge, QR code, ou règles automatiques par type d’utilisateur.
  • Comment on rattache une session : à une chambre, à un client, à un véhicule de navette, à un centre de coût interne, etc.
  • Ce que l’on fait des exceptions : session interrompue, badge perdu, borne hors service, litige, etc.

Recommandation de projet : exiger une procédure exploitation (qui fait quoi, avec quels accès) et une recette “front desk” (tests côté réception) au même titre que les tests techniques. Cette logique se rapproche de la démarche livrables/exploitation décrite dans DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

5) Interfaces : OCPP pour l’exploitation, Modbus pour l’intégration bâtiment (souvent)

Le point clé : “compatible” ne suffit pas. Un protocole définit un langage, mais pas forcément le périmètre réellement supporté par la borne, ni le comportement en cas de panne. Il faut donc concevoir par fonctions (pilotage, comptage, droits, supervision) puis vérifier les interfaces disponibles.

OCPP : utile pour superviser, administrer et tracer

OCPP est un standard ouvert pour la communication entre une borne (Charging Station) et un système de supervision/gestion (CSMS). En conception, cela devient le bon candidat pour :

  • Remonter des états et événements (disponibilité, sessions, alertes selon produit).
  • Administrer des droits d’accès selon l’architecture retenue (badges, listes locales, règles).
  • Appliquer des politiques de charge, lorsque la borne et le CSMS supportent réellement les fonctions attendues.

Point de vigilance : OCPP existe en versions. En pratique, votre cahier des charges doit exiger la version et les profils réellement supportés, pas seulement “OCPP”. Pour une référence de définition et de versions côté Open Charge Alliance, voir OCPP protocols (Open Charge Alliance).

OCPP et “smart charging” : optionnel selon profils

Dans OCPP, toutes les fonctions ne font pas partie d’un socle unique : certains périmètres (comme le Smart Charging) dépendent de profils et de mises en œuvre. Conséquence projet : une borne OCPP peut être parfaitement supervisable sans offrir le pilotage fin attendu pour un délestage dynamique. Il faut donc vérifier la prise en charge réelle, côté borne et côté CSMS.

Pour ancrer ce point (sans le surinterpréter), notez que dans le programme de certification OCPP 2.0.1, le profil Core est obligatoire, tandis que Smart Charging et Advanced Security sont listés comme optionnels : cela rappelle qu’un libellé “OCPP” ne suffit pas à décrire le périmètre. Référence : Certification OCPP 2.0.1 (Open Charge Alliance).

Sécurité OCPP : ne pas confondre “certifié OCPP” et “architecture sécurisée”

Une borne connectée est un équipement réseau. Or, le fait d’être “compatible OCPP” ne décrit pas à lui seul la posture de sécurité réelle : selon les produits et le couple “borne + CSMS”, le périmètre de sécurité mis en œuvre (chiffrement, authentification, gouvernance des identités, durcissement réseau, mise à jour) peut varier.

Conséquence projet (pragmatique) : traitez la sécurité comme une exigence de conception et d’exploitation — et pas comme un slogan. En cahier des charges, cela se traduit généralement par :

  • un chiffrement des communications et une authentification adaptés à l’architecture retenue (à confirmer selon les capacités de la borne et du CSMS) ;
  • une gouvernance des comptes (droits, traçabilité, suppression des accès) ;
  • une gestion de cycle de vie (mises à jour, certificats/identités si utilisés, sauvegardes et procédures de renouvellement) ;
  • des tests de mode dégradé : une sécurité trop “rigide” peut bloquer l’exploitation si elle est mal opérée ; une sécurité trop “laxe” peut exposer le réseau.

Pour une lecture plus opérationnelle (process, journalisation, gestion des certificats, recommandations), vous pouvez aussi vous appuyer sur le guide OCA : OCPP Security Operations Guide (Open Charge Alliance).

Modbus : utile pour interfacer une logique locale (mais registres variables)

Modbus est un protocole ouvert, très utilisé en bâtiment pour la mesure et certaines commandes. Pour la recharge VE, Modbus peut devenir pertinent lorsque vous visez une logique locale : délestage immédiat, intégration GTB, échange avec un contrôleur local, ou lecture de compteurs.

Mais Modbus n’est pas “plug and play” : le mapping des registres (ce que la borne expose, ce que l’on peut écrire, à quelle unité, à quelle granularité) est spécifique au fabricant. Autrement dit : dire “Modbus” ne garantit pas qu’on puisse imposer une consigne de courant, ni remonter une mesure utile au même niveau de détail que votre besoin. C’est un point à valider sur la documentation de la borne candidate.

6) KNX / GTB : comment intégrer la recharge sans fragiliser l’exploitation

Dans une villa, KNX sert souvent de socle pour coordonner énergie, CVC, éclairage, et scénarios. Dans un hôtel, on est plus proche d’une logique immotique/GTB, où la cohérence des responsabilités est essentielle. Pour le cadre général, voir KNX : le standard ouvert de la domotique et de l’immotique et Qu’est-ce que l’immotique ?.

KNX et recharge : passerelles et périmètre

Dans beaucoup de projets, KNX ne parle pas “nativement” à une borne. L’intégration passe donc par une couche d’interface (par exemple Modbus, API, ou supervision). Le projet doit décider si KNX :

  • Lit des informations (état, puissance, énergie) pour un tableau de bord ou une logique énergétique.
  • Écrit des consignes (limites) vers une passerelle/contrôleur, lorsque la borne et l’interface l’autorisent réellement.

Pour la stabilité, il est généralement préférable de concevoir une logique où les fonctions essentielles (sécurité électrique, protections, contraintes critiques) ne dépendent pas d’une supervision “confort”. La philosophie est similaire à celle décrite dans nos guides de conception : prévoir une architecture qui reste compréhensible, maintenable et testable.

Tableau, réseaux et documentation : la recharge touche au “socle”

Si KNX (ou une GTB) intervient, cela implique souvent des passerelles IP, des interfaces Modbus, et une intégration réseau. Il faut donc traiter très tôt :

7) Réseau (hôtel et sites multi-usages) : VLAN, accès et isolation

La recharge connectée (bornes, supervision, passerelles) devient un lot IP. En hôtel, cela doit s’inscrire dans l’architecture réseau globale, au même titre que Wi-Fi, vidéosurveillance, VoIP ou GRMS. Deux lectures complémentaires :

Recommandation d’architecture : isoler la recharge comme un réseau technique

Sans sur-spécifier, un principe robuste consiste à isoler :

  • Le réseau “technique” (bornes, passerelles, supervision),
  • Le réseau “administration” (interfaces de gestion),
  • Le réseau “invités” (qui ne doit pas atteindre les systèmes techniques).

Ce n’est pas une obligation “protocole” : c’est un choix de sécurité et de maintenabilité. L’objectif : limiter les flux, simplifier le diagnostic, et éviter qu’un équipement exposé ne devienne une porte d’entrée vers le reste du bâtiment.

Pour une référence “bonnes pratiques” (OT/IT) sur la segmentation logique, NIST décrit notamment l’usage des VLAN comme un moyen de séparation logique lorsque la séparation physique n’est pas possible : NIST SP 800-82r3 — Guide to Operational Technology (OT) Security.

À cadrer au CCTP : dépendances réseau “minimales” de la recharge

Une borne pilotée via OCPP, une passerelle Modbus et un CSMS (cloud ou local) introduisent des dépendances IT qu’il vaut mieux déclarer plutôt que découvrir en fin de chantier. Recommandation de projet : demander au fournisseur (borne et CSMS) une fiche d’interfaces listant au minimum :

  • les flux nécessaires au fonctionnement (supervision, temps, résolution DNS, mises à jour si utilisées) ;
  • les ports/protocoles requis (à valider sur documentation fabricant, car cela varie) ;
  • les adresses/IP ou FQDN attendus (utile pour filtrage sortant) ;
  • le comportement si ces dépendances tombent (supervision indisponible, DNS indisponible, etc.).

Ce cadrage facilite ensuite une politique réseau propre : pas d’exposition entrante inutile, flux sortants limités, et diagnostics plus rapides en cas d’incident.

8) Mode dégradé : le critère qui révèle la qualité de conception

La recharge est souvent perçue comme non critique… jusqu’au jour où elle fait partie de l’expérience client (hôtel) ou du quotidien (villa). Le mode dégradé doit donc être défini, puis testé.

Offline OCPP : ce que la supervision ne doit pas vous faire oublier

Les documents OCPP décrivent un comportement “offline” typique : une session en cours continue, les messages peuvent être mis en mémoire tampon puis transmis au retour de connexion ; en revanche, l’autorisation de nouvelles sessions dépend des mécanismes locaux (listes locales, règles, choix d’exploitation). Cela signifie concrètement : le projet doit décider à l’avance ce qui est accepté lorsque le lien vers la supervision n’est plus disponible.

Pour une référence explicite sur ce comportement (buffering, autorisations offline et variables associées), voir le whitepaper OCA : Improving Uptime Monitoring with OCPP (Open Charge Alliance).

Point d’attention : autoriser des sessions “offline” pour des identifiants inconnus peut introduire un risque d’exploitation (notamment si une logique de facturation ou d’autorisation dépend de la supervision). C’est donc une décision métier autant que technique.

Ce qu’il faut exiger : une recette “pannes” et pas seulement des tests de charge

Un cahier des charges sérieux prévoit des essais :

  • Perte Internet / perte supervision.
  • Redémarrage de borne et reprise.
  • Conflit de charges (scénario de pointe) et stabilité du délestage.
  • Comportement des droits d’accès en mode offline (selon stratégie retenue).

Dans un hôtel, cette logique s’inscrit dans la démarche de readiness et de passation vers l’exploitation, au même titre que les autres systèmes connectés (voir DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?).

9) Checklists de conception (pratiques) : villa vs hôtel

Checklist villa (projet haut de gamme)

  • Puissance disponible : contraintes au tableau et usages concurrents.
  • Objectif : recharge “simple” ou optimisation énergie (PV/batterie) ? (voir KNX, photovoltaïque, batteries et recharge VE)
  • Délestage : quels circuits sont prioritaires ? (voir Délestage intelligent)
  • Interface : OCPP utile ou pas ? Modbus exploitable ou uniquement mesure ?
  • Intégration KNX : lecture seule vs consigne, et DOE (voir DOE domotique).
  • Mode dégradé : que se passe-t-il si Internet tombe ?

Checklist hôtel (parking clients et exploitation)

  • Politique de service : inclus, contrôlé, ou facturable (et comment).
  • Gestion des droits : clients vs personnel vs prestataires.
  • Comptage : sous-comptage et reporting (voir Sous-comptage énergétique).
  • Architecture réseau : VLAN, filtrage, supervision (voir VLAN et architecture IP hôtel).
  • Mode dégradé : sessions en cours, autorisation offline, procédures de contournement.
  • DOE + passation exploitation : accès, sauvegardes, comptes, runbook (voir DOE & maintenance d’un hôtel connecté).

Conclusion : une borne VE réussie est une architecture testée

Choisir une borne, ce n’est pas seulement choisir une puissance ou un design : c’est définir une architecture capable de tenir la charge (électrique), la réalité d’exploitation (droits, traçabilité), et les pannes (mode dégradé). OCPP, Modbus et KNX/GTB sont des briques utiles, mais leurs fonctions réelles varient selon les modèles et les versions : le projet doit donc exiger des preuves (documentation, profils, essais) et une recette adaptée au site.

Pour cadrer votre projet (villa ou hôtel) et éviter les zones grises entre lots (électricité, réseau, GTB, exploitation), vous pouvez vous appuyer sur un cahier des charges structuré — par exemple en vous inspirant de la méthode décrite dans Cahier des charges KNX pour une villa : que faut-il spécifier avant de consulter un intégrateur ? et en l’adaptant à la recharge.

Si vous souhaitez valider une architecture de recharge (puissance, délestage, interfaces, réseau et exploitation) sur plans avant consultation des fournisseurs, Domocasa peut vous aider à cadrer le périmètre et les tests de recette.

19Jan

Maintenance des équipements d’hôtel : quels engagements prévoir dans le contrat ?

by Domocasa
Guides techniques Hôtellerie

Illustration générée par IA — visuel conceptuel.

Pourquoi un contrat de maintenance « courant faible » se négocie comme un contrat de service

Dans un hôtel, le courant faible (réseau IP, Wi‑Fi, VoIP, IPTV, CCTV, contrôle d’accès, GRMS, interfaces PMS, etc.) n’est pas une simple liste d’équipements à « maintenir ». C’est un ensemble de services visibles par le client (connectivité, téléphonie, TV, accès chambre) et critiques pour l’exploitation (réception, housekeeping, maintenance, sécurité, supervision).

Un contrat trop centré sur le matériel (ex. « disponibilité des bornes Wi‑Fi ») peut afficher des indicateurs satisfaisants… tout en laissant le service inutilisable (portail captif en panne, DHCP/DNS indisponibles, VLAN mal taggé, coupure WAN, etc.). À l’inverse, un contrat centré sur l’expérience (capacité à se connecter et à obtenir un service stable) oblige à clarifier ce qui est mesuré, qui agit et dans quels délais.

SLA, OLA et contrats sous-jacents : clarifier la chaîne d’engagements avant de parler pénalités

SLA : l’engagement « face à l’exploitant » (ou face au propriétaire)

Le SLA (Service Level Agreement) formalise le niveau de service attendu : périmètre, indicateurs, méthode de mesure, délais (prise en charge / diagnostic / rétablissement), reporting, exclusions, obligations des parties.[1]

OLA : l’engagement interne qui rend le SLA tenable

Un OLA (Operational Level Agreement) désigne, au sens ITIL, un accord entre un fournisseur de services IT et une autre partie de la même organisation (par exemple : service desk ↔ équipe réseau, équipe exploitation ↔ achats). L’objectif est de fixer des responsabilités et des délais entre équipes internes afin de rendre les engagements SLA tenables.[2]

En hôtellerie, cette logique est utile dès lors que plusieurs équipes internes (exploitation, IT, sécurité, direction technique) se partagent la chaîne de traitement d’un incident : qui qualifie, qui décide, qui autorise une coupure, qui valide un mode dégradé, etc.

Contrats sous-jacents (« underpinning contracts » / UC) : les engagements externes à aligner

Pour les tiers (FAI/WAN, trunk SIP, éditeur PMS, support constructeur, licences, plateformes cloud…), ITIL emploie le terme d’Underpinning Contract (UC) : un contrat avec un fournisseur externe dont les services soutiennent la livraison du service au client.[2]

Dans la pratique, beaucoup d’hôtels disposent d’un SLA “global” mais de contrats sous‑jacents (FAI, support PMS, support constructeur…) qui ne garantissent pas les mêmes délais. Résultat : le SLA global devient intenable. La bonne méthode consiste à aligner SLA (engagement global), OLA (organisation interne) et UC (engagements tiers) dès la phase de consultation.

Étape 1 : partir d’un mini « catalogue de services » (et pas d’une nomenclature de matériels)

Avant toute négociation de MTTR ou d’astreinte, définissez un catalogue court des services à maintenir. Ce catalogue peut devenir l’annexe qui structure le contrat.

Modèle de catalogue (structure à copier)

Modèle — catalogue de services (périmètre, dépendances, plage, criticité).
Service Périmètre (inclus) Dépendances (hors périmètre à expliciter) Plage de service Criticité
Wi‑Fi invités WLAN + LAN de support + DHCP/DNS (si fournis) + portail captif (si fourni) + supervision FAI/WAN (si non inclus), énergie, terminaux clients À définir (exploitation) Élevée
Wi‑Fi staff / opérations SSID/VLAN staff + accès aux services métiers nécessaires Éditeur PMS / applicatifs tiers À définir Très élevée
Réseau cœur (switching/routage) Cœur/distribution/accès + configurations + sauvegardes Travaux tiers, modifications non validées À définir Très élevée
Téléphonie IP / VoIP LAN voix + IPBX (si inclus) + postes/terminaux (si inclus) Trunk opérateur/SIP, lien Internet (si VoIP externe) À définir Élevée
Interfaces PMS (serrures/GRMS/IPTV) Connecteurs, passerelles, services d’intégration (selon périmètre) Support PMS/éditeurs, licences, API À définir Très élevée

Pour remettre ces services dans une vision globale des lots et dépendances d’un établissement, voir courant faible dans un hôtel : les systèmes indispensables à prévoir.

Étape 2 : KPI/SLI/SLO — définir des indicateurs mesurables et opposables

Un KPI utile n’est pas seulement “technique”. Il doit être reproductible (même test = même résultat), compréhensible (exploitation et prestataires) et actionnable (si l’alerte tombe, quelqu’un sait quoi faire).

Disponibilité : ne pas signer un pourcentage si personne ne sait le convertir

Quand un contrat parle de disponibilité (en %), il doit préciser la période d’observation (mensuelle, trimestrielle), la plage de service (jour/nuit, saison, etc.) et la méthode de mesure (sonde, supervision, test boîte noire). Sans cela, la disponibilité devient une discussion sans fin.

Modèle KPI – Wi‑Fi invités (orienté expérience)

Objectif : décrire un Wi‑Fi “qui marche” comme un client, pas comme une borne.

Modèle KPI — Wi‑Fi invités (SLI orienté expérience utilisateur).
Élément Définition contractuelle (modèle)
Service Wi‑Fi invités – SSID X – zones (chambres / lobby / MICE)
SLI (expérience) Taux de connexions réussies sur un test standard : association au SSID → attribution IP (DHCP) → résolution DNS → accès web (HTTP/HTTPS) → portail captif (si présent)
Méthode de mesure Sonde(s) / client(s) de test, emplacements fixes + scénarios de roaming dans zones clés
Exclusions Fenêtres de maintenance validées, force majeure, indisponibilité FAI si hors périmètre
Reporting Mensuel : disponibilité, incidents majeurs, actions correctives/préventives

Modèle KPI – Téléphonie IP / VoIP

Modèle KPI — téléphonie IP / VoIP (service et qualité de transport).
Élément Définition contractuelle (modèle)
SLI (service) Taux d’appels aboutis (selon périmètre), disponibilité du service de réception, disponibilité des appels internes
SLI (qualité) Indicateurs de qualité sur le chemin réseau (perte/latence/gigue) sur les segments concernés
Dépendances Trunk opérateur / SIP, WAN, alimentation PoE, configuration VLAN/QoS (si retenue au design)

Pour recadrer le rôle du réseau (LAN/WAN), des dépendances et des responsabilités dans un environnement convergé, voir architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?.

Modèle KPI – Interfaces PMS (serrures, GRMS, IPTV)

Pour les interfaces, le point crucial est de définir “service rétabli” de manière opérationnelle (ce que la réception doit pouvoir faire, même en mode dégradé).

Modèle KPI — interfaces PMS (définition opérationnelle du « service rétabli »).
Service Définition « rétabli » (exemples à formaliser) Mode dégradé acceptable
Encodage / remise de clé La réception peut encoder une clé et ouvrir une chambre selon la procédure prévue Procédure manuelle documentée, traçable
Synchronisation PMS ↔ serrures Les droits de séjour sont appliqués et cohérents avec les changements de chambre Rattrapage par batch / resync documenté
Statuts PMS ↔ GRMS Les statuts nécessaires à l’exploitation (check‑in/out, états de chambre) sont exploités selon périmètre Fonctionnement local chambre préservé

Pour cadrer « qui échange quoi » (et éviter qu’un système secondaire devienne indispensable), voir PMS, GRMS, GTB, serrures : qui échange quoi dans un hôtel ?.

Étape 3 : MTTR, prise en charge, diagnostic, rétablissement — verrouiller le chrono

Un contrat qui annonce un « MTTR » sans définir le départ/arrêt du chrono crée mécaniquement un litige. D’un point de vue métrique, le MTTR (Mean Time To Recovery) est un temps moyen de récupération calculé sur une période, utile pour piloter (et comparer) la performance d’un service après coup.[3]

Pour rendre le contrat exploitable au quotidien, il est généralement plus opérationnel de définir au contrat des horloges complémentaires (définitions contractuelles, à valider avec l’exploitation) :

  • TTA (prise en charge) : délai pour reconnaître l’incident et ouvrir le circuit de traitement.
  • Temps de diagnostic : délai pour qualifier la cause probable (WAN, Wi‑Fi, cœur réseau, applicatif, interface, etc.).
  • TTR (rétablissement) : délai pour restaurer le service, y compris par contournement validé.
  • MTTR (moyenne) : indicateur de pilotage calculé sur une période, après coup.[3]

Cette séparation rend les engagements plus réalistes : certains incidents se diagnostiquent vite mais exigent une pièce, d’autres se rétablissent vite via contournement mais demandent une correction définitive planifiée.

Étape 4 : astreinte, escalade et fenêtres de maintenance — rendre le SLA « opérable »

Astreinte : écrire une mécanique, pas un slogan

Une astreinte “24/7” n’a pas de valeur si le contrat ne précise pas :

  • le canal d’entrée (numéro unique / portail tickets) et qui peut l’utiliser (réception, responsable technique, direction),
  • la matrice de sévérité (incidents bloquants vs dégradations),
  • ce que l’astreinte inclut (télédiagnostic, téléaction) et ce qui déclenche un déplacement,
  • les droits d’action autorisés (redémarrage contrôleur, bascule lien, rollback config, etc.),
  • les obligations côté hôtel (personne joignable, accès local technique, clés, badges, autorisations).

Fenêtres de maintenance : éviter le “hors SLA” trop large

Les fenêtres de maintenance doivent être décrites comme un processus :

  • préavis (qui valide, comment),
  • plages autorisées (nuit, heures creuses),
  • tests de non‑régression attendus,
  • plan de retour arrière (rollback) si l’intervention dégrade le service.

Sur un hôtel en exploitation, une maintenance réseau “non concertée” peut impacter simultanément Wi‑Fi, VoIP, IPTV et interfaces de chambre. Le contrat doit donc prévoir une coordination et une méthode, pas seulement “une autorisation de couper”.

Étape 5 : multi‑prestataires — contractualiser une matrice de responsabilités (RACI)

Le risque principal en exploitation hôtelière est le renvoi de responsabilité : « c’est l’opérateur », « c’est le PMS », « c’est le Wi‑Fi », « c’est le LAN », etc. La réponse est une matrice RACI annexée au contrat : Responsable, Approbateur, Consulté, Informé.

En pratique, cette annexe s’articule souvent avec :

  • un OLA interne (qui fait quoi dans l’organisation de l’hôtel),
  • et des UC (contrats sous-jacents) avec les tiers, alignés sur les engagements SLA quand c’est nécessaire.[2]

Modèle RACI (structure à adapter à votre hôtel)

Modèle RACI — responsabilités multi-prestataires (structure à adapter).
Activité / Service Exploitant hôtel Mainteneur courant faible Opérateur Internet Éditeur PMS Prestataire Wi‑Fi (si distinct)
Supervision / alerting I R/A C I C
Incident Wi‑Fi (auth/DHCP/DNS interne) C R/A I I R/C
Incident WAN / lien FAI indisponible I C R/A I I
Incident interface PMS ↔ serrures C R/C I R/C I
Changement planifié (MAJ firewall/switch/AP) A R I I C

Pour cadrer les risques cybersécurité et les accès entre prestataires (comptes, VPN, segmentation), voir cybersécurité d’un hôtel connecté.

Étape 6 : stock de pièces — la condition cachée de tout MTTR ambitieux

Un engagement de rétablissement rapide n’est pas tenable si la logistique pièce est ignorée. Deux approches se complètent souvent :

  • Stock sur site (pièces “critiques” pour restaurer le service).
  • Support constructeur (échange avancé, options de remplacement rapide) — à traduire en engagement local réaliste selon la disponibilité effective.

Modèle de politique de pièces (à annexer)

Modèle — politique de pièces (classification et stratégie de remplacement).
Classe Exemples (à adapter) Stratégie recommandée Justification
A (bloquant) Pare‑feu/routeur, switch cœur/distribution, contrôleur Wi‑Fi (si présent) Spare sur site ou solution de redondance + procédure de bascule testée Un seul incident peut affecter plusieurs services
B (critique local) Switch d’étage, alimentation PoE critique, AP zones sensibles Stock minimal (modèles standardisés) + procédure de remplacement Réduit fortement le temps d’indisponibilité
C (non bloquant) Éléments secondaires, périphériques non critiques Commande à la demande Optimisation du coût de stock

Le contrat doit indiquer : qui porte le stock, où il est stocké, qui a le droit de le sortir, comment on reconstitue, et comment on trace (numéro de série, date, ticket).

Étape 7 : accès distants (VPN), comptes, sauvegardes — prérequis contractuels, pas “bonnes pratiques” optionnelles

Sans accès distant maîtrisé, une grande partie des incidents se transforme en déplacements inutiles et en temps de diagnostic. Mais un accès distant mal cadré crée un risque majeur. Le contrat doit donc inclure une annexe « accès & sécurité » avec des exigences opposables.

Checklist contractuelle « accès distants »

  • Mode d’accès : exiger une protection adaptée de la confidentialité et de l’intégrité des communications. Lorsque le mécanisme d’accès distant n’apporte pas cette protection, prévoir une protection additionnelle (par exemple via VPN ou TLS), selon l’architecture retenue.[4]
    En pratique projet, cela revient souvent à éviter l’exposition directe d’interfaces d’administration sur Internet, ou à l’encadrer strictement (périmètre, durée, comptes, traçabilité, analyse de risque), lorsque le modèle d’exploitation l’impose.
  • Comptes : comptes nominatifs et révocation documentée (fin de mission).
  • Droits : principe du moindre privilège (qui peut configurer quoi).
  • Traçabilité : journalisation minimale des connexions et des actions sensibles quand l’outil le permet.
  • Procédure d’urgence (“break‑glass”) : qui l’active, sur quel périmètre, comment on referme.
  • Sauvegardes : configurations exportables (pare‑feu/switch/Wi‑Fi), documentation d’emplacement, méthode de restauration testée.

Pour les sujets supervision et indicateurs réellement utiles (éviter les alertes non actionnables), voir supervision réseau : quels équipements et indicateurs surveiller ?.

Étape 8 : pénalités réalistes — privilégier des crédits de service applicables

Des pénalités trop agressives ou mal mesurées peuvent devenir difficiles à appliquer (preuve, imputabilité multi‑prestataires, exclusions, contestations) et détourner l’énergie des actions correctives. Une approche souvent plus robuste consiste à prévoir des crédits de service (service credits) fondés sur une méthode de mesure acceptée, avec des exclusions et un plafond.

Point de cadrage : ce mécanisme existe notamment chez certains fournisseurs (ex. AWS) et peut inspirer une clause “maintenance” à condition de l’adapter au périmètre hôtelier (et de ne pas le confondre avec une garantie “tout risque” universelle).[5]

  • un indicateur de disponibilité et une méthode de mesure acceptés,
  • des exclusions claires (maintenance validée, force majeure, dépendance hors périmètre),
  • un plafond mensuel (pour rester proportionné),
  • et, si souhaité, un mécanisme “non financier” utile (heures de prévention, audit, optimisation Wi‑Fi, revue d’architecture).

Modèle de clause (structure)

  • Si le niveau de service mesuré est inférieur à l’objectif sur la période, un crédit s’applique sur le forfait du service concerné (par paliers).
  • Le crédit est plafonné pour éviter une exposition disproportionnée (à définir au contrat).
  • Les cas d’exclusion et les responsabilités multi‑prestataires sont listés (RACI, OLA interne et UC).

Annexes recommandées (pack contractuel “prêt exploitation”)

Pour qu’un SLA reste utile après l’ouverture, structurez le contrat en annexes courtes et opposables :

  1. Catalogue des services (périmètre, dépendances, criticité).
  2. SLI/SLO par service (méthode de mesure, reporting).
  3. Process incident (définitions contractuelles TTA/TTR, astreinte, escalade, preuves attendues).
  4. Fenêtres de maintenance (préavis, tests, rollback).
  5. RACI multi‑prestataires + OLA interne (organisation) et UC (contrats tiers).
  6. Accès distants & sécurité (VPN/TLS selon architecture, comptes, journaux, sauvegardes).
  7. Politique pièces (stock, standardisation, reconstitution).
  8. Crédits de service (règles, plafonds, exclusions).

Pour organiser la passation entre chantier et exploitation (documentation, sauvegardes, procédures), voir DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

À quel moment contractualiser ? Avant la pré‑ouverture, sinon vous subissez l’exploitation

La meilleure fenêtre pour verrouiller SLA, organisation interne (OLA), contrats tiers (UC), accès, supervision, procédures et pièces est avant l’arrivée des premiers clients. C’est aussi le moment où vous pouvez tester la chaîne (incident simulé, coupure WAN, bascule, restauration de configuration, remplacement d’un AP, etc.).

Pour cadrer la recette de pré‑ouverture (réseau, Wi‑Fi, chambre, interfaces, services visibles client), voir pré‑ouverture d’un hôtel : checklist technique des systèmes courant faible.

Conclusion : un « bon SLA » ne promet pas l’impossible, il rend le service réparable

Un contrat de maintenance courant faible hôtelier solide ne se juge pas à un MTTR “agressif” ou à un pourcentage de disponibilité isolé. Il se juge à sa capacité à rendre les incidents diagnosticables, réparables et coordonnés en conditions réelles : multi‑prestataires, contraintes d’accès, pièces, saisons, exploitation.

Si vous préparez un appel d’offres maintenance ou une reprise d’hôtel, l’objectif est simple : transformer l’architecture technique en engagements opérables (SLA + organisation interne + contrats tiers + runbook + supervision + pièces + accès).

Si vous souhaitez cadrer un périmètre de maintenance (réseau/Wi‑Fi/VoIP/TV/GRMS) avant ouverture, commencez par une liste de services et une matrice de responsabilités : c’est souvent la base la plus rentable à sécuriser.

Références (sources)

  1. SLA : définition (NIST CSRC Glossary).
    https://csrc.nist.gov/glossary/term/SLA
  2. OLA / UC / Service Hours / Support Hours : définitions (ITIL v3 Glossary — 30 May 2007).
    https://hci-itil.com/ITIL_v3/docs/ITILV3_Glossary_English_v1_2007_0.pdf
  3. Métriques MTTD/MTTR (définitions) : NIST SP 800‑55 Vol. 1 (publication).
    https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=958991
  4. Accès distants (guide) : NIST SP 800‑46 Rev. 2 — Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security.
    https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-46r2.pdf
  5. Service credits : exemple de mécanisme de crédits de service dans un SLA (AWS).
    https://aws.amazon.com/compute/sla
15Jan

Hôtel : partager ses contenus sur la TV sans accéder aux autres chambres

by Domocasa
Hôtellerie Réseaux et Wi-Fi TV et Affichage digital

Illustration générée par IA — visuel conceptuel.

Dans un hôtel, le casting est un service client de plus en plus attendu : le voyageur veut retrouver ses contenus sur la TV de sa chambre, sans passer par des logins sur un appareil partagé. Côté exploitation, l’objectif est tout aussi clair : aucun client ne doit pouvoir découvrir (ni caster vers) la TV d’une autre chambre.

Le problème récurrent vient d’un malentendu d’architecture : la “découverte” (device discovery) et la “segmentation” (isolation réseau) ne suivent pas les mêmes règles. En pratique, on segmentera très volontiers avec des VLAN et des SSID, puis on s’étonnera que le casting ne fonctionne plus… ou, à l’inverse, on ouvrira trop large et on créera un risque de cross-room.

Ce guide propose une lecture agnostique des marques : principes mDNS/Bonjour, architectures possibles, et recette (tests) à exiger avant déploiement.

Le vrai sujet : “découverte” ≠ “segmentation”

Dans la plupart des environnements hôteliers, on veut simultanément :

  • Segmenter les clients entre eux (confidentialité et sécurité), et isoler les réseaux métiers (PMS, GRMS, CCTV, VoIP, administration) du réseau invité.
  • Autoriser localement une interaction très spécifique : le smartphone du client doit trouver et joindre uniquement le receiver de sa chambre (TV, dongle, set-top box, solution intégrée Hospitality TV).

Or la découverte AirPlay et une grande partie des implémentations “Cast” reposent sur des mécanismes de type mDNS/DNS‑SD (Bonjour). Ces annonces sont, par conception, locales au segment réseau : c’est utile à la maison, mais en hôtel cela se heurte immédiatement aux frontières L3 (VLAN) et aux politiques d’isolation Wi‑Fi.

Rappel technique : pourquoi mDNS se “casse” dès qu’on segmente

mDNS/Bonjour : conçu pour le local

mDNS (Multicast DNS) est conçu pour une découverte link‑local. Concrètement, un terminal envoie typiquement ses requêtes mDNS vers 224.0.0.251:5353 (IPv4) et FF02::FB:5353 (IPv6) (RFC 6762).

Conséquence opérationnelle : ce trafic n’est pas destiné à être routé entre sous-réseaux. En pratique, la plage multicast 224.0.0.0/24 (où se trouve 224.0.0.251) correspond à du Local Network Control ; l’IANA indique que les routeurs multicast ne doivent pas forwarder des datagrammes à destination de ce bloc, regardless of its TTL. Donc, dès que vous traversez une frontière L3 (souvent un VLAN), la découverte ne “passe” plus comme à la maison — et le bon réflexe devient de concevoir une passerelle/proxy mDNS (avec filtrage), plutôt que d’espérer “router le multicast”.

AirPlay : plusieurs méthodes de découverte (Bonjour, BTLE, peer-to-peer)

Apple précise qu’un appareil peut découvrir un Apple TV par Bonjour, par advertisement d’adresse IP via Bluetooth Low Energy, ou via une découverte peer-to-peer (AirPlay). Les appareils préfèrent le peer-to-peer, mais peuvent établir la connexion via la méthode jugée la plus “responsive” ou la plus récemment utilisée.

Dans le cas de la découverte Bonjour (mDNS), Apple rappelle aussi le point clé côté réseau : Bonjour s’appuie sur du multicast et, comme le multicast n’est généralement pas routé entre sous-réseaux, ce mode requiert que les équipements soient sur le même sous-réseau IP pour une découverte simple. Sur des réseaux plus larges, Apple indique qu’une Bonjour gateway (ou technologie similaire) peut être utilisée ; et que les réseaux utilisant ce type de mécanisme pour AirPlay doivent annoncer _airplay._tcp et _raop._tcp, en précisant qu’AirPlay requiert une découverte “live” (et pas seulement une publicité DNS “avancée”).

Point de vigilance projet (hôtel) : les modes BTLE / peer‑to‑peer existent et peuvent faciliter certaines situations, mais ils sont à qualifier avec la politique IT/sécurité et l’architecture d’isolation retenue. Dans beaucoup de projets, on cherche au contraire un comportement prévisible et gouverné (découverte “par chambre” et remise à zéro en fin de séjour), ce qui amène souvent à privilégier une approche réseau (Bonjour/mDNS avec filtrage, ou gateway) recettée et documentée.

Chromecast / Cast : traiter la découverte comme un sujet mDNS (avant d’ouvrir des ports)

Sur le terrain, un réflexe utile consiste à séparer :

  • Découverte : “je vois le receiver dans la liste”.
  • Contrôle : “je sélectionne la TV, je lance la lecture”.
  • Média : “le flux audio/vidéo se lance et reste stable”.

Un blocage fréquent est au premier niveau : la découverte ne traverse pas une segmentation L3, ou elle est stoppée par une isolation Wi‑Fi. Côté Cast, on retrouve typiquement une requête mDNS sur un type de service du style _googlecast._tcp.local (voir la documentation Google Cast de dépannage découverte). Avant de multiplier des règles firewall, il faut donc valider le plan de découverte (et sa politique “par chambre”).

Trois architectures possibles (et leurs compromis)

Il n’existe pas une architecture universelle : tout dépend du niveau d’isolation attendu, de la capacité d’exploitation (maintenance), et de l’intégration TV retenue (IPTV, Hospitality TV, dongles, receivers intégrés).

Architecture A — Segment “par chambre” (VLAN / micro‑segmentation)

Principe : chaque chambre dispose de son propre segment IP, sur lequel cohabitent les terminaux du client et le receiver de la chambre.

  • Atout : la découverte et le casting deviennent souvent plus simples conceptuellement : on reste “local”.
  • Point d’attention : la charge d’exploitation augmente fortement : adressage, DHCP, supervision, troubleshooting, et cohérence de configuration sur un grand parc.

Cette approche est cohérente quand l’objectif d’isolation est très élevé et que le réseau est déjà fortement industrialisé (automatisation, templates, exploitation outillée).

Architecture B — VLAN clients + VLAN TV, avec passerelle mDNS/Bonjour (souvent envisagée)

Principe :

  • Les clients restent sur un VLAN/SSID invité (ou un ensemble de VLAN invités).
  • Les TVs/receivers restent dans un VLAN dédié (TV/Rooms/AV).
  • Une passerelle mDNS (selon constructeurs : “Bonjour gateway”, “mDNS gateway”, “AirGroup”, etc. — exemples non exhaustifs) proxy/cache les annonces et les rend visibles de façon sélective entre segments.

Ce que vous cherchez à obtenir n’est pas “le multicast partout” : c’est une visibilité contrôlée. En hôtellerie, la question n’est donc pas seulement “comment traverser les VLAN”, mais surtout :

  • Comment associer un client à sa chambre (ou à une zone) ?
  • Comment publier uniquement le receiver pertinent (et pas toutes les TVs de l’étage) ?

À cadrer sans hypothèse de marque : pour AirPlay, Apple mentionne explicitement l’annonce des services _airplay._tcp et _raop._tcp lorsqu’une gateway Bonjour est utilisée. Pour Google Cast, la documentation de dépannage renvoie au service _googlecast._tcp.local côté découverte. Les flux de contrôle/média au-delà de la découverte doivent ensuite être établis sur la base des receivers réellement déployés (TV intégrée, dongle, set‑top box, etc.) et validés en recette.

Cette architecture s’intègre naturellement dans une conception plus large de réseau convergé (Wi‑Fi, IPTV, VoIP, CCTV, GRMS). Voir : Architecture réseau IP d’un hôtel.

Architecture C — Même VLAN, avec “client isolation” (à manier avec prudence)

Principe : on place clients et receivers dans le même VLAN, puis on active une isolation “client-to-client” sur le WLAN.

  • Atout : simplifie le routage (tout est “local”).
  • Risque : une isolation Wi‑Fi stricte bloque précisément ce que vous voulez autoriser (client → receiver), car le receiver est souvent vu comme “un autre client”. On finit alors par empiler des exceptions (allowlist) et l’ensemble devient difficile à maintenir.

Réserve importante : les fonctions d’isolation (périmètre, exceptions possibles, logique “same‑AP” vs “multi‑AP”, allowlists) varient fortement selon les plateformes Wi‑Fi et leurs versions. Dans un projet hôtelier, ce point doit être considéré comme à vérifier en recette, et non comme une hypothèse.

Cette approche peut fonctionner si vous maîtrisez très précisément les exceptions (et si le receiver n’est pas un client Wi‑Fi “classique” ou si sa politique est gérée nativement par la plateforme de casting/hospitality).

Concevoir une expérience “par chambre” : principes agnostiques

L’objectif, quel que soit le constructeur Wi‑Fi/TV, peut se résumer ainsi :

Un terminal client ne doit découvrir (mDNS) et joindre (contrôle/média) que le receiver de la chambre (ou du groupe de chambres) où il séjourne.

Pour y parvenir, on retrouve généralement trois leviers (souvent combinés) :

Approche “localisation réseau”

On déduit la chambre (ou la zone) à partir d’indices réseau : AP, étage, switchport, micro-segmentation, etc. C’est une méthode robuste quand l’infrastructure est bien documentée et stable (ce qui suppose un DOE réseau propre).

Approche “identité” (rôle / attributs / accès)

On associe l’accès du client à un rôle/identité exploitable par les politiques réseau (par exemple via les mécanismes d’authentification du Wi‑Fi invité). Attention : cela ne signifie pas “rendre le casting dépendant d’une usine à gaz”. Cela signifie définir un attribut exploitable pour filtrer la découverte.

Pour replacer ce sujet dans une stratégie globale de Wi‑Fi invité (parcours client, isolement, portail captif), voir : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client.

Approche “inventaire des receivers” (TV/receivers déclarés et gouvernés)

Dans un hôtel, on ne veut pas “découvrir tout ce qui diffuse”. Il faut une base propre des receivers autorisés, correctement nommés, et une politique qui évite les dérives (TV remplacée, dongle déplacé, receiver réinitialisé, etc.). C’est un sujet d’exploitation, pas seulement de réseau.

Recette (tests) : la checklist qui évite les mauvaises surprises

Avant d’équiper des étages entiers, recetez une zone pilote (ou une chambre témoin) avec une grille de tests. La logique est proche de la méthode “mock-up” que l’on applique déjà au GRMS et aux parcours client en chambre (voir : Chambre témoin hôtel).

Bloc à tester Test réalisable Ce que le test prouve (et ce qu’il ne prouve pas)
Découverte mDNS Depuis le smartphone, vérifier que la TV/receiver de la chambre apparaît rapidement et de façon stable (entrées/sorties de veille, redémarrage AP, redémarrage receiver). Prouve que le plan de découverte est opérationnel. Ne prouve pas que le flux média sera stable en charge.
Anti cross-room Depuis une chambre A : vérifier l’absence de visibilité des receivers des chambres B/C. Répéter depuis chambre B. Prouve que la politique “par chambre” fonctionne. Ne prouve pas que les exceptions réseau sont minimales (à auditer).
Isolation Wi‑Fi Activer l’isolation client et confirmer précisément ce qui est bloqué/autorisé (client ↔ receiver, client ↔ client, client ↔ gateway). Prouve le comportement réel (souvent différent des hypothèses). Ne remplace pas la validation d’une politique durable (éviter l’allowlist “infinie”).
Roaming Lancer un cast puis se déplacer dans la chambre, le couloir (selon le cas d’usage) et observer la continuité ou la reprise. Prouve la tolérance du service aux changements de cellule. Ne prouve pas la performance en simultanéité (à tester séparément).
Charge / simultanéité Organiser un test réaliste : plusieurs casts en parallèle sur une zone pilote, tout en gardant une navigation Internet “normale”. Prouve la tenue de l’architecture en conditions proches du réel. Ne remplace pas une supervision continue en exploitation.
Modes dégradés Simuler : perte d’un lien d’étage, redémarrage contrôleur Wi‑Fi, indisponibilité d’une passerelle mDNS (si utilisée), redémarrage de TV/receiver. Prouve ce que vivra l’exploitation lors d’un incident. Ne remplace pas un runbook clair (qui fait quoi, dans quel ordre).

Points d’attention : TV, casting et exploitation hôtelière

Ne pas confondre “TV connectée” et “Hospitality TV”

La capacité de remise à zéro (fin de séjour), le verrouillage des réglages, la gestion centralisée et l’exploitation quotidienne ne dépendent pas uniquement du réseau. Le choix de la TV (et de l’écosystème) doit être pensé avec la stratégie de casting et la confidentialité. Voir : Hospitality TV : différence avec une Smart TV classique.

IPTV, coaxial et casting : ne mélangez pas les sujets

Un casting “par chambre” ne nécessite pas forcément une migration IPTV complète : dans certains contextes, des établissements conservent le coaxial pour les chaînes linéaires tout en ajoutant un plan IP pour le casting. Le point dur reste souvent : réseau IP, segmentation, Wi‑Fi et politique mDNS. Pour l’arbitrage IPTV/coax : IPTV ou télédistribution coaxiale : quelle architecture pour un hôtel.

Le réseau invité doit rester un réseau “invité”, même si vous y autorisez du casting

Autoriser un casting contrôlé ne justifie pas d’ouvrir des flux inutiles vers des réseaux métiers ou techniques. La séparation VLAN/pare-feu et une gouvernance claire des flux restent indispensables (voir : Wi‑Fi invités et VLAN).

Conclusion : réussir le casting en hôtel, c’est “designer” la découverte

Pour permettre AirPlay/Chromecast en hôtel sans casser l’isolation des chambres, le point clé n’est pas de “choisir un VLAN”. Le point clé est de traiter la découverte mDNS/Bonjour comme un système : périmètre, politiques, association client ↔ chambre, et recette exploitable.

Vous envisagez une architecture de casting par chambre, ou vous corrigez un site où « le casting marche une fois sur deux » ? Nous pouvons vous aider à cadrer une matrice d’architecture (réseau/Wi‑Fi/TV) et une recette adaptée à votre établissement, en cohérence avec votre réseau IP hôtelier.

Références techniques (pour approfondir)

Copyright © 2025 Domocasa. All rights reserved.