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).
