DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?

Un hôtel peut être livré avec des chambres intelligentes, des serrures électroniques, une supervision technique et un réseau performant… puis se retrouver démuni au premier incident si les équipes ne disposent ni des bonnes sauvegardes, ni des bons contacts, ni d’une procédure claire. Le DOE d’un hôtel connecté ne doit donc pas être vu comme une simple archive de fin de chantier. Avec le dispositif de maintenance, il organise le passage d’une installation technique à un service hôtelier exploitable, réparable et évolutif.

Photo by Valentin Lacoste on Unsplash

Synthèse décideur (à lire en 2 minutes)

  • Bonne pratique : ne livrez pas “un PDF” unique. Structurez la remise en 3 ensembles (DOE technique, guide d’exploitation métiers, plan de maintenance/continuité) avec droits d’accès distincts, à définir au projet.
  • Souvent utile : prévoir des livrables par système (GRMS/KNX, PMS, réseau/Wi‑Fi, serrures, vidéosurveillance, TV/téléphonie, GTB) + une matrice d’interfaces (événements, autorité de la donnée, logs, tests), formalisée au cahier des charges/contrat.
  • Sauvegardes : l’objectif opérationnel est une restauration testée et documentée (et pas seulement “des fichiers déposés”), selon les exigences retenues au projet.
  • Accès & secrets : remise via coffre à secrets / procédure nominative (pas dans le DOE diffusé), avec mécanisme d’urgence (“break-glass”) défini au projet.
  • Vidéosurveillance & données personnelles : prévoir un cadrage conformité (loi 09‑08) et un dossier d’exploitation ; la CNDP rappelle notamment information, sécurité, notification préalable selon le régime applicable et conservation limitée (voir sources citées).

Que remettre au propriétaire ? Que doit posséder l’exploitant ? Que conserver chez le mainteneur ? Et comment préparer les interventions sans perturber les clients ? Voici un guide pratique pour les hôtels, resorts et riads au Maroc.

Le DOE hôtelier ne se résume pas à des plans

Le dossier des ouvrages exécutés (DOE) décrit l’installation telle qu’elle a réellement été réalisée. Selon les marchés, on parle aussi de dossier de récolement ou de dossier “as-built” : l’objectif reste le même, à savoir documenter l’exécution réelle et les éléments nécessaires à l’exploitation.

Dans les marchés de travaux, la logique « dossier de récolement / DOE selon les prescriptions définies au marché » est une pratique contractuelle : le contenu exact dépend du cahier des charges et des clauses du projet. À titre d’exemple de formulation (dans un référentiel CCTG associé à un cadre contractuel spécifique, à ne pas interpréter comme une norme “automatiquement applicable” à tous les projets au Maroc), voir : Guide d’application du Fascicule 69 (mention « selon les prescriptions définies au marché »).

Mais dans un établissement connecté, connaître l’emplacement d’un équipement ne suffit pas : les systèmes communiquent, des services dépendent de serveurs ou de licences, et certaines actions doivent être coordonnées entre plusieurs prestataires.

Une documentation utile doit répondre à quatre questions : qu’avons-nous installé ? comment cela doit-il fonctionner ? comment le diagnostiquer ? comment rétablir le service après une panne ?

Notre guide sur le DOE domotique explique la remise des plans, fichiers ETS et configurations techniques. Ici, nous allons plus loin dans la passation entre le chantier et l’exploitation hôtelière : responsabilités, continuité de service, consignes aux équipes, accès de maintenance et suivi dans la durée.

Trois dossiers complémentaires à livrer, pas un seul fichier PDF

Pour éviter qu’une réceptionniste doive parcourir des schémas réseau ou qu’un prestataire extérieur accède à des secrets techniques, il est utile de séparer les documents selon leur public.

