Category "Hôtellerie"

14Sep

Piloter l’éclairage d’un hôtel : KNX direct, DALI‑2 local ou DALI‑2 relié à la GTB — comment choisir sans complexifier

by Domocasa
Énergie et CVC Hôtellerie Smart Building et GTB

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

Dans un hôtel, la vraie question n’est pas uniquement « KNX ou DALI ? ». C’est surtout : où place-t-on l’intelligence d’éclairage (scènes, horaires, modes ménage, dérogations), qui en porte la responsabilité (lot éclairage, lot GTB/automatisme, IT, exploitant), et comment cela se maintient au jour 2 (remplacements, extensions, diagnostic, migrations).

Ce guide compare trois architectures réalistes — KNX direct, DALI‑2 local, DALI‑2 relié à la GTB — avec un objectif clair : réduire le risque opérationnel (pannes, dépendances, responsabilités floues) sans sacrifier le confort client.

Ce que DALI‑2 standardise réellement (et pourquoi c’est important en exploitation)

Pour prendre une décision d’architecture, il faut clarifier ce que recouvre « DALI‑2 » côté exploitation.

DALI‑2 s’appuie sur un programme de certification (interopérabilité)

La DALI Alliance (DiiA) présente DALI‑2 comme une évolution structurée autour d’un programme de certification, avec des spécifications de tests dérivées de parties pertinentes de la norme IEC 62386 (et/ou de spécifications DiiA), et une logique de vérification dans le processus de certification. Pour une approche projet, l’idée centrale est simple : la maintenabilité multi‑marques ne se décrète pas, elle se contractualise et se vérifie.

La preuve opérationnelle passe par la base produits publique

Point très concret pour les CCTP et la réception : la DALI Alliance met à disposition une base produits publique pour identifier les références annoncées comme certifiées DALI‑2. En pratique, c’est un outil utile pour limiter les ambiguïtés « DALI compatible » / « DALI‑2 certifié » au moment des achats, des substitutions et des remplacements.

Attention au périmètre « certifiable » selon les parties

La DALI Alliance publie également un statut de certification indiquant que la certification DALI‑2 s’appuie sur des tests maintenus par la DiiA, dérivés de parties IEC 62386 et/ou de spécifications DiiA, et que la disponibilité des parties peut évoluer. Conséquence projet : quand vous spécifiez « DALI‑2 », évitez les formulations vagues et listez les familles d’équipements concernées (drivers, contrôleurs, capteurs/entrées, alimentations, passerelles si elles sont dans le périmètre du lot éclairage), puis exigez des preuves adaptées à chaque famille.

Les trois architectures d’éclairage les plus courantes en hôtellerie

Option A — « KNX direct » : l’intelligence d’éclairage portée par KNX

Principe : la logique d’éclairage (scènes, commandes, horaires, modes) est gérée dans l’écosystème KNX. Selon le design, l’éclairage peut être piloté par des actionneurs KNX (commutation/variation) ou via des interfaces KNX vers une couche « lighting ».

Ce que vous gagnez

  • Unification des usages côté chambre (éclairage, stores, états hôteliers, scénarios transverses), avec une logique cohérente si le projet est déjà fortement orienté KNX.
  • Un outillage d’intégration centralisé pour une grande partie des fonctions (au prix d’une discipline de documentation, sauvegardes et versioning).

Points de vigilance « jour 2 »

  • Dépendance forte au projet et à sa gouvernance : maintenabilité (accès, sauvegardes, cohérence des noms, gestion des modifications) devient un enjeu majeur.
  • Cybersécurité dès qu’il y a interconnexion IP : si des segments KNX sont exposés à un réseau IP externe (accès distant, backbone mutualisé, interconnexion avec la GTB, etc.), la KNX Association distingue KNX IP Secure et KNX Data Secure et documente le commissioning sécurisé via ETS. Ce sujet relève moins du « protocole » que de l’architecture réseau et des règles d’accès.

Quand c’est pertinent : établissements où l’exploitation est prête à assumer une gouvernance KNX solide (documentation, sauvegardes, accès, contrat de support), et où l’intégrateur a une méthode robuste de transfert « jour 2 ».

Option B — « DALI‑2 local » : l’intelligence au niveau éclairage (chambre, zone, étage)

Principe : l’éclairage fonctionne de manière autonome à l’échelle locale via des contrôleurs DALI‑2 (et des équipements DALI‑2 adaptés). La chambre (ou la zone) doit rester exploitable même si la GTB ou certaines couches IP sont indisponibles.

Ce que vous gagnez

  • Résilience fonctionnelle : un incident GTB, une indisponibilité réseau ou une maintenance serveur ne doit pas « éteindre l’expérience client » si la logique essentielle est locale.
  • Une chaîne de responsabilité plus lisible côté lot éclairage : on pilote d’abord l’éclairage par l’éclairage, avec un périmètre de mise en service et de diagnostic souvent plus simple à organiser.

Points de vigilance

  • Ne pas confondre “DALI” et “DALI‑2” dans les marchés : l’intérêt opérationnel (interopérabilité revendiquée) implique de spécifier et vérifier « DALI‑2 certifié » et pas seulement « DALI ».
  • Documenter la mise en service : adressage, groupes, scènes, remplacements attendus, et procédure de rétablissement après remplacement (qui fait quoi, avec quel outil, sur quel périmètre).

Quand c’est pertinent : hôtels qui veulent limiter l’effet de bord d’une GTB sur le confort, tout en gardant une approche “terrain” claire et maintenable.

Option C — « DALI‑2 + GTB » : DALI‑2 terrain + supervision/coordination GTB

Principe : DALI‑2 reste le bus « terrain » (drivers, capteurs, contrôleurs), et la GTB (ou un GRMS/plateforme d’exploitation) se connecte via une passerelle/serveur d’intégration pour la supervision, des modes globaux, des alarmes et parfois des tableaux de bord exploitation.

Ce que vous gagnez

  • Une séparation utile entre “fonctionnement local” et “fonctions de supervision” : l’éclairage reste opérationnel localement, tandis que la GTB apporte visibilité et coordination.
  • Un levier exploitation multi‑bâtiments : supervision, homogénéisation des alarmes, consolidation, et stratégies de maintenance si l’organisation le justifie.

Le vrai point de risque : la passerelle et la frontière de responsabilité

La passerelle n’est pas un détail « technique » : elle fixe la frontière contractuelle et donc votre capacité à diagnostiquer sans renvoi de responsabilité. En cas d’incident (scènes inactives, commandes inopérantes, retours incohérents), l’exploitation doit pouvoir isoler rapidement si la cause est : terrain DALI, contrôleur local, passerelle, GTB, réseau IP, règles d’automatisation, ou droits utilisateurs.

Quand c’est pertinent : projets où la direction technique veut une supervision centralisée (KPI, alarmes, exploitation multi‑sites) sans rendre la chambre dépendante d’un serveur ou d’un réseau.

Comment choisir sans complexifier : raisonner “exploitation” avant “protocole”

Au lieu d’empiler des arguments techniques, partez de quelques décisions d’exploitation. Ce sont elles qui déterminent ensuite l’architecture.

Question 1 — Que doit rester fonctionnel en cas de panne GTB ou réseau ?

  • Si l’objectif est « la chambre doit rester utilisable (boutons, scènes, logique essentielle) même en panne GTB/IP », privilégiez une logique locale (DALI‑2 local, ou DALI‑2 + GTB avec autonomie clairement définie).
  • Si vous acceptez qu’une couche centrale soit critique, l’approche « KNX direct » peut convenir, à condition d’anticiper gouvernance, continuité et support.

Question 2 — Qui maintient quoi au jour 2 ? (RACI par couches)

Les projets hôteliers souffrent rarement d’un “mauvais protocole” ; ils souffrent surtout d’un RACI implicite. Une structure simple (à adapter à votre organisation) consiste à distinguer :

  • Lot éclairage : conformité des équipements, mise en service terrain, scènes locales, documentation et procédures de remplacement.
  • Lot GTB/GRMS : supervision, historisation, synoptiques, alarmes, gestion des droits, exploitation à distance.
  • Interface (passerelle/serveur d’intégration) : fourniture, versions logicielles, sauvegarde/restauration, mapping (points, libellés, états), tests d’intégration et diagnostic.
  • IT / réseau : segmentation, règles firewall, accès distants, supervision réseau, politiques de mots de passe et comptes.

À l’écrit, ce découpage est souvent plus protecteur qu’un long comparatif “protocolaire”.

Question 3 — Comment allez-vous prouver l’interopérabilité en réception ?

Si votre promesse projet est « remplaçable et multi‑marques », la réception ne peut pas se limiter à “ça s’allume”. Il faut des preuves adaptées à l’objectif. Une approche pragmatique côté DALI‑2 consiste à :

  • Spécifier “DALI‑2 certifié” (et pas seulement “compatible”).
  • Vérifier les références via la base produits publique de la DALI Alliance.
  • Tester des scénarios d’exploitation (modes chambre, ménage, DND/MUR si applicable, comportements en mode dégradé), idéalement en zone témoin.

Pour aller plus loin sur la méthode de tests terrain, voir notre guide : Réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité.

Recommandation de projet (à adapter) pour limiter les surprises “jour 2”

Chaque hôtel a ses contraintes, mais si votre priorité est d’éviter les dépendances cachées tout en gardant une supervision exploitable, une approche souvent saine consiste à viser :

  • DALI‑2 local pour la logique essentielle d’éclairage (fonctionnement autonome par chambre/zone/étage),
  • + un raccordement à la GTB pour la supervision, les alarmes et certains modes globaux,
  • avec une frontière claire entre ce qui est indispensable au confort client (local) et ce qui relève de l’optimisation/reporting (central).

Cette recommandation n’est pas une règle universelle : elle doit être confirmée par vos contraintes de lotissement, votre organisation maintenance, et votre stratégie de support (interne/contrat).

Ce qu’il faut “mettre noir sur blanc” dans le CCTP / marché

Exiger et prouver « DALI‑2 certifié » (si DALI‑2 est retenu)

  • Exigence : préciser les familles d’équipements soumises à l’exigence DALI‑2 (drivers, contrôleurs, capteurs/entrées, alimentations, etc.) selon votre architecture.
  • Preuve attendue : validation des références via les ressources publiques de la DALI Alliance.
  • Substitutions : exiger que toute substitution conserve le même niveau de revendication (certification) et qu’elle soit testée en zone témoin avant déploiement.

Définir l’état minimal en mode dégradé

Écrivez explicitement ce que l’hôtel considère comme « service minimum » :

  • Que doit-il se passer si la GTB est indisponible ?
  • Que doit-il se passer si la passerelle d’intégration est indisponible ?
  • Que doit-il se passer si la supervision est coupée (maintenance serveur) ?

Ce point, très “exploitation”, évite une architecture sur‑optimisée mais fragile.

Verrouiller les livrables “jour 2” (DOE d’exploitation, pas seulement plans)

Quel que soit le choix KNX/DALI/GTB, la maintenabilité dépend des livrables concrets : nomenclature des zones, logique des scènes, sauvegardes, versions, procédures de remplacement, et méthode de diagnostic. Sur ce sujet, voir : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?

Traiter cybersécurité et réseau comme une contrainte d’architecture

Dès qu’une architecture implique des échanges IP (GTB, supervision, accès distant, interconnexions), la segmentation réseau, les droits et la traçabilité deviennent un sujet projet à part entière. Pour cadrer ces dépendances, vous pouvez compléter avec :

Conclusion

Décider entre KNX direct, DALI‑2 local ou DALI‑2 relié à la GTB n’est pas un débat de protocole : c’est une décision d’architecture d’exploitation. La meilleure option est celle qui rend explicites :

  • où vit la logique indispensable au confort client,
  • comment vous prouvez l’interopérabilité à la réception,
  • comment vous remplacez et étendez au jour 2,
  • et comment vous répartissez les responsabilités entre lots.

Si vous souhaitez cadrer cette décision dès la phase conception (schémas d’architecture, RACI, exigences de réception et livrables), l’équipe Domocasa peut vous accompagner de manière neutre, orientée exploitation.

Sources et documentation (références publiques)

10Sep

D4i (DALI‑2) en hôtellerie : quelles données luminaires sont réellement exploitables pour la maintenance et l’énergie ?

by Domocasa
Énergie et CVC Guides techniques Hôtellerie

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

D4i en hôtellerie : partir des “données luminaire”, sans sur‑promettre

Dans un hôtel, l’éclairage est partout (chambres, circulations, restaurants, back‑of‑house). Pourtant, la vraie difficulté commence souvent après la réception de chantier : inventorier ce qui a été réellement posé, remplacer vite ce qui tombe en panne, documenter les variantes (optique, température de couleur, finitions), et comprendre les dérives (surconsommation, défauts récurrents, erreurs de paramétrage).

D4i (DALI for IoT) est parfois présenté comme une brique “IoT‑ready”. C’est utile… à condition de bien distinguer :

  • ce que la certification D4i garantit côté luminaire/driver (présence de certaines capacités de données et d’alimentation),
  • ce qui dépend du système (collecte, passerelles, supervision/GTB/GRMS, historisation, alertes, ticketing, exports, cybersécurité).

Ce guide traduit D4i en exigences d’exploitation “jour 2” réellement actionnables en hôtellerie : diagnostic, inventaire et énergie — et encadre clairement les limites, notamment sur la “maintenance prédictive”.

Comprendre D4i : ce que c’est (et ce que ce n’est pas)

D4i = une extension de la certification DALI‑2

La DALI Alliance présente D4i comme une extension du programme de certification DALI‑2, orientée “luminaire connecté”, avec un socle d’exigences obligatoires (dont les smart data).

Traduction opérationnelle côté maîtrise d’ouvrage / exploitation hôtelière :

  • DALI‑2 vise l’interopérabilité de produits certifiés, mais certaines capacités de “data” peuvent être optionnelles selon les équipements.
  • D4i impose un socle minimal de données côté driver, ce qui facilite l’inventaire et le diagnostic si la collecte est prévue.

Pour clarifier le vocabulaire (DALI‑2 / D4i / DALI+), vous pouvez aussi lire : différences entre DALI‑2, D4i et DALI+.

D4i facilite l’intégration sur luminaire… mais ne remplace pas la supervision

D4i aide à standardiser l’intégration de “devices” sur ou dans le luminaire (capteurs, interface de communication), notamment via des exigences d’alimentation et de comportement. Mais D4i ne dit pas, à lui seul :

  • quel protocole bâtiment ou quelle interface vous utiliserez (GTB, GRMS, supervision),
  • comment les alertes seront définies, acquittées et historisées,
  • comment vous transformerez un défaut en ticket GMAO, en intervention et en preuve de résolution.

En pratique : D4i normalise des données “au plus près du luminaire”. La valeur en exploitation dépend de l’architecture de collecte et de supervision.

Quelles données D4i sont réellement exploitables ?

Le point clé, côté exploitation : D4i rend obligatoires des familles de données normalisées dans le driver, issues des spécifications DALI Data :

  • Luminaire Data : informations “asset” (identité, caractéristiques),
  • Energy Data : énergie/puissance (selon ce que le driver implémente),
  • Diagnostics Data : compteurs et états utiles au dépannage.

Attention : les pages de synthèse indiquent aussi que certains champs restent optionnels selon la spécification détaillée et le produit. Cela doit être cadré dans votre consultation si vous visez un usage précis (inventaire, indicateurs énergie, règles d’alerting).

Famille de données (DALI Data) À quoi ça sert en hôtellerie Limites à cadrer (projet / supervision / marché)
Luminaire Data (Part 251)
  • inventaire “as‑built” fiable (variantes, références),
  • DOE numérique plus maintenable,
  • standardisation multi‑sites (chaîne hôtelière).
  • les champs peuvent être supportés mais mal renseignés : exiger un encodage réel,
  • prévoir une méthode d’export exploitable (et répétable).
Energy Data (Part 252)
  • indicateurs énergie par zone/groupe,
  • détection de dérives (usage atypique),
  • corrélation avec occupation/horaire (si données disponibles côté hôtel).
  • ne pas confondre avec du comptage “réglementaire” : usage exploitation,
  • qualité, granularité, et exploitation dépendent de l’historisation et des règles côté système.
Diagnostics Data (Part 253)
  • déclenchement d’alertes avant plainte client (défauts explicites),
  • aide au diagnostic (driver vs source vs module),
  • maintenance basée sur compteurs simples (heures, démarrages) sans promettre de prédiction.
  • tous les champs ne sont pas forcément présents selon produits : lister vos besoins,
  • le ticketing/GMAO reste un lot système (et non une “fonction D4i”).

Part 251 (Luminaire Data) : l’inventaire “as‑built” au niveau luminaire

Cette famille regroupe des informations utiles à l’asset management. Les exemples cités par la DALI Alliance incluent notamment des caractéristiques luminaire (ex. informations de flux, CCT/CRI, etc.).

Ce que vous pouvez raisonnablement exiger en hôtellerie :

  • des champs réellement renseignés (pas seulement “supportés”),
  • une convention de nommage/variantes (même référence commerciale, optiques ou températures de couleur différentes),
  • une méthode de lecture/export intégrable au DOE (CSV/JSON, ou export supervision).

