Illustration générée par IA — visuel conceptuel.
Dans un hôtel, la vraie question n’est pas uniquement « KNX ou DALI ? ». C’est surtout : où place-t-on l’intelligence d’éclairage (scènes, horaires, modes ménage, dérogations), qui en porte la responsabilité (lot éclairage, lot GTB/automatisme, IT, exploitant), et comment cela se maintient au jour 2 (remplacements, extensions, diagnostic, migrations).
Ce guide compare trois architectures réalistes — KNX direct, DALI‑2 local, DALI‑2 relié à la GTB — avec un objectif clair : réduire le risque opérationnel (pannes, dépendances, responsabilités floues) sans sacrifier le confort client.
Ce que DALI‑2 standardise réellement (et pourquoi c’est important en exploitation)
Pour prendre une décision d’architecture, il faut clarifier ce que recouvre « DALI‑2 » côté exploitation.
DALI‑2 s’appuie sur un programme de certification (interopérabilité)
La DALI Alliance (DiiA) présente DALI‑2 comme une évolution structurée autour d’un programme de certification, avec des spécifications de tests dérivées de parties pertinentes de la norme IEC 62386 (et/ou de spécifications DiiA), et une logique de vérification dans le processus de certification. Pour une approche projet, l’idée centrale est simple : la maintenabilité multi‑marques ne se décrète pas, elle se contractualise et se vérifie.
La preuve opérationnelle passe par la base produits publique
Point très concret pour les CCTP et la réception : la DALI Alliance met à disposition une base produits publique pour identifier les références annoncées comme certifiées DALI‑2. En pratique, c’est un outil utile pour limiter les ambiguïtés « DALI compatible » / « DALI‑2 certifié » au moment des achats, des substitutions et des remplacements.
Attention au périmètre « certifiable » selon les parties
La DALI Alliance publie également un statut de certification indiquant que la certification DALI‑2 s’appuie sur des tests maintenus par la DiiA, dérivés de parties IEC 62386 et/ou de spécifications DiiA, et que la disponibilité des parties peut évoluer. Conséquence projet : quand vous spécifiez « DALI‑2 », évitez les formulations vagues et listez les familles d’équipements concernées (drivers, contrôleurs, capteurs/entrées, alimentations, passerelles si elles sont dans le périmètre du lot éclairage), puis exigez des preuves adaptées à chaque famille.
Les trois architectures d’éclairage les plus courantes en hôtellerie
Option A — « KNX direct » : l’intelligence d’éclairage portée par KNX
Principe : la logique d’éclairage (scènes, commandes, horaires, modes) est gérée dans l’écosystème KNX. Selon le design, l’éclairage peut être piloté par des actionneurs KNX (commutation/variation) ou via des interfaces KNX vers une couche « lighting ».
Ce que vous gagnez
- Unification des usages côté chambre (éclairage, stores, états hôteliers, scénarios transverses), avec une logique cohérente si le projet est déjà fortement orienté KNX.
- Un outillage d’intégration centralisé pour une grande partie des fonctions (au prix d’une discipline de documentation, sauvegardes et versioning).
Points de vigilance « jour 2 »
- Dépendance forte au projet et à sa gouvernance : maintenabilité (accès, sauvegardes, cohérence des noms, gestion des modifications) devient un enjeu majeur.
- Cybersécurité dès qu’il y a interconnexion IP : si des segments KNX sont exposés à un réseau IP externe (accès distant, backbone mutualisé, interconnexion avec la GTB, etc.), la KNX Association distingue KNX IP Secure et KNX Data Secure et documente le commissioning sécurisé via ETS. Ce sujet relève moins du « protocole » que de l’architecture réseau et des règles d’accès.
Quand c’est pertinent : établissements où l’exploitation est prête à assumer une gouvernance KNX solide (documentation, sauvegardes, accès, contrat de support), et où l’intégrateur a une méthode robuste de transfert « jour 2 ».
Option B — « DALI‑2 local » : l’intelligence au niveau éclairage (chambre, zone, étage)
Principe : l’éclairage fonctionne de manière autonome à l’échelle locale via des contrôleurs DALI‑2 (et des équipements DALI‑2 adaptés). La chambre (ou la zone) doit rester exploitable même si la GTB ou certaines couches IP sont indisponibles.
Ce que vous gagnez
- Résilience fonctionnelle : un incident GTB, une indisponibilité réseau ou une maintenance serveur ne doit pas « éteindre l’expérience client » si la logique essentielle est locale.
- Une chaîne de responsabilité plus lisible côté lot éclairage : on pilote d’abord l’éclairage par l’éclairage, avec un périmètre de mise en service et de diagnostic souvent plus simple à organiser.
Points de vigilance
- Ne pas confondre “DALI” et “DALI‑2” dans les marchés : l’intérêt opérationnel (interopérabilité revendiquée) implique de spécifier et vérifier « DALI‑2 certifié » et pas seulement « DALI ».
- Documenter la mise en service : adressage, groupes, scènes, remplacements attendus, et procédure de rétablissement après remplacement (qui fait quoi, avec quel outil, sur quel périmètre).
Quand c’est pertinent : hôtels qui veulent limiter l’effet de bord d’une GTB sur le confort, tout en gardant une approche “terrain” claire et maintenable.
Option C — « DALI‑2 + GTB » : DALI‑2 terrain + supervision/coordination GTB
Principe : DALI‑2 reste le bus « terrain » (drivers, capteurs, contrôleurs), et la GTB (ou un GRMS/plateforme d’exploitation) se connecte via une passerelle/serveur d’intégration pour la supervision, des modes globaux, des alarmes et parfois des tableaux de bord exploitation.
Ce que vous gagnez
- Une séparation utile entre “fonctionnement local” et “fonctions de supervision” : l’éclairage reste opérationnel localement, tandis que la GTB apporte visibilité et coordination.
- Un levier exploitation multi‑bâtiments : supervision, homogénéisation des alarmes, consolidation, et stratégies de maintenance si l’organisation le justifie.
Le vrai point de risque : la passerelle et la frontière de responsabilité
La passerelle n’est pas un détail « technique » : elle fixe la frontière contractuelle et donc votre capacité à diagnostiquer sans renvoi de responsabilité. En cas d’incident (scènes inactives, commandes inopérantes, retours incohérents), l’exploitation doit pouvoir isoler rapidement si la cause est : terrain DALI, contrôleur local, passerelle, GTB, réseau IP, règles d’automatisation, ou droits utilisateurs.
Quand c’est pertinent : projets où la direction technique veut une supervision centralisée (KPI, alarmes, exploitation multi‑sites) sans rendre la chambre dépendante d’un serveur ou d’un réseau.
Comment choisir sans complexifier : raisonner “exploitation” avant “protocole”
Au lieu d’empiler des arguments techniques, partez de quelques décisions d’exploitation. Ce sont elles qui déterminent ensuite l’architecture.
Question 1 — Que doit rester fonctionnel en cas de panne GTB ou réseau ?
- Si l’objectif est « la chambre doit rester utilisable (boutons, scènes, logique essentielle) même en panne GTB/IP », privilégiez une logique locale (DALI‑2 local, ou DALI‑2 + GTB avec autonomie clairement définie).
- Si vous acceptez qu’une couche centrale soit critique, l’approche « KNX direct » peut convenir, à condition d’anticiper gouvernance, continuité et support.
Question 2 — Qui maintient quoi au jour 2 ? (RACI par couches)
Les projets hôteliers souffrent rarement d’un “mauvais protocole” ; ils souffrent surtout d’un RACI implicite. Une structure simple (à adapter à votre organisation) consiste à distinguer :
- Lot éclairage : conformité des équipements, mise en service terrain, scènes locales, documentation et procédures de remplacement.
- Lot GTB/GRMS : supervision, historisation, synoptiques, alarmes, gestion des droits, exploitation à distance.
- Interface (passerelle/serveur d’intégration) : fourniture, versions logicielles, sauvegarde/restauration, mapping (points, libellés, états), tests d’intégration et diagnostic.
- IT / réseau : segmentation, règles firewall, accès distants, supervision réseau, politiques de mots de passe et comptes.
À l’écrit, ce découpage est souvent plus protecteur qu’un long comparatif “protocolaire”.
Question 3 — Comment allez-vous prouver l’interopérabilité en réception ?
Si votre promesse projet est « remplaçable et multi‑marques », la réception ne peut pas se limiter à “ça s’allume”. Il faut des preuves adaptées à l’objectif. Une approche pragmatique côté DALI‑2 consiste à :
- Spécifier “DALI‑2 certifié” (et pas seulement “compatible”).
- Vérifier les références via la base produits publique de la DALI Alliance.
- Tester des scénarios d’exploitation (modes chambre, ménage, DND/MUR si applicable, comportements en mode dégradé), idéalement en zone témoin.
Pour aller plus loin sur la méthode de tests terrain, voir notre guide : Réception d’un éclairage DALI‑2 en hôtel : comment vérifier l’interopérabilité.
Recommandation de projet (à adapter) pour limiter les surprises “jour 2”
Chaque hôtel a ses contraintes, mais si votre priorité est d’éviter les dépendances cachées tout en gardant une supervision exploitable, une approche souvent saine consiste à viser :
- DALI‑2 local pour la logique essentielle d’éclairage (fonctionnement autonome par chambre/zone/étage),
- + un raccordement à la GTB pour la supervision, les alarmes et certains modes globaux,
- avec une frontière claire entre ce qui est indispensable au confort client (local) et ce qui relève de l’optimisation/reporting (central).
Cette recommandation n’est pas une règle universelle : elle doit être confirmée par vos contraintes de lotissement, votre organisation maintenance, et votre stratégie de support (interne/contrat).
Ce qu’il faut “mettre noir sur blanc” dans le CCTP / marché
Exiger et prouver « DALI‑2 certifié » (si DALI‑2 est retenu)
- Exigence : préciser les familles d’équipements soumises à l’exigence DALI‑2 (drivers, contrôleurs, capteurs/entrées, alimentations, etc.) selon votre architecture.
- Preuve attendue : validation des références via les ressources publiques de la DALI Alliance.
- Substitutions : exiger que toute substitution conserve le même niveau de revendication (certification) et qu’elle soit testée en zone témoin avant déploiement.
Définir l’état minimal en mode dégradé
Écrivez explicitement ce que l’hôtel considère comme « service minimum » :
- Que doit-il se passer si la GTB est indisponible ?
- Que doit-il se passer si la passerelle d’intégration est indisponible ?
- Que doit-il se passer si la supervision est coupée (maintenance serveur) ?
Ce point, très “exploitation”, évite une architecture sur‑optimisée mais fragile.
Verrouiller les livrables “jour 2” (DOE d’exploitation, pas seulement plans)
Quel que soit le choix KNX/DALI/GTB, la maintenabilité dépend des livrables concrets : nomenclature des zones, logique des scènes, sauvegardes, versions, procédures de remplacement, et méthode de diagnostic. Sur ce sujet, voir : DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?
Traiter cybersécurité et réseau comme une contrainte d’architecture
Dès qu’une architecture implique des échanges IP (GTB, supervision, accès distant, interconnexions), la segmentation réseau, les droits et la traçabilité deviennent un sujet projet à part entière. Pour cadrer ces dépendances, vous pouvez compléter avec :
- Architecture réseau IP d’un hôtel
- Cybersécurité d’un hôtel connecté : protéger GRMS, PMS, GTB et réseau
Conclusion
Décider entre KNX direct, DALI‑2 local ou DALI‑2 relié à la GTB n’est pas un débat de protocole : c’est une décision d’architecture d’exploitation. La meilleure option est celle qui rend explicites :
- où vit la logique indispensable au confort client,
- comment vous prouvez l’interopérabilité à la réception,
- comment vous remplacez et étendez au jour 2,
- et comment vous répartissez les responsabilités entre lots.
Si vous souhaitez cadrer cette décision dès la phase conception (schémas d’architecture, RACI, exigences de réception et livrables), l’équipe Domocasa peut vous accompagner de manière neutre, orientée exploitation.