Tableau 1 — Trois ensembles documentaires recommandés (à définir au projet et au contrat).
Dossier Destinataires principaux Contenu attendu
DOE technique Propriétaire, responsable technique, mainteneurs habilités Plans tels que construits, inventaire, architectures, versions, configurations et sauvegardes
Guide d’exploitation Direction, réception, housekeeping, sécurité, maintenance interne Modes opératoires, anomalies fréquentes, gestes autorisés et circuits d’escalade
Plan de maintenance et de continuité Exploitant, prestataires, IT et responsables de contrats Responsabilités, contrôles périodiques, sauvegardes, procédures de reprise et conditions de support

Ces ensembles peuvent partager un référentiel, mais les droits d’accès doivent rester distincts. Les informations confidentielles — comptes administrateurs, clés de sécurité, secrets de connexion — ne doivent pas être placées dans un PDF général envoyé à tous les intervenants.

Où stocker quoi : propriétaire, exploitant, mainteneur

Au-delà du contenu, l’enjeu est de savoir qui détient l’information, où elle est stockée et comment elle est récupérable le jour où l’équipe change ou qu’un prestataire n’est plus disponible. Le tableau ci-dessous est une organisation possible, à adapter aux contrats et à la gouvernance interne.

Tableau 2 — Répartition possible des informations (exemple organisationnel, à adapter aux contrats et habilitations).
Type d’information Copie “référence” à conserver Accès opérationnel Notes de sécurité / continuité
Plans as-built, synoptiques, schémas d’interfaces Propriétaire (référentiel officiel) Exploitant + mainteneurs habilités Versionner et dater chaque mise à jour
Configurations exportables (switch/pare-feu/contrôleurs/NVR/passerelles) Propriétaire ou exploitant (coffre documentaire) Mainteneur du lot + IT hôtel Chiffrer au repos, tracer les exports/imports
Projets de programmation (ex. ETS/GRMS) et bibliothèques associées Propriétaire (pérennité / changement d’intégrateur) Intégrateur/mainteneur autorisé Clarifier les droits d’usage/transfert dans les contrats
Secrets, mots de passe, clés, certificats Exploitant ou propriétaire (coffre-fort à secrets) Accès nominatif, journalisé Remise hors PDF ; procédure d’urgence “break-glass”
Contrats, licences, abonnements (cloud/SaaS), garanties, contacts Exploitant (pilotage) + propriétaire (contrôle) Direction + IT Suivre dates d’expiration et dépendances
Procédures (incidents, exploitation, escalade) et comptes rendus Exploitant Équipes terrain + prestataires Conserver un historique et un statut des actions

Quels livrables faut-il demander pour chaque système ?

Le DOE est plus facile à contrôler lorsque chaque lot possède une liste de livrables et un responsable. Une solution « intégrée » ne fait pas disparaître les limites contractuelles entre fabricants, installateurs et exploitants.

Tableau 3 — Livrables typiques par système (à formaliser au cahier des charges/contrat, puis vérifiés en recette).
Système Documents et fichiers à recevoir Vérification utile
GRMS, KNX et commandes des chambres Schémas, repérages, scénarios et états, fichiers projets exportables, configurations des interfaces CVC et éclairage Correspondance avec les typologies de chambres, les adresses et les commandes réellement installées
PMS et passerelles hôtelières Liste des interfaces, événements échangés, versions, dépendances, interlocuteurs et conditions d’accès aux configurations Arrivée, départ, changement de chambre et reprise après indisponibilité d’une interface
Réseau, Wi-Fi et serveurs Plan des baies, schémas de topologie, inventaire, adressage utile, VLAN, sauvegardes des équipements et relevés de recette Identification rapide du switch ou du lien en défaut et restauration d’une configuration
Serrures et contrôle d’accès Inventaire des portes, matrice des profils, procédures de révocation, paramètres de gestion, modes secours et documentation fournisseur Perte de badge, départ du personnel, changement de chambre et coupure réseau
Vidéosurveillance et sûreté Implantations, inventaire des caméras/NVR, schémas, procédures d’accès aux images et maintenance Recherche d’incident autorisée, stockage et restitution selon les règles applicables
Téléphonie IP, TV et affichage Plan de numérotation, trunks et renvois prévus, configurations exportables, sources et distribution des contenus Appel réception–chambre, redémarrage TV et récupération de l’affichage après panne
GTB, énergie et gestion de l’eau Liste des points, alarmes, seuils, compteurs, dépendances et procédures de remise en service Identification d’une alarme et diagnostic d’un équipement ou d’une consommation anormale