Pour replacer ces exigences dans une logique DOE, voir aussi : DOE et maintenance d’un hôtel connecté : que faut‑il remettre à l’exploitant ?

Part 252 (Energy Data) : utile pour piloter, comparer, détecter

La DALI Alliance cite des catégories telles que active energy/power, apparent energy/power et load‑side energy/power, en précisant que certaines informations sont optionnelles selon les spécifications détaillées.

Ce que ça change (si vous historisez) :

  • suivi énergie par zones (étage, aile, restaurant, BOH),
  • comparaison entre zones “équivalentes” (détection de dérives),
  • dialogue plus factuel entre maintenance, exploitation et direction (sans sur‑ingénierie).

Point de vigilance : D4i porte sur la capacité à reporter des données. La valeur dépend ensuite de votre collecte, de votre fréquence d’échantillonnage, de votre historisation, et des règles d’analyse retenues (supervision/GTB/BI).

Part 253 (Diagnostics & Maintenance) : le diagnostic devient industrialisable

La DALI Alliance indique que des informations de diagnostic peuvent inclure des conditions de défaillance et des compteurs (ex. temps de fonctionnement, compteur de démarrages, informations électriques/thermiques), tout en précisant que certaines informations sont optionnelles selon la spécification détaillée.

Usages hôtellerie :

  • déclencher des tickets sur des défauts explicites (et non sur une simple baisse “ressentie”),
  • orienter l’intervention (quoi remplacer, où, avec quelle variante),
  • mettre en place des règles simples de maintenance (par seuils ou tendances) sans appeler cela “prédictif”.

Les prérequis D4i qui comptent pour le “jour 2”

Côté drivers : données obligatoires, et exigences d’alimentation

La DALI Alliance indique que, pour les drivers D4i, les Parts DALI Data 251/252/253 deviennent obligatoires. Elle indique également, côté alimentation, une exigence obligatoire autour de Part 250 (Integrated Bus Power Supply), tandis que Part 150 (AUX Power Supply) est présentée comme optionnelle sur la page de synthèse D4i.

Interprétation “marché hôtel” : si vous prévoyez d’ajouter des devices sur luminaire (capteurs, communication), vous devez vérifier dès la conception quel mode d’alimentation est retenu (bus / auxiliaire), et surtout s’il est compatible avec les devices choisis et leur intégration système.

Côté “control devices” montés luminaire : ce que cela implique pour la collecte

La DALI Alliance indique aussi qu’un “control device” D4i (monté dans ou sur le luminaire) relève d’exigences dédiées (notamment Part 351), avec des classes/types, des contraintes de consommation et un mécanisme de priorité.

Le piège courant : acheter “D4i” comme une propriété du luminaire, sans spécifier le chemin complet jusqu’à la supervision. Résultat : des données existent dans les drivers, mais aucune collecte centralisée n’est réellement mise en service, ou l’export n’est pas exploitable.

À traduire en exigences :

  • décrire l’architecture cible de collecte (contrôleurs, passerelles, supervision),
  • décrire l’export attendu (inventaire + diagnostic + énergie),
  • décrire le scénario d’exploitation (alertes, acquittement, ticket, preuves).

La base produits DiiA : un garde‑fou achats et réception

La DALI Alliance indique que les produits D4i certifiés sont listés dans la Product Database, et que des produits non listés ne doivent pas être considérés comme certifiés D4i (la compatibilité fonctionnelle, elle, se vérifie au cas par cas).

Elle précise aussi que la validité de la certification est liée à une identité produit (marque, GTIN, versions firmware/hardware, ID), et que ces informations peuvent être lues depuis une memory bank (voir DALI Alliance — Product Database).

Point crucial : “D4i” n’est pas une promesse uniforme, c’est une vérification de références et versions

En hôtellerie (notamment en rénovation et en multi‑sites), c’est un point clé pour limiter les surprises :

  • un produit “proche” d’un modèle certifié n’est pas un produit certifié,
  • une version firmware/hardware différente peut changer le comportement réel (interopérabilité, données réellement exposées, bugs, etc.),
  • la preuve doit pouvoir se relier à la base, et à l’identification produit en réception.

Attention utile en consultation : les luminaires ne sont pas “certifiés D4i” au sens strict

La DALI Alliance indique que la certification des luminaires n’est pas offerte, tout en autorisant l’usage de la marque D4i sur des luminaires qui respectent des exigences de marque et d’usage. Conséquence côté projet : si un luminaire est présenté comme “D4i”, sécurisez la traçabilité en demandant les références exactes (drivers et, le cas échéant, control devices) et leur présence dans la Product Database.

Transformer D4i en exigences d’exploitation (hôtellerie)

Ci‑dessous, une grille d’exigences typiques orientées “jour 2”, à adapter selon votre périmètre (neuf/rénovation, chambres vs espaces publics, intégration GRMS/GTB, niveau de supervision attendu).

Exigences “inventaire & DOE exploitable”

  • Références vérifiables : exiger que les composants annoncés (drivers / control devices) soient vérifiables dans la base produits DiiA, avec une correspondance claire sur les versions.
  • Encodage réel de Luminaire Data : exiger non seulement la compatibilité, mais l’encodage effectif des champs utiles à votre exploitation (variantes, caractéristiques, identification).
  • Export de réception : exiger un export structuré reliant : localisation (zone/pièce), adresse/identité logique, identifiants produits (selon ce qui est disponible), et données utiles au DOE.

Pour une approche “exigences de données” formalisées et vérifiables, voir : exiger (et vérifier) les bonnes données à la livraison avec buildingSMART IDS.

Exigences “diagnostic & maintenance”

  • Lecture & historisation : préciser quelles données seront lues, à quelle fréquence, où elles sont historisées (supervision, GTB, outil tiers) et comment elles s’exportent.
  • Règles d’alerting : définir les événements qui déclenchent une alerte exploitable (et éviter les alertes non actionnables).
  • Ticketing : définir qui reçoit quoi, comment l’équipe acquitte, et comment la preuve de correction est conservée (processus, pas seulement technologie).

Exigences “énergie” (sans confusion comptage/contrôle)

  • Périmètre clair : énergie d’éclairage pour pilotage et comparaison (exploitation), pas une promesse de comptage certifié.
  • Indicateurs réalistes : tendances, comparaisons et alertes (zone qui dérive), plutôt que promesse d’optimisation automatique.

Recette de réception : ne pas confondre “compatible” et “exploitable”

En hôtellerie, une recette est souvent ce qui transforme une option technique en résultat réel. Pour cadrer l’interopérabilité et éviter les incompatibilités, voir : réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité.

Maintenance “prédictive” : ce que D4i aide à faire… et ce qu’il ne garantit pas

La DALI Alliance cite des cas d’usage possibles (monitoring, asset management, predictive maintenance…) ; en projet, il faut lire cela comme des potentialités rendues possibles par la disponibilité de données et par l’intégration de devices — pas comme une fonction automatiquement livrée par le simple fait d’acheter “D4i”.

Ce que D4i apporte concrètement

  • un socle de données structurées (inventaire, énergie, diagnostic) au niveau driver,
  • un cadre d’intégration pour devices montés luminaire,
  • une base plus solide pour standardiser des exigences multi‑marques.

Ce qu’il faut en plus pour parler de “prédiction”

  • des historiques propres et exploitables (durée, continuité, qualité),
  • des règles (seuils/tendances) ou des modèles (statistique/ML) dont les limites sont connues,
  • une intégration GMAO (tickets, stocks, SLA) et un process d’exploitation robuste,
  • un cadrage clair des responsabilités (qui corrige quoi, dans quel délai, avec quelle preuve).

Recommandation de cadrage : contractualisez d’abord un périmètre “diagnostic + inventaire + énergie” réellement livrable, puis traitez la prédiction comme un lot optionnel, conditionné par la qualité des données effectivement collectées.

Méthode simple avant d’acheter “D4i” pour un hôtel

  1. Valider les références : vérifier dans la base produits DiiA les composants annoncés (drivers, control devices) et leurs identités/versions.
  2. Demander un export type : exiger un exemple d’export d’inventaire et de diagnostic (format, champs, cohérence) sur une zone pilote.
  3. Tester sur zone témoin : une zone représentative (chambre, couloir, espace public) avec vos scénarios d’exploitation (alertes, acquittement, export, ticket).
  4. Écrire noir sur blanc ce qui doit être “renseigné” (Luminaire Data) et ce qui doit être “collecté + historisé + exportable” (Energy/Diagnostics).

Conclusion

D4i est particulièrement intéressant en hôtellerie quand on l’utilise comme un outil de fiabilisation du “jour 2” : inventaire, diagnostic, lecture énergie. La certification donne un socle (données normalisées et exigences d’intégration) — mais la valeur dépend de votre capacité à spécifier les champs attendus, vérifier les références/versions dans la base produits, et industrialiser la collecte et le ticketing.

Si vous souhaitez cadrer un lot éclairage “exploitable” (marché, recette, DOE, supervision), Domocasa peut vous aider à transformer ces principes en exigences projet, adaptées à votre architecture (GRMS/GTB/supervision) et à vos contraintes d’exploitation.

Sources et documentation

7Sep

Rénover un éclairage DALI en hôtel : ce qui change avec DALI‑2 et comment migrer sans mauvaises surprises

by Domocasa
Énergie et CVC Guides techniques Hôtellerie

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

En rénovation hôtelière, l’éclairage est rarement un “lot isolé”. On cherche souvent à étendre (quelques chambres, un étage, un restaurant), à remplacer progressivement des luminaires/drivers, et à ajouter des capteurs — sans immobiliser l’exploitation. Dans ce contexte, la question “DALI vs DALI‑2” revient vite, surtout lorsqu’on doit faire cohabiter un existant hétérogène et des équipements neufs annoncés “interopérables”.

Ce guide propose une méthode de décision (conserver / migrer / segmenter) et une checklist chantier pour éviter les mauvaises surprises : contrôleurs, capteurs, alimentation bus, topologie, adressage, recette en zone témoin. Les points normatifs (IEC 62386) sont cités comme limites et références : la compatibilité réelle reste toujours “produit + version + mise en service”.

Bien nommer ce que vous avez (pour éviter les malentendus)

DALI (le protocole)

DALI (Digital Addressable Lighting Interface) est un protocole standardisé de communication numérique bidirectionnelle pour le contrôle d’éclairage, structuré par la norme internationale IEC 62386 (multi‑parties) et complété par des spécifications et un programme de certification portés par la DALI Alliance (DiiA). Pour un rappel “fonctionnement” orienté exploitation, vous pouvez aussi lire : DALI : comment fonctionne l’éclairage professionnel intelligent ?

« DALI version‑1 » (souvent appelé “DALI‑1” sur le terrain)

La DALI Alliance décrit DALI version‑1 comme une version plus ancienne du protocole qui, historiquement, couvrait principalement les control gear (drivers/ballasts), et ne définissait pas de la même manière (ou pas du tout, selon les cas) un cadre complet et testable pour les control devices (contrôleurs d’application, capteurs, boutons…) ainsi que certains éléments d’écosystème (dont l’alimentation de bus) dans l’approche “version‑1”. Référence : DALI Alliance — DALI / DALI‑2 comparison.

DALI‑2 (à comprendre comme un “cadre + tests”, pas comme un slogan)

DALI‑2 est présenté par la DALI Alliance comme un programme de certification s’appuyant sur la version la plus récente du protocole, visant une meilleure interopérabilité multi‑fabricants grâce à des procédures de tests plus détaillées et une vérification des résultats. Référence : DALI Alliance — DALI / DALI‑2 comparison. Pour clarifier les termes associés (DALI‑2, D4i, DALI+), voir aussi : DALI‑2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?

Ce qui change avec DALI‑2 (et pourquoi c’est critique en rénovation d’hôtel)

Interopérabilité : le changement se voit surtout côté “contrôle”

En rénovation, il est fréquent de trouver des drivers “DALI” qui semblent se comporter correctement, mais un contrôle plus fragile ou plus “à la marque” dès qu’on ajoute des capteurs, des boutons, des scénarios, ou des passerelles. La DALI Alliance met justement en avant que DALI‑2 élargit le périmètre et vise une interopérabilité multi‑fabricants améliorée via la certification (tests détaillés et résultats vérifiés). Référence : DALI / DALI‑2 comparison.

Révision IEC 62386 (2014) : amélioration de l’interopérabilité et rétrocompatibilité

Un point important pour décider “conserver vs migrer” : la DALI Alliance documente qu’une révision majeure d’IEC 62386 (en 2014) a eu pour objectifs d’améliorer l’interopérabilité, combler des lacunes et standardiser des control devices, tout en maintenant la compatibilité ascendante (backwards compatibility). Référence : DiiA — Changes to IEC 62386 enabling DALI‑2 (PDF).

À traduire en langage chantier : “rétrocompatible” ne veut pas dire “tout marchera en mélangeant n’importe quoi”. Cela signifie plutôt que l’évolution du standard a été pensée pour ne pas casser le parc au niveau protocolaire, tout en ajoutant des clarifications (timings, comportements attendus, cas limites) susceptibles d’exposer des équipements historiquement “tolérants” mais non stricts.

Capteurs DALI‑2 : des “Parts” dédiées et certifiables

La DALI Alliance indique que des input devices (ex. boutons, capteurs) sont spécifiés par des parties dédiées (notamment Parties 301 à 304 selon les familles de dispositifs) et que la certification DALI‑2 peut s’appliquer à des produits implémentant une ou plusieurs de ces parties. Référence : DALI Alliance — Sensors et, pour la vue “statut/parts”, DALI‑2 status.

Méthode de décision (rénovation/extension) : conserver, migrer, ou segmenter

La bonne stratégie dépend rarement d’un choix “religieux” DALI vs DALI‑2. Elle dépend de ce que vous changez réellement et de ce que vous devez garantir en exploitation (continuité de service, maintenabilité, multi‑marques, remplacements au fil de l’eau).

Cas A — Vous remplacez surtout des luminaires/drivers, sans ajouter de capteurs ni logique avancée

Vous pouvez souvent conserver l’existant si le contrôleur reste en place et si vous verrouillez les risques “bus” (alimentation, câblage, distances, adressage). Cela correspond à des rénovations “à l’identique amélioré” (par exemple remplacement de luminaires en chambres, sans refonte de la logique).

Points à sécuriser systématiquement (référence : DALI Quick Start Guide (PDF)) :

  • Alimentation du bus : le bus DALI doit être alimenté pour communiquer (le guide décrit une tension typique de bus), avec des alimentations pouvant aller jusqu’à une limite de courant indiquée.
  • Budget courant : l’alimentation doit couvrir la consommation cumulée des équipements présents sur le bus.
  • Topologie et distances : le guide décrit un bus 2 fils, des topologies possibles (chaîne/étoile/mix), l’interdiction d’une boucle fermée, et donne des recommandations de câble et de distance maximale “entre les deux appareils les plus éloignés”.

Décision pratique : si vous gardez le même contrôleur et que vous ne changez pas le “système de contrôle” (capteurs/logiciels/scènes), concentrez l’effort sur la stabilité électrique et topologique du bus, puis sur la recette fonctionnelle minimale (variation, scènes, retours d’état utiles).

Cas B — Vous voulez ajouter/standardiser des capteurs et des contrôleurs en multi‑marques

La migration vers DALI‑2 devient généralement l’option la plus maîtrisable, parce que DALI‑2 encadre (et cherche à certifier) des control devices (capteurs, boutons, contrôleurs), alors que DALI version‑1 ne les couvrait pas dans le même cadre. Référence : DALI / DALI‑2 comparison.

En hôtellerie, ce cas arrive typiquement lors de :

  • rénovation chambre par chambre (ajout d’occupation, scénarios ménage/DND/MUR selon l’architecture),
  • rénovation des circulations (présence + asservissement),
  • standardisation maintenance (remplacements plus simples, moins de dépendances “propriétaires”).

Conseil de méthode : traitez le sujet comme une chaîne “capteurs → contrôleur → gear”, pas comme une simple compatibilité de drivers.

Cas C — Vous étendez l’installation et vous devez faire cohabiter “ancien + neuf”

L’approche la plus pragmatique, surtout quand l’hôtel ne peut pas s’arrêter, consiste à :

  1. Conserver temporairement un segment existant (pour limiter l’impact sur l’exploitation),
  2. déployer un segment rénové “propre” (souvent en DALI‑2 sur la partie contrôleurs/capteurs),
  3. planifier un raccordement/une convergence seulement après validation en zone pilote.

Attention : l’extension “au fil de l’eau” force parfois la segmentation (plusieurs bus, plusieurs contrôleurs, passerelles). Le DALI Quick Start Guide rappelle notamment une capacité d’adressage par bus (distinguant gear et control devices), qui devient vite un point bloquant quand on ajoute des capteurs et des boutons bus‑powered.

Les pièges les plus fréquents au chantier (et comment les éviter)

Confondre “compatible DALI” et “interopérable”

La DALI Alliance oppose explicitement l’ambition d’interopérabilité de DALI‑2 (tests plus complets, résultats vérifiés) et les limites historiques d’une approche “version‑1” au périmètre plus restreint. Référence : DALI / DALI‑2 comparison.

