Category "Hôtellerie"

5Nov

Cadrer énergie et confort d’un hôtel : comment traduire une “classe BACS” (ISO 52120‑1) en exigences et critères de recette

by Domocasa
Guides techniques Hôtellerie Smart Building et GTB

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

Dans un hôtel, l’automatisation n’est jamais un sujet « énergie » isolé. Elle touche simultanément : le confort client (et donc la réputation), la continuité de service, les équipes d’exploitation, et la consommation réelle (souvent tirée par le CVC, l’éclairage et des dérives de réglage). Résultat : quand on écrit un cahier des charges GTB/BMS, le risque n’est pas de manquer de fonctions… mais de ne pas réussir à transformer une ambition (« viser une classe BACS ») en exigences vérifiables et en tests de recette qui protègent le projet.

Ce guide propose une démarche praticable en maîtrise d’ouvrage, maîtrise d’œuvre et AMO : utiliser une logique de classes BACS (ISO 52120‑1) comme grille de cadrage, sans reproduire la norme (souvent accessible via achat), et surtout en traduisant chaque attente en critères testables sur un hôtel.

ISO 52120‑1 et « classes BACS » : ce qu’il est raisonnable d’en retenir pour un projet hôtelier

La fiche officielle ISO de l’ISO 52120‑1 indique que le document définit : (i) une liste structurée de fonctions liées au contrôle/automatisation et à la gestion technique, (ii) une méthode pour définir des exigences minimales ou des spécifications, et (iii) des méthodes pour estimer/évaluer l’effet de ces fonctions sur la performance énergétique (dont une approche « factor-based »). Source : ISO

Dans l’écosystème BACS, les classes (souvent présentées de A à D) servent à exprimer un niveau de fonctionnalité attendu, et non un choix de marque, de protocole (BACnet/KNX/Modbus…), ni une architecture unique.

Pour se représenter le type de fonctions concernées, un document de synthèse Siemens (basé sur EN ISO 52120‑1) illustre notamment des familles comme le contrôle d’éclairage (pilotage par occupation, pilotage par niveau lumineux / apport de lumière du jour), le contrôle des stores, et des mécanismes de coordination entre lots. Source : Siemens (document de synthèse)

Point de cadrage (Maroc) : ce guide n’est pas un chapitre réglementaire. Il propose une méthode de cadrage et de contractualisation (exigences + recette) utile dans un projet hospitality, quel que soit le pays, à adapter au contexte contractuel et d’exploitation de l’établissement.

La méthode (hôtel) : passer d’objectifs énergie/confort à des exigences GTB testables

Étape 1 — Écrire les objectifs « côté exploitation », avant de parler de classe

Commencez par formaliser quelques objectifs observables (et leurs limites) plutôt que des intentions générales. Exemples typiques en hôtellerie :

  • Confort : cohérence des températures ressenties, absence de bascules agressives, stabilité et simplicité des commandes.
  • Énergie : réduction des consommations en inoccupation, limitation des dérives (consignes trop basses/hautes, équipements en marche hors usage).
  • Exploitation : diagnostic possible sans dépendre d’un prestataire unique, alarmes utiles (pas « bruyantes »), historisation exploitable.
  • Expérience client : parcours d’arrivée, scènes, modes ménage, dérogations (late check-out, demande spécifique).

Ces objectifs deviennent vos « exigences de résultat » : ils guideront le choix de classe, puis les fonctions à exiger et les tests à prévoir.

Étape 2 — Découper l’hôtel en zones d’usage (et accepter qu’il n’y ait pas une seule classe partout)

Un hôtel est multi‑régimes. Chercher une seule classe uniforme sur tout le site conduit souvent à sur‑spécifier certaines zones et à sous‑sécuriser les zones critiques. Un découpage utile côté BACS/GTB ressemble souvent à :

  • Chambres et suites : CVC terminal, états (fenêtre, présence), modes (DND/MUR), éclairage et occultation selon architecture.
  • Parties communes : lobby, restaurant, salles de réunion/événementiel (usages variables, calendriers, scénarios).
  • Circulations : éclairage (présence/horaires), exigences simples mais robustes.
  • Back‑of‑house : bureaux, locaux staff (contraintes et priorités différentes).
  • Production CVC : chaufferie / production de froid / CTA / ECS (souvent très rentable à superviser et optimiser).

Livrable : une nomenclature des zones (codes stables), réutilisable ensuite dans le point naming GTB, les synoptiques et les PV de recette.

Étape 3 — Définir une classe cible par zone/système (et documenter les hypothèses)

La classe (A/B/C/D) devient une décision de niveau de service. Pour éviter l’effet « objectif marketing », associez à chaque choix :

  • ce que l’exploitation saura maintenir (compétences, organisation, prestataires),
  • ce que vous voulez être capable de prouver en recette (mesures, journaux, tendances),
  • ce que vous acceptez comme modes dégradés (panne capteur, perte supervision, etc.).

En pratique, beaucoup de projets hospitality choisissent des exigences plus fortes (donc un niveau fonctionnel plus ambitieux) sur : chambres (logique d’occupation), production CVC, zones événementielles, et ce qui génère des plaintes ou des dérives coûteuses.

La matrice « fonctions → exigences → preuves » : l’outil qui transforme une classe en clauses contractuelles

ISO 52120‑1 annonce explicitement une méthode pour définir des exigences minimales/spécifications autour des fonctions BACS/TBM. Source : ISO

Sans recopier de tableaux normatifs, vous pouvez mettre en place une matrice (tableau dans le CCTP ou fichier partagé projet) qui lie chaque attente à une preuve. Structure recommandée :

  • Zone (code),
  • Système (CVC, éclairage, stores, supervision…),
  • Fonction attendue (libellé métier),
  • Classe cible (comme niveau minimal visé),
  • Exigence testable (condition → comportement → résultat attendu),
  • Données nécessaires (points, états, consignes, historiques),
  • Priorités & dérogations (qui a la main ? combien de temps ? que se passe‑t‑il ensuite ?),
  • Test de recette (procédure),
  • Preuve (capture supervision, tendance horodatée, log contrôleur, PV),
  • Critère d’acceptation (valeur cible / tolérance / « à définir »).

Patron d’écriture (simple) pour rendre une exigence vérifiable

  • Déclencheur : un événement (occupation, horaire, ouverture fenêtre, changement consigne…).
  • Action attendue : ce que le système doit faire (mode, consigne, limitation, scène…).
  • Résultat observable : ce qu’on doit voir en supervision/terrain (état, retour capteur, absence de conflit…).
  • Preuve : comment on le démontre (tendance, log, PV, capture écran horodatée).

Astuce projet : si vous n’arrivez pas à écrire la preuve, l’exigence est souvent trop floue (ou dépend d’un élément non prévu : capteur manquant, point non historisé, etc.).

Exemples (hôtel) : traductions en exigences testables sur le CVC et l’éclairage

Les exemples ci‑dessous sont des patrons. Ils servent à fabriquer vos clauses (avec vos paramètres projet), pas à imposer une stratégie unique.

Exemple A — Chambre : CVC piloté par occupation + état fenêtre (économie sans plaintes)

  • Exigence : « Quand la chambre passe de inoccupée à occupée, le CVC passe en mode Confort, sauf si la fenêtre est ouverte. »
  • Points nécessaires : état occupation (source à définir), état fenêtre, mode CVC, consigne, température, défauts.
  • Test : simuler les transitions (avec et sans fenêtre ouverte) et vérifier l’enchaînement des états + la cohérence des retours capteurs.
  • Preuve : tendance horodatée (occupation, fenêtre, consigne, température, mode) + PV.

Ce type d’exigence se combine très naturellement avec un cahier des charges GRMS. Voir : Cahier des charges GRMS hôtel : les points à spécifier.

Exemple B — Parties communes : éclairage sur présence + calendrier + apport de lumière du jour

Le document de synthèse Siemens (basé sur EN ISO 52120‑1) illustre des fonctions telles que le contrôle d’éclairage par occupation et par niveau lumineux / lumière du jour, classées par niveaux. Source : Siemens (document de synthèse)

  • Exigence : « En zone lobby, l’éclairage doit suivre un calendrier (journée/soirée/événement) et intégrer une logique d’absence (extinction/abaissement) sans dégrader l’accueil. »
  • Option si capteurs : « Si une régulation sur lumière du jour est retenue, la consigne cible, les limites (plancher/plafond) et le comportement en défaut capteur doivent être définis et testés. »
  • Test : tester un changement de calendrier, une simulation de présence/absence, puis une variation de mesure (si applicable) et observer la réponse.
  • Preuve : capture des états/scènes, journaux, et tendances d’ordres (dimming/ON/OFF) selon architecture.

Si votre projet inclut DALI‑2, vous pouvez compléter avec une recette dédiée : Réception d’un éclairage DALI‑2 en hôtel.

Exemple C — Stores, éclairage et CVC : clarifier « qui commande quoi » (sinon, recettes impossibles)

Une difficulté classique en hôtel est la coordination entre : occultation (confort visuel/thermique), scènes d’éclairage (ambiance/housekeeping) et CVC (charge thermique). Le document Siemens mentionne explicitement des logiques de coordination entre lots (ex. combinés lumière/stores/CVC). Source : Siemens (document de synthèse)

Dans votre matrice, forcez la clarification par écrit :

  • priorité client vs priorité énergie (et durée des overrides),
  • priorité commande locale vs commande centrale,
  • comportement en mode ménage et en chambre libérée,
  • comportement en cas de perte de communication entre sous‑systèmes.

Recette GTB/BMS : transformer vos exigences en tests (sans découvrir les problèmes en fin de chantier)

La valeur d’une « classe cible » se voit au moment de la recette : est‑ce que vous pouvez prouver que les fonctions attendues existent, sont réglées, et se comportent correctement en conditions réalistes ?

Recette fonctionnelle (type FAT/maquette) : valider la logique avant le chantier

  • Valider les séquences (modes, transitions, priorités).
  • Valider que les points nécessaires existent (et portent les bons états/unités).
  • Valider les scénarios d’exploitation (override, défaut capteur, mode dégradé).

Recette site (type SAT) : valider capteurs/actionneurs et sens d’action

  • Tests d’E/S (capteurs, actionneurs, retours d’état).
  • Vérification des alarmes utiles (défaut sonde, incohérence état/ordre, etc.).
  • Contrôle de la supervision (synoptiques minimaux, navigation, acquittements).

Recette intégrée (tests inter‑lots) : là où une « bonne classe » fait vraiment la différence

Les économies et la stabilité viennent souvent des interactions (GRMS↔CVC↔éclairage↔stores, GTB↔production, etc.). En hôtel, une pratique très efficace consiste à verrouiller ces tests sur une chambre témoin et/ou une zone pilote, puis à industrialiser le déploiement.

À ce sujet : Chambre témoin hôtel : comment valider le GRMS, le CVC et l’éclairage.

Livrables à exiger pour que la classe BACS reste « maintenable » après réception

  • Matrice fonctions → exigences → tests → preuves (à jour, versionnée).
  • Point list (noms, unités, états, alarmes, historiques, fréquence de trend « à définir »).
  • SoO / séquences de fonctionnement (modes, priorités, dérogations, défauts capteurs).
  • Synoptiques et vues d’exploitation (minimum viable pour opérer).
  • Dossier d’exploitation numérique (sauvegardes, exports, droits d’accès, procédures).

Sur la logique « cahier des charges → exigences actionnables → preuves de recette », vous pouvez aussi vous inspirer de notre démarche cybersécurité (même logique de contractualisation par preuves) : Transformer un référentiel en exigences concrètes (exemple IoT).

Points d’attention (hôtellerie) : ce qui fait échouer la promesse « classe BACS »

  • Confondre classe et protocole : la classe est un niveau fonctionnel. KNX/BACnet/DALI/Modbus sont des moyens.
  • Sur‑spécifier sans preuve : une fonction non testée en recette est une fonction « supposée ».
  • Ignorer l’exploitation : plus de fonctions = plus de réglages, d’alarmes, de données à maintenir. Il faut un niveau cohérent avec l’organisation site.
  • Ne pas cadrer les dérogations : en hôtel, le confort et l’exploitation imposent des overrides. Ils doivent être prévus, tracés et testés.

Sources et documentation (accès public)

Si vous le souhaitez, nous pouvons vous aider à transformer votre « classe cible par zone » en matrice d’exigences et en plan de recette exploitable (chambre témoin, tests inter‑lots, preuves attendues) avant lancement d’appel d’offres.

28Oct

Sécuriser les systèmes techniques d’un hôtel connecté avec IEC 62443 : zones, conduits, accès et maintenance

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

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

Dans un hôtel connecté, la cybersécurité ne se résume pas à “séparer des VLAN”. On doit surtout décider qui peut accéder à quoi, dans quelles conditions, et comment on maintient l’ensemble (multi-prestataires, télémaintenance, support éditeurs, interventions d’urgence) sans créer d’accès permanents difficiles à tracer.

L’approche ISA/IEC 62443, historiquement portée par les environnements d’automatisation et de contrôle, apporte un cadre très utile pour l’hôtellerie : modéliser le périmètre en “zones et conduits”, puis traduire ce modèle en livrables projet (cartographie, exigences, règles d’accès/maintenance, preuves de recette) utilisables par la maîtrise d’ouvrage, l’intégrateur et l’exploitant.

Objectif de ce guide : proposer une démarche applicable à un projet hôtelier (neuf ou rénovation), sans posture “certification”.

Pourquoi IEC 62443 est utile en hôtellerie (sans “projet de certification”)

La série ISA/IEC 62443 décrit une approche holistique pour définir et maintenir des systèmes d’automatisation/contrôle sécurisés, avec des exigences et des processus qui dépassent la seule technique réseau (gouvernance, exploitation, maintenance). Cette série est présentée comme un cadre transverse (“horizontal”) utilisable dans de nombreux environnements OT/IACS ; dans un hôtel, elle aide à structurer un périmètre de systèmes techniques exploités sur la durée (et souvent maintenus par plusieurs intervenants).

Dans un hôtel, cette grille de lecture aide à éviter deux écueils fréquents :

  • La sécurité “par couches empilées” : un VPN ici, un VLAN là, quelques mots de passe changés… sans modèle d’ensemble ni responsabilités claires.
  • La sécurité “non maintenable” : une segmentation trop théorique, qui se dégrade au premier incident ou à la première intervention urgente.

À retenir : vous pouvez très bien viser une démarche alignée avec 62443 (livrables et exigences inspirés de la méthode) sans que l’objectif du projet soit une “certification”.

Le cœur de la méthode : définir des zones (à protéger) et des conduits (à contrôler)

Étape préalable : définir le “système sous considération” (SUC)

Avant de dessiner des zones, on fixe le périmètre utile au projet. Dans un hôtel, ce périmètre comprend typiquement des systèmes OT / courants faibles tels que :

  • GRMS (gestion technique de chambre) et ses interfaces,
  • GTB/GTC (CVC, énergie, supervision technique),
  • Vidéosurveillance (CCTV / VMS),
  • Contrôle d’accès (portes, locaux techniques, parkings),
  • et, selon les sites, des briques “techniques” plus spécifiques (production, locaux machine, etc.).

Ce qui est hors périmètre (par exemple, le Wi‑Fi invité ou l’IT bureautique) reste important : il faut lister les interfaces entre OT et IT, car elles deviennent des conduits à sécuriser.

Zone : regrouper des actifs qui “se protègent de la même façon”

Une zone n’est pas un VLAN. C’est un regroupement d’actifs (équipements, serveurs, applications, postes opérateur, passerelles) qui partagent des exigences de sécurité proches, en fonction :

  • des conséquences d’une compromission (sûreté, disponibilité, impact client, exploitation),
  • de l’exposition (zones publiques, back-of-house, locaux techniques),
  • des contraintes d’exploitation (fonctionnement continu, fenêtres de maintenance, tolérance au redémarrage),
  • des acteurs (qui administre, qui maintient, qui supervise).

Conduit : formaliser et sécuriser les communications entre zones