Pour rendre ces livrables réellement exploitables, demandez aussi (quand pertinent et si contractuellement prévu) : versions firmware/logiciel, dépendances cloud/SaaS, liste des licences et dates d’expiration, pré-requis matériels (serveur, VM, passerelle), et conditions d’accès support (portail éditeur, contrat, contacts).

La sécurité incendie et les installations réglementées exigent leurs dossiers, essais et attestations propres suivant le cadre applicable, préparés et validés par les professionnels compétents. Le DOE de courant faible doit identifier leurs interfaces sans se substituer à ces documents ni à leurs responsabilités.

Interfaces PMS ↔ serrures ↔ GRMS/GTB : la matrice qui évite les “zones grises”

La plupart des incidents d’exploitation ne viennent pas d’un équipement isolé, mais d’une interface : événement PMS non reçu, passerelle indisponible, divergence entre “statut chambre” et “droits d’accès”, etc. En complément des DOE par lot, demandez une matrice d’interfaces (un document court, lisible, versionné) qui précise au minimum :

  • Qui échange quoi (événements, états, commandes) et à quel moment (check-in, check-out, changement de chambre, chambre “hors service”, etc.).
  • Quel système fait autorité pour chaque donnée (ex. occupation, statut chambre, droits d’accès, consignes CVC), et quelle est la règle en cas de conflit.
  • Paramètres d’intégration à conserver (endpoints, ports, certificats, comptes techniques, mappings) via une remise sécurisée (pas en clair dans un guide diffusé).
  • Où sont les logs/journaux utiles au diagnostic et qui peut y accéder.
  • Tests de recette associés (cas nominaux + cas dégradés) et leurs PV.

Notre article sur les échanges entre PMS, GRMS, GTB et serrures détaille cette logique d’“autorité de la donnée” et la nécessité de tester les scénarios opérationnels.

Format, propriétaire, mise à jour : mini-checklist par lot

Une cause fréquente d’échec à la livraison est l’ambiguïté : « document fourni » mais inexploitable, introuvable ou non maintenu. Sans imposer un outil particulier, une grille minimale aide à cadrer les attentes.

Tableau 4 — Mini-checklist de remise et de mise à jour (exigences à définir au marché).
Élément à exiger Format attendu Responsable (propriétaire du contenu) Mise à jour
Synoptique + architecture PDF + source éditable si prévue au contrat Entreprise du lot À chaque modification structurelle
Inventaire (matériel/logiciel) Tableur/export + PDF Exploitant (référentiel) avec contributions prestataires À chaque ajout/remplacement
Configuration exportable / sauvegarde Fichier natif + note de restauration Mainteneur du lot Après modification validée
Procédures d’exploitation et d’incident Fiches courtes par métier Exploitant (validation) + mainteneur (contenu technique) Après retour d’expérience / évolution
PV de recette + réserves PV daté, versionné Exploitant + MOE/MOA selon organisation À chaque phase de réception

Ces points sont à adapter au cahier des charges. L’important est d’avoir une traçabilité : qui met à jour, quoi, quand, et où se trouve la version de référence.

DOE réseau / Wi‑Fi : ce qu’il faut pouvoir diagnostiquer et restaurer