Action projet (recommandation) : sur les nouveaux lots (contrôleurs, capteurs, alimentations de bus, passerelles), exigez des références identifiables et vérifiables, et surtout prévoyez une recette en zone pilote. Sur ce point, vous pouvez compléter avec notre article orienté réception : Réception d’un éclairage DALI‑2 en hôtel : vérifier l’interopérabilité.

Sous‑dimensionner (ou mal gérer) l’alimentation de bus

Le dimensionnement et la configuration de l’alimentation de bus sont des causes classiques de comportements instables (détection intermittente, pertes de commandes, commissioning difficile). Le DALI Quick Start Guide fournit des ordres de grandeur et des limites (tension typique, courant maximal par bus, recommandations de mise en œuvre).

  • Comptez les équipements et leur consommation bus (y compris capteurs/boutons alimentés par le bus).
  • Vérifiez qu’il n’y a pas de “sur‑ajout” d’alimentations en parallèle lors de remplacements partiels (réutilisation + ajout sans re‑cadrage).
  • Anticipez qu’un remplacement “fonctionnel” peut changer la consommation bus (par exemple ajout d’input devices bus‑powered).

Topologie : étoile/chaîne possibles, boucle fermée à éviter

En rénovation, une boucle fermée apparaît vite (reprises, dérivations, raccordements non documentés). Le guide DALI décrit des topologies possibles et indique d’éviter la boucle fermée. Référence : DALI Quick Start Guide.

Action projet : exigez un as built (plan “tel que construit”) du bus et prévoyez un contrôle avant réception (instrumentation / testeur / validation par l’intégrateur selon l’outillage disponible).

Distances : l’écart “entre extrêmes” compte en étoile

Le guide DALI donne une recommandation de distance maximale entre les deux appareils les plus éloignés, sous hypothèses (section câble / courant d’alimentation). Référence : DALI Quick Start Guide.

À retenir : en hôtel, une distribution en étoile depuis une gaine technique peut avoir beaucoup de câble “au total” tout en respectant la contrainte “entre extrêmes”. Ce n’est pas intuitif, donc cela mérite un contrôle explicite sur plan.

Adressage : l’extension peut saturer “en silence”

Le DALI Quick Start Guide rappelle une capacité d’adresses par bus, en distinguant gear et control devices. En rénovation/extension, l’ajout de capteurs et de boutons peut faire exploser le besoin d’adresses plus vite que prévu.

  • Faites un inventaire d’adresses (ce qui existe réellement, pas seulement ce qui est sur plan).
  • Réservez une marge pour les phases futures et les pièces de rechange.
  • Si nécessaire, segmentez (plusieurs bus) plutôt que “forcer” l’ajout sur un bus déjà dense.

Checklist de migration DALI “historique” → DALI‑2 (spécial rénovation hôtelière)

Audit terrain (avant de lancer les commandes)

  1. Cartographier les bus (zones, longueurs, topologies, points de dérivation).
  2. Inventorier : alimentations de bus, contrôleurs, capteurs/boutons, drivers (marque/modèle/référence).
  3. Relever : adressage réellement utilisé (gear + control devices) et marge disponible (référence : DALI Quick Start Guide).
  4. Vérifier : budget courant bus (dimensionnement, cohérence des alimentations, marge) (référence : DALI Quick Start Guide).
  5. Classer les zones selon criticité exploitation (circulations, zones publiques, back‑office, pièces techniques, zones ouvertes tard / tôt), et poser une stratégie de bascule (plages horaires, phasage, modes dégradés).

Stratégie de migration (dans l’ordre du risque)

  • Priorité contrôle (contrôleur + capteurs) : c’est souvent là que les incompatibilités se révèlent, et c’est l’axe où DALI‑2 apporte un cadre de certification. Références : Comparison, DALI‑2 status, Sensors.
  • Priorité stabilité bus (alimentation + topologie) : dimensionnement, absence de boucle, distances recommandées, cohérence des reprises (référence : DALI Quick Start Guide).
  • Priorité remplacement progressif (drivers/luminaires) : à condition de figer les critères de recette (variation, scènes, comportements de reprise) et de documenter les références réellement installées.

Recette en zone pilote (puis généralisation)

En hôtel, une “zone pilote” peut être un étage, un couloir, ou une chambre témoin techniquement représentative. La logique est la même que pour d’autres lots technologiques hôteliers : tester une expérience complète avant de la reproduire. Voir aussi : Chambre témoin hôtel : valider GRMS, CVC et éclairage.

Scénarios à tester (exemples) : adaptez à votre exploitation et à votre architecture (GRMS/GTB éventuelle, procédures ménage, zones communes).

  • présence → allumage / absence → extinction ou veille,
  • scènes (accueil, lecture, nuit, ménage, circulation),
  • commande manuelle + reprise par l’automatisme,
  • comportement en cas de micro‑coupures et remises sous tension (la documentation DiiA sur l’évolution IEC 62386 évoque des clarifications liées à l’alimentation et aux timings, à confronter à vos équipements réels). Référence : Changes to IEC 62386 enabling DALI‑2 (PDF).

Limite à annoncer : ces tests valident un périmètre (vos références, vos versions, vos réglages). Ils ne remplacent pas une preuve générique “ça marchera toujours” si vous changez de produits plus tard.

Cas particulier hôtellerie : continuité de service, remplacements “au fil de l’eau” et maintenabilité

Dans un hôtel, la rénovation d’éclairage se confronte à trois réalités opérationnelles :

  • Continuité de service : on ne coupe pas facilement des zones (chambres, circulations, espaces communs).
  • Remplacements progressifs : un stock de pièces, des changements de marques, et des “petites améliorations” s’étalent dans le temps.
  • Maintenabilité (jour 2) : si le contrôle est trop spécifique, chaque remplacement devient une mini‑ingénierie.

Une stratégie DALI‑2 bien cadrée ne supprime pas ces contraintes, mais aide à les rendre pilotables si vous exigez (1) un périmètre clair, (2) une recette, (3) une documentation exploitable (DOE).

Plus largement, si votre rénovation est multi‑lots (réseau, GTB, GRMS, etc.), vous pouvez replacer l’éclairage dans une méthode globale de rénovation hôtel : Rénover la technologie d’un hôtel existant sans refaire tout le bâtiment.

Ce qu’il faut écrire clairement dans vos pièces (CCTP / méthode / DOE)

Dire explicitement de quoi vous parlez (gear vs control devices, parts, zones)

Évitez les formulations “DALI compatible” sans périmètre. Préférez une définition opérationnelle : quels types de produits (drivers, capteurs, contrôleurs, alimentations), quelles fonctions (variation, scènes, retours), et quelles zones. Les pages DALI Alliance relatives au statut DALI‑2 renvoient également à une logique de “Parts” et de références associées. Référence : DALI‑2 status.

Ne pas sur‑promettre l’interopérabilité sans recette

DALI‑2 est conçu pour améliorer l’interopérabilité via certification, mais la réussite chantier dépend d’une recette adaptée à votre exploitation et à vos équipements réels. Référence : DALI / DALI‑2 comparison. Pour une démarche de contrôle, appuyez‑vous sur une recette de réception (zone pilote, preuves, tests) plutôt que sur une simple déclaration produit. Voir : Réception d’un éclairage DALI‑2 en hôtel.

Prévoir le “jour 2” : adressage, plans, procédures de remplacement

Un hôtel vit et évolue. Documentez au minimum : plans de bus as built, segmentation, règles d’adressage, sauvegardes/export de configuration quand c’est possible, et procédure de remplacement d’un driver ou d’un capteur (qui fait quoi, avec quel outillage, dans quels délais).

Résumé décisionnel (lecture en une minute)

  • Si vous remplacez surtout des drivers/luminaires et conservez le contrôleur, vous pouvez souvent rester proche de l’existant, à condition de verrouiller alimentation bus, topologie, distances et adressage (référence : DALI Quick Start Guide).
  • Si vous ajoutez des capteurs et/ou vous mélangez les marques côté contrôle, DALI‑2 est généralement la trajectoire la plus robuste car il encadre et cherche à certifier les control devices (références : Comparison, Sensors, Status).
  • Dans un hôtel, migrez par segments, validez une zone pilote (étage/couloir/chambre témoin) et gardez de la marge (adresses, courant bus) pour les étapes intermédiaires.

Sources et documentation (références publiques)

Si vous préparez une rénovation d’éclairage DALI en hôtel et que vous voulez sécuriser la trajectoire (conserver, segmenter, migrer), l’enjeu n’est pas seulement “quel protocole”, mais quels tests, quelles preuves, et quels livrables pour que l’exploitation puisse vivre avec le système.

3Sep

Éclairage de sécurité en hôtel : utiliser DALI Emergency pour automatiser les tests et remonter les défauts

by Domocasa
Énergie et CVC Guides techniques Hôtellerie

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

En hôtellerie, l’éclairage de sécurité est un sujet « exploitation » avant d’être un sujet « technologie ». Le besoin terrain est simple : pouvoir déclencher des tests, récupérer des résultats, et remonter vite les défauts (équipement, batterie, bloc d’urgence…) sans dépendre d’opérations manuelles longues, dispersées et difficiles à prouver.

DALI Emergency est l’extension DALI qui vise précisément l’intégration de l’éclairage de sécurité dans un système de contrôle numérique, avec des mécanismes d’automatisation des tests et de reporting exploitables, y compris via une supervision/GTB selon l’architecture retenue. (DALI Alliance — DALI Emergency)

Note de cadrage importante (Maroc / ERP / assurance) : cet article décrit ce que DALI Emergency permet techniquement et ce qu’un exploitant peut raisonnablement exiger en conception et en recette. Les obligations (périodicité, nature des essais, forme des rapports, conservation des preuves, etc.) dépendent du projet et du cadre applicable. La DALI Alliance rappelle seulement que des tests périodiques sont requis dans de nombreux pays et que l’éclairage de sécurité est régi par des réglementations. (source)

À qui sert DALI Emergency (côté exploitation hôtelière) ?

DALI Emergency s’adresse aux projets où l’on veut :

  • industrialiser les tests (planification, traçabilité, réduction des passages manuels),
  • centraliser les résultats (au moins dans un contrôleur, idéalement dans une supervision si le site en dispose),
  • accélérer le diagnostic (identifier une zone, un appareil, un état, un défaut récurrent),
  • préparer l’exploitation (preuves de recette, transfert maintenance, continuité de service).

En complément, si vous êtes en phase de réception DALI au sens large (interopérabilité, cohérence DALI‑2, livrables, méthode de tests), vous pouvez aussi lire : Réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité et éviter les incompatibilités.

DALI Emergency en clair : ce que couvre le standard

Le périmètre mis en avant : l’éclairage de sécurité « self-contained »

La DALI Alliance met en avant le cas self‑contained, où la batterie est intégrée au luminaire (ou associée au luminaire). C’est un périmètre important à expliciter dès le CCTP, car les attentes et les interfaces diffèrent selon le type de solution d’éclairage de sécurité retenue. (DALI Alliance — DALI Emergency)

DT1 / IEC 62386‑202 : identifier la “famille” DALI concernée

Côté DALI, le contrôle gear d’urgence pour le self‑contained correspond à IEC 62386 Part 202, également identifié comme Device Type 1 (DT1). (DALI Emergency) (Tech Note — Device Types)

Traduction « exploitation » : demander “DALI Emergency” de façon générique est insuffisant. Pour cadrer un lot et éviter les malentendus, on cherche au minimum à relier la fonction attendue (tests/reporting) à un périmètre de device type / part identifié.

DALI‑2 Emergency : interopérabilité et certification

La DALI Alliance indique que la certification DALI‑2 Emergency est ouverte pour le contrôle gear d’éclairage de sécurité self‑contained, sur la base de l’IEC 62386‑202. (DALI Alliance — DALI Emergency)

Si vous souhaitez replacer DALI‑2 dans l’ensemble des termes DALI (DALI‑2 / D4i / DALI+), voir : DALI‑2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?.

Automatiser les tests : ce que vous pouvez exiger “fonctionnellement”

La DALI Alliance précise que DALI permet d’automatiser des tests pour l’éclairage de sécurité self‑contained, avec déclenchement par commandes DALI ou via un timer optionnel (selon l’implémentation). (DALI Alliance — DALI Emergency)

Ce que ça veut dire, concrètement, dans un hôtel

Pour éviter les recettes ambiguës (“ça marche”) et les dérives en exploitation (“on ne sait pas prouver”), on peut formuler des exigences orientées résultats, indépendantes des marques :

  • Plan de tests : quels tests sont prévus dans votre projet (et sur quelles zones), qui les lance (contrôleur / maintenance / supervision), et comment on évite un impact sur l’exploitation (ex. séquencement par zones).
  • Traçabilité : existence d’un journal des tests lancés et de leurs résultats (dans le contrôleur et/ou dans un outil de supervision).
  • Exportabilité : capacité à exporter les preuves (fichier, extraction, ou mécanisme équivalent) afin que l’exploitant ne soit pas prisonnier d’un PC de mise en service ou d’une compétence rare.
  • Mode dégradé : que se passe‑t‑il si la supervision est indisponible ? Les tests restent‑ils exécutables et les preuves récupérables a posteriori ?

Ce cadrage n’impose pas une forme réglementaire : il garantit simplement que les essais ne sont pas « perdus » et qu’une équipe exploitation peut opérer le système dans la durée.

Remonter les défauts : supervision et diagnostic “praticables”

La page DALI Emergency évoque l’intérêt d’intégration avec des systèmes de gestion du bâtiment (GTB/BMS), qui peuvent accéder aux capacités de contrôle et d’interrogation DALI, incluant tests automatisés et reporting. (DALI Alliance — DALI Emergency)

Point d’attention : la DALI Alliance ne décrit pas, sur cette page, un protocole unique côté GTB (BACnet, Modbus, API, etc.). L’enjeu projet est donc de définir, puis de recetter, la chaîne complète : DALI ↔ contrôleur ↔ passerelle ↔ supervision ↔ export des preuves.

Interopérabilité : vérifier que le contrôleur “comprend” ce qu’il a sur le bus

Un bon diagnostic commence par une capacité simple : savoir identifier les équipements et leurs capacités réelles sur le bus.

La DALI Alliance rappelle que les device types concernent les parties control gear (Parts 2xx), et qu’un contrôleur peut vérifier la capacité d’un équipement via la commande QUERY DEVICE TYPE. (DALI Alliance — Tech Note “Device types”)

Exigence exploitable à écrire et à recetter :

  • obtenir une liste d’inventaire par ligne DALI (adresses, localisation, capacité détectée),
  • pouvoir relier un événement ou un défaut à un repérage terrain (plans / nomenclature / étiquetage),
  • éviter les architectures où seuls l’intégrateur ou un logiciel propriétaire permettent de “relire” l’installation.

Spécifier correctement : “DALI‑2 certifié” ne veut pas dire “tout est certifié”

La DALI Alliance explique que la certification DALI‑2 repose sur des tests créés et maintenus par l’Alliance, dérivés de parties IEC 62386 et/ou de spécifications DiiA ; et que la possibilité de certifier dépend de l’inclusion d’une Part dans les séquences de test. (DALI Alliance — DALI‑2 certification status)

Ce que l’exploitant peut exiger sans entrer dans les détails normatifs

  • Matériel d’urgence DALI‑2 Emergency certifié pour le périmètre self‑contained (DT1 / IEC 62386‑202), et pas seulement “compatible”. (DALI Alliance — DALI Emergency)
  • Références exactes (marque, modèle, firmware si applicable) et périmètre revendiqué (ce qui est certifié, ce qui ne l’est pas).
  • Dossier d’exploitation : qui déclenche les tests, où sont stockés les logs, comment on exporte, qui reçoit les alertes, comment on accuse réception et on suit les actions correctives.

Limite volontaire de ce guide : avec les seules pages DALI Alliance citées ci‑dessus, on ne peut pas établir ici la liste exhaustive des commandes/paramètres de test ni un format standard unique de rapport. Ce point se traite au niveau (i) documentation de l’outil/contrôleur choisi, et/ou (ii) documentation fabricant des équipements, et (iii) cahier de recette spécifique au projet.

Structurer une recette orientée “preuves” (modèle hôtel)

L’objectif est de sortir d’une recette “on allume / ça marche” pour obtenir un dossier exploitable sur plusieurs années : inventaire, repérage, logs, et démonstration que la chaîne de supervision (si elle existe) remonte des informations utilisables.

Pré‑recette documentaire (avant essais)

À demander avant toute mise en service :

  • Schéma d’architecture : lignes DALI, contrôleurs, alimentations de bus, passerelles éventuelles vers GTB/BMS.
  • Inventaire : liste des équipements d’urgence par zone (circulations, escaliers, issues, locaux techniques…), avec repérage terrain.
  • Correspondance adresse ↔ localisation : un plan et une nomenclature qui permettent d’intervenir sans ambiguïté.
  • Procédure d’exploitation : qui exécute les tests, quand, comment les preuves sont conservées et comment un défaut est traité (workflow).

Pour élargir à la logique “livrables exploitant” (au‑delà du seul éclairage), voir : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

Recette fonctionnelle (sur site)