Dans l’approche IEC 62443, un conduit sert à formaliser et contrôler les communications entre zones : quels flux existent réellement, pour quel besoin, via quels points de contrôle, avec quelles exigences (authentification, filtrage, journalisation, chiffrement si pertinent, etc.). IEC 62443‑3‑2 mobilise cette logique dans la démarche SUC → zones/conduits → risque → SL‑T → exigences. En pratique projet, un conduit devient un contrat d’échange : quels flux, pour quel besoin, via quels points de contrôle, avec quelles exigences (authentification, filtrage, journalisation, chiffrement si pertinent, etc.).

Conséquence importante : entre deux zones, vous pouvez avoir plusieurs conduits (par exemple, un conduit “supervision” et un conduit “maintenance”). Et un conduit peut se matérialiser par plusieurs mécanismes à la fois (pare-feu, bastion, DMZ, règles applicatives, procédure d’accès nominative…).

Traduire IEC 62443 en livrables projet (ceux qui “tiennent” en exploitation)

Le bénéfice principal de la démarche, c’est la production de documents relisibles, contractuels quand il le faut, et surtout réutilisables quand les prestataires changent.

Livrable : périmètre (SUC) et responsabilités

  • Périmètre OT concerné (ce qui est “dans” et “hors” SUC).
  • Liste des parties prenantes (hôtel / opérateur, IT, intégrateurs, mainteneurs, éditeurs).
  • Responsabilités et circuits de validation (qui approuve une ouverture de flux ? qui crée un compte prestataire ? qui fait la revue des accès ?).

Livrable : cartographie “zones & conduits” (vue fonctionnelle + vue exploitable)

Deux niveaux sont utiles :

  • Vue fonctionnelle (lisible MOA/exploitation) : zones, rôles, échanges “métier” entre zones.
  • Vue exploitable (lisible intégration/réseau) : points d’entrée, équipements frontières, règles de filtrage attendues, chemins de télémaintenance, emplacements de journalisation.

Livrable : registre des conduits (le document qui évite les “exceptions” permanentes)

Pour chaque conduit, on documente au minimum :

  • zones source/destination,
  • finalité (supervision, événements, mises à jour, télémaintenance, etc.),
  • points de contrôle (pare-feu, bastion, proxy, passerelle applicative),
  • exigences (authentification, restrictions de flux, traçabilité),
  • mode dégradé (que se passe-t-il si le conduit est indisponible ?).

Livrable : spécification d’exigences cybersécurité (orientée preuves, pas “liste d’outils”)

Au lieu d’imposer uniquement une architecture (“on met des VLAN”), on formalise des exigences vérifiables, par exemple :

  • Accès et identités : comptes nominatifs, cycle de vie des comptes prestataires, règles d’accès d’urgence.
  • Droits : séparation exploitation / maintenance, moindre privilège, rôles.
  • Flux : logique de liste blanche, flux latéraux interdits par défaut, points d’entrée identifiés.
  • Journalisation : quoi journaliser, où centraliser, qui relit, comment enquêter.
  • Gestion des changements : procédure, validation, retour arrière, sauvegardes.
  • Mises à jour et vulnérabilités : stratégie de patching adaptée aux contraintes OT (tests, fenêtres, exceptions documentées).

Livrable : gouvernance des accès et de la maintenance (souvent le vrai “risque OT” en hôtel)

En hôtellerie, le risque provient fréquemment de la multiplicité des intervenants (CCTV, contrôle d’accès, GTB, ascenseurs, TV, réseau…) et de l’héritage de comptes/mots de passe installateur. Ce livrable décrit :

  • comment une intervention est demandée, validée et clôturée,
  • comment les accès sont ouverts temporairement,
  • comment les sessions sont tracées (et par qui elles sont consultables),
  • comment on audite périodiquement les accès et les exceptions.

Sur la remise des documents et l’organisation côté exploitation, vous pouvez compléter avec : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?

Exemple de découpage zones & conduits pour un hôtel (à valider en atelier)

L’exemple ci-dessous est une proposition de structuration (pas un modèle universel). Il doit être ajusté selon l’architecture réelle, les prestataires, et l’évaluation de risque.

Zones typiques (exemple)

  • Zone supervision OT : serveurs et postes opérateur de supervision (GTB, GRMS, VMS, management contrôle d’accès), outils d’administration strictement OT.
  • Zone terrain GRMS : contrôleurs de chambre, passerelles, équipements techniques de chambre dans le périmètre.
  • Zone terrain GTB/GTC : contrôleurs techniques, automates, passerelles CVC/énergie.
  • Zone sûreté – vidéosurveillance : caméras, enregistreurs, stockage, consoles opérateur dédiées.
  • Zone sûreté – contrôle d’accès : contrôleurs, passerelles, postes de gestion, interfaces porte/parking.
  • Zone OT DMZ / zone d’échange : services de transit entre OT et IT (bastion, relais de mises à jour, collecte de logs, interfaces applicatives).
  • Zone IT (hors OT) : annuaire/IdP, ITSM, SIEM, PMS et services corporate, avec des interfaces OT cadrées.

Pour clarifier les échanges entre systèmes hôteliers (qui échange quoi, et pourquoi), voir aussi : PMS, GRMS, GTB, serrures et contrôle d’accès : qui échange quoi dans un hôtel ?

Conduits typiques (exemple)

  • Conduit “supervision” : supervision OT ↔ terrain (GRMS/GTB), strictement limité aux flux nécessaires.
  • Conduit “événements sûreté” : contrôle d’accès / VMS → supervision ou postes opérateur, avec exigences fortes de traçabilité.
  • Conduit “OT ↔ IT” : exports contrôlés (tableaux de bord, événements, reporting), idéalement via une zone d’échange (DMZ OT).
  • Conduit “télémaintenance prestataire” : accès distant vers OT, uniquement via un point de contrôle (bastion/DMZ), avec sessions traçables et accès temporaires.

Ce dernier conduit mérite presque un dossier à lui seul : en exploitation, c’est souvent lui qui “détricote” une segmentation pourtant correcte sur le papier.

Du niveau de sécurité cible à des exigences actionnables (sans sur-spécifier)

IEC 62443‑3‑2 formalise une démarche où l’on partitionne en zones et conduits, puis où l’on définit un niveau de sécurité cible (SL‑T) par zone et par conduit, avant de documenter les exigences de sécurité. L’intérêt, côté projet hôtelier, est de rendre explicite :

  • les zones qui demandent une posture plus exigeante (ex. sûreté, accès aux chambres, supervision),
  • les conduits “sensibles” (ex. OT↔IT, télémaintenance, administration),
  • les compromis nécessaires avec l’exploitation (continuité de service, fenêtres d’intervention, contraintes legacy).

Pour éviter de transformer “SL‑T” en jargon, une méthode simple consiste à relier vos exigences à des familles d’objectifs. IEC 62443‑3‑3 décrit des foundational requirements (FR) qui couvrent notamment l’identification/authentification, le contrôle d’usage, l’intégrité système, la confidentialité des données, la restriction des flux, la réponse aux événements et la disponibilité des ressources.

Concrètement, au lieu d’écrire “SL‑T élevé”, on traduit en questions de conception et clauses projet :

  • IAC / UC : comment sont gérés les comptes nominatif, prestataire, urgence ? Quelles preuves de revue d’accès ?
  • RDF : quels flux doivent exister, et quels flux doivent être impossibles ?
  • TRE : quels événements déclenchent une alerte, qui la reçoit, et quelle escalade ?
  • RA : quelles protections ne doivent pas dégrader la disponibilité OT (scans, redémarrages, mises à jour forcées) ?

Ne pas confondre “VLAN” et “zones & conduits”

Un VLAN (ou une VRF, ou un sous-réseau) est une mise en œuvre possible de votre découpage, mais il ne couvre pas à lui seul :

  • la gouvernance des accès (comptes, droits, prestataires, urgence),
  • la télémaintenance (chemin unique, validation, traçabilité),
  • la preuve (logs, horodatage, capacité d’enquête),
  • la maintenabilité (ce qui change, qui peut changer, comment les exceptions sont gérées).

Pour une base claire côté réseau (segmentation et filtrage), vous pouvez compléter avec : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ? et Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?

Accès, télémaintenance et traçabilité : traiter explicitement le “conduit prestataire”

Principe de base : pas d’accès distant direct vers le terrain

Dans une logique “conduits”, on évite autant que possible les accès du type “PC prestataire → contrôleur terrain”. On préfère un chemin maîtrisé :

  • un point d’entrée unique (bastion / passerelle d’administration) positionné dans une zone d’échange (DMZ OT),
  • des comptes nominatifs et temporaires quand pertinent,
  • une traçabilité des actions (au minimum, journalisation d’accès ; selon le contexte, enregistrement de session),
  • une fermeture systématique de l’accès après intervention (pas de tunnels “toujours ouverts”).

Journalisation et horodatage cohérent

Le meilleur modèle zones/conduits perd beaucoup de valeur si l’on ne peut pas reconstituer une séquence d’événements. Une attention particulière doit être portée à la cohérence temporelle (équipements, serveurs, postes), car elle conditionne la qualité des logs et des preuves en cas d’incident.

Sur ce point, voir : Caméras et contrôle d’accès : pourquoi synchroniser l’heure des équipements ?

Recette : comment vérifier que la segmentation “tient” dans la durée

Une démarche alignée IEC 62443 devient réellement utile quand elle se traduit en tests de recette et en preuves (PV, exports de configuration, captures contrôlées, procédures). Exemples de vérifications pragmatiques à intégrer au projet :

  • Tests de flux : depuis chaque zone, vérifier que seuls les flux attendus passent (et que les flux “interdits” échouent).
  • Tests de télémaintenance : démontrer le chemin réel (entrée → bastion/DMZ → cibles), les droits, et la trace laissée.
  • Tests de comptes : créer/supprimer un compte prestataire selon la procédure, puis prouver qu’il n’existe plus d’accès résiduel.
  • Tests de mode dégradé : valider ce qui continue de fonctionner si un conduit OT↔IT est coupé.

Point d’attention OT : certaines pratiques IT “par défaut” (scan agressif, redémarrages automatiques, déploiement d’agents non maîtrisés) peuvent dégrader un environnement technique. La recette doit donc vérifier la sécurité et la continuité de service, avec des responsabilités claires.

Pour aller plus loin (et articuler avec vos livrables hôteliers)

Conclusion

Appliquer IEC 62443 dans un hôtel, ce n’est pas “faire de l’industriel” pour le principe. C’est surtout utiliser une méthode robuste pour structurer la sécurité OT en livrables de projet : un périmètre clair, une cartographie zones/conduits, des exigences vérifiables, et une gouvernance d’accès/maintenance adaptée au multi-prestataires.

Si vous ne deviez démarrer que par un seul chantier : formalisez la cartographie zones & conduits et traitez le conduit de télémaintenance (qui, quand, comment, via quel point de contrôle, et quelle trace). C’est souvent là que se joue la différence entre une segmentation “présentable” et une exploitation réellement maîtrisée.

Sources et documentation

27Oct

DNS chiffré (DoH) : pourquoi il perturbe filtrage et portail captif — et comment l’aborder proprement (hôtel, bureau, villa)

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

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

Pourquoi ce sujet apparaît maintenant dans les projets Wi‑Fi (hôtel, bureau, villa)

Dans un établissement recevant des invités (hôtel, espaces événementiels, bureaux avec visiteurs, grande villa), le DNS est souvent un « outil d’exploitation » : il aide à appliquer un filtrage simple, à faire apparaître un portail captif, et à produire des journaux utiles pour le support. Or, de plus en plus de systèmes et navigateurs savent utiliser DNS over HTTPS (DoH) : les requêtes DNS passent alors dans un flux HTTPS chiffré. Le résultat est très concret : les mécanismes qui reposent sur l’observation ou la modification du DNS « en clair » deviennent moins visibles, moins pilotables, parfois inopérants.

Important : l’objectif ici n’est pas de décrire des techniques de contournement, mais de donner un cadre de décision et des options « propres » pour garder une expérience Wi‑Fi prévisible, tout en conservant un niveau de maîtrise proportionné (sécurité, support, conformité interne).

Pour resituer le sujet dans l’exploitation d’un Wi‑Fi visiteurs, vous pouvez aussi lire : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client.

DoH, en pratique : ce que dit le standard (et ce que cela implique)

Le RFC de référence décrit DoH comme un transport des messages DNS « au-dessus » de HTTPS (voir RFC 8484 — DNS Queries over HTTPS (DoH)). Dans ses considérations opérationnelles, il souligne un point directement pertinent pour les réseaux gérés : les mécanismes de filtrage ou d’inspection qui s’appuient sur du DNS non sécurisé ne s’appliquent pas de la même manière en environnement DoH, du fait des protections apportées par TLS.

Traduction projet : si votre stratégie repose sur « voir le DNS en port 53 » (ou injecter des réponses DNS), vous devez accepter que certains terminaux, dans certaines configurations, échappent à ce levier dès lors qu’ils utilisent DoH vers un résolveur externe.

Trois impacts typiques côté bâtiment : filtrage, portail captif, journaux

Filtrage “par DNS” : une promesse plus difficile à tenir sur un réseau invité

Dans beaucoup de projets, le filtrage côté Wi‑Fi invités est volontairement simple : listes de domaines, catégories, SafeSearch, anti‑malware “DNS‑based”. Tant que le terminal interroge votre résolveur (ou votre service de filtrage DNS), la politique est visible. Avec DoH vers un résolveur tiers, ce n’est plus garanti.

Conséquence : si le filtrage fait partie d’un engagement d’exploitation (par exemple « Wi‑Fi famille »), il faut cadrer ce que vous garantissez réellement sur du BYOD, et sur quels périmètres vous pouvez être strict (terminaux gérés vs invités).

Portail captif : attention aux portails qui reposent sur des détournements DNS/HTTP

De nombreux portails captifs historiques “fonctionnent” en pratique en jouant sur DNS et/ou HTTP : renvoyer une adresse identique pour toutes les requêtes DNS, ou intercepter les requêtes HTTP et renvoyer un redirect. Le document de conception Chromium OS sur la détection de portails décrit explicitement ces schémas comme fréquents dans les portails d’hôtels, cafés ou aéroports (voir Chromium OS — Network Portal Detection).

Le risque avec DoH n’est pas uniquement « le portail ne s’affiche pas » : c’est surtout une variabilité d’expérience selon les terminaux (navigateur, OS, applications), car certains parcours d’onboarding supposent implicitement un DNS “pilotable”. Le RFC 8952 — Captive Portal Architecture rappelle d’ailleurs une limite structurelle : les solutions de portail captif qui affectent DNS/HTTP fonctionnent généralement comme prévu avec les navigateurs, mais peuvent casser d’autres applications utilisant ces protocoles, et les applications d’autres protocoles ne sont pas forcément alertées que le réseau est captif.

En environnement hospitality, cela se traduit souvent par des symptômes “terrain” : applications qui semblent « sans Internet » alors que le Wi‑Fi est associé, casting qui ne se comporte pas comme attendu, ou parcours de connexion qui dépend trop d’un seul mécanisme.

Journalisation DNS : utile pour le support… mais moins complète si une partie du DNS part en DoH externe

Beaucoup d’organisations s’appuient sur les journaux DNS pour diagnostiquer : « l’utilisateur a-t-il bien résolu tel domaine ? », « y a-t-il eu des requêtes suspectes ? », « quel équipement a tenté quoi ? ». Si une partie des terminaux envoie du DNS en DoH vers un service tiers, votre résolveur local ne verra pas ces requêtes : la journalisation “DNS‑centrée” perd en exhaustivité.

Point de gouvernance : ce n’est pas “plus de logs”, c’est “pas les bons logs au même endroit”. Il faut donc décider où placer l’observabilité (réseau, proxy/SWG, EDR, SIEM…), et ce qui est réellement nécessaire pour l’exploitation (support, sécurité, audit interne).

Réponses « propres » : options de conception plutôt qu’un bras de fer avec le BYOD

1) Séparer clairement les périmètres : invités vs métiers vs technique

La réponse la plus robuste (et la plus “bâtiment”) consiste souvent à limiter ce que vous attendez du réseau invité, et à renforcer ce qui compte sur les périmètres que vous maîtrisez :

  • Invités (BYOD) : viser une expérience simple, stable, et une isolation réseau forte ; accepter que vous ne contrôlez pas le terminal (et donc pas complètement son DNS).
  • Staff / back‑office : politiques de sécurité plus strictes, supervision, contrôle des postes.
  • IoT bâtiment / GRMS / GTB / CCTV : segmentation, flux minimaux autorisés, et dépendances documentées.