Dans un hôtel connecté, le réseau est le socle : une panne Wi‑Fi, un conflit d’adressage ou une segmentation inadaptée peut impacter les chambres (GRMS), les serrures, la TV, la téléphonie IP, la supervision ou le PMS. Plutôt que de viser une “liste universelle”, l’objectif est d’avoir des livrables qui permettent de localiser, isoler et restaurer rapidement.

  • Topologie (cœur/distribution/accès), plan des baies, repérage des liaisons critiques.
  • Plan d’adressage et segmentation (VLAN/SSID invités, staff, IoT/courant faible), règles de filtrage et dépendances (à définir avec l’IT/sécurité selon le contexte).
  • Accès d’administration : méthode d’accès (sur site / distant si autorisé), comptes, rôles, et procédure de remise/révocation via canal sécurisé.
  • Sauvegardes exportables (switches, contrôleurs Wi‑Fi, pare-feu) + procédure de restauration testable.
  • Recette Wi‑Fi : livrer les résultats et hypothèses (couverture, capacité, zones prioritaires, limites connues) et les paramètres associés (puissance/canaux si documentés au projet).

Les détails (journalisation, conservation, accès) relèvent généralement d’un arbitrage IT/sécurité et conformité. Dans le cadre de ce guide, l’enjeu est de documenter qui décide, où se trouvent les logs utiles au diagnostic, et comment l’équipe habilitée peut y accéder en cas d’incident.

Exiger des sauvegardes exploitables, pas seulement leur existence

Un fichier de configuration ancien, incomplet ou impossible à restaurer ne protège pas l’exploitation. Lors de la livraison, il convient d’identifier le système concerné, sa version, la date de l’export, les dépendances éventuelles et le responsable de sa conservation.

Pour les installations KNX, la documentation KNX relative à la sauvegarde de projet rappelle l’intérêt de sauvegarder après modification et de vérifier la réimportation. Le projet ETS remis doit correspondre au paramétrage final réellement déployé. Les modalités de remise des données et des clés de sécurité doivent être fixées contractuellement avec les personnes habilitées.

La logique s’étend aux switches, pare-feu, contrôleurs, passerelles et plateformes de supervision. Le NIST SP 1339 (OT Backup Quick Start Guide, publication finale juin 2026) indique, dans une logique “OT” (Operational Technology), l’intérêt d’intégrer les sauvegardes à la gestion des changements, de les produire régulièrement, de les tester et de les revoir lors d’exercices de reprise. C’est un guide technique international (pas un texte de droit marocain) : à vous de définir au projet quels périmètres hôtelier relèvent de cette logique (réseau, GTB, contrôle d’accès, etc.) et quels objectifs opérationnels vous retenez.

RPO/RTO : clarifier l’objectif de reprise, même simplement

Sans cadrage, une “sauvegarde” reste un mot. Deux notions utiles à formaliser (au moins à titre interne, puis à décliner dans les contrats si nécessaire) sont :

  • RPO (Recovery Point Objective) : la perte de données maximale acceptable (par exemple, perdre la configuration des changements de la journée vs de la semaine).
  • RTO (Recovery Time Objective) : le temps cible pour remettre le service en fonctionnement (par exemple, minutes/heures/jours).

Dans un hôtel, les cibles RPO/RTO varient selon le service : l’accès aux chambres ou le réseau cœur n’ont pas la même tolérance qu’un affichage non critique. Les valeurs doivent être définies avec l’exploitant et les prestataires, puis traduites en moyens (sauvegarde, matériel de rechange, astreinte, procédure, fenêtres d’intervention). L’important est d’aligner ces objectifs avec l’exploitation réelle (taux d’occupation, périodes sensibles, organisation des équipes) et les conditions contractuelles de support.

Accès et secrets : une méthode de remise opérationnelle

Dire « ne mettez pas les secrets dans un PDF » ne suffit pas : il faut une méthode de gestion des accès, compatible avec l’exploitation et auditable.