Tests typiques (à adapter au projet et au contrôleur retenu) :

  • Capacités détectées : vérifier que le contrôleur identifie correctement les équipements pertinents (logique device type / interrogation). (Tech Note — Device Types)
  • Déclenchement de tests : démontrer que les tests peuvent être lancés via commandes DALI et/ou via un timer optionnel si la solution s’appuie dessus. (DALI Emergency)
  • Collecte des résultats : s’assurer que le résultat est bien enregistré (journal consultable), qu’il est relié à un repérage (zone/appareil), et qu’il est récupérable (export).

Recette de supervision (si GTB / BMS / supervision technique)

Si le projet prévoit une supervision, il est utile de recetter :

  • la présence des objets attendus (états, défauts, résultats de tests) dans la supervision,
  • la cohérence de nommage (repérage terrain),
  • les droits et rôles (qui acquitte, qui modifie la planification),
  • le comportement en cas de rupture de communication (alarme, file d’attente, reprise).

La DALI Alliance souligne l’intérêt de l’intégration GTB/BMS autour du contrôle, de l’interrogation, des tests automatisés et du reporting, sans imposer sur cette page un mode d’intégration unique. (DALI Emergency)

Checklist “exploitation” : ce que l’hôtel doit obtenir à la livraison

  • Périmètre clair : self‑contained, et identification DT1 / IEC 62386‑202 côté équipements concernés. (DALI Emergency)
  • Automatisation des tests démontrée : commandes DALI et/ou timer optionnel selon la solution, avec un scénario exploitable (planification, séquencement). (source)
  • Journalisation et preuves : résultats consultables, traçables, exportables (au moins depuis l’outil principal de gestion/contrôle).
  • Inventaire + repérage : plans et nomenclature, correspondance adresse ↔ localisation.
  • Interopérabilité cadrée : revendications de certification DALI‑2 situées correctement (tests/Parts), avec références précises. (DALI‑2 certification status)

Questions à poser (courtes, actionnables)

  1. Les équipements d’urgence self‑contained sont‑ils DALI‑2 Emergency certifiés (DT1 / IEC 62386‑202) ? (source)
  2. Comment les tests sont‑ils planifiés : commandes DALI, timer optionnel, supervision ? (source)
  3. Où sont stockées les preuves horodatées (journaux) et comment les exporte‑t‑on ?
  4. Comment la solution identifie les capacités des équipements (ex. device type / interrogation) et produit un inventaire exploitable ? (source)
  5. Si une GTB/BMS existe : quelles informations remontent réellement (états, défauts, résultats) et via quelle chaîne d’intégration ? (source)

Conclusion : viser une installation “testable et prouvable”

Dans un hôtel, la différence entre un éclairage de sécurité « installé » et un éclairage de sécurité « exploitable » se joue souvent sur des détails de méthode : inventaire, repérage, planification, export des logs et recette de la supervision. DALI Emergency fournit un cadre technique pour automatiser les tests et remonter des informations ; à vous (MOA, AMO, exploitant, BE) de transformer ces capacités en preuves et en process contractuels.

Si vous préparez une réception ou une rénovation, Domocasa peut vous aider à cadrer une recette orientée exploitation (livrables, responsabilités, tests et modes dégradés) en complément des exigences de sécurité propres à votre projet.

Sources et documentation

31Août

Réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité et éviter les incompatibilités

by Domocasa
Énergie et CVC Guides techniques Hôtellerie

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

Objectif : vous donner une recette de réception (preuves à exiger + vérifications + tests terrain) pour confirmer qu’un lot annoncé « DALI‑2 » est réellement interopérable et maintenable en exploitation hôtelière, sans dépendre d’un seul fabricant.

Périmètre volontairement strict : éclairage DALI‑2 (drivers / ballasts, capteurs, contrôleurs DALI, alimentations de bus, passerelles DALI). On ne traite pas ici le GRMS/GTB/KNX/BACnet, sauf si votre architecture impose une interface (dans ce cas, la recette DALI‑2 reste valable mais doit être complétée par une recette d’intégration).

Pour un rappel sur les concepts DALI côté exploitation, voir : DALI : comment fonctionne l’éclairage professionnel intelligent ?. Et pour clarifier les termes « DALI‑2 / D4i / DALI+ » : DALI‑2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?.

Ce que DALI‑2 « garantit »… et ce que vous devez encore prouver en réception

La DALI Alliance (DiiA) indique opérer un programme de certification DALI‑2 « indépendamment vérifié », destiné à démontrer la conformité de produits aux spécifications DALI‑2. Les tests s’appuient sur des DALI‑2 Test Specifications dérivées de parties d’IEC 62386 et/ou de spécifications DiiA. Les produits qui complètent le processus de certification peuvent utiliser les marques DALI‑2 (logos/wordmarks) selon les règles DiiA. Source : DALI Alliance — DALI‑2 certification.

Traduction “exploitation hôtel” : la certification est une base utile, mais elle ne remplace pas une recette de chantier (tests fonctionnels, cohérence des références réellement posées, procédure de remplacement, sauvegarde/restore de configuration, etc.). Votre réception doit donc faire deux choses :

  • Prouver que les composants livrés correspondent bien à des produits certifiés (traçabilité).
  • Démontrer que l’installation se comporte correctement dans vos usages hôteliers (tests terrain).

Preuve n°1 à exiger : une traçabilité “composant par composant” (pas seulement “DALI‑2” dans un CCTP)

Le livrable attendu (format opérateur)

Demandez au titulaire/intégrateur une liste « as delivered » (tableur) qui couvre tous les composants DALI : drivers/ballasts, capteurs/entrées, contrôleur(s) DALI, alimentations de bus, répéteurs, passerelles DALI, etc. Pour chaque ligne, exigez :

  • Marque (celle visible sur l’étiquette/produit).
  • Référence commerciale exacte.
  • Rôle (driver/control gear, control device, application controller, bus power supply…).
  • Lien vers l’entrée correspondante dans la Product Database DiiA (ou capture datée + URL).
  • Statut : DALI‑2 Certified (oui/non), D4i Certified (oui/non).
  • DALI Parts déclarées (information présente dans la base produits).

Pourquoi c’est crucial : la DiiA explique que sa Product Database contient les composants DALI‑2 et D4i certifiés (et des produits DALI « version 1 » enregistrés). Source : DALI Alliance — Product Database (API publique).

Point d’attention “luminaires” (souvent source de malentendu)

La DiiA indique explicitement qu’elle n’opère pas de programme de certification pour les luminaires. En revanche, elle décrit comment les marques/logos DALI‑2 peuvent s’appliquer aux luminaires lorsque les composants DALI qu’ils contiennent sont certifiés et listés. Source : DALI Alliance — DALI luminaires.

Conclusion réception : ne recevez pas « un luminaire DALI‑2 » comme une promesse vague. Recevez une liste de composants identifiés (drivers, capteurs, etc.) et une preuve base DiiA pour chacun.

Vérifier la certification dans la base produits DiiA (méthode simple, reproductible)

Où vérifier

La DiiA met à disposition une Product Database publique, qui expose notamment des informations telles que le statut DALI‑2 Certified (oui/non), D4i Certified (oui/non) et les DALI Parts. Source : Product Database DiiA.

La procédure de contrôle (à faire pour chaque référence critique)

  1. Retrouver la référence exacte dans la base (attention aux variantes et suffixes de référence).
  2. Vérifier que le statut attendu est bien « DALI‑2 Certified » (et/ou « D4i Certified » si vous l’exigez au marché).
  3. Contrôler les DALI Parts annoncées : elles doivent être cohérentes avec la fonction attendue (driver, capteur, contrôleur…).
  4. Archiver une preuve datée (PDF/print avec URL et date de consultation), à intégrer au DOE.

Astuce “exploitation” : faites cette vérification avant la mise en service finale. C’est à ce moment qu’un remplacement de référence (ou une correction de commande) coûte le moins cher.

Le point critique : la certification vaut pour un produit identifié (marque / versions / identifiants)

La Product Database contient un avertissement important : l’information concerne le produit spécifique qui a été testé et la validité est liée à la cohérence entre marque, GTIN, versions firmware/hardware et un ID unique (ces éléments sont présentés comme lisibles via la memory bank 0). Source : avertissements Product Database DiiA.

Comment l’exploiter en réception (sans faire de “test de labo”)

  • À la livraison : photos d’étiquettes (marque + référence) et cohérence avec la liste « as delivered ».
  • À la mise en service : demandez une exportation des informations disponibles via l’outil de commissioning / contrôleur DALI (et, si l’outil le permet, lecture des informations d’identification). Archivez l’export dans le DOE.
  • En maintenance : formalisez une règle simple : toute pièce remplacée doit être strictement équivalente (même identité produit) ou, à défaut, être elle aussi identifiée comme certifiée dans la base DiiA pour la marque effectivement apposée.

Important : ces contrôles doivent être réalisés par des intervenants qualifiés et dans le respect des règles de sécurité électrique du site. Le but ici est la traçabilité et la maintenabilité, pas d’encourager des manipulations improvisées.

Cas à haut risque en hôtel : logos, OEM/ODM et rebranding

La DiiA rappelle que les marques (DALI, DALI‑2, D4i, etc.) sont des marques de la DiiA et que leur usage est encadré. La page « Trademarks and Logos » décrit aussi des points de vigilance pour les situations OEM/ODM et rebranding. Source : DALI Alliance — Trademarks and Logos.

Test opérateur très simple

Si la marque affichée sur le produit (ou sur l’étiquette) ne correspond pas à ce que vous trouvez dans la Product Database, vous êtes dans une zone de risque : demandez une clarification écrite et un alignement (références, marque, preuve base DiiA), ou un remplacement.

Recette terrain : tests d’acceptation “interopérabilité & maintenance” (sans banc de conformité)

Les tests ci-dessous sont des tests d’acceptation projet orientés exploitation. Ils ne prétendent pas reproduire les tests de certification DALI‑2 opérés par la DiiA. L’objectif est de prouver que, dans votre hôtel, l’installation est utilisable et maintenable.

Jeu de tests minimum par zone type

Définissez des zones représentatives (par exemple : chambre type, circulation d’étage, hall, salle de réunion, back‑of‑house) puis validez, pour chaque zone :

  • Commande de base : allumage/extinction, variation, comportement cohérent sur l’ensemble des charges.
  • Groupes : un groupe commande toutes les charges attendues, et uniquement elles.
  • Scènes : rappel de scènes et cohérence après coupure/retour secteur (test à planifier pour ne pas impacter l’exploitation).
  • Entrées (si prévues) : capteurs de présence/luminosité, boutons, priorités, temporisations selon vos règles d’exploitation.
  • Diagnostic : sur un échantillon encadré, simuler une indisponibilité d’un composant (selon procédure intégrateur) et vérifier que : (a) le reste du bus continue de fonctionner, (b) l’anomalie est identifiable (au minimum par zone/ligne), (c) la remise en état est documentée.

Le test “maintenabilité” qui révèle les mauvaises surprises

Sur une ou deux zones pilotes (avant généralisation) :

  • Faites remplacer un driver ou un capteur par une référence identique (même marque/réf).
  • Vérifiez que l’intervention est réaliste en conditions d’hôtel : réadressage limité, récupération des groupes/scènes, procédure claire, pas besoin de reprogrammer tout un étage pour une panne isolée.

Si ce test est difficile en “zone pilote”, il sera coûteux et risqué une fois l’hôtel en exploitation.

Les preuves à exiger au DOE (pour éviter le “DALI‑2 en théorie”)

En hôtellerie, un DOE exploitable fait souvent la différence entre une installation “qui marche à la livraison” et une installation “maintenable sur la durée”. Pour cadrer le sujet DOE côté hôtel, vous pouvez aussi lire : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

Pack de preuves “alignées DiiA”

  • Exports/prints (datés) des entrées Product Database pour les composants majeurs, avec statut DALI‑2/D4i et DALI Parts. Source : Product Database DiiA.
  • Une note de réception qui rappelle le principe : la certification s’applique au produit testé et à son identité (marque/GTIN/versions/ID) tel qu’indiqué par la DiiA, et qui décrit comment le chantier a figé cette identité (photos, exports, liste as delivered, etc.). Source : avertissements Product Database DiiA.

Pack “exploitation” recommandé (pour le jour 2)

  • Schémas « as built » : topologie par zone/étage, repérage des lignes/bus, repérage des alimentations de bus et contrôleurs.
  • Table d’adressage : adresses DALI, groupes, scènes, logique des capteurs (et les conventions de nommage).
  • Sauvegardes de configuration : fichiers/projets de commissioning, versions logicielles, procédure de restauration.
  • Procédure de remplacement : pas à pas (ce que l’équipe maintenance doit faire et ce qu’elle ne doit pas faire).
  • Liste des références “pièces de rechange” compatibles (avec preuve DiiA quand applicable).

Faut-il exiger des tests de conformité officiels (ProbitLab2) en réception ?

La DiiA explique que les tests de conformité DALI‑2/D4i s’appuient sur des équipements ProbitLab / ProbitLab2 et le logiciel ProbitBench (Lichtvision Engineering), et indique que le support ProbitLab a cessé au 29 février 2024 et que ProbitLab2 est requis pour les tests DALI. Source : DALI Alliance — Testing for DALI‑2 compliance.

Lecture “exploitation hôtel” : vous n’êtes généralement pas censé acheter un banc de conformité pour réceptionner un chantier. En revanche, vous êtes en droit d’exiger : (a) des composants réellement certifiés (preuve base DiiA), (b) une recette terrain documentée, (c) un DOE qui rend l’éclairage maintenable.

Que faire si un composant n’est pas certifié DALI‑2 (ou si la “Part” n’est pas disponible)

La DiiA publie aussi un statut des « DALI‑2 Parts » indiquant que les tests sont dérivés de parties IEC 62386 ou de spécifications DiiA, et qu’une « Part » qui n’est pas incluse dans les séquences de test ne peut pas être certifiée tant qu’elle n’est pas libérée. Source : DALI Alliance — DALI‑2 certification status.

Conduite à tenir en réception :

  • Si votre marché exige “certifié DALI‑2”, demandez un alignement produit (référence alternative certifiée) ou une dérogation formalisée (acceptée par la maîtrise d’ouvrage) avec risques clairement explicités (interopérabilité, maintenance, dépendance fournisseur).
  • Si le projet accepte un mélange (cas fréquent en rénovation/extension), documentez-le clairement dans le DOE et renforcez les tests terrain et la stratégie pièces de rechange.

Conclusion : la recette DALI‑2 qui protège l’exploitant hôtelier

  • Ne recevez pas un mot (« DALI‑2 ») : recevez une liste de composants et une preuve dans la Product Database.
  • Figez l’identité des produits installés (marque/référence et, si disponible via l’outil, informations d’identification) : c’est directement lié à la logique de validité rappelée dans la base DiiA.
  • Testez des usages (zones types) et testez le remplacement : c’est le meilleur indicateur de maintenabilité.
  • Archivez des preuves datées dans le DOE : elles sont déterminantes quand il faut remplacer, étendre ou arbitrer un litige.

Si vous préparez une pré‑ouverture ou une réception multi‑lots, notre checklist globale peut servir de trame, à compléter avec cette recette DALI‑2 : Pré‑ouverture d’un hôtel : la checklist technique des systèmes courant faible.

Besoin d’un appui méthodologique (documents à exiger, plan de tests, DOE exploitable) pour votre hôtel au Maroc ? Domocasa peut vous aider à cadrer une recette orientée exploitation, sans surcharger le projet.

Sources et documentation (consultables)

27Août

Rénovation d’hôtel : comment garder les identifiants chambre, porte et équipements cohérents entre PMS, GRMS, GTB et serrures

by Domocasa
Guides techniques Hôtellerie

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

Dans un hôtel, une cause classique d’incidents « incompréhensibles » entre systèmes vient d’un problème très simple : les mêmes chambres, portes et équipements n’ont pas les mêmes identifiants selon le PMS, le GRMS, la GTB et le logiciel de serrures. Tant que personne ne touche au bâtiment, l’écart reste parfois invisible. Mais lors d’une rénovation, d’une renumérotation, d’un changement d’exploitant ou d’une migration PMS, ce décalage devient un accélérateur d’erreurs.

Ce guide propose une méthode pragmatique pour mettre en place un référentiel “chambre & équipements” (Room/Unit IDs) et une gouvernance associée, afin que vos intégrations restent cohérentes dans la durée — y compris quand les outils changent.

Pour replacer ce sujet dans une vue “interfaces et responsabilités”, vous pouvez aussi lire : PMS, GRMS, GTB, serrures et contrôle d’accès : qui échange quoi dans un hôtel ?

Pourquoi un référentiel d’identifiants est indispensable (et pas seulement « un tableau Excel »)

Les intégrations hôtelières s’appuient très souvent sur un identifiant de chambre ou de porte comme “clé” d’échange : numéro de chambre, nom de porte, ID d’hébergement, etc. Quand deux systèmes ne parlent pas exactement de la même chose, il faut mapper (faire correspondre) ces objets.

  • Certains PMS documentent explicitement la nécessité d’un mapping de chambres pour l’intégration de clés lorsque les formats diffèrent (ex. gestion des zéros en tête). C’est le cas dans la documentation Stayntouch. Source
  • Cloudbeds indique que les noms/IDs de chambres côté PMS ne correspondent pas toujours au système de serrures et propose un champ « Doorlock ID » pour faire la correspondance. Source
  • Sur certaines architectures GRMS/supervision, le PMS identifie une chambre via un room number tandis que la plateforme de room control supervise plutôt une area number : une table de mapping est alors requise. Source