Cette logique rejoint l’architecture globale d’un réseau hospitality. Voir : Architecture réseau IP d’un hôtel : faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS, ainsi que Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ?.

Si vous cherchez une explication plus “méthode” sur la séparation des usages, vous pouvez aussi lire : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?.

2) Concevoir le portail captif comme un service (parcours, compatibilité, modes dégradés)

Le message du RFC 8952 est utile à traduire en cahier des charges : un portail captif n’est pas seulement une redirection, c’est un service d’onboarding qui doit tenir face à des applications et OS variés.

Recommandations de projet (sans entrer dans des recettes techniques) :

  • Éviter de dépendre d’un “détournement DNS” pour déclencher l’expérience de connexion ; à défaut, en connaître les limites.
  • Tester le parcours avec plusieurs profils de terminaux (smartphones, laptops, objets de chambre, usages de salles de réunion) et pas seulement “un navigateur sur un PC”.
  • Prévoir un mode secours exploitable par l’accueil ou le support (information simple, procédure, escalade), car la variabilité des terminaux est une donnée de base de l’hospitality.

Pour la partie “dépendances invisibles” (DNS/DHCP/RADIUS) qui peut aussi se confondre avec des symptômes liés au DNS chiffré, voir : Wi‑Fi d’hôtel en panne : vérifier DNS, DHCP et RADIUS.

3) Sur les équipements que vous gérez : poser une politique endpoint explicite sur DoH

Sur le périmètre géré (postes staff, tablettes d’accueil, équipements de salles, flotte entreprise), le bon levier est souvent la politique endpoint (MDM/AD/gestion navigateur) plutôt qu’une bataille sur le réseau invité.

Objectif : être cohérent. Soit vous désactivez DoH sur un périmètre donné (si votre politique interne l’exige), soit vous l’accompagnez avec un DNS chiffré sous contrôle (voir point suivant).

4) Proposer un DNS chiffré “sous gouvernance” (plutôt que subir un DoH tiers)

Dans certains contextes, la réponse la plus propre n’est pas d’empêcher le DNS chiffré, mais de fournir un DNS chiffré opéré/maîtrisé par l’organisation (en interne ou via service managé), surtout pour les segments staff et techniques. Microsoft décrit l’activation et le dépannage dans sa documentation sur le DNS chiffré et DoH : Microsoft Learn — DNS Encryption using DNS over HTTPS et Enable DNS over HTTPS in DNS Server.

Intérêt projet : vous conciliez confidentialité sur le Wi‑Fi (DNS chiffré) et exigences d’exploitation (split‑DNS, politiques internes, journalisation adaptée), au lieu d’avoir des terminaux qui “sortent” vers des résolveurs publics hétérogènes.

5) Tirer parti des mécanismes de “signal réseau” quand ils existent… sans les surestimer

Firefox documente des mécanismes pour éviter d’activer DoH par défaut sur des réseaux où il peut casser des fonctions locales (noms privés, filtrage, etc.). Mozilla décrit notamment le principe du canary domain use-application-dns.net et précise ses conditions et limites : il ne s’applique pas si l’utilisateur active DoH manuellement. Voir : Mozilla — Configure networks to disable DNS over HTTPS et Mozilla — Canary domain use-application-dns.net.

C’est une piste utile de gouvernance (surtout en environnements corporate), mais elle reste dépendante du navigateur et de son mode d’activation : on la considère comme un signal, pas comme un contrôle universel du parc invité.

Mini plan de tests (exploitation) : valider l’impact sans “sur‑ingénierie”

Avant de décider “bloquer vs accompagner”, un plan de tests simple évite les décisions théoriques. Voici une grille orientée exploitation (à adapter à votre contexte et à vos fournisseurs) :

Ce que vous testez Ce que vous observez Limites à garder en tête
Onboarding portail captif (plusieurs OS/navigateurs) Affichage de la page, stabilité de la session, réauthentification après veille Un test « navigateur » ne couvre pas les apps non-navigateur ; le RFC 8952 souligne les limites des mécanismes DNS/HTTP pour ces cas.
Services sensibles côté client (casting, applis de réunion, streaming) Découverte, connexion, comportement en “réseau captif” Les symptômes peuvent être confondus avec des dépendances DNS/DHCP/RADIUS.
Filtrage annoncé sur Wi‑Fi invités Écart entre filtrage “théorique” et filtrage réellement constaté Avec DoH, les leviers DNS non chiffrés ne s’appliquent pas nécessairement (voir RFC 8484).
Observabilité (support) Quels journaux sont vraiment exploitables lors d’un incident La journalisation DNS n’est plus exhaustive si une partie du DNS part en DoH externe.

À retenir (décisionnel)

  • DoH chiffre le DNS dans HTTPS ; le RFC 8484 explique pourquoi les approches de filtrage/inspection basées sur du DNS non sécurisé deviennent moins opérables en environnement DoH.
  • Les portails captifs “historiques” basés sur DNS/HTTP sont structurellement fragiles (compatibilité applicative) ; un DNS chiffré peut accentuer la variabilité d’expérience côté invité (voir RFC 8952).
  • La réponse la plus robuste est souvent : segmentation (invités vs interne), politiques endpoint sur le périmètre géré, et éventuellement un DNS chiffré sous gouvernance plutôt qu’un DoH tiers.

Sources et documentation

Si vous préparez une rénovation ou un nouveau site, l’étape la plus efficace est souvent de formaliser ces choix dans un livrable d’exploitation (périmètres, politiques, tests et modes dégradés), puis de valider sur une zone pilote avant généralisation. Pour cadrer ce livrable, vous pouvez compléter avec : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

19Oct

Mettre hors service une baie réseau ou une gestion technique du bâtiment (GTB) : check-list de passation, effacement et rotation des accès

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

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

Fin de contrat d’infogérance, changement d’exploitant, rénovation, migration vers une nouvelle architecture: la “sortie de parc” d’une baie réseau (et, très souvent, des serveurs/accès IT d’une gestion technique du bâtiment (GTB)) se joue moins sur le démontage du matériel que sur la rotation des accès et l’effacement maîtrisé de ce qui reste sur les équipements.

L’objectif de ce guide est simple: vous aider à produire une passation testable et traçable (inventaire, sauvegardes, rotation des secrets, révocation des certificats, retrait des accès distants, effacement des supports) pour un site hospitality/tertiaire, sans dépendre d’une marque de firewall/switch/GTB en particulier.

Dans quels cas ce guide s’applique (et ce qu’il ne couvre pas)

Cas typiques: changement de prestataire réseau, transfert d’un établissement à un nouvel exploitant, changement de solution GTB/GRMS, restructuration de l’architecture (segmentation OT/IT, nouveau firewall), remplacement d’un parc d’équipements, fin de location/retour constructeur.

Ce guide reste volontairement agnostique constructeur: pour les commandes exactes (effacement, export, “factory reset”, de-provision cloud), référez-vous à la documentation du fabricant de chaque équipement. En revanche, la logique (quoi inventorier, quoi révoquer, quoi tester, comment tracer) est largement transposable.

Pour replacer ces actions dans une architecture d’hôtel (réseaux Wi‑Fi, IPTV, VoIP, CCTV, GRMS/GTB), voir aussi: Architecture réseau IP d’un hôtel : principes et dépendances.

Et si vous cherchez une vue “cybersécurité” plus large (au-delà de la seule passation/sortie de parc): Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ?.

1) Cadrer la passation avant de toucher au matériel

Clarifier le scénario de “sortie”

  • Transfert: une partie des équipements et/ou des configurations doit continuer à vivre (nouvel exploitant, nouvelle équipe IT/OT).
  • Remplacement: les équipements sont retirés et remplacés, avec bascule vers une nouvelle architecture.
  • Rebut / recyclage / revente: les supports sortent de votre contrôle; l’effacement devient un sujet central.

Définir le périmètre (réseau + “IT de la GTB”)

Au-delà de la baie, une GTB moderne implique souvent des éléments IT (serveur de supervision, VM, base de données, accès distant intégrateur, passerelles IP, comptes “service”). Une passation sérieuse couvre généralement:

  • Edge/accès Internet: routeur, firewall, VPN, liens de secours éventuels.
  • Switching: cœur/distribution/accès, PoE, ports critiques (caméras, AP, contrôleurs).
  • Wi‑Fi: contrôleur (ou plateforme cloud), SSID, sécurité, éventuel RADIUS/802.1X.
  • Services d’infra: supervision, syslog, sauvegarde, NTP/DNS/DHCP/RADIUS si sur site.
  • “IT de la GTB”: serveur(s) GTB, passerelles, accès distant, comptes d’intégration (API/BDD), historiques si présents sur supports locaux.

Si votre établissement est segmenté entre OT et IT, ce moment est souvent l’occasion de valider que la séparation est compréhensible et documentée: Séparer les équipements du bâtiment du réseau informatique (OT/IT).

Geler, capturer l’état, préparer un retour arrière

  • Geler les changements non tracés pendant la fenêtre de passation (sinon l’inventaire devient faux).
  • Capturer l’état: versions logicielles, topologie logique, photos de baie, exports de configuration quand c’est pertinent.
  • Valider un plan de retour arrière: si une rotation de secrets coupe un service critique, comment revenir au dernier état fonctionnel.

2) Inventaire “utile” : matériel, accès, secrets, certificats, accès distants

Le point qui fait échouer une passation n’est pas l’absence d’un schéma, mais l’oubli d’un point d’entrée: un compte support, une clé API, un secret RADIUS, un certificat 802.1X, un tunnel VPN encore actif, ou un équipement “adopté” dans un tenant cloud dont personne ne récupère la main.

Un tableau unique pour piloter la sortie

Créez un tableau “Identité / Secret / Où c’est configuré / Action (révoquer, détruire, transférer) / Preuve”. Exemple de structure:

Domaine À inventorier Exemples Preuve attendue
Comptes Comptes locaux + comptes annuaires/cloud Admins, comptes “break-glass”, comptes support Liste des comptes restants + responsabilité (qui en a la garde)
Secrets machine-à-machine Secrets partagés et jetons RADIUS shared secret, tokens API, secrets d’intégration GTB Journal de rotation (sans stocker les secrets en clair)
Clés Clés SSH, clés privées, PSK Accès admin, VPN, Wi‑Fi (selon design) Anciennes clés invalidées / nouvelles clés déployées
Certificats Chaînes de confiance, certificats serveur & client EAP‑TLS/802.1X, VPN, HTTPS d’administration Liste des certificats révoqués + test d’échec/succès
Accès distants Tunnels et portails VPN SSL/IPsec, bastion, accès cloud constructeur, modem/4G Tableau des accès supprimés/transférés (date + responsable)
Supports & stockage Tout ce qui stocke des données SSD/HDD, eMMC, cartes SD, logs locaux, VM/snapshots Fiche d’effacement (méthode, outil, n° de série, destination)

Ne pas oublier les “dépendances invisibles”

Les services d’adressage, de noms et d’authentification sont souvent hors de la baie (VM, cloud, prestataire) mais indispensables: DNS/DHCP/RADIUS/NTP, supervision, sauvegarde, licences. Si vous devez sécuriser la continuité de service, gardez une vue “jour‑2”: Réseau informatique : quelles sauvegardes prévoir pour redémarrer après une panne ?.

3) Sauvegardes et DOE : ce qu’on transfère vs ce qu’on détruit

Transférer ce qui rend l’exploitation possible (sans exposer les secrets)

  • Dossier réseau: plan IP/VLAN, schémas, logique de nommage (si vous en avez une), règles firewall structurantes, paramètres Wi‑Fi.
  • Procédures d’exploitation: restauration, mises à jour, supervision, points de contact.
  • Configurations exportées si elles servent de base au nouvel exploitant (et seulement via un canal sécurisé).

Sur la logique “DOE orienté exploitation” (qui remet quoi, sous quelle forme), vous pouvez compléter avec: DOE et maintenance d’un hôtel connecté : livrables à remettre à l’exploitant.

Éviter la fuite par les exports et les images systèmes

  • Considérez tout export comme potentiellement sensible: certains équipements incluent des secrets (ou des éléments dérivables) dans les sauvegardes.
  • Une image VM/snapshot peut contenir des clés, des jetons, des historiques, et des identifiants de services.
  • Si une configuration doit être transmise, planifiez la rotation des secrets (section suivante) comme une action à part entière, avec tests.

4) Rotation des secrets : la règle de base en sortie de parc

En fin de contrat, le risque n’est pas seulement qu’un ancien compte reste actif. C’est aussi que quelqu’un conserve une ancienne copie de configuration (ou un export) qui, si les secrets n’ont pas été changés, reste exploitable.

Rotation, révocation, destruction : clarifier l’action attendue

  • Rotation: on conserve le service, mais on change les secrets (comptes, mots de passe, clés, jetons) et on met à jour les dépendances.
  • Révocation: on invalide une identité (certificat, accès) et on force l’échec des tentatives d’usage futures.
  • Destruction: on supprime toute trace d’un secret pour qu’il ne puisse pas être récupéré (référence utile côté cryptographie: la définition de “key destruction” dans NIST SP 800‑57 Part 1 Rev.5). Source NIST SP 800‑57 Part 1 Rev.5 (PDF).

Check-list de rotation (ordre conseillé)

  1. Comptes: supprimer les comptes nominaux sortants, supprimer/justifier les comptes génériques, changer les mots de passe des comptes administrateurs conservés.
  2. Chemins d’administration: remplacer les clés SSH, désactiver les jetons d’API, retirer les adresses IP/ACL “allowed hosts” associées à l’ancien prestataire.
  3. Secrets d’infrastructure: secrets partagés RADIUS/802.1X, secrets entre contrôleur et équipements, secrets de supervision/collecte (SNMPv3, syslog, agents).
  4. VPN et interconnexions: comptes VPN, tunnels site-à-site, comptes “support”, règles temporaires (NAT/port-forward) laissées pendant un chantier.

Point d’attention: ne stockez pas les secrets en clair dans le DOE. Préférez un coffre (ou un mécanisme interne) et un journal “fait / vérifié”, qui prouve la rotation sans divulguer la valeur.

5) Certificats 802.1X (EAP‑TLS) : révocation, chaîne de confiance, tests

En environnement hôtel/tertiaire, 802.1X peut être utilisé sur le Wi‑Fi staff, certains VLAN d’administration, ou des ports filaires. C’est puissant… mais les certificats sont des identités “durables”, donc la passation doit traiter explicitement la révocation.

Ce que disent les textes (et ce que ça change côté projet)

La RFC 5216 (EAP‑TLS) rappelle que les certificats sont des assertions d’identité longue durée et que les implémentations doivent pouvoir vérifier la révocation; elle impose le support des Certificate Revocation Lists (CRL) et recommande le support d’OCSP. Source RFC 5216 (EAP‑TLS).

Procédure de passation (agnostique constructeur)

  • Identifier où “vit” l’autorité de certification (CA) et qui en a la responsabilité (interne, prestataire, cloud).
  • Inventorier les certificats et chaînes de confiance réellement utilisés (serveur RADIUS, certificats clients, éventuels certificats sur contrôleurs/équipements).
  • Révoquer ce qui doit l’être (ex: certificats d’équipements appartenant à un prestataire sortant) et vérifier que l’infrastructure de statut (CRL/OCSP) reste atteignable dans la nouvelle organisation.
  • Nettoyer les “trust anchors”: retirer les CA/intermédiaires qui ne doivent plus être approuvés.
  • Tester avec un certificat révoqué (échec attendu) et un certificat valide (succès attendu).

Pour une approche orientée exploitation (éviter les pannes liées aux certificats, organiser le renouvellement et la révocation, définir des tests), voir aussi: Wi‑Fi 802.1X : éviter la panne quand un certificat expire (EAP‑TLS).

6) Retirer les accès distants (firewall, GTB, supervision) : l’angle mort classique

Un démontage “propre” peut laisser intact un accès distant, si l’équipement (ou son remplaçant) reste joignable via VPN, NAT, compte cloud, tunnel support, ou bastion. Dans un transfert, l’objectif est de fermer ce qui doit disparaître et de transférer ce qui doit rester, avec de nouveaux secrets et une nouvelle responsabilité.

