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)
- ISO — ISO 52120‑1:2021 (fiche officielle et abstract)
- Siemens — document de synthèse EN ISO 52120‑1 (classes et exemples de fonctions)
- BUILD UP — présentation des guidelines eu.bac (mention du rôle de EN ISO 52120‑1)
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.