Conclusion opérationnelle : en pratique, les PMS, GRMS, GTB et systèmes de serrures n’emploient pas tous le même schéma d’identifiants ni les mêmes formats (numéros, noms, zéros en tête, objets “room” vs “area”, etc.). On rencontre donc des formats divergents et, très souvent, des mappings à maintenir. La solution la plus robuste est une solution de gouvernance de données projet : un référentiel maître, des identifiants stables, et des correspondances explicites vers chaque système.

Principe clé : séparer l’identifiant stable de la “chambre affichée”

Le piège classique consiste à confondre :

  • Ce qui est stable (un identifiant interne) : ce qui doit survivre à une rénovation, une renumérotation ou un changement d’outil.
  • Ce qui est affiché (numéro sur la porte, signalétique, marketing, plan d’étage) : ce qui peut évoluer.

Exemple typique : une chambre “405” affichée au client peut devenir “305” après reconfiguration d’un étage, alors que vous voulez conserver une continuité de traçabilité (historique des interventions, historique technique, liens vers équipements, etc.).

Ce que le référentiel doit contenir : un modèle minimal (qui tient en exploitation)

Le bon niveau de détail dépend de votre projet, mais un modèle minimal permet déjà d’éviter la majorité des incohérences.

Objet 1 — L’unité vendable (Room / Unit côté PMS)

C’est ce que le PMS vend et assigne à un séjour. Une suite “vendable” peut correspondre à plusieurs espaces physiques.

  • unit_id : identifiant stable interne (ne pas le réutiliser).
  • unit_public_number : numéro affiché / signalétique (évolutif).
  • attributs utiles : bâtiment/aile/étage, notes d’exploitation, dates de validité si vous gérez des phases de rénovation.

Objet 2 — La porte / le point d’accès (Door)

Une “chambre vendable” peut avoir plusieurs portes pertinentes (entrée principale, porte communicante, porte de service, etc.).

  • door_id : identifiant stable interne.
  • door_role : entrée principale, communicante, service…
  • lock_vendor_id / doorlock_id : identifiant attendu par le système de serrures quand il impose son propre repérage (ou quand l’API le prévoit).
  • linked_unit_id : lien explicite vers l’unité vendable.

Sur le volet serrures/contrôle d’accès, voir aussi : Serrures électroniques d’hôtel : online, offline, mobile key et intégration PMS.

Objet 3 — L’espace technique (Space / Zone côté GRMS/GTB)

Le GRMS et la GTB raisonnent souvent en “zones” (ou espaces) plutôt qu’en “chambres vendables”. Il faut donc une correspondance explicite entre les deux.

  • space_id : identifiant stable interne.
  • linked_unit_id : lien vers l’unité vendable.
  • controller_id (optionnel mais utile) : contrôleur de chambre / automate / passerelle associée.

Pour aller plus loin côté GTB/GRMS (structure des points, maintenabilité, exploitation multi-sites), voir : Modéliser les points GTB/GRMS avec Project Haystack (site/equip/point).

Objet 4 — L’équipement (Asset)

Thermostat, actionneur, variateur, capteur d’ouverture, contrôleur de fan-coil, compteur, etc.

  • asset_id : identifiant stable interne.
  • asset_type : type fonctionnel (pour exploiter et filtrer).
  • linked_space_id : rattachement explicite à l’espace.
  • network_id (optionnel) : IP/MAC/adresse bus… utile, mais à traiter comme une propriété technique, pas comme l’identité fonctionnelle.

Nommage : viser un format “terrain” et un format “machine”

Un référentiel robuste doit servir à la fois :

  • aux équipes terrain (maintenance, sécurité, housekeeping) : lisibilité ;
  • aux intégrations (API, exports, imports) : stabilité.

Convention simple : deux champs complémentaires

  • Nom terrain (human-friendly) : ce que l’on retrouve sur les plans et sur site (ex. “Chambre 405”, “405-Entrée”).
  • ID stable (machine-friendly) : un identifiant interne qui ne change pas quand on renumérote (ex. “UNIT-…”, “DOOR-…”, “ASSET-…”).

Important : évitez de faire dépendre votre identité stable d’une convention “fragile” (étage + numéro). En rénovation, ce sont précisément ces éléments qui bougent le plus.

Le “golden record” : une table maître unique + des mappings contrôlés

Le cœur de la méthode, c’est de décider où est la vérité. Dans les faits, le référentiel n’est ni “le PMS”, ni “la GTB”, ni “le logiciel de serrures” : c’est une table maître (golden record) que les systèmes consomment.

Contenu minimal de la table maître

  • unit_id (stable) + unit_public_number (affiché)
  • door_id + doorlock_id/lock_vendor_id (si applicable)
  • space_id / zone_id (GTB/GRMS)
  • statut (actif / retiré / en travaux) + commentaires d’exploitation

Pourquoi formaliser le mapping “PMS ↔ serrures” dès le départ

La documentation Cloudbeds explique que le nom/ID de chambre côté PMS ne correspond pas forcément au système de serrures et prévoit un champ dédié (« Doorlock ID ») pour gérer ce décalage. Source Le même éditeur documente aussi un support explicite du mapping Doorlock IDs ↔ définitions de chambres pour réduire les contournements quand les noms divergent. Source

Cette réalité (formats divergents, dépendance au mapping) existe au-delà d’un éditeur particulier : la question à trancher est donc organisationnelle, pas “outil par outil”.

Règles anti-accidents (celles qui évitent les catastrophes en exploitation)

Ne jamais réutiliser un identifiant stable

Quand une chambre est supprimée, fusionnée, ou transformée, l’identifiant stable doit passer en retiré (déprécié), mais ne doit pas être réattribué plus tard à une autre chambre. C’est le seul moyen de conserver des historiques fiables (tickets, interventions, journaux d’événements, analyses énergétiques, etc.).

Traiter la “suite” comme un objet à part entière

Une suite vendable peut regrouper plusieurs espaces et parfois plusieurs portes. Si vous ne modélisez pas cette relation, vous finissez par bricoler des équivalences qui casseront lors de la première reconfiguration commerciale.

Ne pas confondre identité fonctionnelle et repérage IP

Votre plan d’adressage réseau (IP, VLAN, DNS, réservations DHCP) est indispensable, mais il répond à une autre question : comment joindre un équipement, pas ce qu’il représente dans l’exploitation. Pour structurer la couche réseau (noms, adresses, cohérence), voir : Réseau : organiser les adresses et les noms des équipements.

Gouvernance : qui a le droit de changer quoi (et comment)

Un référentiel “meurt” presque toujours pour la même raison : tout le monde peut changer les noms, mais personne ne porte la responsabilité de la cohérence inter-systèmes.

Rôles recommandés (simples, mais non négociables)

  • Owner du référentiel (exploitation, AMO ou maîtrise d’ouvrage déléguée) : arbitre, valide, versionne.
  • Contributeurs : intégrateur GRMS, intégrateur GTB, serrurier électronique, IT, mainteneur CVC.
  • Consommateurs : PMS, housekeeping, sécurité, maintenance, BI/reporting.

Process de changement : la “fiche de changement”

Chaque changement (renumérotation, fusion, découpage, changement de serrure, migration PMS, modification des zones GTB) doit passer par une fiche simple :

  • raison du changement (travaux, rebranding, reconfiguration commerciale…)
  • objets impactés (unit/door/space/asset)
  • mappings à mettre à jour (PMS, serrures, GRMS, GTB, housekeeping…)
  • date d’effet + scénario de retour arrière (si possible)
  • tests de non-régression (voir section recette)

Ce niveau de rigueur n’est pas “administratif” : même des solutions d’intégration demandent explicitement de cibler la chambre par un identifiant (ex. « Device Name » à renseigner avec le numéro de chambre dans certains paramétrages). Source

Rénovation : scénarios typiques et méthode de migration

Renumérotation à périmètre constant

  • Conserver les identifiants stables (unit_id, door_id, space_id, asset_id).
  • Changer le numéro affiché (unit_public_number) et mettre à jour les mappings vers les systèmes.
  • Conserver une trace de l’ancienne valeur (historique) pour les équipes (et pour diagnostiquer des logs anciens).

Fusion (deux chambres deviennent une suite vendable)

  • Créer une nouvelle unité vendable (nouveau unit_id) pour la suite.
  • Marquer les anciennes unités comme retirées/non vendables (sans réutiliser leurs IDs).
  • Documenter la relation : une unité vendable regroupe plusieurs espaces et/ou plusieurs portes.

Découpage (une suite devient deux chambres)

  • Conserver l’ancienne unité en historique (retirée).
  • Créer les nouvelles unités vendables.
  • Réattribuer explicitement les portes, zones et équipements au bon objet “après travaux”.

Changement d’exploitant ou migration PMS

C’est un cas à haut risque, car le nouvel exploitant arrive souvent avec ses conventions de codification. Votre protection, c’est d’avoir un référentiel stable et un mapping documenté. Dans la pratique, le mapping peut devenir obligatoire dès qu’un PMS et un système de clés ne partagent pas le même format de numéros. Source

Pour réduire les intégrations “sur mesure” fragiles et cadrer les échanges, une piste utile est d’exiger des interfaces structurées quand elles existent. Voir : HTNG Express : simplifier les échanges avec le logiciel de gestion.

Recette : comment tester que le référentiel et les mappings tiennent en production

Le test n’est pas uniquement “le check-in fonctionne”. Il faut valider les cas de vie réelle, surtout ceux qui cassent en rénovation :

  • Check-in / check-out sur une chambre renumérotée : la clé se code sur la bonne porte, et le GRMS applique les bons états.
  • Changement de chambre (room move) : le mapping suit l’affectation, sans “rester” sur l’ancienne porte.
  • Chambres communicantes / suites : les bonnes portes réagissent et les bonnes zones techniques restent associées.
  • Mode dégradé : selon l’architecture retenue, définir puis tester ce qui se passe si le PMS est indisponible (par exemple : quelles fonctions le GRMS peut continuer à assurer localement, et quelles fonctions dépendent d’une couche centrale). Vérifier aussi, dans la mesure du possible, que l’accès et les fonctions essentielles ne reposent pas sur un point de défaillance unique — ou, si ce n’est pas réaliste dans votre architecture, que les impacts sont connus, acceptés, et couverts par une procédure d’exploitation.

Sur la validation en amont (chambre témoin, déploiement), voir : Chambre témoin hôtel : comment valider le GRMS, le CVC et l’éclairage.

Livrables à exiger (MOA/AMO/MOE/integrateurs) pour que le référentiel survive

  • Référentiel des objets (unit/door/space/asset) + règles de nommage.
  • Tables de mapping par système (PMS, serrures, GRMS, GTB…), avec date de génération et version.
  • Procédure de changement (qui modifie, qui valide, comment versionner).
  • Procédure de migration (avant/après, tests, plan de retour arrière si possible).
  • Remise à l’exploitant : livrables exploitables, pas seulement des exports “points automate”.

Pour cadrer la remise documentaire et la maintenabilité (au-delà du seul référentiel), voir : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?

Checklist express (à utiliser en réunion projet)

  • Avez-vous un identifiant stable de chambre (unit_id) distinct du numéro affiché sur la porte ?
  • Avez-vous une correspondance explicite PMS ↔ serrures (doorlock_id / door name / mapping) ?
  • Avez-vous une correspondance explicite “unité vendable” ↔ “zone technique” (GRMS/GTB) ?
  • Avez-vous une règle claire « pas de réutilisation d’ID » + un statut “retiré/en travaux” ?
  • Avez-vous un owner du référentiel et un processus de changement versionné ?

Sources et documentation (sélection)

Besoin d’un cadrage rapide sur votre projet ?

Si vous préparez une rénovation ou une migration PMS/serrures/GRMS, un atelier court de cadrage (objets du référentiel, règles d’identifiants, mappings, recette) permet souvent d’éviter des reconfigurations coûteuses en phase d’ouverture.

Domocasa peut vous accompagner en AMO/ingénierie d’intégration sur ces sujets, en coordination avec vos intégrateurs et éditeurs.

20Août

Casting en chambre d’hôtel (Chromecast/AirPlay) : choisir une approche opérable (mode invité, confidentialité, reset, support)

by Domocasa
Hôtellerie TV et Affichage digital

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

Le « casting en chambre » (projeter Netflix, YouTube, Spotify… depuis le smartphone du client vers la TV) paraît simple. En réalité, c’est un sujet d’exploitation “jour 2” : selon l’approche retenue, la même promesse peut générer très peu d’appels… ou au contraire une succession de tickets (appairage, “mauvaise TV”, confidentialité, TV bloquée sur un compte, reset au départ, etc.).

Le guide AHLA/HTNG “Guest Room Entertainment – Product Orientation and System Considerations” (v1.0, 2022) insiste notamment sur deux axes qui devraient être contractualisés dès l’amont : la sécurité / confidentialité (caster uniquement vers la bonne chambre) et la réinitialisation entre séjours (manuelle, temporisée, ou automatisée via PMS).

Clarification sur le terme “mode invité”. Dans cet article, « mode invité » désigne un parcours de casting managé et opérable (onboarding guidé, association à la bonne chambre, et reset/turnover entre séjours). Ce n’est pas la fonction Guest mode de Chromecast : le guide AHLA/HTNG cite au contraire, côté bonnes pratiques Chromecast, la recommandation de désactiver ce Guest mode (à traiter comme une option spécifique du produit, distincte du “mode invité” au sens hôtelier).

Clarifier le périmètre : casting, OTT sur la TV, IPTV… ce ne sont pas les mêmes problèmes d’exploitation

Avant de comparer des marques ou des fonctionnalités, il est utile de séparer trois couches, car elles n’ont pas les mêmes impacts sur le support :

  • Casting (Chromecast / AirPlay) : le client pilote la lecture depuis son terminal, et la TV devient un “récepteur”.
  • Apps OTT sur la TV : le client utilise directement des applications sur la TV (souvent avec authentification et donc un enjeu d’effacement au départ).
  • Socle TV hôtelier (coaxial / IPTV / hybride) : diffusion des chaînes linéaires et de l’expérience TV de base, avec ses propres contraintes de distribution et de maintenance.

Pour le socle “chaînes TV”, et pour éviter de mélanger les sujets, vous pouvez vous appuyer sur : IPTV ou télédistribution coaxiale : quelle architecture pour un hôtel ? et Comment distribuer les chaînes TV dans un hôtel ou une résidence ?

Trois approches de “casting en chambre” (et ce que ça change en tickets support)

Approche A — Le client apporte son dongle (Chromecast / Apple TV “BYOD”)

Sur le papier, c’est l’option la plus simple pour l’hôtel : “le client se débrouille”. En pratique, elle échoue souvent sur un point très concret : les réseaux Wi‑Fi d’hôtels reposent fréquemment sur un portail captif (page d’acceptation / authentification). Or Google indique que les appareils de streaming Google ne supportent pas les réseaux nécessitant une connexion via portail captif, typiques des hôtels.

Source : Google Chromecast Help — captive portal networks.

Conséquence exploitation : quand le client a un problème, vous n’avez ni standard matériel, ni pilotage, ni procédure reproductible. C’est souvent un ticket “réception / IT”, sans garantie de résolution.

Approche B — Casting “géré” par l’hôtel (Chromecast/AirPlay intégrés + onboarding maîtrisé)

C’est l’approche la plus cohérente lorsque l’objectif est la réduction des tickets et une confidentialité crédible. Le guide AHLA/HTNG met en garde contre le casting “non géré” en environnement hôtelier (risques de diffusion vers la mauvaise chambre et de modifications non désirées de réglages/affichages), et décrit des mécanismes de gestion visant à permettre un casting “sécurisé”.

Source : AHLA/HTNG — Guest Room Entertainment Requirements.

Conséquence exploitation : vous pouvez définir un parcours invité, une procédure de reset, une supervision, et surtout une responsabilité claire entre intégrateur, éditeur, opérateur Wi‑Fi et exploitation.

Approche C — Apps OTT directement sur la TV (Netflix/YouTube intégrés)

C’est souvent un complément utile, mais cela déplace le sujet : dès que vous demandez au client de saisir ses identifiants sur la TV, l’enjeu devient l’effacement des données et des sessions au départ (checkout) et en cas de changement de chambre.

Le guide AHLA/HTNG inclut explicitement la question du reset entre séjours, y compris via intégration PMS selon les solutions.

Source : AHLA/HTNG — sections sur reset / PMS.

Définir “opérable” : la grille de décision côté MOA / exploitation

Une solution est “opérable” si, une fois l’hôtel ouvert, elle reste compréhensible, réinitialisable et supportable sans dépendre d’une équipe IT surdimensionnée ni d’actions manuelles systématiques en chambre.

Confidentialité inter-chambres : le critère non négociable

Le minimum attendu est simple à énoncer : un client ne doit jamais pouvoir voir la TV d’une autre chambre, ni sélectionner un mauvais “récepteur”. Le guide AHLA/HTNG traite ce point comme un critère de sécurité/expérience, et présente des familles d’approches (par exemple proxy mDNS, ou réseaux “par chambre” de type PAN/VLAN dynamique) pour gérer le casting de façon sécurisée.

