Télémétrie CVC sur un parc immobilier multisite

Un exploitant immobilier gère un parc national de bâtiments à usage mixte : bureaux, sites industriels légers et quelques entrepôts frigorifiques. Deux sites ne partagent jamais le même millésime CVC. Certains tournent sur une installation BACnet/IP récente, d'autres sur des boucles Modbus RTU, et plusieurs dépendent de contrôleurs OEM fermés qui n'exposent rien d'autre qu'un port de service non documenté.

La demande était étroite et exigeante : trois chiffres, chaque site, une seule vue normalisée. La consommation énergétique en temps réel par installation. Un historique des défauts et alarmes avec des horodatages qui concordent d'un fournisseur à l'autre. Les heures de fonctionnement par actif majeur, pour que la maintenance suive l'usure plutôt que le calendrier. On avait proposé à l'exploitant un abonnement SaaS par site avec un engagement minimum de cinq ans, qu'il a refusé par principe. Les données sont une vérité opérationnelle, et la vérité opérationnelle appartient à l'infrastructure propre de l'exploitant, pas à la location d'un tiers.

Le réflexe, sur un tel programme, est de poser un nouveau BMS devant l'ancien. Nous avons argumenté contre, pour trois raisons.

Cela réinvente une roue qui tourne déjà. La plupart des sites disposaient déjà d'un BMS fonctionnel au niveau installation, séquençant correctement refroidisseurs et centrales de traitement d'air. Remplacer cette couche coûte un an de perturbation et un cycle d'achat pluriannuel, en échange de fonctions que le site possède déjà.

Cela ne résout pas le problème multisite. Un second BMS n'est qu'un second silo. La question n'a jamais été « que fait cette installation à l'instant » : elle était « que se passe-t-il sur l'ensemble du parc cette nuit à 02:00 », et aucun BMS mono-site n'y répond.

Cela échange un verrou contre un autre. L'exploitant vivait déjà avec un verrou fournisseur au niveau installation. Payer pour s'en offrir un second, cette fois sur la couche de données, n'avait aucun sens.

Nous avons donc bâti l'inverse d'un nouveau BMS : une couche de télémétrie fine qui lit dans les systèmes déjà en place et expédie des enregistrements normalisés vers le plan de données de l'exploitant. Elle ajoute un chemin par lequel les données circulent. Elle ne change rien à la façon dont les bâtiments sont pilotés.

Chaque site reçoit une passerelle Linux ouverte Owasys, installée aux côtés des contrôleurs existants, et non entre eux et l'installation. La passerelle parle BACnet/IP avec les installations modernes, Modbus RTU sur boucle série avec les plus anciennes, et un adaptateur sur mesure avec les contrôleurs OEM fermés. Cet adaptateur a été négocié avec l'OEM sous le contrat propre de l'exploitant, pas le nôtre, et cela comptait : les droits d'accès sont restés chez la partie à qui appartiennent les bâtiments.

Un daemon d'acquisition interroge chaque système amont selon sa propre cadence, plus rapide sur les compteurs d'énergie, plus lente sur les consignes à variation lente, et normalise chaque relevé vers un modèle d'actifs CVC partagé : centrale de traitement d'air, refroidisseur, pompe, tour aéroréfrigérante, zone. Il écrit un enregistrement par actif par minute dans un buffer time-series local, de sorte qu'une liaison réseau coupée ne coûte qu'un bref rejeu. Depuis ce buffer, un publisher MQTT expédie vers un broker hébergé par l'exploitant. Un worker stream distribue ensuite les données dans deux directions : vers Timescale pour les tableaux de bord en direct, et vers un object store de long terme pour la conformité et l'audit.

Le modèle d'actifs est un schéma plat que nous livrons et que l'exploitant possède. Chaque point de chaque site s'y rattache. Rien dans le chemin n'est un tableau de bord d'adaptateur par fournisseur, car dès l'instant où les données d'un site n'ont de sens que dans l'écran d'un fournisseur, la vue à l'échelle du parc est morte.

Vague 1, site de référence (semaines 1 à 4). Un immeuble de bureaux doté de l'installation BACnet la plus complète. Il a servi à figer le modèle d'actifs, à valider les KPI énergie face à des relevés de compteurs auxquels l'exploitant faisait déjà confiance, et à confirmer que le BMS existant n'entrerait pas en conflit avec la nouvelle passerelle sur le bus.

Vague 2, les sites difficiles (semaines 5 à 12). Trois sites équipés de contrôleurs OEM fermés. Le goulot d'étranglement n'a jamais été le code. C'était le travail juridique pour ouvrir le port de service OEM sous le contrat de l'exploitant, que nous avons traité en premier, avant de bâtir l'adaptateur dans le compte de l'exploitant une fois l'accès accordé. Lent sur le calendrier, rapide une fois débloqué.

Vague 3, le reste du parc (semaines 13 à 26). À ce stade, l'installation était devenue une routine : une passerelle pré-flashée, une checklist de relevé de site, une fenêtre de câblage de deux heures et une passe d'étalonnage face aux valeurs que le BMS existant remontait déjà. Les équipes terrain ont mené les installations. Nous avons vu chacune se mettre en ligne depuis la console de l'exploitant.

Les tableaux de bord étaient la petite partie. Ce qui comptait, c'est que l'équipe opérations pouvait poser une question sur l'ensemble du parc et faire confiance à la réponse.

• KPI énergie CVC à l'échelle du parc, à l'heure : en direct sur tous les sites à quelques minutes des données d'installation, contre un délai de reporting d'un à trois jours auparavant.
• Temps pour identifier quel site a déclenché une alarme hors heures : quelques secondes, depuis une liste classée unique, au lieu d'appeler tour à tour le facility manager de chaque site.
• Tableaux de bord dont l'exploitant dépend encore d'un fournisseur pour la publication : zéro.
• La maintenance est désormais planifiée selon les heures de fonctionnement par actif majeur, et non selon un intervalle de calendrier fixe.

Le programme s'est déroulé en Conseil, Implémentation, Exploitation, avec une date de transfert ferme inscrite dans le SOW. Au transfert, l'exploitant a reçu l'image de la passerelle et les instructions pour la reconstruire depuis les sources, les sources du daemon d'acquisition, le modèle d'actifs CVC, les tableaux de bord accompagnés de leurs requêtes sous-jacentes, et un runbook pour mettre un nouveau site en service sans nous.

Douze mois plus tard, l'exploitant a ajouté quatre sites par lui-même. C'est l'affirmation qui nous tient le plus à cœur, parce qu'elle est falsifiable : l'équipe peut étendre le système sans rouvrir notre contrat, et elle l'a fait.