Pourquoi les équipements d’un hôtel ne se parlent pas à la livraison

La scène est classique. L’hôtel est livré, les chambres sont superbes, chaque équipement a été choisi avec soin. Le thermostat dessiné par l’architecte est magnifique, la climatisation est un modèle haut de gamme, l’éclairage est parfaitement dimensionné. Et pourtant, rien ne fonctionne ensemble.

Le thermostat ne pilote pas la climatisation. La clim continue de souffler quand la fenêtre est ouverte. Le bouton « Tout éteindre » près de la porte laisse les stores ouverts et la salle de bain allumée. Le personnel apprend à contourner les défauts, et le client, lui, découvre une chambre qui ne réagit pas comme il s’y attend.

Ce n’est pas un problème de qualité des équipements. C’est un problème d’interopérabilité, et il se règle bien avant le chantier.

Pourquoi ça arrive

Chaque équipement parle sa propre langue

Dans une chambre d’hôtel moderne, on trouve facilement cinq ou six familles d’équipements, et autant de protocoles de communication :

• l’éclairage, souvent en DALI ou en variation classique ;
• la climatisation, avec le protocole propre à son fabricant, parfois accessible en Modbus ou BACnet via une passerelle ;
• les commandes murales et les capteurs, fréquemment en KNX ;
• le contrôle d’accès et les serrures, sur leur propre système ;
• le multimédia, la télévision, parfois une tablette de services ;
• la GTB de l’hôtel, qui supervise l’ensemble.

Chacun de ces systèmes fonctionne très bien seul. Mais pour qu’une information circule de l’un à l’autre (« la fenêtre est ouverte », « le client vient de sortir », « la chambre est libérée »), il faut un traducteur. Et ce traducteur, personne ne l’a prévu.

Les lots sont conçus séparément

Sur un projet hôtelier, le lot CVC, le lot électricité, le lot contrôle d’accès et le lot multimédia sont souvent étudiés, consultés et attribués séparément. Chaque entreprise livre un système conforme à son cahier des charges. Personne n’a pour mission de faire fonctionner l’ensemble.

Résultat : les échanges entre systèmes sont découverts à la mise en service, quand il est trop tard pour les prévoir proprement.

Le choix esthétique passe avant le choix technique

L’architecte d’intérieur choisit un thermostat pour son design, ce qui est parfaitement légitime. Mais si personne ne vérifie qu’il sait communiquer avec la climatisation retenue par le bureau d’études fluides, le problème est créé sur le papier, des mois avant le chantier.

Ce que ça coûte

Un défaut d’interopérabilité ne se voit pas dans le budget de construction. Il se paie ensuite, pendant des années :

• en énergie : une climatisation qui ne sait pas que la chambre est vide, ou que la fenêtre est ouverte, tourne pour rien ;
• en exploitation : le personnel multiplie les interventions manuelles, les réglages chambre par chambre, les rondes de vérification ;
• en expérience client : des commandes qui ne font pas ce qu’elles annoncent, une chambre trop froide à l’arrivée, une application qui ne pilote que la moitié de la chambre ;
• en conformité : le décret BACS exige désormais explicitement l’interopérabilité des systèmes dans les bâtiments tertiaires concernés.

Et le rattrapage coûte cher. Ajouter des passerelles après coup, reprendre des câblages, reprogrammer des équipements installés : tout cela se fait chambre par chambre, souvent dans un hôtel déjà en exploitation.

Comment l’éviter

1. Poser la question dès la conception

La question « comment ces équipements vont-ils communiquer ? » doit être posée au moment où on les choisit, pas à la mise en service. Pour chaque équipement, il faut savoir quel protocole il utilise, quelles informations il peut transmettre, et lesquelles il peut recevoir.

C’est le moment où les bureaux d’études jouent un rôle décisif : ils sont les mieux placés pour détecter les incompatibilités sur les plans, avant qu’elles ne deviennent des problèmes de chantier.

2. Écrire les scénarios attendus

Plutôt que de lister des équipements, il est beaucoup plus efficace de décrire ce que la chambre doit faire :

• « quand le client sort, la chambre passe en mode économie » ;
• « quand la fenêtre s’ouvre, la climatisation s’arrête » ;
• « quand la chambre est libérée à la réception, elle se prépare pour le client suivant » ;
• « le bouton près de la porte éteint tout, stores compris ».

Chaque scénario révèle immédiatement les échanges nécessaires entre systèmes. Ils ont toute leur place dans le CCTP.

3. Confier l’intégration à un acteur identifié

Il faut que quelqu’un soit responsable du fonctionnement de l’ensemble, pas seulement de chaque partie. C’est le rôle d’un intégrateur : il connaît les protocoles, choisit les passerelles, programme les échanges, et répond du résultat.

4. Tester avant le chantier

L’idéal est de valider le fonctionnement complet d’une chambre avant de la reproduire. Une chambre témoin, ou mieux, un tableau testé en atelier avec les vrais équipements, permet de corriger les défauts une fois, plutôt que cent fois sur site.

Notre approche

C’est précisément la raison d’être de JarvisPro, le superviseur que nous développons chez mySmartJarvis. Il joue le rôle de traducteur entre les équipements de fabricants différents, qu’il s’agisse de climatisation, d’éclairage, de stores, de chauffage ou de commandes murales, et permet de programmer les scénarios de la chambre comme un tout.

Les données sont traitées localement, dans le bâtiment : la chambre continue de fonctionner normalement même en cas de coupure internet.

Et parce que nos tableaux sont montés, câblés et programmés dans notre atelier, l’interopérabilité est testée avant d’arriver sur le chantier. L’électricien raccorde, la chambre fonctionne.

En résumé

Les équipements d’un hôtel ne se parlent pas à la livraison parce que personne ne leur a appris à le faire. La solution n’est pas de choisir d’autres équipements, mais de prévoir leur dialogue dès la conception : identifier les protocoles, écrire les scénarios attendus, confier l’intégration à un responsable unique, et tester avant de reproduire.

Vous préparez un projet hôtelier et souhaitez sécuriser l’interopérabilité dès la conception ? Parlons-en