Source : AHLA/HTNG — méthodes proxy/mDNS et PAN/VLAN dynamique.

Côté Domocasa, pour la compréhension du mécanisme réseau sans transformer cet article en guide d’ingénierie, vous pouvez lire : Hôtel : partager ses contenus sur la TV sans accéder aux autres chambres.

Onboarding “sans réception” : viser un parcours autoporteur

Chaque étape supplémentaire (changer d’entrée HDMI, trouver un menu, saisir un code, comprendre un SSID, etc.) augmente mécaniquement le volume d’assistance. Les parcours par QR code sont un bon exemple d’onboarding qui limite la friction.

  • Apple décrit, dans son guide iPhone, un usage “AirPlay in your hotel room” basé sur QR code et des étapes guidées (connexion Wi‑Fi et association à la TV).
  • Apple illustre également un modèle “privacy by design” dans certains hôtels IHG : QR code unique par chambre et connexion effacée lors du checkout (exemple de niveau d’exigence à viser contractuellement, même si votre solution n’est pas identique).

Sources : Apple Support — Use AirPlay in your hotel room ; Apple Newsroom — AirPlay in select IHG Hotels & Resorts properties.

Reset / turnover : ce qui “sauve” ou “tue” l’exploitation

Le guide AHLA/HTNG recommande de clarifier comment le système est réinitialisé entre séjours : action manuelle, effacement temporisé, ou automatisation via PMS selon les cas. Pour la MOA, la bonne question n’est pas “est-ce possible ?” mais :

  • Qui déclenche le reset (PMS, housekeeping, front desk, supervision) ?
  • Quand (checkout, chambre libérée, changement de chambre, passage en maintenance) ?
  • Que remet-on à zéro (appairages, sessions, historique, paramètres TV, associations réseau) ?
  • Comment prouve-t-on que l’effacement est effectif (démonstration en chambre témoin et procédure de test en recette) ?

Source : AHLA/HTNG — reset manuel/temporisé/PMS.

Organisation support : séparer “front desk” et “IT/OPS” avec un runbook simple

Un projet “opérable” définit clairement ce que fait :

  • La réception (message standard, vérifications simples, escalade au bon niveau).
  • Le support IT/OPS (diagnostic, remise en service, actions à distance si possible).
  • Le prestataire / intégrateur (analyse de cause, corrections structurelles, mises à jour, garanties).

Pour structurer cela au niveau “méthode projet”, l’article DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ? aide à cadrer les livrables attendus (procédures, référentiels, responsabilités).

Checklist RFP : questions à poser (avec démo et tests “chambre témoin”)

Plutôt qu’une liste de fonctionnalités marketing, demandez une démonstration centrée sur des scénarios d’exploitation. Voici une base de questions “qui évitent les mauvaises surprises”.

Sécurité et confidentialité

  • Comment garantissez-vous que le client ne voit que la TV de sa chambre ? (Mécanisme, garde-fous, cas limites.)
  • Que se passe-t-il en cas de changement de chambre (upgrade, maintenance, surbooking) ?
  • Quelles données sont conservées (journaux, identifiants, associations), où, et comment sont-elles effacées ?

Turnover / reset

  • Quelle est la stratégie de reset : manuelle, temporisée, automatisée via PMS ? (Démonstration attendue.)
  • Que couvre le reset : appairage, sessions, paramètres TV, comptes OTT, associations réseau ?

Expérience client (parcours réel)

  • Quel est le parcours exact en chambre : QR code, menu TV, télécommande, choix d’entrée HDMI ?
  • Le parcours reste-t-il compréhensible si le client ne parle pas la langue locale ?
  • Qu’est-ce qui est affiché à l’écran quand le casting échoue (message actionnable vs message technique) ?

Réalité Wi‑Fi (sans transformer le sujet en “refaire le réseau”)

  • Votre solution fonctionne-t-elle si le Wi‑Fi invité repose sur un portail captif ? (Point critique, voir la limitation documentée côté Google.)
  • Comment conciliez-vous l’isolation entre clients et la découverte des récepteurs (ex. mDNS), sans exposer les chambres entre elles ?

Sources : Google Chromecast Help — captive portal ; AHLA/HTNG — casting managé et méthodes de séparation. Pour aller plus loin côté Wi‑Fi invité (sécurité vs simplicité), voir : Wi‑Fi invités : quelle sécurité choisir pour garder une connexion simple ?

Exploitation, mises à jour et modes dégradés

  • Quels incidents sont traitables à distance (sans entrer en chambre) ? Lesquels nécessitent une action locale ?
  • Quelle est la politique de mises à jour (côté TV, côté récepteurs, côté plateforme) et quel est le plan de retour arrière si une mise à jour dégrade l’expérience ?
  • Quel est le comportement en mode dégradé : Wi‑Fi instable, Internet dégradé, plateforme indisponible, TV redémarrée ?

Procédures “jour 2” : un standard simple et réaliste

À adapter à votre organisation, mais l’important est d’avoir des procédures courtes, testées, et réellement appliquées.

Au check-in

  • Message unique, facile : “Pour partager votre contenu sur la TV, scannez le QR code affiché à l’écran.” (Le parcours AirPlay par QR code est documenté côté Apple.)
  • Si intégration PMS : vérifier en recette que l’état “occupée” active bien l’expérience attendue (et que l’état “libre” retire bien les associations).

Source : Apple Support — AirPlay à l’hôtel.

Pendant le séjour (support niveau réception)

  • Vérifier que le client est sur le bon Wi‑Fi (SSID invité attendu, pas un réseau personnel ou un hotspot).
  • Faire répéter le parcours (QR code / association) plutôt que “toucher à la TV” sans méthode.
  • Escalader si le symptôme touche la confidentialité (voir ci-dessous).

Au checkout

  • Exiger un effacement automatique si possible (idéalement lié au checkout ou à l’état de chambre), ou définir une procédure staff si ce n’est pas faisable dans votre contexte.
  • Se donner une méthode de vérification simple en chambre témoin (recette) : démontrer que l’association n’est plus valide après checkout.

À titre d’exemple d’exigence “privacy”, Apple décrit dans le cas IHG une connexion effacée au checkout (modèle d’intention, à traduire contractuellement selon votre solution).

Source : Apple Newsroom — AirPlay in select IHG Hotels & Resorts properties.

Ticket critique : “je vois une autre TV / je peux caster ailleurs”

Traitez ce cas comme un incident majeur de confidentialité :

  • Couper temporairement la fonction casting de la chambre concernée (ou du groupe de chambres) selon les possibilités.
  • Corriger la cause (erreur d’affectation, de segmentation, ou de mécanisme de découverte) avant remise en service.
  • Documenter le scénario et le test de non-régression pour la recette.

Le guide AHLA/HTNG met précisément en avant le risque de diffusion vers une “mauvaise chambre” lorsque le casting n’est pas géré correctement.

Source : AHLA/HTNG — risques d’un environnement non managé.

Intégration SI hôtel : PMS, GRMS, réseau… qui fait quoi ?

Pour rester “opérable”, une solution de casting/OTT doit éviter les responsabilités floues. Les états du séjour (check-in, chambre occupée, checkout, out-of-order) relèvent souvent du PMS et structurent les actions d’exploitation (activation, désactivation, reset). En parallèle, certains systèmes de chambre (GRMS) orchestrent déjà des états de chambre et des scénarios d’exploitation.

Si vous souhaitez cadrer ces interfaces au niveau “architecture fonctionnelle”, lire : GRMS : comment fonctionne la gestion intelligente d’une chambre d’hôtel ?

À retenir : une décision rapide, sans se tromper de problème

  • Éviter le casting “non géré” en environnement hôtelier : la confidentialité et la maîtrise des comportements en dépendent. (Référence AHLA/HTNG.)
  • Contractualiser le reset/turnover : qui déclenche, quand, quoi, et comment on vérifie. (Référence AHLA/HTNG.)
  • Privilégier un onboarding autoporteur (ex. QR code) pour réduire la dépendance à la réception. (Références Apple.)
  • Ne pas bâtir la stratégie sur le BYOD dongle si votre Wi‑Fi repose sur portail captif : la limitation est documentée côté Google. (Référence Google.)

Si vous souhaitez cadrer ce sujet dans un programme plus large “courant faible & expérience client”, vous pouvez aussi consulter : Courant faible dans un hôtel : les systèmes indispensables à prévoir.

Besoin d’un cadrage AMO (RFP, scénarios de recette, livrables d’exploitation) pour votre projet au Maroc ? Domocasa peut vous aider à formaliser une approche qui limite les tickets support et reste maintenable après ouverture.

Sources et documentation (références primaires)

17Août

Rénover ou étendre la GTB d’un hôtel : que change BACnet/SC (Secure Connect) et comment le tester avant migration ?

by Domocasa
Guides techniques Hôtellerie Smart Building et GTB

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

Pourquoi BACnet/SC arrive dans les projets GTB d’hôtels (rénovation, extension, multi-bâtiments)

Dans un hôtel, la GTB/BMS n’est plus un « îlot technique » : supervision, accès de maintenance, interconnexion de bâtiments, coexistence avec l’IT (réseau, virtualisation, sauvegardes) et contraintes de cybersécurité deviennent structurantes. Dans ce contexte, BACnet/SC (BACnet Secure Connect) est souvent évoqué comme une évolution utile pour réduire certains risques « sur le fil » et rendre l’architecture plus gouvernable.

BACnet/SC ne remplace pas BACnet : c’est une option standardisée de couche liaison (data link) introduite par des addenda au standard BACnet (ANSI/ASHRAE 135), et présentée comme un moyen de transporter des messages BACnet au-dessus de connexions WebSocket sécurisées par TLS. Pour une synthèse « industrie », voir la page BACnet International dédiée à BACnet/SC.

BACnet/SC, en clair : ce que c’est (et ce que ce n’est pas)

Ce que c’est

  • Une option de transport pour BACnet : BACnet/SC encapsule des messages BACnet dans des connexions WebSocket, typiquement en mode sécurisé (WSS), en s’appuyant sur TLS (voir l’addendum « bj » accessible publiquement).
  • Une architecture qui s’organise autour d’une “hub function” : le standard décrit une fonction de hub pour relayer certains types de trafic (notamment des mécanismes équivalents aux usages « broadcast »), ce qui change la manière de raisonner en flux et en dépendances.
  • Une problématique certificats/PKI : BACnet/SC introduit (dans la pratique) la nécessité d’une gouvernance des certificats, côté nœuds et côté hub, avec des impacts directs sur l’exploitation.

Ce que ce n’est pas

  • Un “patch sécurité global” : chiffrer et authentifier un transport ne durcit pas un superviseur, ne corrige pas des mots de passe faibles, ne segmente pas le réseau à votre place, et ne remplace pas la supervision sécurité.
  • Une politique d’autorisations métier clé en main : BACnet/SC répond d’abord à un besoin de transport sécurisé. La gouvernance « qui a le droit de faire quoi » (procédures, comptes, rôles, accès distants) reste un sujet projet.
  • Une preuve de conformité multi-constructeurs : l’interopérabilité réelle dépend des équipements, des versions et de la manière dont chaque fabricant met en œuvre BACnet/SC. Elle doit être testée dans votre contexte (périmètre, topologie, exploitation).

Ce que BACnet/SC sécurise réellement (et pourquoi c’est utile en hôtellerie)

Sur la base des textes publics disponibles (addenda ASHRAE/ BACnet et pages d’organismes), BACnet/SC vise essentiellement à réduire les risques d’écoute/modification « sur le transport » et à rendre l’établissement de communications plus maîtrisable dans des environnements où l’IT exige des pratiques proches des standards réseau modernes :

  • Confidentialité et intégrité “sur le fil” : les échanges sont transportés via WebSocket sur TLS (WSS), ce qui limite l’écoute passive et la modification triviale du trafic sur des segments réseau partagés.
  • Authentification des pairs via certificats : l’usage de TLS implique une chaîne de confiance et une notion d’identité des équipements (nœuds/hub), au lieu d’une communication « implicitement de confiance » sur un VLAN OT.
  • Une logique “sessions” et connexions établies : l’approche connection-oriented est mise en avant par BACnet International comme un changement structurant par rapport à des transports historiquement plus permissifs.

Dans un hôtel, cela peut être particulièrement pertinent dès que la GTB doit cohabiter avec des contraintes fortes (segmentation IT/OT, prestataires multiples, exploitation multi-sites, accès de maintenance). Mais l’intérêt ne se démontre pas par une promesse : il se valide par une architecture et des tests (voir plus bas).

Ce que BACnet/SC ne fait pas (limites à expliquer dès l’AMO)

Il ne garantit pas l’intégrité logicielle des équipements

Sur la partie « confiance dans le code exécuté », un addendum public lié à BACnet/SC explicite qu’il est assumé que les pairs d’une connexion WebSocket établie sont « de confiance » (y compris le code qu’ils exécutent) et que la validation de ce code et de son origine est hors périmètre du standard : voir ANSI/ASHRAE Addendum cd to ANSI/ASHRAE Standard 135-2020 (PDF). Autrement dit : BACnet/SC protège un transport, pas la chaîne de confiance logicielle de vos contrôleurs, passerelles et serveurs.

Il n’automatise pas la gouvernance “certificats” (rotation, révocation, départ prestataire)

Un autre point important, souvent sous-estimé en exploitation : les contrôles de certificats « additionnels » (au-delà d’un socle minimal) ne sont pas faits par défaut, afin de préserver l’interopérabilité, et la prise en charge/la mise à jour des informations de révocation est explicitement décrite comme une décision locale. Là encore, voir ANSI/ASHRAE Addendum cd to ANSI/ASHRAE Standard 135-2020 (PDF). En pratique, la réussite dépend d’un choix clair : qui porte l’autorité de certification (CA), comment on renouvelle, comment on révoque, comment on audite.

Il ne remplace pas la segmentation réseau (et peut même créer un faux sentiment de sécurité)

Chiffrement ≠ cloisonnement. Si votre architecture autorise trop de chemins (VLAN mal séparés, règles firewall trop ouvertes, bastions absents, accès distants non maîtrisés), BACnet/SC ne corrigera pas ces défauts. Il faut continuer à concevoir une segmentation, des flux autorisés, des comptes et des procédures.

Architecture BACnet/SC : hub, redondance, et dépendances à assumer

Le hub devient un actif critique

Le modèle “hub-and-spoke” change la lecture des risques. Le hub concentre des fonctions de relais et devient un composant à traiter comme critique : durcissement, sauvegarde, supervision, logs, cycle de vie, et parfois haute disponibilité.

Primary hub / failover hub : attention aux règles propres aux fabricants

Le standard évoque un concept de hub et la notion de continuité associée. Côté mise en œuvre, les fabricants peuvent imposer des contraintes de topologie et de rôle. Par exemple, la documentation Johnson Controls (Facility Explorer) décrit un Primary Hub et un Failover Hub optionnel, et donne un cadre de fonctionnement et de bascule qui doit être compris et testé avant de généraliser en hôtel.

À décider au niveau projet : qu’est-ce que votre “site” BACnet/SC ?

En hôtellerie, la question n’est pas théorique. Selon l’organisation de l’exploitation et la topologie (plusieurs bâtiments, extension, tour + annexes, SPA indépendant, logements du staff, etc.), la notion de “site” peut recouvrir :

  • un bâtiment,
  • un campus hôtelier,
  • un ensemble de sous-réseaux OT,
  • ou un périmètre d’exploitation contractuel (un mainteneur, une gouvernance certificats).

Cette décision impacte la PKI, le réseau, la résilience et la capacité de diagnostic.

TLS, certificats et CA : la partie “invisible” qui fait réussir (ou échouer) la migration

BACnet/SC introduit mécaniquement une discipline certificats. C’est souvent là que les projets se compliquent, non pas techniquement, mais opérationnellement.

Ce qu’il faut clarifier avant d’écrire un CCTP

  • Qui détient la CA ? Propriétaire/Exploitant, intégrateur, mainteneur, DSI groupe ? La réponse doit être contractuelle, pas “implicite”.
  • Quel processus d’onboarding ? Demande de certificat, signature, déploiement, association à l’équipement, validation.
  • Quel processus de renouvellement ? Calendrier, responsabilité, supervision des expirations, fenêtre d’intervention réaliste en exploitation hôtelière.
  • Quel processus en cas d’incident ? Départ d’un prestataire, compromission suspectée, rotation d’une CA, retrait d’un équipement.

Selon les gammes, des guides de mise en service détaillent des workflows (exemple : documentation Facility Explorer BACnet/SC). L’objectif côté AMO/BE n’est pas d’imposer un outil unique, mais d’exiger un livrable exploitable : procédures, responsabilités, et preuve de test en conditions réalistes.

Comment évaluer BACnet/SC dans une rénovation/extension d’hôtel (méthode pragmatique)

Le bon objectif n’est généralement pas “basculer tout le BACnet en BACnet/SC” d’un coup, mais de prouver ce que BACnet/SC apporte sur un périmètre pilote, et d’identifier les dépendances d’exploitation avant généralisation.