Côté firewall / routeur

  • Supprimer ou transférer les comptes VPN, certificats VPN, tunnels IPsec/SSL, et les règles temporaires (port-forwarding de chantier, accès “exceptionnels”).
  • Désactiver l’administration depuis Internet si elle n’est pas strictement nécessaire (et, si elle est nécessaire, limiter par IP, MFA, bastion, journalisation).
  • Vérifier qu’aucune IP de prestataire sortant n’est encore autorisée dans des ACL d’administration.

Côté GTB / supervision

  • Retirer les tunnels “support” permanents, VPN intégrateur, accès distants implicites.
  • Si la GTB ou des équipements réseau sont gérés via une plateforme cloud: prévoir une étape de désassociation / de-provision du tenant sortant et valider que la nouvelle équipe récupère l’administration.
  • Changer les comptes “service” des connecteurs (BDD, API, passerelles) lors d’un transfert d’exploitation.

7) Effacement des configurations et des supports : s’aligner sur une méthode (Clear / Purge / Destroy)

Un switch, un firewall, un contrôleur Wi‑Fi, un serveur GTB ou une VM de supervision peuvent contenir: configuration, logs, captures, certificats, clés privées, tokens, historiques, parfois des identifiants d’accès à d’autres systèmes. Traitez donc l’effacement comme un vrai sujet de sanitization, pas comme un simple “factory reset”.

Trois méthodes à connaître (repère: NIST SP 800‑88 Rev.2)

NIST SP 800‑88 Rev.2 (septembre 2025) propose une classification pratique:

  • Clear: techniques logiques visant les zones adressables par l’utilisateur (par ex.: réécriture, ou option de remise à l’état usine). Le document indique que ces techniques n’affectent typiquement pas l’utilisabilité du support.
  • Purge: techniques physiques ou logiques rendant la récupération infeasible même avec des moyens de laboratoire “state of the art”, tout en gardant le support potentiellement réutilisable; NIST indique que, lorsque possible, Purge devrait être utilisé plutôt que Clear.
  • Destroy: destruction rendant la récupération infeasible et rendant le support inutilisable.

Référence: NIST SP 800‑88 Rev.2 (PDF) (page CSRC: NIST SP 800‑88 Rev.2 (fiche publication)).

Choisir la méthode selon la destination (décision projet)

  • Transfert interne: un Clear peut être acceptable si vous gardez le contrôle du support et si la vérification est possible, mais l’arbitrage dépend de votre niveau de sensibilité et de ce qui est stocké (clés privées, historiques, données personnelles, etc.).
  • Transfert à un tiers / revente: privilégier une approche de type Purge (voire Destroy selon la sensibilité) et documenter la méthode + la preuve.
  • Recyclage / rebut: la question devient: qui a le contrôle du support, et quelle preuve vous pouvez archiver.

Si votre projet traite aussi l’effacement de serveurs vidéo/NAS/NVR, vous pouvez compléter avec: Remplacer un NVR, NAS ou serveur vidéo : effacer disques et cartes SD (méthode NIST 800‑88).

Vérifier et tracer: une preuve d’effacement, pas une intention

NIST SP 800‑88 Rev.2 insiste sur la vérification des résultats (inspection pour confirmer que la technique a bien abouti) et propose un modèle de Certificate of Sanitization (annexe) pour documenter l’opération: méthode (Clear/Purge/Destroy), technique, outils (avec version), vérification/validation, destination, signatures. Source NIST SP 800‑88 Rev.2 (PDF).

Concrètement, votre dossier de clôture doit permettre de répondre à deux questions simples:

  • “Qu’est-ce qui est sorti du site?” (numéro de série, support, destination)
  • “Qu’est-ce qui a été fait dessus?” (méthode, outil, qui, quand, vérification)

8) Dossier de clôture : ce qu’on remet à l’exploitant (ou au propriétaire)

Livrables minimum (orientés passation)

  • Inventaire final: matériel, versions, numéros de série, rôle, destination.
  • Dossier réseau: schémas, plan IP/VLAN, éléments Wi‑Fi utiles, sauvegardes transmises (si applicable).
  • Journal de rotation / révocation: comptes, clés, tokens, secrets partagés, certificats.
  • Journal de retrait / transfert des accès distants: VPN, portails, bastions, comptes support.
  • Fiches d’effacement: par support/équipement sortant, avec preuve vérifiable.

Critères d’acceptation (tests simples, reproductibles)

  • Un compte de l’ancien prestataire ne fonctionne plus (connexion admin/VPN: échec attendu).
  • Un certificat 802.1X révoqué n’ouvre plus l’accès (échec attendu) et un certificat valide fonctionne (succès attendu).
  • Aucun tunnel VPN/support “historique” n’est actif.
  • Les équipements sortants redémarrent sans configuration, sans comptes, sans certificats importés (selon la méthode retenue) et la preuve d’effacement est archivée.

Check-list imprimable (résumé)

A. Préparation

  • [ ] Scénario validé (transfert / remplacement / rebut / retour constructeur)
  • [ ] Fenêtre d’intervention + rollback validés
  • [ ] Gel des changements + capture de l’état (versions/topologie/photos)

B. Inventaire

  • [ ] Matériel + stockage + numéros de série + destination
  • [ ] Comptes, secrets, certificats, accès distants listés dans un tableau unique

C. Sauvegardes / DOE

  • [ ] Livrables à transférer identifiés (schémas, configs utiles, procédures)
  • [ ] Risques de fuite par exports/images pris en compte (secrets non transmis en clair)

D. Rotation / révocation

  • [ ] Comptes admins changés / comptes sortants supprimés
  • [ ] Clés SSH, tokens API, secrets partagés (RADIUS/802.1X, supervision) rotatés
  • [ ] Certificats 802.1X: inventaire, révocation, nettoyage CA, tests d’échec/succès

E. Accès distants

  • [ ] VPN/tunnels supprimés ou transférés avec nouveaux secrets
  • [ ] Portails cloud/support: désassociation (de-provision) du tenant sortant et transfert de la responsabilité

F. Effacement & preuve

  • [ ] Méthode Clear/Purge/Destroy choisie selon la destination du support
  • [ ] Effacement réalisé + vérifié
  • [ ] Preuve archivée (fiche / certificat interne, incluant outil et version)

G. Passation

  • [ ] Dossier final remis (inventaire, journaux rotation/révocation, retraits d’accès distants, preuves d’effacement)
  • [ ] Tests d’acceptation réalisés et signés

Sources et documentation

Pour une passation “fin de vie / transfert” adaptée à votre établissement (baie réseau, Wi‑Fi, GTB/GRMS, vidéosurveillance, contrôle d’accès), l’idéal est de transformer cette check-list en plan d’exécution (responsables, séquencement, tests, preuves). Si vous souhaitez un cadrage projet ou une revue de dossier de passation, vous pouvez nous contacter via Domocasa.

8Oct

Wi‑Fi 802.1X : éviter la panne quand un certificat expire (EAP‑TLS, renouvellement, révocation, tests)

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

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

Un Wi‑Fi « entreprise » ou « staff » basé sur 802.1X est souvent perçu comme plus robuste qu’un simple mot de passe partagé. Pourtant, un incident revient régulièrement en exploitation : l’expiration d’un certificat qui entraîne une vague d’échecs d’authentification et, dans le pire cas, une indisponibilité quasi totale du service sur les terminaux concernés.

Ce guide propose une méthode vendor‑agnostic (sans pas‑à‑pas produit) pour prévenir ce type de panne en environnement commercial et hôtellerie au Maroc : inventaire des certificats, calendrier, renouvellement sans rupture, tests réalistes, gestion de la révocation et scénarios de mode dégradé.

Ce qui se passe réellement quand « le Wi‑Fi tombe » à cause d’un certificat

Dans un Wi‑Fi 802.1X en EAP‑TLS, l’accès réseau dépend d’un échange TLS encapsulé dans EAP. La décision d’accepter ou de refuser la connexion s’appuie notamment sur la validation de certificats X.509 : période de validité, chaîne de confiance et, selon les politiques, vérification du statut de révocation.

Une fois la date de fin de validité (notAfter) dépassée, la validation PKIX échoue : le certificat n’est plus considéré comme valide « au temps courant ». Cette logique est décrite dans la validation de certificats X.509 (RFC 5280), et elle s’applique aux échanges TLS utilisés par EAP‑TLS (RFC 5216 ; pour TLS 1.3 : RFC 9190).

Pourquoi l’impact peut être massif

  • Certificat serveur EAP‑TLS expiré : beaucoup (voire la majorité) des terminaux refusent la connexion au SSID « staff »/« corporate ».
  • Intermédiaire (CA) expiré : panne plus « surprenante » car le certificat serveur peut sembler encore valide, mais la chaîne ne l’est plus.
  • Certificats clients expirés : impact ciblé sur certaines populations (terminaux métier, postes administratifs, équipements d’exploitation), parfois sans affecter le Wi‑Fi invité.
  • Révocation / statut : selon l’architecture, la disponibilité d’OCSP/CRL et le comportement des clients peuvent créer des échecs intermittents ou différés. EAP‑TLS a une contrainte particulière : le terminal n’a pas forcément de connectivité IP avant l’authentification, donc la vérification « en ligne » n’est pas toujours possible pendant l’échange initial (RFC 5216).

Étape 1 — Faire l’inventaire des certificats « qui peuvent casser le Wi‑Fi »

Objectif : être capable de répondre à ces questions, avant l’incident :

  • Quel certificat peut faire tomber quel SSID / quel profil Wi‑Fi ?
  • Quelle population est impactée (staff, terminaux métier, IoT, BYOD, prestataires) ?
  • Où se renouvelle ce certificat (PKI interne, prestataire, service managé) et qui est responsable ?
  • Quelle dépendance existe (chaîne intermédiaire, racine, mécanisme de révocation) ?

Registre minimal recommandé

Sans imposer d’outil, un registre simple (tableur ou CMDB) suffit si vous le tenez réellement à jour :

  • Certificat serveur EAP‑TLS (serveur RADIUS / service d’authentification) : identité présentée (CN/SAN), chaîne fournie, date d’expiration, emplacement, procédure de déploiement.
  • Chaîne intermédiaire (sub‑CA) : dates d’expiration, où elle est stockée et comment elle est distribuée côté serveur.
  • Racines de confiance effectivement présentes sur les terminaux (MDM, GPO, profils mobiles, images poste).
  • Certificats clients (si EAP‑TLS mutualisé) : par population, mode d’enrôlement, règles de renouvellement, mécanisme de révocation.
  • Statut / révocation : CRL, OCSP, OCSP stapling (notamment mis en avant côté TLS 1.3 dans EAP‑TLS : RFC 9190 ; OCSP : RFC 6960).

Conseil d’exploitation : relier certificats et dépendances « invisibles »

Dans beaucoup d’hôtels et de sites tertiaires, l’échec 802.1X se confond avec d’autres causes (DNS, DHCP, RADIUS indisponible, problème de routage, etc.). Une bonne pratique consiste à documenter le « chemin d’accès » complet. Pour une approche checklist des dépendances, vous pouvez compléter ce guide avec : Wi‑Fi d’hôtel en panne : vérifier les services d’adressage, de noms et d’authentification.

Étape 2 — Mettre un calendrier de renouvellement (et pas seulement une alerte)

Le piège classique est de découvrir l’expiration « trop tard » : on renouvelle dans l’urgence, on déploie sans tests, et on crée une panne différente (mauvaise chaîne, identité serveur inattendue, terminaux non provisionnés en confiance, etc.).

Deux horizons à formaliser

  • Renouvellement standard : une fenêtre suffisamment en amont pour préparer le nouveau certificat, tester et orchestrer le déploiement (y compris la propagation MDM/GPO côté clients).
  • Incident imminent : un runbook plus « opérationnel » (gel des changements non essentiels, communication interne, validation accélérée, décision de mode dégradé si nécessaire).

Le calendrier doit couvrir toute la chaîne (serveur + intermédiaires + racines si rotation), pas uniquement le certificat « visible » côté serveur.

Étape 3 — Renouveler sans rupture : principes agnostiques produit

Un renouvellement EAP‑TLS réussi consiste à changer un composant cryptographique sans casser la confiance des terminaux. Les étapes exactes dépendent de votre contrôleur Wi‑Fi, serveur RADIUS et outils poste, mais les principes restent constants.

Principe A : ne changez pas la « confiance » au même moment que le certificat serveur, sauf si c’est piloté

Si vous introduisez une nouvelle CA (racine/intermédiaire), la priorité est de distribuer cette confiance à tous les terminaux concernés avant la bascule du serveur. Les environnements hôteliers sont particulièrement exposés si des appareils sont rarement connectés au réseau interne (terminaux saisonniers, appareils de prestataires, stocks en réserve).

Principe B : vérifier ce que les clients « attendent » du serveur

Selon la configuration des supplicants, les clients peuvent vérifier l’identité du serveur (CN/SAN), l’usage du certificat (Extended Key Usage) et la chaîne. EAP‑TLS recommande de valider des points comme l’usage prévu du certificat via l’Extended Key Usage (voir RFC 5216).

Principe C : prévoir une coexistence maîtrisée

Dans un parc hétérogène, certains terminaux mettent plus de temps à recevoir les nouveaux paramètres de confiance (ou ont des stacks TLS plus strictes). Prévoir une période de coexistence (ancienne et nouvelle confiance) peut réduire le risque, mais doit rester contrôlée et documentée (sinon, vous accumulez de la dette de sécurité).

Étape 4 — Tests : « comme si ça expirait demain »

La meilleure prévention est de tester avant la date critique, avec un panel de terminaux représentatifs. Le but n’est pas de tester « le Wi‑Fi » au sens radio, mais le chemin d’authentification et ce qui l’entoure.

Table de tests recommandés (et leurs limites)

Test Objectif Limites / points d’attention
Connexion EAP‑TLS sur un panel de terminaux Valider que l’authentification passe après changement (certificat/chaîne) Un panel incomplet donne une fausse confiance : inclure terminaux métier, OS variés, profils MDM/GPO, appareils « anciens » encore en production
Validation de chaîne présentée par le serveur Vérifier que le serveur fournit la chaîne attendue (hors racine) EAP‑TLS recommande que le serveur fournisse la chaîne pour faciliter la validation côté client (RFC 5216)
Test « heure incorrecte » (client et serveur) Éliminer un faux diagnostic : un certificat peut être refusé si l’heure système est erronée Ne remplace pas la supervision NTP ; utile surtout en incident ou sur équipements souvent éteints
Test de révocation (selon votre politique) Vérifier le comportement en cas de certificat révoqué et la disponibilité des mécanismes de statut En EAP‑TLS, la vérification en ligne peut ne pas être possible avant d’avoir du réseau ; le RFC prévoit des vérifications après authentification (RFC 5216)

Supervision : distinguer « qualité Wi‑Fi » et « échecs d’authentification »

Pour que l’alerte soit actionnable, vos outils (contrôleur Wi‑Fi, RADIUS, SIEM, supervision) doivent permettre de séparer :

  • les problèmes radio (couverture, interférences, saturation),
  • les problèmes d’accès réseau (DHCP/DNS),
  • les problèmes d’authentification 802.1X (EAP‑TLS, certificats, chaîne, statut).

Sur la conception globale d’un réseau Wi‑Fi professionnel (au‑delà du sujet certificats), voir : Réseau Wi‑Fi professionnel : comment bien le concevoir en entreprise ?.

Expiration vs révocation : deux scénarios, deux gestes d’exploitation

Un point important pour les équipes IT et exploitation : expiration et révocation ne se traitent pas comme le même événement.

  • Expiration : événement attendu (cycle de vie normal). La prévention repose sur le calendrier et les tests.
  • Révocation : événement de sécurité (perte d’un terminal, suspicion de compromission, retrait d’accès). Les exigences de vérification du statut sont discutées dans les RFC (révocation et mécanismes associés : RFC 5280 ; OCSP : RFC 6960 ; EAP‑TLS TLS 1.3 : RFC 9190).

Recommandation de projet : documenter « qui peut révoquer » et « comment on vérifie »