À titre de bonnes pratiques (à adapter à votre organisation et après validation IT/sécurité) :

  • Coffre-fort à secrets (numérique) avec accès nominatif, journalisation et droits par périmètre (réseau, GRMS, serrures, vidéosurveillance, etc.).
  • Remise initiale sous double contrôle : deux personnes habilitées valident la complétude (comptes, clés, licences) et l’accès effectif.
  • Accès d’urgence (“break-glass”) : compte/clé scellé(e) pour rétablir un service, avec procédure d’ouverture, traçabilité et rotation immédiate après usage.
  • Accès distant : préciser le mode autorisé (ex. VPN), l’authentification renforcée (ex. MFA) et les conditions d’activation/désactivation.
  • Rotation post-réception : après la remise et la stabilisation, changer les secrets “par défaut” et ceux connus d’un prestataire sortant, conformément aux contraintes des systèmes.

Ces principes doivent être alignés avec les contraintes des éditeurs/fabricants (comptes imposés, licences, accès cloud) et validés par les responsables sécurité et conformité de l’établissement.

Le propriétaire, l’exploitant et le mainteneur n’ont pas les mêmes besoins

Le propriétaire doit pouvoir préserver la valeur technique du bâtiment, comprendre les dépendances contractuelles et assurer la possibilité de faire intervenir un autre professionnel si nécessaire. L’exploitant doit pouvoir servir les clients et piloter ses équipes au quotidien. Le mainteneur a besoin de diagnostics, de configurations et d’autorisations adaptés au périmètre de son intervention.

Il faut donc nommer explicitement les responsables de chaque activité, au lieu de laisser la question ouverte jusqu’au premier incident.

Tableau 5 — Exemple de matrice responsabilités / preuves (à adapter à l’organisation de l’hôtel).
Action Responsable à désigner Preuve de bonne réalisation
Créer un droit d’accès temporaire Responsable d’exploitation ou sécurité habilité Procédure approuvée et essai pratique
Modifier un scénario GRMS Intégrateur autorisé, avec validation des changements Compte rendu, nouvelle sauvegarde et tests
Traiter une coupure d’un switch IT ou prestataire réseau désigné Contact d’escalade, plan d’intervention et restitution
Gérer une mise à jour logicielle Mainteneur du système concerné, sous contrôle de l’exploitant Étude d’impact, fenêtre d’intervention, sauvegarde, recette
Administrer les droits des prestataires Propriétaire du service ou administrateur habilité Accès limités, datés et révoqués en fin de mission

Cette matrice n’est qu’un exemple. Les rôles réels dépendent de l’organisation de l’hôtel et de ses contrats. Il faut notamment définir qui décide, qui réalise, qui vérifie et qui est informé lors d’une modification susceptible d’affecter les chambres occupées.

Transformer le DOE en procédures simples pour les équipes de terrain

Une équipe de réception ne devrait pas avoir à découvrir l’architecture PMS–serrures pendant qu’un client attend devant sa chambre. De même, le housekeeping ne doit pas improviser lorsqu’un scénario de chambre ne s’active pas. Le guide d’exploitation doit donc être organisé par symptômes et par métier, non uniquement par nom de matériel.

Chaque fiche courte peut suivre cinq rubriques : ce que l’équipe observe, ce qu’elle peut vérifier sans risque, ce qu’elle ne doit pas modifier, qui contacter et comment confirmer le retour à la normale.

Exemple (illustratif) : si une clé mobile ne fonctionne plus, la réception vérifie d’abord les informations autorisées liées au séjour et suit la procédure de support de la solution. En cas de doute, elle utilise une méthode de secours approuvée. Elle ne réinitialise pas une passerelle, ne diffuse pas un compte maître et ne contourne pas les règles d’identification. Si plusieurs chambres sont touchées, l’anomalie est escaladée selon la procédure de l’hôtel.

Pour préparer ces gestes avant l’accueil des premiers clients, notre checklist technique de pré-ouverture d’un hôtel présente la logique de recette des services.

Organiser la maintenance à trois niveaux