Étape A — Cartographier le “BACnet réel”, pas le BACnet théorique

  • Quels sous-systèmes parlent BACnet (CVC, CTA, production, comptage, parkings, etc.) ?
  • Quels sont les consommateurs de données (supervision, GMAO, énergie, BI, dashboards) ?
  • Quels sont les points d’entrée (postes opérateurs, VPN, accès mainteneur, interconnexions) ?
  • Quelles frontières réseau existent déjà (VLAN OT/IT, DMZ, bastion) ?

Dans la majorité des rénovations, cette cartographie est le vrai point de départ : elle évite de “sécuriser” une surface mal définie.

Étape B — Définir une architecture cible “minimum viable” (pilotable et réversible)

  • Identifier où la fonction de hub sera portée (serveur, superviseur, appliance), et qui l’exploite.
  • Décider si un mécanisme de continuité (failover) est requis au regard des impacts métiers.
  • Définir des flux réseau explicites : qui initie, qui accepte, depuis où, et comment c’est journalisé.

Point de vigilance : évitez d’écrire des exigences “de port” ou de “paramètres par défaut” sans documentation fabricant du matériel réellement retenu. Le cahier des charges doit plutôt exiger une matrice de flux et une preuve de test sur l’architecture retenue.

Étape C — Piloter sur un segment et tester la résilience (avant d’étendre)

Choisissez un périmètre pilote compatible avec l’exploitation (fenêtre d’intervention, retour arrière possible). Validez notamment :

  • établissement des connexions et stabilité,
  • reconnexions après coupure réseau, redémarrage hub, redémarrage nœud,
  • comportement en mode dégradé (perte hub principal, bascule si un mécanisme de failover est mis en place),
  • qualité des logs : diagnostic faisable par l’exploitant, pas seulement par un intégrateur “avec son PC”.

Étape D — Tester l’exploitation certificats (ce qui casse vraiment les projets)

Ajoutez des scénarios “vrais de vrais” dans la recette :

  • ajout d’un nouvel équipement (onboarding complet),
  • remplacement d’un contrôleur,
  • certificat expiré (détection, alerte, rétablissement),
  • rotation de confiance (changement de CA ou retrait d’un prestataire),
  • restauration hub (sauvegarde/restauration + vérification de la confiance et des services).

Le point clé : si ces opérations ne sont pas simples, documentées et attribuées à un responsable, BACnet/SC peut devenir une dette d’exploitation au lieu d’un gain sécurité.

Compatibilité et trajectoire de migration : ce qu’on peut dire, et ce qu’il faut exiger

Ce qu’on peut affirmer sans surpromettre

  • BACnet/SC fait partie des évolutions normalisées de BACnet via des addenda au standard ANSI/ASHRAE 135 (voir la liste des addenda sur bacnet.org et l’addendum “bj” accessible publiquement).
  • Les implémentations concrètes (hubs, nœuds, outils de certificats, limites) sont documentées par les fabricants au cas par cas (exemple : guides Johnson Controls Facility Explorer).

Ce qui doit être vérifié “produit par produit” (et donc écrit dans le dossier de consultation)

  • Quels équipements existants sont réellement migrables vers BACnet/SC (mise à jour firmware, changement de matériel, passerelle) ?
  • Quels rôles sont supportés : nœud uniquement, hub, support du mécanisme de continuité ?
  • Quelles sont les exigences IT associées (certificats, sauvegardes, OS si hub sur serveur, mécanismes de logs) ?
  • Quelle preuve de test multi-constructeurs est fournie (interop) dans une topologie comparable à votre hôtel ?

Check-list AMO/BE : les questions qui évitent les migrations “déceptives”

  • Architecture : où se situe la fonction de hub, comment est-elle durcie, sauvegardée, supervisée ?
  • Continuité : que se passe-t-il si le hub devient indisponible (localement, ou depuis une partie du réseau) ?
  • Certificats : qui porte la CA, quels workflows, quels livrables, quels accès, quelles responsabilités ?
  • Exploitation : quels logs, quels diagnostics, quel runbook ? Qui est autonome après réception ?
  • Réseau : quelles règles de flux et comment prouver qu’on ne “tunnele” pas la segmentation OT/IT ?
  • Réversibilité : quel plan de retour arrière pendant la phase pilote, sans mettre l’hôtel en risque opérationnel ?
  • Interop : quels scénarios multi-marques ont été testés, et lesquels restent à valider chez vous ?

Conclusion : quand BACnet/SC vaut l’effort en hôtellerie

BACnet/SC devient particulièrement pertinent lorsque la GTB doit s’aligner avec des exigences IT (segmentation, chiffrement, traçabilité), lorsqu’une extension ou une interconnexion multiplie les flux, et lorsque l’exploitation exige des pratiques plus cadrées (prestataires, multi-sites, accès distants).

Mais pour éviter les déceptions, il faut le traiter comme un projet d’architecture + exploitation : hub (et éventuellement continuité), gouvernance certificats, procédures et tests, et intégration dans une démarche de cybersécurité globale.

Pour aller plus loin (hôtellerie)

Si vous préparez une rénovation ou une extension, l’approche la plus robuste est souvent de formaliser d’abord les flux et responsabilités (IT/OT), puis de cadrer un pilote BACnet/SC avec des tests d’exploitation (certificats, bascule, restauration) avant généralisation.

Sources et documentation (références publiques)

3Août

Déployer IPv6 dans un hôtel : choisir dual‑stack ou IPv6‑only (NAT64/DNS64) et sécuriser Wi‑Fi, IoT et exploitation

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

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

Pourquoi IPv6 devient un sujet « exploitation » dans un hôtel

Dans un environnement hôtelier, IPv6 n’est pas un simple sujet « réseau ». C’est un choix d’architecture qui touche directement :

  • l’expérience client sur le Wi‑Fi invités (portail captif, accès simple, compatibilité BYOD),
  • la continuité de service des systèmes IoT/OT bâtiment (GTB/GRMS, contrôle d’accès, CCTV, capteurs),
  • les usages IPTV/OTT et les équipements hétérogènes (TV, décodeurs, apps),
  • la sécurité (politique firewall et zones),
  • les journaux et la traçabilité (support, incidents, corrélation),
  • les méthodes de dépannage (outils, runbooks, supervision).

L’objectif de ce guide est volontairement opérationnel : comprendre les modèles de déploiement (dual‑stack vs IPv6‑only avec NAT64/DNS64), leurs risques concrets en hôtellerie, et une méthode de migration progressive sans « demi‑IPv6 » difficile à exploiter.

IPv6 en clair : ce qui change vraiment (sans cours de routage)

IPv6 est un protocole différent, avec son en‑tête et des en‑têtes d’extension

IPv6 définit un en‑tête de base et un mécanisme d’extension headers chaînables, identifiés via le champ Next Header. Ce modèle fait partie de la spécification IPv6. RFC 8200

Conséquence projet : il ne suffit pas de « cocher IPv6 ». Le comportement des équipements de sécurité (firewall, inspection, détection) et des politiques (filtrage, journalisation) doit être validé en IPv6, au même niveau de rigueur qu’en IPv4.

En dual‑stack, le terminal choisit IPv4 ou IPv6 (et peut basculer si l’un est dégradé)

Dans un réseau où IPv4 et IPv6 coexistent (dual‑stack), un même terminal peut tenter l’un ou l’autre pour atteindre une destination. Les algorithmes côté clients visent justement à réduire les délais visibles quand une famille est défaillante ou plus lente, en lançant des tentatives concurrentes. RFC 8305 (Happy Eyeballs v2)

Implication hôtelière : un IPv6 « parfois cassé » peut se traduire par des lenteurs intermittentes (temps d’attente, comportements incohérents d’apps), tout en étant difficile à diagnostiquer puisque le terminal finira parfois par retomber sur IPv4… après un délai.

Les modèles de déploiement possibles en hôtellerie

Modèle A — IPv4‑only (héritage)

Vous limitez l’exploitation à un seul protocole et vous restez dans des schémas connus. Mais vous repoussez le sujet, et vous risquez de devoir compenser par davantage de complexité « autour » (NAT, plans d’adressage contraints, extensions de VLAN, interconnexions multi‑sites).

Modèle B — Dual‑stack (IPv4 + IPv6)

Le réseau fournit IPv4 et IPv6 sur les segments où c’est raisonnable (Wi‑Fi invités, LAN, certains VLAN métiers/techniques), et vous rendez les services accessibles dans les deux familles lorsque c’est pertinent.

  • Avantage : compatibilité maximale (BYOD, objets hétérogènes, TV/décodeurs), migration progressive.
  • Point de vigilance : vous opérez « deux piles » (adressage, règles, supervision). Le risque classique n’est pas la complexité technique en soi, mais l’asymétrie d’hygiène : une politique solide en IPv4 et une politique incomplète en IPv6.

Modèle C — IPv6‑only sur certains segments, avec NAT64/DNS64

Le segment (souvent candidat : Wi‑Fi invités, parfois un périmètre IoT maîtrisé) fonctionne sans IPv4. L’accès vers des destinations IPv4 est assuré via une chaîne de traduction et de résolution :

  • NAT64 : traduction stateful permettant à des clients IPv6‑only de joindre des serveurs IPv4 en unicast TCP, UDP ou ICMP. RFC 6146
  • DNS64 : côté DNS, synthèse de réponses AAAA à partir de réponses A, afin d’orienter le client IPv6 vers le traducteur (en cohérence avec NAT64). RFC 6147

En complément, on rencontre souvent 464XLAT dans les architectures IPv6‑only : combinaison d’une traduction stateful dans le cœur (référencée comme NAT64) et d’une traduction stateless côté « edge/client », pour fournir une connectivité IPv4 limitée à travers un réseau IPv6‑only. RFC 6877

Point clé hôtellerie : l’IPv6‑only avec traduction peut très bien fonctionner… à condition que les usages reposent sur le DNS et que les applications/équipements ne dépendent pas d’IPv4 « en dur » (littéraux IPv4, comportements atypiques). En Wi‑Fi invités, cela se valide par des tests représentatifs, pas par hypothèse.

Impacts concrets en hôtel : ce qui change par domaine

Wi‑Fi invités : portail captif, « walled garden » et cohérence IPv4/IPv6

Le Wi‑Fi invités est le plus exposé : appareils inconnus, diversité d’OS, exigences d’accès simple, pression sur le support.

En dual‑stack, le risque typique est un portail captif et des règles « pensées en IPv4 ». Exemple de symptômes :

  • le portail s’affiche mais certaines apps restent bloquées (car elles sortent en IPv6),
  • le parcours pré‑auth / post‑auth n’est pas strictement équivalent entre IPv4 et IPv6,
  • l’hôtel croit « isoler »… mais laisse un chemin IPv6 moins filtré.

En IPv6‑only + NAT64/DNS64, vous ajoutez des dépendances critiques :

  • le DNS récursif fourni au client doit être DNS64 (si vous adoptez ce modèle),
  • le chemin vers l’Internet IPv4 doit bien passer par NAT64,
  • les exceptions (paiement, OTA, outils d’assistance, etc.) doivent être testées « comme en vrai » (périmètre applicatif + conditions réseau réalistes).

Note d’exploitation : dans ce contexte, « walled garden » désigne généralement la liste d’exceptions autorisées avant authentification (par exemple DNS, accès à un site de paiement ou à une page spécifique), et elle doit rester cohérente en IPv4 et IPv6.

Pour la partie expérience et sécurité Wi‑Fi (portail captif, isolation, choix WPA3/OWE/802.1X), vous pouvez compléter avec : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client et Wi‑Fi invités : quelle sécurité choisir pour garder une connexion simple ?.

IoT/OT bâtiment : stabilité, hétérogénéité, et risques « silencieux »

Dans un hôtel, les réseaux techniques et IoT/OT sont rarement homogènes. On y trouve des équipements à cycles de vie longs, des passerelles, des firmwares peu mis à jour, et des dépendances de prestataires.

  • Dual‑stack est souvent le point de départ le plus prudent : vous conservez l’IPv4 pour le legacy et vous introduisez l’IPv6 là où vous maîtrisez (serveurs, supervision, passerelles, périmètres pilotes).
  • IPv6‑only avec NAT64/DNS64 peut être pertinent sur un sous‑ensemble très maîtrisé (par exemple des équipements gérés, standardisés, et testés), mais il faut anticiper les cas où l’équipement contacte des services via IPv4 littéral ou via des protocoles peu tolérants à la traduction.

Sur la segmentation et la cohabitation des lots (Wi‑Fi, IPTV, VoIP, CCTV, GRMS), une lecture utile : Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?

IPTV/OTT : diversité des terminaux et validation « références réelles »

Les services OTT reposent en général sur DNS et HTTPS, souvent via CDN. Dans ce contexte, IPv6 peut fonctionner sans douleur… mais l’écosystème hôtelier est hétérogène (TV de plusieurs générations, décodeurs, apps, DRM, mises à jour inégales).

Recommandation projet : quel que soit le modèle (dual‑stack ou IPv6‑only), validez sur vos références réelles (modèles de TV/décodeurs, apps effectivement déployées, scénarios d’usage client), avec une phase d’observation suffisante pour capter les effets « intermittents ».

Pour cadrer l’architecture TV côté hôtel : IPTV ou télédistribution coaxiale : quelle architecture pour un hôtel ?

VPN, support à distance et prestataires : éviter les angles morts

La bonne question n’est pas « le VPN supporte IPv6 » au sens marketing, mais :

  • devez‑vous transporter des réseaux IPv6 dans le tunnel (accès admin, supervision, inter‑sites) ?
  • vos politiques de filtrage et vos zones sont‑elles symétriques ?
  • vos journaux et outils de sécurité conservent‑ils les adresses IPv6 (et les rendent‑ils exploitables) ?

Sur la gouvernance cybersécurité et la séparation des environnements dans un hôtel connecté : Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ?

Firewall IPv6 : les points à traiter explicitement (pas « plus tard »)

Dual‑stack : « oublier IPv6 » équivaut à ouvrir une seconde porte

En dual‑stack, un même poste a potentiellement deux voies de sortie. Si votre politique est stricte en IPv4 mais permissive en IPv6 (par oubli, par défaut, ou par absence de règles), vous créez une voie de contournement involontaire.

Extension headers : valider le comportement de filtrage/inspection

IPv6 inclut un mécanisme d’en‑têtes d’extension chaînables. C’est un élément normal du protocole et il doit être compris par les briques de sécurité, au moins dans les cas couverts par votre périmètre. RFC 8200

À traduire en exigences projet : documenter et tester le comportement des équipements (firewall, IDS/IPS, outils de capture) sur les cas IPv6 pertinents pour votre exploitation, au lieu de supposer une équivalence automatique avec IPv4.

Politique simple par zones (exemple de logique)

Sans entrer dans une « norme » universelle, un hôtel gagne souvent à formaliser une politique par zones, puis à la décliner en IPv4 et IPv6 :

  • Invités : flux sortants strictement nécessaires (avec journalisation), isolation inter‑clients, pas d’accès vers les réseaux techniques/métiers.
  • IoT/OT : autoriser vers les collecteurs/contrôleurs et services attendus, bloquer le reste, limiter l’exposition latérale.
  • Admin : accès restreint, comptes nominaux, bastion si applicable, supervision renforcée.

Journaux, traçabilité et exploitation : ce qui devient plus exigeant avec IPv6

« Qui était ce client ? » ne doit pas dépendre uniquement de l’adresse IP

En hôtel, les demandes support et les incidents imposent souvent de corréler un événement réseau à un contexte : terminal, utilisateur, chambre, période, SSID, etc.

Avec IPv6, la corrélation uniquement via l’adresse IP est fragile : selon les OS et les mécanismes de confidentialité (adresses temporaires), l’adresse source peut évoluer. RFC 8981 La bonne pratique consiste à préparer des points de corrélation complémentaires (selon votre modèle Wi‑Fi et vos outils) :

  • identité (portail captif, comptes, jetons),
  • logs contrôleur Wi‑Fi (association, session),
  • logs d’authentification (si 802.1X/RADIUS),
  • logs DNS (encore plus utiles en DNS64 : comprendre ce qui a été synthétisé, et quand),
  • journaux firewall (avec une politique de conservation et d’export adaptée à l’exploitation).

Pour cadrer le sujet sous l’angle sécurité/exploitation (au‑delà des outils), une lecture normative utile : RFC 9099.

Sur les « services invisibles » qui font tomber un Wi‑Fi (et qui doivent être pensés avec le même sérieux en IPv6/dual‑stack) : Wi‑Fi d’hôtel en panne : vérifier les services d’adressage, de noms et d’authentification.

Adressage et nommage : éviter que le plan IPv6 devienne un second chaos

Dual‑stack signifie aussi « deux plans à tenir ». Même si IPv6 change les conventions, l’enjeu exploitation reste le même : une nomenclature cohérente, des plages documentées, et des choix clairs par VLAN/SSID.

Pour une méthode simple (adressage IP et noms, tous protocoles confondus) : Réseau d’hôtel : organiser les adresses et les noms des équipements.

Choisir entre dual‑stack et IPv6‑only (NAT64/DNS64) : une grille de décision

Choisir plutôt le dual‑stack si…

  • vous avez beaucoup d’équipements hétérogènes (IoT/OT, TV, décodeurs, solutions tierces) dont vous ne maîtrisez pas le comportement IPv6,
  • vous voulez réduire le risque de compatibilité à court terme,
  • vos outils d’exploitation/sécurité ne sont pas encore outillés pour traiter IPv6 au même niveau que l’IPv4 (tableaux de bord, parsers, corrélation, runbooks).