Sans entrer dans des détails dépendants d’éditeurs, un document interne simple évite la panique en cas d’incident :

  • quels cas déclenchent une révocation (perte d’équipement, départ d’un prestataire, incident sécurité),
  • qui décide et qui exécute (PKI, IT, RSSI, prestataire),
  • comment les terminaux obtiennent l’information de statut (CRL/OCSP) et quelles dépendances réseau cela implique.

Mode dégradé : décider avant la crise (et assumer le compromis)

Quand l’authentification 802.1X échoue massivement, la tentation est forte de « contourner » (changer de méthode, baisser le niveau de sécurité, ouvrir un SSID). En environnement hôtelier et commercial, cela peut exposer des systèmes métiers.

Un mode dégradé doit donc être une décision de risque préparée :

  • SSID de secours très restreint (quarantaine / VLAN limité) pour maintenir quelques fonctions vitales.
  • Accès filaire temporaire pour des postes critiques (réception, back‑office) lorsque c’est possible.
  • Procédure d’inscription d’urgence pour terminaux métier, encadrée et tracée.

En hôtellerie, ce sujet s’inscrit dans une vision plus large de l’architecture IP (Wi‑Fi, VoIP, IPTV, sûreté, GRMS). Pour une vue d’ensemble utile en conception, voir : Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?.

Runbook « jour J » : quoi vérifier quand la panne est déjà visible

  1. Confirmer l’horodatage (heure/zone) sur : serveur(s) d’authentification, contrôleur/gestion Wi‑Fi, quelques terminaux représentatifs.
  2. Identifier le point commun des échecs : même SSID, même profil EAP, même population (par exemple appareils métiers).
  3. Isoler le certificat suspect : certificat serveur EAP‑TLS, intermédiaire, certificats clients d’une population.
  4. Contrôler la chaîne présentée et la date de fin de validité.
  5. Si statut/révocation en cause : vérifier la disponibilité et l’accessibilité des mécanismes (CRL/OCSP) et tenir compte du fait que le contrôle peut intervenir après l’obtention de connectivité selon les implémentations et les recommandations EAP‑TLS (RFC 5216).
  6. Appliquer la correction (renouvellement, re‑déploiement de chaîne, distribution de confiance) puis re‑tester le panel.
  7. Communiquer : périmètre impacté, contournement temporaire, état d’avancement, conditions de retour à la normale.

Ce qu’il faut documenter pour que l’incident ne se reproduise pas

  • Registre des certificats Wi‑Fi (propriétaire, usage, chaîne, dates, procédure, plan de repli).
  • Calendrier récurrent + alertes exploitables (pas une simple notification « à la date d’expiration »).
  • Procédure de renouvellement avec fenêtre de tests et critères de validation.
  • Procédure de révocation (qui, quand, comment, dépendances réseau).
  • Scénario de mode dégradé validé et assumé (technique + sécurité + exploitation).

Quand faire appel à Domocasa

Si vous exploitez un Wi‑Fi 802.1X en entreprise ou en hôtellerie et que vous souhaitez sécuriser la phase « jour 2 » (inventaire, procédures, tests, modes dégradés, supervision), Domocasa peut vous accompagner sur l’architecture et la maintenabilité de l’infrastructure. Voir : Réseau d’entreprise.

Sources et documentation

  • RFC 5216 — EAP‑TLS.
  • RFC 9190 — EAP‑TLS 1.3.
  • RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
  • RFC 6960 — Online Certificate Status Protocol (OCSP).
1Oct

Remise d’un éclairage DALI‑2 : le dossier d’exploitation minimal à exiger pour rester autonome en hôtel

by Domocasa
Énergie et CVC Guides techniques Hôtellerie

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

Un éclairage DALI‑2 peut être « OK à la réception » et devenir difficile à maintenir quelques mois plus tard si l’exploitant ne dispose pas de la cartographie d’adressage, des groupes/scènes réellement programmés, et d’un inventaire vérifiable des produits installés (et de leur statut de certification).

Ce guide propose un dossier d’exploitation minimal (orienté remise / jour 2) pour un hôtel : il vise l’autonomie (dépannage, remplacement d’équipements, évolution de scènes), sans dépendre systématiquement du prestataire de mise en service.

Périmètre : lot éclairage DALI‑2 (drivers / capteurs / contrôleurs DALI, passerelles éventuelles). Les obligations réglementaires locales ne sont pas traitées ici : elles varient selon le projet et le cadre applicable.

Pourquoi un dossier d’exploitation DALI‑2 spécifique (et pas un DOE “papier” générique) ?

En DALI, l’exploitation quotidienne se fait rarement « luminaire par luminaire ». En pratique, l’hôtel travaille avec :

  • des adresses (pour identifier un équipement précis),
  • des groupes (zones fonctionnelles),
  • des scènes (ambiances),
  • et des déclencheurs (boutons, capteurs, horaires, intégration GTB/GRMS).

Si ces éléments ne sont pas documentés et sauvegardés, le système reste pilotable… mais devient fragile à maintenir : un simple remplacement de driver ou une modification d’ambiance peut entraîner des régressions, voire une reprogrammation complète.

Rappels utiles (pour cadrer vos livrables)

DALI‑2 : interopérabilité et certification (à vérifier sur une base publique)

DALI‑2 renvoie à des spécifications techniques et à un programme de certification opéré par la DALI Alliance (DiiA). Côté exploitant, le point clé est opérationnel : vous devez pouvoir recouper les références installées avec la base produits publique, et conserver une traçabilité suffisante pour éviter les confusions de versions.

Adresses, groupes, scènes : les limites “bus” à connaître (pour détecter un DOE incomplet)

Sans transformer votre remise en audit normatif, il est utile de connaître quelques repères décrits dans le DALI Quick Start Guide :

  • les commandes peuvent être adressées à un équipement, à un groupe, ou en broadcast (diffusion),
  • les scènes sont stockées au niveau des équipements d’éclairage (control gear) et rappelées par commande,
  • la structuration adresses / groupes / scènes impose une discipline documentaire : si vos tableaux sont absents, l’exploitation devient dépendante.

Le dossier minimal à exiger à la remise : 4 blocs

Bloc A — Architecture “tel que construit” (as built)

Objectif : diagnostiquer vite (panne de segment, défaut d’alimentation, problème localisé), et isoler clairement ce qui relève du DALI et ce qui relève d’une intégration (GTB/GRMS, IP, passerelle).

À exiger (minimum) :

  • Synoptique as built : lignes/bus DALI (par zone/étage), alimentation(s) de bus, application controller(s), passerelles éventuelles (ex. vers GTB/GRMS).
  • Plan ou schéma de repérage terrain : coffrets/armoires, borniers, repères, correspondance “zone ↔ ligne/bus”.
  • Topologie déclarée (étoile / ligne / mix) et points de segmentation (si applicable).

Recommandation projet : ajoutez une page « hypothèses d’installation » (ce qui a été retenu et pourquoi) plutôt qu’un simple schéma : c’est souvent ce qui fait gagner du temps en dépannage.

Bloc B — Inventaire des produits installés + preuve de certification

Objectif : remplacer sans régression, maîtriser le multi‑marques, et vérifier la conformité annoncée au marché.

À exiger (minimum) :

  • Inventaire par bus / zone : drivers (control gear), capteurs et interfaces (input devices), contrôleurs DALI (control devices), alimentations de bus, passerelles.
  • Pour chaque référence : marque, référence commerciale, rôle (control gear / control device / input device), localisation, quantité.
  • Éléments d’identité permettant de confirmer qu’il s’agit bien du produit certifié listé dans la base DALI Alliance (ex. GTIN et informations associées lorsque disponibles côté produit/base).

Pièces justificatives (pragmatiques) :

  • un export (CSV/PDF) de l’outil de mise en service/supervision montrant les équipements détectés,
  • pour les références “critiques” (drivers principaux, contrôleur, capteurs) : lien vers la fiche correspondante dans la Product Database (ou un identifiant permettant de la retrouver sans ambiguïté).

Règle simple à écrire dans votre demande de remise : « Tout équipement présenté comme DALI‑2 certifié doit être retrouvable dans la Product Database. S’il ne l’est pas, il doit être explicitement identifié comme non certifié (ou hors périmètre de certification) dans l’inventaire. »

Bloc C — Adressage, groupes, scènes : la cartographie d’exploitation

Objectif : comprendre “qui pilote quoi”, modifier une ambiance, réadresser un équipement remplacé, et diagnostiquer les effets de bord (un bouton qui agit sur la mauvaise zone, une scène incomplète, etc.).

1) Table d’adressage (par bus)

À exiger : un tableau « adresse → équipement », lisible par l’exploitation, comprenant au minimum :

  • adresses DALI et type d’équipement,
  • zone/localisation (étage, secteur, local technique),
  • désignation exploitation (noms compréhensibles),
  • marque/référence (renvoi vers l’inventaire).

2) Table des groupes

À exiger : la liste des groupes, leur nom d’usage, et leurs membres (adresses). Sans cette table, vous ne pouvez pas reprendre proprement une logique “zone”.

3) Table des scènes (ambiances)

À exiger : la liste des scènes réellement utilisées, avec :

  • nom d’usage (Accueil jour, Accueil nuit, Nettoyage…),
  • zone/groupe concerné,
  • déclencheur (bouton, horaire, GTB/GRMS…),
  • résultat attendu (au minimum par groupe ; plus fin si votre programmation est plus fine).

4) Matrice “entrées → actions” (boutons/capteurs → groupes/scènes)

À exiger : une matrice qui relie chaque commande (bouton, capteur, contact) à l’action attendue : groupe ciblé, scène rappelée, temporisations/conditions utiles à l’exploitation et au support.

Bloc D — Sauvegardes, accès et restauration (anti-dépendance)

Objectif : ne pas être bloqué si un contrôleur tombe en panne, si un prestataire intervient sans traçabilité, ou si vous devez répliquer une configuration sur une zone similaire.

À exiger (minimum) :

  • Fichier(s) projet natifs de l’application controller / outil de mise en service (format éditeur), plus la version logicielle utilisée.
  • Exports lisibles (CSV/PDF) : inventaire détecté, adressage, groupes, scènes, matrice entrées→actions. (Il n’existe pas, à notre connaissance, un format universel unique “DOE DALI‑2” : contractualisez les formats acceptés sur votre projet.)
  • Accès : comptes, niveaux de droits, adresses IP si applicable, procédure de remise/changement de mots de passe (à gérer selon vos règles IT).
  • Procédure courte (et testée) : restauration du projet, remplacement d’un équipement, réintégration dans groupes/scènes, vérification du résultat.

Vérifications rapides le jour de la remise (orientées exploitation, pas “audit laboratoire”)

Vérifier que la logique groupes/scènes est documentée (sinon vous êtes dépendant)

Choisissez quelques zones représentatives (ex. un couloir, un lobby, un espace back‑of‑house) et vérifiez :

  • qu’un groupe “zone” existe et correspond au terrain,
  • qu’une ou deux scènes correspondent à une intention d’usage claire et reproductible,
  • qu’un déclencheur (bouton/capteur/horaire) correspond à la matrice entrées→actions remise.

Si “ça marche” mais que les tables (adressage/groupes/scènes) ne sont pas remises, vous n’avez pas un dossier d’exploitation : vous avez une démonstration.

Vérifier l’inventaire et la certification sur un échantillon critique

Sur quelques références clés (drivers dominants, contrôleur, capteurs), recoupez :

  • la référence exacte installée (marque + référence),
  • sa présence dans la Product Database si elle est annoncée certifiée,
  • et, si nécessaire, les éléments d’identité permettant d’éviter une confusion de variante/version.

Cette vérification est particulièrement utile en hôtellerie, où le stock de maintenance et les remplacements par lots font vite apparaître des “quasi‑équivalents” qui ne se comportent pas exactement pareil.

Modèles de tableaux (à copier-coller dans votre demande de remise)

Modèle 1 — Adressage (par bus)

Bus Adresse Type Zone Désignation exploitation Marque / Référence Remarques
DALI-A … Control gear / Control device / Input device … … … …

Modèle 2 — Groupes

Bus Groupe Nom du groupe Membres (adresses) Usage
DALI-A … … … Zone / Ménage / Maintenance / Autre

Modèle 3 — Scènes

Bus Zone / Groupe Scène Nom d’usage Déclencheur Résultat attendu
DALI-A … … … Bouton / Horaire / GTB …

Modèle 4 — Entrées → Actions

Commande (device/instance) Localisation Évènement Action (groupe/scène) Temporisations / conditions Comment tester
… … Appui / Présence / Absence… … … …

À relier à vos autres livrables “hôtel” (pour éviter les angles morts)

Ce dossier d’exploitation DALI‑2 ne remplace pas vos documents d’exploitation transverses (réseau, supervision, organisation maintenance). Pour une approche DOE “jour 2” plus globale, voir : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?

Et si votre enjeu est de valider l’interopérabilité (preuves, tests de réception, réduction du risque multi‑marques), vous pouvez compléter avec : Réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité et éviter les incompatibilités.

Conclusion

Un bon dossier d’exploitation DALI‑2 pour un hôtel tient en quatre blocs simples : as built, inventaire vérifiable (avec statut de certification quand il est revendiqué), cartographie adresses/groupes/scènes, et sauvegardes + procédures de restauration. C’est ce socle qui vous évite de “tout reprogrammer” au premier remplacement, et qui protège votre exploitation contre la dépendance à un outil ou à un prestataire unique.

Si vous le souhaitez, Domocasa peut vous aider à transformer cette checklist en liste de livrables contractuels (formats, responsabilités, critères de réception) adaptée à votre architecture (DALI‑2 local, intégration KNX/GTB/GRMS, supervision).

Sources et documentation

28Sep

Étendre un pilotage KNX sans tirer un bus partout : que permet KNX IoT (Ethernet, Wi‑Fi, Thread) pour un hôtel ?

by Domocasa
Hôtellerie Smart Building et GTB Smart Home et KNX

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

Dans un hôtel existant, KNX “classique” (par exemple en KNX TP sur paire torsadée) reste une base très fiable. Le problème apparaît lorsqu’il faut étendre l’automatisation vers des zones difficiles à recâbler : étage déjà fini, nouvel espace (boutique, spa, salle de réunion), bâtiment annexe, ou extension livrée après coup.

KNX IoT apporte une réponse structurante : au lieu de raisonner “bus partout”, on peut raisonner KNX sur IP (IPv6), avec des médias comme Ethernet, Wi‑Fi ou Thread, tout en restant dans l’écosystème KNX (commissioning, modèles, interopérabilité). L’enjeu, côté exploitation hôtelière, est de rendre cette extension testable en recette et industrialisable sur plusieurs sites, sans créer une usine à gaz.

KNX IoT, en clair : ce que ça change (et ce que ça ne change pas)

KNX IoT n’est pas “un produit Wi‑Fi” : c’est une évolution KNX vers l’IP

KNX IoT s’appuie sur une communication IPv6 et peut fonctionner sur des médias IP modernes. Concrètement, cela ouvre la porte à des équipements KNX IoT qui communiquent sur Ethernet, Wi‑Fi ou Thread, sans exiger de tirer un bus TP jusque partout. Source : KNX Association — KNX Technology.

KNX IoT ne “remplace pas” mécaniquement KNX TP

Dans la majorité des hôtels, une stratégie réaliste consiste plutôt à composer :

  • conserver KNX TP comme socle dans les zones déjà câblées (chambres, couloirs, locaux techniques historiques),
  • ajouter des extensions sur IP lorsque l’extension TP serait trop intrusive ou trop coûteuse,
  • cadrer l’intégration (supervision/GTB, outils énergie, maintenance) via des interfaces standardisées plutôt que des mappings “fait maison” différents sur chaque site.

Les médias KNX IoT utiles en extension d’hôtel : Ethernet, Wi‑Fi, Thread

KNX décrit des profils d’équipements KNX IoT (Point API devices) selon le média IP utilisé, et précise un point important pour l’IT : sur Wi‑Fi et Thread, la couche physique n’est pas “spécifiée KNX” comme elle l’est sur TP/RF ; KNX IoT s’appuie sur un média IPv6 existant. Source : KNX Technology.