Un plan de maintenance n’exige pas nécessairement une présence permanente d’un spécialiste de chaque marque, mais il doit rendre lisible le chemin de résolution.

  • Niveau 1 – équipe de l’hôtel : constater, vérifier les fonctions accessibles, documenter l’anomalie, appliquer la consigne validée et contacter le bon interlocuteur.
  • Niveau 2 – intégrateur ou mainteneur : diagnostiquer les équipements et interfaces de son périmètre, intervenir à distance ou sur site dans les conditions autorisées, restaurer le service et mettre à jour la documentation.
  • Niveau 3 – fabricant, éditeur ou opérateur : traiter les incidents nécessitant une expertise produit, une correction logicielle, une licence, un échange matériel ou une intervention opérateur.

Les plages de disponibilité, les délais de prise en charge, les délais d’intervention et les éventuels engagements de rétablissement doivent être définis dans le contrat ; ils ne peuvent pas être déduits du seul mot « maintenance ». Distinguez bien une demande de support, un incident bloquant l’accès à des chambres, une dégradation du Wi-Fi et une simple modification de confort.

Les interventions programmées se préparent avec l’exploitant : période de faible occupation lorsque c’est possible, sauvegarde préalable, information des équipes concernées et vérification après changement. L’objectif n’est pas d’éviter toute maintenance, mais d’éviter qu’elle crée une nouvelle panne visible par les clients.

Hiérarchiser les incidents selon leurs conséquences sur le service

Un voyant rouge sur une passerelle n’a pas le même impact qu’une panne générale des serrures, même si les deux produisent une alerte. Pour classer les incidents, l’établissement gagne à regarder les effets opérationnels réels : sécurité des personnes, accès aux chambres, continuité d’accueil, impact sur les zones occupées, nombre d’utilisateurs touchés et existence d’une solution de secours.

On peut distinguer, à titre d’organisation interne, les situations critiques, les dégradations majeures et les défauts mineurs. La qualification se fait selon le projet et les obligations applicables ; la sécurité des personnes et les dispositifs réglementés priment toujours sur la commodité ou l’optimisation énergétique.

Le compte rendu d’incident doit inclure au minimum la zone affectée, l’heure du signalement, les premiers symptômes, les actions tentées, le prestataire intervenu et les éléments permettant de confirmer le retour au service normal. Cet historique facilite ensuite la maintenance préventive.

Préparer la reprise après panne ou changement de prestataire

Imaginons un contrôleur central défaillant un soir où l’hôtel est presque complet. Les équipes doivent savoir quelles fonctions demeurent locales, quels accès de secours sont prévus et quel interlocuteur peut restaurer le service. Le mainteneur, de son côté, doit retrouver la configuration compatible, la version logicielle, le schéma de réseau et le statut des droits sans deviner les paramètres.

Ce scénario se prépare pendant la recette. Il suppose de tester les modes dégradés compatibles avec l’architecture et de définir les dépendances entre PMS, GRMS, contrôle d’accès, réseau et alimentation.

La continuité de service inclut aussi la possibilité d’un changement d’intégrateur. Les licences, comptes, contrats de support, outils de programmation, fichiers de projets et droits d’utilisation doivent être clarifiés à la remise. Une liste de mots de passe ne remplace ni les droits contractuels, ni la formation nécessaire pour utiliser un logiciel propriétaire.

Construire un registre technique qui reste à jour

Un hôtel évolue : chambres reconfigurées, nouveaux points Wi-Fi, serrures remplacées, passerelles mises à jour, scénarios revus ou zones transformées en salles de réunion. Le DOE doit suivre ces changements si l’on veut qu’il reste exploitable.

Le guide australien Foundations for OT cybersecurity: Asset inventory guidance for owners and operators (publié et “last reviewed” le 14 août 2025) met en avant, pour des environnements OT, des actions clés telles que : inventorier les actifs, documenter les dépendances réseau, classifier les actifs, et stocker de manière sécurisée des informations complémentaires (dont des manuels fournisseurs et des dossiers de maintenance à jour).