Envisager IPv6‑only + NAT64/DNS64 si…

  • vous cherchez à standardiser un segment (souvent le Wi‑Fi invités) et à limiter l’extension d’IPv4 interne,
  • vous pouvez conduire un plan de tests réaliste (panel d’appareils + scénarios),
  • vous acceptez d’introduire une dépendance forte à la chaîne DNS64/NAT64, et vous l’exploitez comme un service critique (monitoring, logs, procédures).

Compromis fréquent (et souvent raisonnable en hôtellerie)

  • Cœur/distribution : dual‑stack, pour garder de la flexibilité.
  • Wi‑Fi invités : dual‑stack au départ (stabiliser sécurité + exploitation), puis évaluer IPv6‑only sur la base de tests et de retours support.
  • IoT/OT : dual‑stack (ou IPv4 segmenté) tant que la qualification équipement n’est pas faite.

Plan de déploiement progressif (orienté risques)

Étape 0 — Préparer l’exploitation avant d’activer IPv6 en production

  • Inventorier les dépendances : firewall, cœur réseau, contrôleur Wi‑Fi/portail captif, DNS, authentification, supervision, SIEM/logs.
  • Définir des critères d’acceptation : règles IPv6 équivalentes IPv4, journaux exploitables, procédure de dépannage, et capacité de retour arrière maîtrisée.

Étape 1 — Piloter en dual‑stack sur un périmètre limité

  • Choisir un périmètre pilote (un bâtiment, un SSID, un étage, un groupe de chambres test).
  • Observer les symptômes « utilisateur » (latences, applis qui se comportent différemment) et les symptômes « exploitation » (logs incomplets, règles manquantes).
  • Réviser la politique firewall et la journalisation jusqu’à une symétrie IPv4/IPv6 crédible.

Étape 2 — Industrialiser l’outillage et les runbooks

  • Supervision : visibilité sur l’état IPv6 (résolution, sessions, routage interne, dépendances DNS).
  • Runbooks : diagnostic Wi‑Fi invité, diagnostic DNS, diagnostic portail captif, diagnostic « certaines apps ne marchent pas ».

Étape 3 — Si pertinent, évaluer IPv6‑only + NAT64/DNS64 sur un segment

  • Valider le couple NAT64 + DNS64 comme une chaîne opérationnelle (logs, supervision, procédures). RFC 6146 / RFC 6147
  • Tester explicitement les cas « à risque » : applis ou équipements qui utilisent des littéraux IPv4, ou des comportements inattendus.
  • Documenter la stratégie pour les terminaux et scénarios qui ne passent pas (y compris l’évaluation d’un mécanisme de type 464XLAT selon vos contraintes). RFC 6877

Check-list de recette (tests réalisables) avant généralisation

Cette liste est volontairement orientée « tests que l’on peut exécuter », sans supposer un produit ou un constructeur.

  • Parcours Wi‑Fi invités : portail captif accessible et cohérent en IPv4/IPv6 (DNS, HTTP(S), redirections, certificats), et règles pré‑auth/post‑auth appliquées dans les deux familles.
  • Expérience applicative : panel représentatif (iOS/Android/Windows/macOS + TV/décodeurs utilisés), tests répétables (jour/soir, charge variable).
  • DNS : résolution cohérente, capacité à diagnostiquer « DNS répond mais l’app ne marche pas », et logs exploitables (notamment si DNS64 est activé).
  • Sécurité : politique firewall IPv6 existante (pas seulement « autoriser tout »), segmentation effective, journalisation utile au support.
  • Traçabilité : capacité à relier un incident à une session (SSID/VLAN, borne, période, identité/portail, événements contrôleur).
  • Modes dégradés : que se passe‑t‑il si le DNS tombe ? si le portail est indisponible ? si la chaîne NAT64/DNS64 est dégradée ?

Questions à poser aux intégrateurs et fournisseurs (AMO / maîtrise d’ouvrage)

Ces questions servent à obtenir des réponses vérifiables (documentation, POC, recette), sans présumer des capacités d’un constructeur.

  • Le contrôleur Wi‑Fi et le portail captif gèrent‑ils des politiques strictement équivalentes en IPv4 et IPv6 (pré‑auth, post‑auth, walled garden) ?
  • Le firewall permet‑il de définir des objets/règles IPv6 avec la même granularité et le même niveau de logs qu’en IPv4 ?
  • Le DNS récursif supporte‑t‑il DNS64 (si vous visez IPv6‑only), et comment se font supervision et export des logs ?
  • Pour NAT64 : quels journaux de traduction sont disponibles, et comment corréler un incident « client » à une session traduite ? RFC 6146
  • Les outils SIEM/supervision de l’hôtel traitent‑ils IPv6 correctement (ingestion, parsers, corrélation) ?
  • Quelle est votre stratégie de tests (panel appareils, TV/décodeurs, applications), et votre stratégie pour les exceptions (appareils incompatibles) ?

À retenir

  • En hôtellerie, dual‑stack est souvent le meilleur point de départ : compatibilité BYOD, migration progressive, qualification des lots hétérogènes.
  • IPv6‑only + NAT64/DNS64 peut être excellent sur certains segments (souvent invités), à condition d’assumer une chaîne DNS64/NAT64 conçue comme un service critique, et validée par une recette réaliste. RFC 6146 / RFC 6147
  • Le risque le plus coûteux n’est pas « IPv6 ne marche pas », mais « IPv6 marche assez pour être utilisé… sans être correctement filtré, journalisé et supportable ». Les mécanismes côté clients (Happy Eyeballs) peuvent masquer une partie des symptômes sans régler la cause. RFC 8305

Sources et documentation (périmètre de ce guide)

  • RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification.
  • RFC 6146 — Stateful NAT64.
  • RFC 6147 — DNS64.
  • RFC 6877 — 464XLAT.
  • RFC 8305 — Happy Eyeballs v2.
  • RFC 8981 — Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6.
  • RFC 9099 — Operational Security Considerations for IPv6 Networks.

Si vous préparez une rénovation ou une mise à niveau réseau (Wi‑Fi, IPTV, segmentation, exploitation), l’enjeu est surtout de transformer ces choix en exigences testables et en procédures support. Domocasa peut vous accompagner en AMO pour cadrer l’architecture cible, la recette et les modes dégradés, avant l’appel d’offres.

30Juil

Rendre la gestion technique d’un hôtel maintenable : modéliser les points GTB/GRMS avec Project Haystack (site/equip/point, historiques, timezone)

by Domocasa
Guides techniques Hôtellerie Smart Building et GTB

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

Pourquoi la “liste de points” d’un hôtel devient vite ingérable

Dans un projet GTB/GRMS, on reçoit souvent un export « points automate » (adresses BACnet, objets Modbus, datapoints propriétaires, etc.) qui fonctionne pour afficher des valeurs… mais ne suffit pas à exploiter le bâtiment sur la durée. Dès que l’on veut faire de la supervision maintenable, des tendances fiables, de l’analytics, ou comparer plusieurs établissements, le problème n’est plus la connectivité : c’est la sémantique.

GTB signifie gestion technique du bâtiment (BMS) ; GRMS désigne généralement le Guest Room Management System (logique de chambre, interfaces client et échanges PMS, etc.).

Project Haystack propose un modèle pragmatique, centré sur des tags, pour transformer des signaux en données réutilisables. L’objectif de cet article est opérationnel : expliquer quoi exiger au DOE (et comment le recetter) pour obtenir une base site / equip / point exploitable en exploitation hôtelière.

Project Haystack en une phrase (version exploitation)

Dans Haystack, une entité (site, équipement, point, etc.) est décrite par un dictionnaire de tags. Une partie importante du “typage” se fait via des marker tags (des tags sans valeur) dont la présence porte le sens (ex. : site, equip, point). Voir : Project Haystack — Introduction.

Cette logique permet de requêter des objets par intention (tous les point historisés d’un site, tous les equip d’un étage, etc.) plutôt que de dépendre d’une convention de nommage fragile.

Le modèle minimal à exiger au DOE : site / space / equip / point

Haystack repose sur un mécanisme de “reflection” : on considère qu’un dict implémente une définition (def) lorsqu’il contient les tags appropriés. Par exemple, si un dict contient le marker equip, il est reflété comme implémentant la def equip. Voir : Project Haystack — Reflection.

Traduction opérationnelle (exigence DOE recommandée) : livrer des entités site, space/room, equip et point clairement taguées, pour que la base soit requêtable et réutilisable (supervision, analytics, multi-sites).

1) Site : la base du multi-sites (et l’endroit où poser la timezone)

Le site est l’entité qui représente l’installation (hôtel, bâtiment, tour, etc.). Dans la pratique projet, c’est l’unité qui vous permettra de faire de la comparaison inter-établissements sans “bricolage” (mêmes tags, mêmes requêtes, mêmes dashboards).

Le tag tz (timezone) peut s’appliquer à un site et sert d’identifiant de timezone. Voir : Project Haystack — def tz.

2) Space / Room : modéliser la chambre comme un objet exploitable

En hôtellerie, une “chambre” doit exister comme entité stable, sans dépendre du libellé d’un point. Haystack définit room comme une pièce fermée d’un bâtiment et précise que room est un sous-type de space. Voir : Project Haystack — def room.

Impact exploitation : vous pouvez agréger (confort, défauts, énergie) par chambre, par typologie, par étage, puis réutiliser la même structure sur un autre site.

3) Equip : l’actif (physique ou logique) qui porte les points

Les équipements sont modélisés avec le marker equip. Voir : Project Haystack — Equips. Un point clé pour éviter les “équipements orphelins” : la documentation indique que les entités equip doivent définir un siteRef vers leur site parent.

Deux tags sont ensuite très utiles en GRMS/GTB :

  • spaceRef pour rattacher un équipement à un espace (ex. contrôleur de chambre rattaché à une room).
  • equipRef pour modéliser la contenance/nesting d’équipements (ex. un sous-système au sein d’un ensemble).

4) Point : capteur, commande, consigne… mais toujours “attaché” à un equip

Un point est tagué avec le marker point. Voir : Project Haystack — Points. La documentation impose une règle essentielle pour la maintenabilité : un point doit être associé à siteRef et equipRef.

Ensuite, la fonction du point doit être explicite via pointFunction (classification sensor/cmd/setpoint, etc.). Voir : Project Haystack — def pointFunction.

Historisation et timezone : rendre les tendances réellement exploitables

Historiser n’est pas “cocher une case” : il faut un contrat de temps

Un point historisé est tagué his. Voir : Project Haystack — Points. Pour l’exploitation, l’enjeu n’est pas seulement de stocker des valeurs, mais d’obtenir des séries temporelles comparables (entre équipements, étages, sites) et interprétables (pas d’ambiguïtés sur le temps).

Haystack indique que si un point implémente his, alors tz et hisMode sont attendus. La même page précise que le tz d’un point historisé doit correspondre à la timezone du site du point.

Point d’attention (très pratique) : dans Haystack, tz est une chaîne (timezone name). Les valeurs attendues sont celles de la définition du tag tz (énumération) — par exemple Casablanca, UTC, New_York. Références : Points et def tz.

hisMode : sampled, cov, consumption… ce que cela change en analytics

Le tag hisMode « indicates the way that history data is collected for a point ». Voir : Project Haystack — def hisMode. Dans les faits, c’est un tag à exiger au DOE parce qu’il conditionne l’interprétation des courbes, des agrégations et des KPI.

  • sampled : séries échantillonnées à intervalle régulier (utile pour beaucoup de tendances de confort).
  • cov : log sur changement (Change Of Value). La valeur “tient” jusqu’au prochain événement (utile pour des états, des modes).
  • consumption : historique de consommation (données intégrales), avec une interprétation de timestamp “fin d’intervalle”.

Accès aux historiques : hisRead / hisWrite

Le chapitre Points mentionne les opérations d’API associées aux historiques, notamment hisRead et hisWrite. Voir : Project Haystack — Points. Pour un exploitant (ou un AMO data), cela permet de cadrer une exigence simple : les historiques doivent être exportables et testables (pas seulement visibles dans un écran).

Commande (writable) : éviter les “écrasements” entre GTB, GRMS et terrain

Le chapitre Points décrit les points commandables avec le marker writable et documente un pattern de commande incluant notamment des tags tels que writeVal, writeLevel, writeStatus, writeErr. Voir : Project Haystack — Points.

En pratique projet (recommandation) : ne livrez pas un point commandable sans livrer aussi la stratégie de priorité (qui a le droit d’écrire, et comment on diagnostique une commande non appliquée). Le but n’est pas d’exposer tous les détails au client final, mais de rendre le diagnostic possible quand plusieurs couches (commande locale, GRMS, GTB) se croisent.

Exemples de tags (hôtel) : une base simple à répliquer

Les exemples ci-dessous illustrent une structure “lisible exploitation” (site → room → equip → points). Ils doivent être adaptés à votre architecture (références, protocoles, fonctions réellement disponibles).

Format : les extraits sont au format Trio, un format texte prévu pour rédiger des entités Haystack à la main (une ligne par tag, les markers étant des tags sans valeur). Voir : Project Haystack — Trio.

Exemple 1 — Site (hôtel)

id: @hotel.demo
site
dis: "Hotel – Site Demo"
tz: "Casablanca"

Note : tz est un identifiant de timezone applicable aux sites et aux points (voir la définition du tag). Project Haystack — def tz.

Exemple 2 — Chambre (room) comme space

id: @hotel.demo.r0706
room
space
dis: "Chambre 706"
siteRef: @hotel.demo

Le tag room est défini comme sous-type de space. Project Haystack — def room.

Exemple 3 — Équipement “contrôleur de chambre”

id: @hotel.demo.r0706.ctrl
equip
dis: "Ch 706 – Controller"
siteRef: @hotel.demo
spaceRef: @hotel.demo.r0706

Le rattachement equip → siteRef est un invariant à exiger. Project Haystack — Equips.

Exemple 4 — Température mesurée (sensor) avec historique

id: @hotel.demo.r0706.temp
point
sensor
dis: "Ch 706 – Temp"
siteRef: @hotel.demo
equipRef: @hotel.demo.r0706.ctrl
spaceRef: @hotel.demo.r0706
kind: "Number"
unit: "°C"
his
tz: "Casablanca"
hisMode: "sampled"

Rappels de cadrage (issus de Points) : un point doit référencer siteRef et equipRef, et l’historisation impose tz et hisMode. Project Haystack — Points.

Exemple 5 — Occupation (consigne) “occupied sp”

Le chapitre Zones documente explicitement la combinaison occupied sp (et occupied sensor) pour modéliser l’occupation. Project Haystack — Zones.

id: @hotel.demo.r0706.occSp
point
occupied
sp
dis: "Ch 706 – Occupied (Schedule)"
siteRef: @hotel.demo
equipRef: @hotel.demo.r0706.ctrl
spaceRef: @hotel.demo.r0706
kind: "Bool"

Checklist DOE (et recette) : ce qu’il faut vraiment vérifier avant réception

Un modèle Haystack “déclaratif” ne suffit pas : il doit être recetté comme un livrable d’exploitation. Voici une checklist volontairement courte (à adapter au projet).

A. Structure et requêtabilité (bloquant)

  • Présence des markers d’entités attendues par votre projet (site, space/room, equip, point) pour que le “typage” Haystack soit exploitable en requêtes (principe de reflection/implementation). Project Haystack — Reflection.
  • Chaque equip a un siteRef cohérent (pas d’équipement “sans site”). Project Haystack — Equips.
  • Chaque point a siteRef + equipRef cohérents (pas de point “hors equip”). Project Haystack — Points.

B. Typage des points (bloquant)

  • pointFunction explicite et unique (sensor/cmd/sp/synthetic, selon le besoin). Project Haystack — Points.
  • kind cohérent avec la valeur (Bool/Number/Str) et unités renseignées lorsque nécessaire (recommandation projet : pas d’unité “implicite”).

C. Historisation (bloquant si vous faites du pilotage/analytics)

D. Commande (si GRMS/GTB doit écrire)

  • Tout point commandable est tagué writable et expose de quoi diagnostiquer une commande (writeLevel/writeStatus/writeErr, selon implémentation). Project Haystack — Points.

E. Livrables “data” à exiger (recommandation projet)

  • Un export complet des entités (sites/spaces/equips/points) au format texte (par ex. Trio) pour audit humain, et/ou au format tabulaire (par ex. Zinc) pour import/outillage.
  • Un jeu de requêtes de recette (exemples) permettant de prouver la cohérence siteRef/equipRef, et d’identifier rapidement les points historisés et commandables.

Gouvernance (projet) : ce que Haystack ne décide pas à votre place

Haystack fixe une structure sémantique, mais votre projet doit encore cadrer des règles d’exploitation. En particulier (recommandations de projet) :

Articles complémentaires Domocasa (pour cadrer un projet hôtel)

Si vous souhaitez transformer ces principes en annexes DOE (tags exigés, jeux de tests, livrables d’export et critères d’acceptation), Domocasa peut accompagner la maîtrise d’ouvrage et l’exploitant sur la partie “données & exploitation” du projet.

Sources et documentation (Project Haystack)

Copyright © 2025 Domocasa. All rights reserved.