Média Ce que ça facilite en hôtel Ce qu’il faut cadrer (recette/exploitation)
Ethernet Extension “back‑office” souvent plus prévisible : locaux techniques, salles de réunion, zones tertiaires, nouvelles armoires. Architecture réseau IP (segmentation, accès maintenance), dépendances IT, gouvernance des accès.
Wi‑Fi Ajouts ponctuels là où tirer du câble est trop intrusif. Couverture réelle, roaming, politique d’accès, et rappel opérationnel : “sans fil” ≠ “sans alimentation” (énergie, maintenance, remplacement).
Thread Îlots mesh IPv6 dans des zones où l’on ne veut pas étendre le Wi‑Fi (ou où le Wi‑Fi “métier” est déjà très chargé). Présence et maintien d’un border router (brique réseau à maintenir), choix d’implantation, continuité de service.

Étendre “sans bus classique” : scénarios d’architecture réalistes

Conserver KNX TP et ajouter des zones KNX IoT (mix TP + IoT)

Ce scénario est souvent le plus pragmatique en hôtellerie : vous conservez les lignes TP existantes (quand elles sont saines), et vous raccordez les nouvelles zones via KNX IoT sur IP.

KNX définit le KNX IoT Router comme une passerelle entre des appareils KNX TP/RF/IPv4 et des appareils KNX IoT, et précise qu’il peut être stand‑alone ou intégré à un autre élément réseau (exemple : Thread Border Router + KNX IoT Router). Source : KNX Technology.

Créer des “îlots” KNX IoT Wi‑Fi (extensions ponctuelles)

Intéressant pour une extension ciblée (une zone premium, un espace événementiel) quand la reprise de câblage est disproportionnée. En revanche, la réussite dépend moins du protocole que de la recette IT : visibilité réseau, droits, stabilité Wi‑Fi “métier”, et capacité des équipes à maintenir cette zone au jour deux.

Pour cadrer le sujet côté infrastructure, vous pouvez aussi lire : Architecture réseau IP d’un hôtel : cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS.

Créer des îlots Thread (mesh) avec border router

KNX documente la notion de Thread Border Router comme élément de topologie nécessaire pour permettre aux équipements Thread de communiquer avec le LAN/WAN. Source : KNX Technology. La documentation support KNX rappelle également que, si des appareils KNX IoT utilisent Thread comme couche réseau, un IPv6 Border Router est requis pour connecter vers “le monde IPv4”. Source : KNX Association — KNX IoT Roll‑out.

Lecture “hôtel” : ce scénario peut être pertinent, mais il introduit une brique active à maintenir. Ce n’est pas un défaut en soi ; c’est un point à assumer explicitement dans les livrables d’exploitation (responsable, sauvegardes, remplacement, supervision de l’état).

Ce qui change le plus en multi‑sites : API et modèles standardisés (exploitation, supervision, outillage)

KNX Information Model + KNX IoT API Server : une voie vers une intégration plus industrialisable

KNX décrit un KNX IoT API Server s’appuyant sur le KNX Information Model, exporté nativement par ETS, afin d’exposer une API standardisée pour des tiers. KNX indique aussi qu’un serveur certifié a été testé contre les spécifications KNX, et qu’un client tiers peut viser une compatibilité “indépendante du fabricant” (au niveau du modèle/API, sous réserve des implémentations). Source : KNX Technology.

En hôtellerie multi‑sites, l’intérêt potentiel est clair : réduire la part d’intégration “sur‑mesure” qui change d’un établissement à l’autre. Mais cela ne dispense pas de valider, fabricant par fabricant, ce qui est réellement exposé (points, diagnostics, commandes) et comment c’est sécurisé.

KNX IoT 3rd Party API : un vocabulaire plus “IT” (OAuth2, scopes, accès au niveau Installation)

La KNX IoT 3rd Party API est documentée comme une API d’accès au niveau Installation, visant des requêtes plus riches (dont historique de valeurs), avec une motivation explicite : permettre à un partenaire de communication non certifié KNX de s’intégrer à une installation KNX Classic. La section d’authentification décrit un flux OAuth2 (authorization code flow) et des scopes read/write. Source : schema.knx.org — KNX IoT 3rd Party API (1.0).

Cadrage versions : dans cet article, les exemples “API / OAuth2 / scopes” s’appuient sur la documentation schema.knx.org en version 1.0 (utile pour comprendre le modèle). Pour un projet, le bon réflexe est de partir de la page officielle KNX IoT Downloads, qui récapitule les versions et statuts ; elle indique notamment la 3rd Party API 2.1.0 en statut release (page affichée comme mise à jour le 01 septembre 2026).

Lecture “exploitation hôtelière” : ce type d’authentification et de gouvernance des accès est généralement plus facile à intégrer dans des pratiques IT (comptes, droits, audit) qu’une accumulation de passerelles hétérogènes. Mais la réalité dépendra du produit qui implémente l’API server/gateway et de sa mise en œuvre sur le réseau du client.

KNX IoT Point API : parler “périphériques et points” (device/points) sur IP

La KNX IoT Point API est documentée comme un mapping vers un modèle de ressources RESTful sur CoAP, avec représentation CBOR/JSON, permettant de lire/écrire et de s’abonner à des événements. Source : schema.knx.org — KNX Point API (1.0.0).

En pratique, c’est intéressant si vous voulez outiller la recette et l’exploitation : inventaire de points, vérification automatisée de comportements attendus, cohérence entre étages, etc. Là encore, cela suppose que les équipements déployés exposent effectivement ces interfaces dans le périmètre de votre projet.

Pour approfondir la logique “hôtel + recette”, voir aussi : Superviser KNX autrement : à quoi sert la KNX IoT Point API pour un hôtel (et quelles limites en recette).

Recette et exploitation : tests concrets à inscrire au projet (sans sur‑promesse)

KNX IoT est une évolution prometteuse, mais la réussite en hôtel dépend d’une recette orientée exploitation. Voici des tests pragmatiques, directement liés à ce que documentent les briques KNX IoT (transports IP, routeur, API) et à ce que l’exploitation doit maîtriser.

Tests “transport et réseau” (Ethernet/Wi‑Fi/Thread)

  • Découvrabilité et visibilité : vérifier que les équipements sont joignables, détectables et commissionnables dans les conditions réelles du site (et pas uniquement “au laboratoire”).
  • Stabilité en conditions d’usage : vérifier les pertes de connectivité lors des opérations normales (maintenance réseau, bascule, extinction locale, redémarrages).
  • Séparation des environnements : clarifier ce qui doit être accessible depuis la supervision, depuis un poste de maintenance, et ce qui doit rester isolé (réseau client, réseau bureautique, réseau “systèmes techniques”).

Tests “mix médias” (KNX TP existant + KNX IoT)

  • Rôle et modes dégradés du KNX IoT Router : définir ce qui se passe si le routeur n’est plus disponible (quels automatismes continuent localement, quels points ne remontent plus, quelles alarmes sont attendues).
  • Continuité fonctionnelle : valider les scénarios essentiels (confort client, sécurité d’usage, modes housekeeping) sur l’existant et sur l’extension.

Tests “API et gouvernance des accès” (Point API / 3rd Party API / API Server)

  • Authentification et droits : valider le modèle d’accès (par exemple, scopes read/write côté 3rd Party API), les comptes, et les responsabilités (IT, intégrateur, exploitation).
  • Contrôle de périmètre : confirmer quels points sont exposés (commande, paramètres, diagnostics) et lesquels ne le sont pas.
  • Recette multi‑sites : définir une check‑list reproductible (inventaire des points, tests de commande, retours d’état, alertes attendues) afin d’éviter une intégration “unique” à chaque établissement.

Maturité et versions : ce que disent les pages officielles (à cadrer avant de standardiser)

Sur un sujet émergent, la question n’est pas seulement “est‑ce spécifié ?”, mais “est‑ce disponible, maintenable, et stable sur la durée ?”. La page support KNX “Downloads” (mise à jour le 01 septembre 2026) liste des versions et statuts de maturité (release, outdated, work in progress) pour plusieurs briques KNX IoT et rappelle que la version de spécification écrite peut différer de la version d’API/Ontologie listée. Source : KNX Association — Downloads.

Lecture “projet hôtel” : avant de promettre une stratégie multi‑sites, il faut verrouiller votre périmètre de versions (spécification + implémentations), et surtout vérifier la disponibilité produit (routeurs, serveurs, périphériques), fabricant par fabricant, avec une preuve de conformité et un plan de mise à jour.

À retenir pour un hôtel (décision rapide)

  • Étendre sans tirer un bus partout : KNX IoT permet d’adosser des zones à un réseau IP (Ethernet/Wi‑Fi/Thread) plutôt que d’étendre du KNX TP de bout en bout.
  • Garder l’existant : une approche hybride est souvent la plus réaliste, avec un KNX IoT Router pour raccorder l’historique KNX TP/RF et les extensions KNX IoT.
  • Industrialiser l’exploitation multi‑sites : l’intérêt des API (Point API, 3rd Party API, API Server + Information Model) est de réduire l’intégration “artisanale”, à condition de cadrer versions, sécurité, responsabilités, et disponibilité produit.

Pour aller plus loin (lectures Domocasa)

Sources et documentation (officielles)

Vous préparez une extension KNX en rénovation, ou un modèle d’exploitation reproductible sur plusieurs établissements ? Domocasa peut vous aider à cadrer l’architecture cible, la recette et les livrables d’exploitation (périmètre, rôles, tests, modes dégradés).

24Sep

Superviser KNX autrement : à quoi sert la KNX IoT Point API pour un hôtel (et quelles limites en recette)

by Domocasa
Guides techniques Hôtellerie Smart Building et GTB

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

Dans un hôtel, la difficulté n’est pas seulement de piloter l’éclairage, le CVC ou les stores en KNX : c’est de rendre ces fonctions exploitables par la supervision/GTB, les outils énergie, la maintenance et, parfois, des applications tierces (dashboards, analytics, GMAO, etc.). Historiquement, cette passerelle se faisait souvent au moyen de mappings très spécifiques (adresses de groupe, conventions locales, passerelles propriétaires), difficiles à industrialiser d’un établissement à l’autre.

La KNX IoT Point API fait partie de KNX IoT : elle vise à standardiser la façon d’exposer et d’accéder à des « points » (valeurs capteurs/actionneurs, paramètres, diagnostics) via IP, avec une logique de découverte, de sécurité et de modèle de ressources plus cohérente que des intégrations ad hoc. L’enjeu, en hôtellerie, n’est pas de promettre une « intégration magique », mais de réduire la part d’ingénierie répétitive et de mieux cadrer ce qui devra être recetté (droits, réseau, sémantique, résilience).

KNX IoT Point API : l’idée (sans marketing)

La documentation KNX IoT présente la Point API Stack comme une cartographie des données applicatives KNX vers un modèle de ressources RESTful, avec des représentations CBOR/JSON, transportées sur CoAP/UDP sur IP. Elle inclut des blocs « Discovery », « Security », « S‑Mode » et l’accès read/write/subscribe à des propriétés de paramètres et de diagnostic (GET/PUT/Observe). (KNX IoT – Point API Stack)

Les fichiers de spécification et schémas OpenAPI de la Point API sont publiés sur schema.knx.org (Point API 1.0.0). (KNX Schema – Point API 1.0.0)

Où se place la Point API dans une architecture d’hôtel ?

Pour éviter les malentendus en conception, il faut distinguer le rôle “device” (exposer des ressources sur le réseau IP) et le rôle “système” (exposer une vision cohérente d’une installation, avec un modèle d’information).

Les briques KNX IoT à connaître (au bon niveau)

  • KNX IoT Point API device : un équipement KNX IoT (Ethernet / Wi‑Fi / Thread) qui expose des ressources accessibles via la Point API. (KNX – KNX Technology)
  • KNX IoT Router : une passerelle entre des segments KNX TP/RF/IPv4 et des équipements KNX IoT. (KNX – KNX Technology)
  • KNX IoT API Server : selon KNX, il utilise le KNX Information Model (exporté nativement par ETS6) pour exposer une API standardisée à des tiers. (KNX – KNX Technology)

Dans un projet hôtel, ces rôles peuvent coexister : on peut exposer certains équipements via Point API, tout en structurant l’intégration « à l’échelle installation » via un serveur (selon l’architecture retenue, le périmètre et les produits disponibles).

Un point d’attention “exploitation” : qui est responsable du mapping ?

Même si l’API standardise la manière de dialoguer, il reste à contractualiser la qualité des données exposées : nommage, structuration par chambre/zone, diagnostics réellement disponibles, etc. Sur un hôtel, c’est typiquement ce qui détermine si la supervision est maintenable au jour 2 (extensions, remplacements, rénovations partielles).

Ce que la KNX IoT Point API standardise (et pourquoi ça aide une supervision)

La Point API Stack décrit plusieurs blocs qui parlent directement aux besoins d’une supervision/GTB ou d’une application tierce.

Découverte (discovery)

La documentation indique que les clients peuvent réaliser la découverte de ressources via CoAP unicast/multicast ou via mDNS (DNS‑SD), afin d’identifier les ressources (functional blocks, propriétés) exposées par un serveur. (KNX IoT – Discovery)

Implication projet : la découverte n’est pas qu’un détail technique. Elle dépend fortement de l’architecture réseau (routage inter‑VLAN, filtrage multicast, politiques IT) et doit donc être testée dans l’environnement réel de l’hôtel.

Lecture/écriture/abonnement sur des URIs (GET/PUT/Observe)

La Point API présente des propriétés paramètres et diagnostics accessibles via une URI unique : lecture (GET), écriture éventuelle (PUT), et abonnement (Observe) pour recevoir des changements. (KNX IoT – r/w/pub/sub)

Pour l’exploitation hôtelière, cela peut aider à rendre plus reproductibles :

  • la lecture d’états utiles (occupation, défauts, températures, positions, etc.),
  • l’écriture de consignes (consignes CVC, modes, scènes…),
  • la remontée d’événements (changements d’état) vers une supervision,
  • l’industrialisation de clients applicatifs (mêmes patterns d’accès, même logique de sécurité).

Réserve importante : le standard cadre l’accès, mais ne remplace pas le travail d’ingénierie sur la sélection des points, leur structuration, et la stratégie de droits (qui peut écrire quoi, où, et quand).

Communication de groupe (S‑Mode)

La documentation de la Stack rappelle le principe S‑Mode : une communication orientée messages pour la communication de groupe, configurée par l’outil de commissioning. (KNX IoT – Group Communication / S‑Mode)

Le prérequis n°1 en hôtellerie : cadrer l’architecture IT/OT (avant de parler API)

En pratique, la réussite d’une supervision via API dépend d’abord de l’architecture IT/OT et de l’exploitation. La Point API étant IP‑native (et la découverte pouvant s’appuyer sur des mécanismes multicast), le projet doit définir :

  • la segmentation réseau (au minimum, séparation des réseaux invités et des réseaux techniques),
  • les flux autorisés (pare‑feu) entre supervision/GTB et équipements exposant l’API,
  • la gouvernance des accès distants (maintenance, intégrateurs, support),
  • les règles de durcissement (comptes, certificats/jetons, rotation, révocation),
  • la stratégie de mise à jour et la gestion des indisponibilités.

Pour cadrer cette couche « hôtel » avant de figer une intégration KNX IoT, deux lectures Domocasa sont souvent utiles :

Modèle d’information KNX : la sémantique compte autant que la connectivité

KNX IoT s’appuie sur le Home and Building Electronic Systems Information Model (EN50090‑6‑2) : la documentation le décrit comme un schéma/vocabulaire pour représenter un graphe d’automatisation (devices, datapoints, locations et relations). (KNX IoT – Information Model)

Dans un hôtel, l’intérêt est très concret : vous ne voulez pas seulement « voir des valeurs », vous voulez pouvoir exploiter des ensembles de points par chambre, par étage, par usage, comparer plusieurs sites, ou encore alimenter des tableaux de bord énergie/maintenance sans réinventer des conventions à chaque projet.

Sur ce sujet « données/sémantique », l’article Domocasa suivant peut compléter la réflexion côté GTB :

Sécurité : ce que KNX IoT prévoit… et ce que le projet doit décider