Sans préjuger de l’applicabilité exacte de l’OT au périmètre hôtelier, l’idée opérationnelle est utile : un inventaire efficace relie chaque équipement à son emplacement, sa fonction, sa référence, sa version, son responsable et sa criticité.

Après une intervention significative, le mainteneur doit indiquer ce qui a changé, sur quelles zones, avec quelle version de configuration et quels essais de validation. Un historique de versions évite les fichiers nommés simplement « sauvegarde finale » ou « final_v2_definitif », devenus impossibles à départager plusieurs années après la livraison.

Ce registre peut prendre la forme d’un outil de GMAO ou d’un autre système documentaire maîtrisé. Le plus important est qu’il existe un référentiel officiel, accessible aux personnes habilitées et réellement mis à jour.

Spécificités d’exploitation au Maroc (points d’attention)

Les principes ci-dessus restent valables, mais certains points reviennent fréquemment dans les projets hôteliers au Maroc. Ils ne remplacent pas une analyse contractuelle et réglementaire locale, à valider avec vos conseils (juridique, conformité, sécurité) et vos assureurs si nécessaire.

  • Réception et “as-built” multi-lots : sur site, le GRMS, le réseau, la TV, la sûreté et la GTB peuvent relever de prestataires différents. Prévoyez une matrice d’interfaces (qui échange quoi, par quel protocole, où sont les journaux, qui supporte quoi) en plus des DOE par lot.
  • Support et disponibilité des compétences : certaines marques/éditeurs ont un support régional indirect (revendeurs, intégrateurs). Formalisez les canaux d’escalade, l’astreinte, et les conditions d’intervention sur site (délais, accès, pièces) dans les contrats.
  • Langues et rotation des équipes : prévoyez des procédures terrain courtes, compréhensibles et testées en conditions réelles (réception, sécurité, housekeeping). Le DOE technique peut rester plus “ingénierie”, mais le guide d’exploitation doit être orienté métiers.
  • Données personnelles (Wi‑Fi, contrôle d’accès, vidéosurveillance) : au Maroc, le cadre général de protection des données personnelles relève notamment de la loi 09‑08 (définition et principes généraux : finalité, proportionnalité, durée adéquate). En pratique, la gestion des accès, des journaux, de la conservation et de la restitution doit être définie avec un responsable conformité désigné et instruite selon le régime applicable, en s’appuyant sur les ressources de la CNDP (ex. page Notifier un traitement).
  • Dépendances Internet et cloud : pour les services qui reposent sur des plateformes distantes (clés mobiles, supervision cloud, analytics), documentez les modes dégradés : que se passe-t-il en cas de coupure Internet ? Quelle procédure de secours est autorisée et testée ?

Vidéosurveillance : trois points à cadrer (CNDP / loi 09‑08)

La vidéosurveillance, lorsqu’elle peut permettre d’identifier des personnes, constitue un traitement de données personnelles. La CNDP rappelle que ces images sont des données personnelles et que leur traitement s’inscrit dans le cadre de la loi 09‑08 (principes généraux) et des conditions précisées dans ses supports d’information (source CNDP : Fiche « La vidéosurveillance »).

Important : selon la finalité, le périmètre et les caractéristiques du dispositif, le régime applicable (déclaration, autorisation, dispense/exception) et les modalités pratiques peuvent varier. Il est donc recommandé de vérifier le cas d’usage de l’établissement via les ressources de la CNDP (par ex. CNDP — Notifier un traitement), en plus de la fiche d’information.

  • Notification préalable et démarche CNDP : la fiche CNDP mentionne une notification/déclaration préalable pour certains dispositifs de vidéosurveillance (source : CNDP — Fiche “La vidéosurveillance”).
  • Information des personnes : la CNDP évoque l’information via affichage/pictogramme et des mentions associées (source : fiche CNDP).
  • Durée de conservation : la CNDP indique que « la durée de conservation des images ne doit pas dépasser trois mois » (source : fiche CNDP). Les durées et modalités concrètes doivent être alignées sur la finalité du dispositif et le cadre applicable au site.

