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

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

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

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

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

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

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

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

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

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

Le piège classique consiste à confondre :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Objet 4 — L’équipement (Asset)

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

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

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

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

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

Convention simple : deux champs complémentaires

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

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

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

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

Contenu minimal de la table maître

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

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

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

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

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

Ne jamais réutiliser un identifiant stable

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

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

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

Ne pas confondre identité fonctionnelle et repérage IP

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

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

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

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

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

Process de changement : la “fiche de changement”

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

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

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

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

Renumérotation à périmètre constant

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

Fusion (deux chambres deviennent une suite vendable)

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

Découpage (une suite devient deux chambres)

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

Changement d’exploitant ou migration PMS

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

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

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

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

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

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

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

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

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

Checklist express (à utiliser en réunion projet)

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

Sources et documentation (sélection)

• Stayntouch — Direct Key Integrations (room mapping)
• Cloudbeds Developers — Access Management & Door Locks (Mapping Rooms / Doorlock ID)
• Cloudbeds Changelog — Room mapping support (Doorlock IDs ↔ rooms)
• Salto Support — PMS authorizations (authorization number)
• Dynalite Multiroom — Integration (room mapping table)
• Lutron — Hotel Integration Appliance (manuel)
• AHLA/HTNG — Event Notification Specification (v3.0)

Besoin d’un cadrage rapide sur votre projet ?

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

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