La documentation de la Point API Stack indique qu’OSCORE (sécurité en couche applicative) sécurise les échanges CoAP, y compris la communication de groupe (S‑Mode) et l’accès aux propriétés paramètres/diagnostics. Elle mentionne aussi un usage optionnel de TLS/(D)TLS (chiffrement en couche transport) pendant le commissioning et l’enrôlement d’identité (LDevID), selon les profils retenus. (KNX IoT – Cybersecurity)

Contrôle d’accès : /auth/at et /auth/crts

La page « Device Access Control » détaille deux ressources structurantes :

  • /auth/at : une liste de jetons d’accès (credentials + permission scopes)
  • /auth/crts : une liste de certificats CA de confiance pour l’authentification (D)TLS

Elle précise aussi qu’un client MaC (Management & Commissioning Client) configure ces ressources pendant le commissioning, et que les scopes portent la logique « qui peut accéder à quoi ». (KNX IoT – Device Access Control)

Décisions à expliciter dans un hôtel (sinon, litige en recette)

  • Lecture vs écriture : quelles applications ont le droit d’écrire des consignes (et lesquelles sont strictement en lecture) ?
  • Périmètre : séparation « chambres / parties communes / locaux techniques » du point de vue droits, et pas seulement du point de vue supervision.
  • Exploitation : qui gère la rotation/révocation des credentials, et comment est documentée la procédure (jour 2) ?

Limites et maturité : ce qui reste de l’ingénierie (et doit être recetté)

Un standard d’API n’implique pas un déploiement universel. Sur un hôtel, trois zones restent typiquement « projet » :

  • Disponibilité réelle : quels équipements du lot supportent effectivement KNX IoT/Point API (et à quelles versions), et quel rôle joue le routeur/serveur dans l’architecture retenue.
  • Qualité du mapping/sémantique : points exposés, structuration, cohérence des tags/relations, diagnostics disponibles.
  • Comportement réseau : découverte (multicast/mDNS), résilience, reprise après redémarrage, et compatibilité avec les politiques IT (filtrage inter‑VLAN, restrictions multicast, etc.).

Versions : ne pas figer un CCTP sur une référence isolée

La page KNX « Downloads » liste plusieurs versions et un statut de maturité. Par exemple, elle indique que la Point API 1.0.0 est « outdated », et présente des entrées 1.1.0 avec des statuts « outdated » et « release » selon l’artefact. (KNX Support – KNX IoT Downloads)

Implication côté hôtel : au lieu d’exiger « KNX IoT » de manière générique, demandez au titulaire d’annoncer la version (API/stack) réellement supportée par les équipements proposés, puis validez l’intégration sur périmètre (pilot zone / PoC) avant généralisation.

Un rappel utile : KNX IoT est une trajectoire (pas un snapshot)

KNX rappelle, lors de la publication du KNX Standard v3.0, que les spécifications KNX IoT (3rd Party API et Point API) constituent un point de départ et sont susceptibles d’évoluer. (KNX – KNX Standard v3.0)

Plus récemment, KNX annonce aussi un alignement des spécifications de test KNX IoT (3rd Party API, Point API, Router) dans le cadre d’une version du standard (v3.0.5). (KNX – Standard v3.0.5)

Checklist de recette (orientée exploitation hôtelière)

Ci‑dessous, une checklist volontairement orientée tests réalisables. Elle ne remplace pas le plan de test GTB/GRMS global : elle cible la couche « API » et ses dépendances (réseau, droits, sémantique).

Thème Test à réaliser Limite / point de vigilance
Découverte Depuis la zone supervision/GTB, vérifier qu’un client retrouve les ressources attendues (selon l’architecture : CoAP unicast/multicast, mDNS). Un réseau « fonctionnel » pour la bureautique peut bloquer multicast/mDNS ; il faut tester dans la segmentation cible.
Inventaire Comparer la liste des équipements/points exposés avec le DOE attendu (chambres, zones, fonctions), et contrôler le nommage minimal utile exploitation. Une API standard ne garantit pas la qualité de modélisation : c’est un livrable à contractualiser.
Lecture Lire les valeurs critiques (états, températures, défauts) et valider la cohérence avec le terrain (pas seulement l’affichage). Certains points peuvent dépendre de la logique locale (GRMS, contrôleurs, modes) : valider les cas d’usage réels (ménage, DND, inoccupé…).
Écriture Écrire des consignes représentatives (modes, setpoints) et vérifier l’effet attendu, y compris en présence de verrouillages/modes locaux. L’écriture doit être limitée aux rôles autorisés (sinon risque opérationnel).
Abonnement / événements Tester Observe : détection de changements sur scénarios réalistes (occupation, scènes, cycles CVC) + comportement lors d’une coupure réseau et au retour. Les performances perçues dépendent du réseau, du filtrage et de l’implémentation des clients (supervision).
Sécurité / droits Vérifier qu’un accès non autorisé est refusé et que les scopes appliquent bien la séparation lecture/écriture et les périmètres (chambres vs communs vs technique). Le contrôle s’appuie notamment sur /auth/at et /auth/crts (commissioning MaC) : il faut une procédure d’exploitation pour la rotation/révocation.
Exploitation Simuler « jour 2 » : remplacement d’un équipement, ajout d’une chambre/zone, restauration après incident, et vérifier l’impact sur l’API et la supervision. Sans procédure et livrables (comptes, accès, sauvegardes), l’API devient un point dur en exploitation.

Où brancher la Point API dans l’hôtel : supervision, GTB, GRMS, PMS…

La Point API traite la couche « points techniques ». Mais dans un hôtel, les effets métier (arrivée, départ, ménage, DND, maintenance) impliquent souvent plusieurs systèmes (PMS, GRMS, GTB, contrôle d’accès…). Avant de connecter une application tierce « à KNX », clarifiez les responsabilités : qui décide, qui exécute, qui supervise, et quel est le mode dégradé si une interface tombe.

Pour poser ce cadre, vous pouvez vous appuyer sur : PMS, GRMS, GTB, serrures et contrôle d’accès : qui échange quoi dans un hôtel ?

Sources et documentation (références publiques)

En résumé (et un conseil simple de maîtrise de risque)

La KNX IoT Point API est une brique intéressante quand l’objectif est de relier KNX à une supervision/GTB ou à des applications tierces en parlant API de manière plus standard, avec une sécurité et une découverte cadrées. Mais, en hôtellerie, le succès se joue surtout dans la recette : droits, réseau, sémantique et procédures jour 2.

Si vous préparez un projet (neuf, rénovation ou extension) et souhaitez cadrer une architecture d’intégration réaliste (périmètre, prérequis IT/OT, stratégie de recette), Domocasa peut intervenir en AMO technique pour transformer ces exigences en livrables projet et critères de réception.

21Sep

Capteurs de présence en hôtel : mieux vaut-il les intégrer en DALI‑2 ou en KNX (et pourquoi l’exploitation change tout)

by Domocasa
Énergie et CVC Guides techniques Hôtellerie

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

En hôtellerie, un capteur de présence n’est pas seulement un “capteur” : c’est un point de contact direct avec l’expérience client (allumage trop agressif la nuit, extinction trop rapide, faux déclenchements) et un sujet d’exploitation (diagnostic, remplacement, stock, cohérence multi‑étages). La question utile n’est donc pas “quelle technologie est la meilleure ?” mais plutôt où placer la détection et où placer la logique pour que le système reste maintenable au jour 2.

Ce guide compare deux stratégies réalistes pour l’éclairage d’un hôtel :

  • Capteurs de présence côté DALI‑2 (capteurs = “input devices” DALI‑2) avec une logique d’éclairage portée par un contrôleur DALI‑2, une passerelle ou une supervision.
  • Présence/logiciel côté KNX (capteurs KNX + logique KNX) avec DALI utilisé comme sous‑système de pilotage des luminaires (souvent via passerelle KNX↔DALI).

La question qui change tout : où vit la logique, et qui saura dépanner ?

Dans un hôtel, la majorité des “irritants” ne viennent pas d’une panne franche du capteur, mais d’un ensemble capteur + règles + temporisations + modes d’exploitation :

  • gestion jour/nuit (balises, niveaux doux, anti‑éblouissement),
  • modes ménage et maintenance (forçages temporaires propres),
  • priorités (DND, présence, commande manuelle, scénarios),
  • comportements en mode dégradé (que se passe‑t‑il si une passerelle ou un contrôleur tombe ?).

Avant de choisir “DALI‑2” ou “KNX”, alignez-vous sur ce point : qui porte la logique d’éclairage (contrôleur DALI‑2, logique KNX, passerelle, supervision/GTB) et quel lot en est responsable en conception, recette et maintenance. Sur ce sujet d’architecture globale, vous pouvez aussi consulter Piloter l’éclairage d’un hôtel : KNX direct, DALI‑2 local ou DALI‑2 relié à la GTB — comment choisir sans complexifier.

Option A — Capteurs de présence en DALI‑2 : ce que DALI‑2 standardise (et ce que vous devez encore cadrer)

DALI‑2 “input devices” : ce que c’est, concrètement

La DALI Alliance présente les capteurs et autres dispositifs d’entrée comme des DALI‑2 input devices. Côté normalisation, un input device DALI‑2 s’appuie sur IEC 62386‑101 et IEC 62386‑103, puis implémente une ou plusieurs parties “applicatives” comme IEC 62386‑301 à 304 (par exemple : 62386‑303 pour les capteurs d’occupation/présence, 62386‑304 pour les capteurs de lumière). Référence : DALI Sensors and other input devices (DALI Alliance) ; Référence : DALI‑2 certification of sensors and input devices… (DALI Alliance / DiiA, PDF).

Trois détails ont un impact direct sur la conception et l’exploitation :

  • Multi‑master : plusieurs input devices peuvent partager le bus DALI,
  • Logique “événementielle” : ces devices sont normalement utilisés en mode event‑driven (avec possibilité de polling/périodique selon cas),
  • “Instances” dans un même produit : la DALI Alliance indique qu’un produit peut contenir jusqu’à 32 instances sous une seule adresse (utile quand un même capteur regroupe présence + luminosité, ou plusieurs zones logiques). Référence : Technical details (DALI Alliance).

Si vous avez besoin de clarifier les périmètres (DALI‑2 vs D4i vs “DALI+”), vous pouvez aussi lire : DALI‑2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?.

Interopérabilité : pourquoi “DALI‑2 certifié” compte en maintenance

Pour l’exploitation, DALI‑2 n’est pas seulement un “protocole” : c’est un programme de certification. La DALI Alliance présente la certification DALI‑2 comme un processus s’appuyant sur des tests et une vérification des résultats, avec des produits référencés publiquement, afin de soutenir l’interopérabilité entre produits certifiés. Référence : DALI‑2 Certification Overview.

Ce point est directement exploitable en hôtellerie : pour limiter les remplacements “à risque”, vous pouvez exiger au CCTP des capteurs DALI‑2 certifiés et vérifier les références dans la base produits publique (DALI Alliance Product Database). La page DALI Alliance sur les capteurs précise aussi que les input devices (dont les capteurs) ont été ajoutés au programme DALI‑2 en mai 2019. Référence : DALI Sensors and other input devices.

Attention : DALI‑2 certifie un langage, pas votre “scénario hôtel”

Point de prudence essentiel : même avec des capteurs DALI‑2 certifiés, le comportement réel (temporisations, priorités, règles jour/nuit, modes ménage/DND, transitions) dépend de l’endroit où vous implémentez la logique : contrôleur DALI‑2, passerelle KNX↔DALI, superviseur/GTB ou contrôleur de chambre. Autrement dit, la certification est une base d’interopérabilité, mais elle ne remplace pas une recette fonctionnelle pensée pour l’hôtellerie.

Pour outiller la réception et éviter les litiges “interopérable sur le papier, irritant sur site”, vous pouvez compléter avec Réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité et éviter les incompatibilités.

Option B — Présence et logique côté KNX : ce que vous achetez en gouvernance et en évolutivité

KNX : interopérabilité multi‑marques et “preuve” via certification

La KNX Association met en avant un écosystème multi‑fabricants, des dispositifs certifiés compatibles inter‑marques et l’usage d’ETS pour concevoir, mettre en service et gérer des projets KNX. Référence : KNX Technology (KNX Association).

Pour l’exploitation, la promesse utile n’est pas “on a mis du KNX” ; c’est :

  • Produits certifiés (preuve multi‑marques),
  • Projet ETS et gouvernance (documentation, sauvegardes, conventions),
  • Capacité à faire évoluer des scénarios (sans “casser” des dépendances invisibles).

La page publique “Certified KNX Devices” présente les dispositifs certifiés comme compatibles multi‑marques et conçus pour fonctionner avec ETS (conception, mise en service, gestion). Référence : Certified KNX Devices.

Pour un rappel “socle” (utile en phase APS/PRO quand on doit expliquer le partage des rôles entre lots), voir aussi : KNX : le standard ouvert de la domotique et de l’immotique.

Le point de vigilance KNX en hôtel : l’outillage exploitation (ETS, DOE, procédures)

KNX peut rendre l’exploitation très robuste… si le projet est géré comme un actif : fichiers ETS à jour, stratégie de sauvegarde, règles de nommage, procédures de reprise, et droits d’accès remis à l’exploitant selon les modalités prévues. Sinon, le remplacement d’un capteur ou une retouche de logique devient vite “risquée” (peur de casser une adresse de groupe, une scène, un mode chambre).

Sur le livrable “exploitation”, vous pouvez aligner vos exigences avec DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?. Et pour cadrer le maintien dans le temps (au-delà de la livraison), voir : Maintenance KNX : comment garantir qu’une installation restera maintenable dans 10 ou 15 ans ?.

Trois architectures hôtelières fréquentes (et leurs impacts maintenance)

Architecture 1 — Zone/chambre “autonome” en DALI‑2

Principe : capteurs DALI‑2 + logique portée par un contrôleur DALI‑2 (local) ; KNX/GTB récupère des états, des commandes ou des modes, selon l’intégration.

Atouts exploitation : une partie des fonctions d’éclairage peut rester locale (moins dépendante d’une intégration transverse). Les capteurs peuvent être “standardisables” si vous imposez du DALI‑2 certifié et vérifiable.

Vigilances : attention à la dépendance au contrôleur (outil de mise en service, export des paramètres, reprise en main par un tiers). C’est souvent là que se joue la maintenabilité réelle, plus que sur le capteur lui‑même.

Architecture 2 — Logique KNX, DALI cantonné au pilotage des luminaires (passerelle KNX↔DALI)

Principe : capteurs et règles en KNX ; DALI sert d’interface fine vers les drivers/luminaires.

Atouts exploitation : cohérence “bâtiment” (éclairage + autres usages) et scénarios de chambre plus faciles à orchestrer (selon le périmètre retenu).

Vigilances : la passerelle KNX↔DALI devient un composant critique (paramétrage, robustesse, comportement en mode dégradé). La maintenance doit savoir diagnostiquer et le DALI et le KNX, ou au minimum isoler rapidement “où est la faute”.

Architecture 3 — Hybride : capteurs DALI‑2 “terrain”, arbitrage “hôtel” centralisé

Principe : DALI‑2 remonte des événements de présence ; KNX/GTB arbitre les modes (jour/nuit, DND, ménage, énergie) et renvoie des ordres.

Atouts exploitation : compromis fréquent en rénovation (on capitalise sur l’existant DALI, tout en ajoutant une logique hôtelière transverse).

Vigilances : principal risque : double logique contradictoire (temporisations actives des deux côtés, règles qui se “battent”). Ce cas est typiquement à traiter par une matrice claire “qui décide / qui exécute”.

Comparatif orienté maintenance : ce qui change vraiment