Dans le DOE/plan de maintenance, l’enjeu pratique est d’identifier : où sont stockées les images, qui a le droit d’accès, comment sont gérés les comptes, et comment les extractions (si autorisées) sont tracées et sécurisées—sans transformer un guide technique en analyse juridique exhaustive.

Checklist de réception : 15 points à contrôler

  1. Un inventaire des systèmes et équipements réellement installés est disponible.
  2. Les schémas de réseau, de câblage et d’interfaces sont conformes à l’exécution finale.
  3. Les lots GRMS, contrôle d’accès, téléphonie, TV, sûreté et supervision sont identifiés.
  4. Les typologies de chambres et scénarios d’exploitation sont documentés.
  5. Les interfaces PMS et leurs dépendances ont été décrites et testées.
  6. Les projets, configurations et sauvegardes exploitables ont été remis suivant les droits convenus.
  7. Au moins un contrôle de restauration ou d’importation adapté a été réalisé et consigné.
  8. Les comptes, secrets et clés sont remis par une procédure sécurisée et distincte.
  9. Les documents réglementaires propres aux systèmes concernés sont fournis par les intervenants compétents.
  10. La matrice des responsabilités de l’exploitant et des prestataires est validée.
  11. Les procédures de panne, de secours et d’escalade sont accessibles aux équipes concernées.
  12. Les contacts, contrats, garanties et modalités de support sont identifiés.
  13. Les équipes opérationnelles ont reçu une formation correspondant à leurs tâches.
  14. Les tests de réception et réserves éventuelles sont consignés avec leur statut.
  15. La méthode de mise à jour du dossier après modification est définie.

Cette checklist constitue une base de discussion contractuelle, et non une liste légale universelle. Les livrables exigibles dépendent du cahier des charges, du marché, des équipements et du cadre réglementaire applicable au site.

Questions fréquentes

Un DOE complet garantit-il qu’un hôtel n’aura jamais de panne ?

Non. Il rend simplement les incidents plus compréhensibles et les interventions plus maîtrisables. La continuité dépend aussi de l’architecture, de la maintenance, de la formation et des dispositifs de secours.

Le client doit-il recevoir le fichier ETS du système KNX ?

Il est fortement recommandé de prévoir contractuellement la remise du projet ETS correspondant à l’installation finale, avec les éléments nécessaires à sa reprise par un intervenant autorisé. La capacité de programmer dépend aussi des outils, licences et droits requis.

La réception et le housekeeping doivent-ils accéder à toutes les configurations ?

Non. Ils doivent disposer des commandes et procédures nécessaires à leur métier. Les outils et identifiants d’administration sont réservés aux personnes habilitées.

Qui met à jour le DOE après une intervention ?

Le contrat de maintenance et la procédure de gestion des changements doivent désigner le responsable. L’essentiel est que chaque modification importante laisse une trace et une configuration de référence validée.

Faire de la livraison le début d’une exploitation durable

La qualité d’un hôtel connecté ne se juge pas seulement à la première visite de chambre témoin. Elle se mesure aussi un an plus tard, lorsque les équipes savent réagir à un incident, qu’un nouvel intervenant retrouve les informations utiles et que les automatismes continuent d’évoluer sans perte de maîtrise.

En combinant un DOE technique précis, un guide d’exploitation accessible et un dispositif de maintenance défini, propriétaire et exploitant protègent la qualité de service comme la pérennité des investissements.

Note : si vous souhaitez cadrer la remise documentaire, la recette et l’organisation de maintenance avec un intégrateur, Domocasa intervient sur la conception, l’intégration et le suivi des systèmes courant faible des établissements hôteliers, en coordination avec les intervenants de chaque lot.

Préparer le DOE et la maintenance de votre hôtel avec Domocasa