Critère d’exploitation Capteurs DALI‑2 (input devices) Présence/logique en KNX
Preuve d’interopérabilité à la réception Exiger « DALI‑2 certified » et vérifier la référence dans la base produits DALI Alliance ; certification avec processus de tests et vérification des résultats. Source Exiger des dispositifs certifiés ; la page KNX “Certified Devices” présente une compatibilité multi‑marques et un usage avec ETS. Source
Remplacement rapide d’un capteur (exploitation en cours) Plutôt favorable si le capteur est standardisé (certifié, référence stockée) et si la logique associée n’est pas “opaque”. À cadrer : procédure de remplacement et de re‑commissioning (qui fait quoi, avec quel outil, et comment prouver le retour à l’état nominal). Plutôt favorable si l’hôtel dispose du projet ETS à jour + conventions + procédure ; sinon le remplacement peut être freiné par la gouvernance (accès, sauvegardes, risque de non‑régression).
Diagnostic (où est la panne ? capteur, logique, passerelle, driver) Le bus DALI donne des mécanismes utiles, mais le diagnostic dépend beaucoup des outils/contrôleurs choisis. Recommandation : prévoir des tests de recette “capteur → événement → action” et des logs côté contrôleur/supervision. La logique peut être plus centralisée, mais l’exploitabilité dépend de la qualité du DOE et des outils (ETS et/ou supervision). L’architecture doit permettre d’isoler rapidement un défaut d’intégration KNX↔DALI si DALI est utilisé.
Évolutivité (extension par phases) Souvent très efficace pour une rénovation “éclairage par zones”, en gardant une cohérence DALI‑2. Pour une approche rénovation, voir Rénover un éclairage DALI en hôtel : migrer vers DALI‑2. Souvent très efficace quand on anticipe des scénarios transverses (modes chambre, intégrations). Le socle KNX reste pertinent si la gouvernance et les livrables sont cadrés.

Grille de décision (questions à trancher avant de figer un CCTP)

  • Qui transforme “présence/absence” en actions d’éclairage (contrôleur DALI‑2, logique KNX, passerelle, GTB) ?
  • Mode nuit : quelle règle évite un allumage brutal (niveaux doux, rampes, balisage, conditions) ?
  • Ménage / maintenance : comment forcer sans “oublier” le forçage (durée, retour automatique, indicateurs) ?
  • Mode dégradé : que se passe‑t‑il si la passerelle / la supervision n’est pas disponible ?
  • Remplacement : quelle stratégie de stock et de références “équivalentes” est réaliste pour l’exploitant ?
  • DOE : quels éléments rendent l’installation reprenable (listes de références certifiées, exports, sauvegardes, procédures) ?

Pour limiter les faux allumages/extinctions (sujet très visible côté client), vous pouvez aussi consulter Détecteurs de présence : comment éviter les allumages et extinctions intempestifs ? (les principes de placement et de temporisation restent utiles, même si un hôtel impose des cas d’usage spécifiques).

Et pour cadrer la validation avant généralisation (étage, aile, puis tout l’établissement), une démarche de zone pilote reste très efficace : Chambre témoin hôtel : comment valider le GRMS, le CVC et l’éclairage avant le déploiement ?.

Recommandations pragmatiques (sans dogme)

  • Si la priorité est le remplacement terrain et l’interopérabilité côté éclairage : une stratégie cohérente DALI‑2 (capteurs DALI‑2 certifiés + architecture de contrôle claire) peut simplifier le stock et les remplacements, à condition de cadrer la mise en service et la reprise.
  • Si la priorité est l’orchestration hôtelière multi‑lots : placer la logique côté KNX (ou un contrôleur “cœur” clairement identifié) peut faciliter les scénarios, à condition de verrouiller les livrables et la gouvernance (ETS/DOE/procédures).
  • Dans tous les cas : refusez l’ambiguïté “double logique”. Une seule couche doit arbitrer les priorités, et l’autre exécuter.

Ce que vous pouvez exiger à la réception (orienté exploitation)

  • Preuve de certification : références DALI‑2 certifiées vérifiables dans la base publique, et/ou dispositifs KNX certifiés (selon architecture).
  • Recette anti‑irritants : une matrice de tests en conditions réelles (jour/nuit, circulation, sanitaires, chambre, ménage) avec critères de validation fonctionnels.
  • DOE exploitable : liste des références, architecture “où vit la logique”, sauvegardes et exports nécessaires, procédure de remplacement d’un capteur et de retour à l’état nominal.

Sources et documentation (références primaires)

Besoin d’aide sur votre cas hôtel (neuf ou rénovation) ? Le plus efficace est de partir d’une zone type (chambre, couloir, sanitaire) et de formaliser : où vit la logique, quelles priorités, et quels tests de réception garantiront le confort et la maintenabilité.

17Sep

Éclairage “constant” en hôtel : comment le spécifier et le valider en réception sans variations désagréables (DALI‑2 et intégrations)

by Domocasa
Énergie et CVC Guides techniques Hôtellerie

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

En hôtellerie, un “maintien d’éclairement” (souvent appelé constant light control ou daylight compensation) est utile… à condition qu’il reste invisible pour le client. Un réglage trop réactif peut créer des micro-variations, un effet de “pompage” ou une reprise d’automatisme ressentie comme intrusive. À l’inverse, un réglage bien cadré améliore le confort en journée, notamment près des façades, sans dégrader l’expérience.

Ce guide propose une méthode orientée réception : quoi écrire dans la spécification (comportements attendus), quoi exiger comme livrables (paramètres et responsabilités), et comment valider sur site avec des tests simples mais sérieux, en DALI‑2 et en intégration (KNX/GTB).

Ce que “constant light” veut dire côté expérience client (et pourquoi c’est différent d’un objectif “énergie”)

En hôtel, on ne cherche pas un “lux constant” au sens mathématique. On cherche un résultat de confort :

  • Pas de variations perceptibles lors des changements lents de lumière du jour (nuages, déplacement du soleil, stores ajustés).
  • Pas d’oscillation (montée/descente répétitive) ni de “marches” visibles.
  • Priorité à l’intention utilisateur : si le client dimme ou lance une scène, l’automatisme ne doit pas “reprendre la main” de façon incompréhensible.

Conclusion pratique : une bonne spécification décrit des règles de comportement (bande de stabilité, vitesse de correction, priorités manuel/auto, conditions d’activation) et pas uniquement une consigne lumineuse.

DALI‑2 : ce qui est standardisé… et ce qui ne l’est pas (à ne pas confondre)

Certification DALI‑2 : une base utile, mais pas une garantie de confort “constant light”

La DALI Alliance (DiiA) présente DALI‑2 comme un périmètre structuré par un programme de certification, avec des Test Specifications dérivées de parties pertinentes d’IEC 62386 (ou de spécifications DiiA), une vérification par la DiiA, et une base publique permettant de vérifier le statut des produits. Source : DALI Alliance — DALI‑2.

Côté projet hôtel, cela se traduit par un réflexe simple : exiger des références certifiées et les vérifier, puis faire une recette chantier orientée usage (car la certification ne remplace pas un test de confort en situation).

Où se trouve “l’intelligence” du maintien d’éclairement ? Souvent dans le contrôleur applicatif (pas dans le driver)

La DALI Alliance décrit les application controllers comme le “cerveau” du système : ils utilisent des informations de diverses sources, prennent des décisions, et envoient les commandes au control gear. Source : DALI Alliance — Control devices.

Conséquence directe : deux installations annoncées “DALI‑2” peuvent avoir un confort constant light très différent, car l’algorithme et les paramètres dépendent du contrôleur (et, en intégration, parfois d’une passerelle ou d’une GTB).

Capteurs DALI‑2 (Part 304) : ce que la DALI Alliance met en avant

La DALI Alliance regroupe les capteurs et input devices dans les Parts 301 à 304, et décrit notamment la Part 304 (Light sensors) : mesure de l’illuminance, hystérésis programmable (pour limiter le trafic), événements périodiques optionnels. Source : DALI Alliance — Sensors and input devices.

Point important pour la réception : l’hystérésis et le mode de remontée (événementiel, périodique, polling) sont des leviers concrets pour éviter des corrections trop fréquentes… mais ce n’est pas “automatique” : cela dépend aussi du contrôleur et de sa logique.

Support des capteurs : tous les contrôleurs ne se comportent pas pareil

La DALI Alliance indique que tous les application controllers ne supportent pas forcément l’usage des input devices, et que certains exploitent des event messages tandis que d’autres utilisent du polling, notamment pour des mesures lentes comme le niveau lumineux. Source : DALI Alliance — Tech note “instance types”.

Pour un hôtel, c’est un point contractuel : vous ne “réceptionnez” pas un concept. Vous réceptionnez un comportement obtenu avec une combinaison précise : capteur + contrôleur (ou passerelle) + paramétrage.

Architectures typiques en hôtel : où se ferme la boucle constant light (à figer avant la recette)

En pratique, vous rencontrerez souvent ces familles d’architectures :

  • DALI‑2 local : capteurs DALI‑2 (ex. Part 304) + application controller DALI‑2 qui calcule et envoie les corrections aux drivers.
  • DALI‑2 avec supervision / GTB : la GTB impose des modes/scènes/horaires, mais la boucle constant light peut rester locale… ou être déplacée (à clarifier).
  • KNX ↔ DALI‑2 via passerelle : l’intégration KNX/DALI‑2 existe (exemple de passerelle cataloguée côté KNX). Source : knx.org — exemple de gateway KNX/DALI‑2. En revanche, les fonctions exactes (présence d’une régulation interne, paramètres accessibles, priorités, comportement en cas de commandes concurrentes) dépendent du modèle et de son application.

À écrire noir sur blanc dans la spécification : qui calcule la correction constant light ?

  • le contrôleur DALI‑2 ?
  • la passerelle KNX/DALI‑2 ?
  • une logique GTB/supervision ?

Tant que ce point n’est pas figé, les tests de réception resteront ambigus (et la responsabilité du confort aussi).

Comment spécifier un maintien d’éclairement “hôtel-compatible” (sans sur-promettre)

1) Délimiter où le constant light est souhaitable… et où il est risqué

Le maintien d’éclairement est généralement plus simple à justifier (et à stabiliser) dans des espaces en journée et où l’on attend une ambiance fonctionnelle :

  • lobby, accueil, circulations éclairées par la façade ;
  • salles de réunion, zones de travail back-of-house ;
  • restaurants en configuration “jour”.

Il est plus délicat dans les ambiances où l’on cherche une intention lumineuse “scène” :

  • chambre client (surtout soirée/nuit) ;
  • spa, ambiances “détente” ;
  • scènes “dîner”, “coucher”, etc.

Bon réflexe projet : en chambre, traiter le constant light comme une fonction conditionnelle (état “jour”, “ménage”, “lecture en journée”…) plutôt que comme un automatisme permanent.

2) Décrire le comportement attendu (les “règles”) plutôt qu’un setpoint isolé

Au lieu d’exiger uniquement “maintien d’éclairement”, décrivez des règles testables :

  • Bande de stabilité : accepter une zone de confort autour d’une référence (la largeur exacte est un choix de projet à valider en zone témoin). Une bande trop étroite pousse à la correction permanente.
  • Vitesse de correction : correction automatique progressive (fondu), sans marches visibles.
  • Fréquence de correction perceptible : éviter les micro-ajustements continus (critère à formaliser en réception par observation + mesures).
  • Priorités : manuel et scènes (client, ménage, nuit) priment selon une matrice de priorités écrite.
  • Conditions d’activation : quand le constant light est actif (modes/états), quand il est suspendu.
  • Garde-fous : limites mini/maxi, comportements en cas de capteur indisponible ou valeurs incohérentes.

3) Exiger la liste des paramètres réellement disponibles (contrôleur/passerelle), et pas une liste “supposée”

Sans présumer de fonctions universelles (elles varient selon contrôleur/passerelle), vous pouvez exiger que l’offre fournisse, pour la zone témoin, une fiche paramètres listant ce qui est réellement réglable, où cela se règle, et qui en est responsable. Typiquement :

  • référence/consigne de régulation par zone (si la boucle existe) ;
  • hystérésis / bande morte (côté capteur Part 304 et/ou côté contrôleur) ;
  • mécanisme de remontée (événementiel, périodique, polling) et sa cadence de lecture/rapport (si applicable) ;
  • temps de transition (fondu) pour les corrections automatiques ;
  • règles de priorité et temporisation de reprise après action manuelle ;
  • valeurs plancher/plafond imposées à la régulation.

Recette / réception : protocole de tests orienté confort (pas seulement “ça répond”)

La logique est la même que pour une chambre témoin : on valide l’expérience et les comportements avant de déployer. (Voir aussi : Chambre témoin hôtel : comment valider le GRMS, le CVC et l’éclairage avant le déploiement ?.)

Pré-recette documentaire (avant essais)

  • Schéma d’architecture : bus DALI, contrôleur applicatif, capteurs, éventuelle passerelle KNX/GTB.
  • Liste des références : drivers/luminaires, capteurs, contrôleur(s), passerelle(s), avec statut DALI‑2 certifié quand applicable (à vérifier dans la base publique DALI‑2). DALI Alliance — DALI‑2.
  • Responsabilités : qui calcule la correction, qui applique les priorités, où sont stockés les paramètres, qui a la main sur la mise en service.

Tests terrain : une grille simple, reproductible et documentée

Test Objectif Comment faire (principe) Limites / points de vigilance
Variation lente “jour” Vérifier l’absence de pompage lors des variations lentes de lumière du jour Mettre la zone en mode où le constant light est actif, puis faire varier lentement l’apport de jour (stores/voilage) et observer si des corrections deviennent perceptibles Le résultat dépend fortement de l’implantation capteur/luminaires ; documenter la configuration exacte du test
Seuil / hystérésis Éviter la correction “au moindre changement” Créer de petites perturbations (ombres partielles, store légèrement ajusté) et vérifier que le système ne “chasse” pas Si micro-variations : revoir hystérésis/bande morte et/ou stratégie de lecture (événement/périodique/polling) et/ou vitesse de correction
Interaction client Vérifier la priorité au manuel et aux scènes Tester dimming manuel, activation de scènes, changement de mode (jour/soir/nuit/ménage) et observer reprise de l’automatisme Ne pas tester “en laboratoire” : tester avec l’interface client réelle (commandes, scénario d’usage)
Implantation capteur Détecter boucles instables dues à reflets / “capteur qui voit le luminaire” Tester plusieurs positions de stores, vérifier l’influence de reflets (miroirs, surfaces brillantes) et la cohérence des corrections Une instabilité peut être un problème d’implantation/calibration plutôt qu’un problème protocolaire

Mesure et acceptation : garder une part “confort” mais la rendre traçable

La réception ne se limite pas à “c’est à peu près bon” :

  • Utilisez un luxmètre comme instrument de trace (sans prétendre à une métrologie de laboratoire) : même emplacement, mêmes conditions, relevés horodatés.
  • Tenez un journal d’observation : corrections visibles (oui/non), oscillation (oui/non), reprise intrusive après action manuelle (oui/non), etc.
  • Adossez l’acceptation à la spécification comportementale (bande de stabilité, vitesse de correction, priorités), définie et validée en zone témoin.

Ce qu’il faut explicitement ne pas promettre (pour éviter les litiges en réception)

  • “DALI‑2 garantit un constant light parfait” : non. DALI‑2 structure l’interopérabilité et la certification, mais l’algorithme et le paramétrage (côté application controller / intégration) restent déterminants. DALI Alliance — DALI‑2 et Control devices.
  • “Une passerelle KNX/DALI‑2 fera forcément X” : non. Une fiche catalogue atteste l’existence de l’intégration, pas les détails de comportement. Exemple knx.org — gateway KNX/DALI‑2.
  • “Le capteur suffit” : non. La DALI Alliance rappelle que les contrôleurs peuvent exploiter les capteurs de manière différente (événements, polling, périodicité), et tous ne supportent pas forcément les input devices. Tech note “instance types”.

Livrables recommandés pour une exploitation hôtelière maintenable

Au-delà de la réception, un constant light “confort” doit rester maintenable au jour 2 (remplacement d’un capteur, changement d’affectation, rénovation partielle). Demandez que le DOE inclue :

  • la fiche paramètres par zone (réglages, priorités, modes, et où ils sont configurés) ;
  • la description d’architecture (qui calcule la boucle, quelles dépendances en intégration) ;
  • les scénarios d’usage (jour/soir/nuit/ménage) et leur logique ;
  • une procédure de retour à un état de référence (réinitialisation de paramètres, restauration).

Sur la logique DOE/exploitation : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

Pour aller plus loin (guides Domocasa liés)

Sources et documentation (références techniques consultées)

Besoin d’un cadrage CCTP + protocole de recette sur une zone témoin (chambre, lobby, restaurant) avant déploiement ? Domocasa peut vous accompagner sur la définition des comportements attendus, la matrice de priorités et les tests d’acceptation.

Copyright © 2025 Domocasa. All rights reserved.