JB ServicesJulien Berton

Décret BACS reporté à 2030 : utiliser le délai pour une GTB interopérable et sécurisée

Par Julien Berton, architecte IT · Publié le · 7 min de lecture

Le décret n° 2025-1343 du 26 décembre 2025 a décalé au 1er janvier 2030 l’obligation d’équiper d’un système d’automatisation et de contrôle (BACS, Building Automation and Control System) les bâtiments tertiaires dont les systèmes de chauffage ou de climatisation dépassent 70 kW. L’échéance initiale était le 1er janvier 2027. Le même texte repousse aussi les obligations sur la régulation de la température et sur le calorifugeage des réseaux de chaleur et de froid.

Trois ans de plus, c’est du temps pour bien faire. C’est aussi le meilleur moyen de se retrouver en 2029 à acheter dans l’urgence une GTB fermée, posée sur le réseau bureautique, que personne ne saura faire évoluer. Cet article reprend ce que dit le texte et ce que j’en retiens côté infrastructure, réseau et cybersécurité.

Le calendrier du décret BACS

  • Décret n° 2020-887 du 20 juillet 2020 : première version, pour les bâtiments tertiaires dont le système de chauffage ou de climatisation (combiné ou non à la ventilation) dépasse 290 kW, avec une échéance au 1er janvier 2025.
  • Décret n° 2023-259 du 7 avril 2023 : extension aux systèmes de plus de 70 kW, échéance fixée au 1er janvier 2027, et ajout d’une inspection périodique des systèmes.
  • Décret n° 2025-1343 du 26 décembre 2025 : report de l’échéance des systèmes de plus de 70 kW au 1er janvier 2030.

Pour les bâtiments au-dessus de 290 kW, le report ne change rien : l’échéance de 2025 est passée. Les obligations sont codifiées aux articles R175-1 et suivants du Code de la construction et de l’habitation. Une dérogation reste possible lorsque le temps de retour sur investissement de l’installation dépasse le seuil prévu par le texte, à condition de pouvoir le justifier par une étude.

Ce que le système doit savoir faire

Le décret ne vise pas une marque ni un protocole. Il fixe des fonctions. Le système doit :

  • suivre, enregistrer et analyser les données de production et de consommation énergétique par zone fonctionnelle, au pas de temps horaire, et conserver les données mensuelles pendant cinq ans ;
  • situer l’efficacité énergétique du bâtiment par rapport à des valeurs de référence ;
  • détecter les pertes d’efficacité des systèmes techniques et en informer l’exploitant ;
  • être interopérable avec les différents systèmes techniques du bâtiment ;
  • permettre un arrêt manuel et la gestion autonome de chacun de ces systèmes.

Deux points de cette liste comptent plus que les autres pour la suite : l’interopérabilité et la conservation des données. Ce sont eux qui décident si la GTB installée pour la conformité servira encore dans dix ans.

L’interopérabilité se joue au choix des protocoles

Un bâtiment tertiaire mélange presque toujours plusieurs générations d’équipements : pompes à chaleur et centrales de traitement d’air en BACnet ou en Modbus, éclairage en KNX, DALI ou protocole propriétaire, compteurs en M-Bus ou en Modbus, capteurs récents en MQTT. Sur le Smart Building dont j’ai repris l’infrastructure chez CESI, la collecte des données des PAC, des CTA et des luminaires passait par BACnet, Modbus, DyNet et TCP/IP, et l’analyse a porté sur plus de 800 millions de lignes.

De cette expérience, je tire quelques règles pour un cahier des charges BACS :

  • exiger des protocoles ouverts et documentés (BACnet/IP, Modbus TCP, KNX, MQTT) sur les équipements et sur la supervision, avec la liste des points exposés ;
  • demander l’accès aux données brutes dans un format exploitable, sans licence supplémentaire par point ni dépendance à un portail en ligne du fournisseur ;
  • prévoir une passerelle par protocole hérité plutôt qu’un remplacement complet, quand l’équipement est encore sain ;
  • nommer les points de manière cohérente dès le départ (bâtiment, niveau, zone, équipement, grandeur), sinon l’analyse par zone fonctionnelle devient un travail de fouille.

Une GTB est un système informatique à sécuriser

Une GTB moderne, c’est un serveur de supervision, une base de données, des passerelles IP et des dizaines d’automates communicants. Tout ce qui s’applique à un système d’information s’applique donc à elle, avec une contrainte en plus : on ne redémarre pas une CTA comme une machine virtuelle.

Les points que je vérifie systématiquement :

  • Segmentation : un ou plusieurs VLAN dédiés aux réseaux techniques, séparés de la bureautique, avec un filtrage explicite des flux entre zones. Seuls les protocoles et les hôtes nécessaires passent.
  • Accès distant : aucun automate ni superviseur joignable directement depuis Internet. La télémaintenance des intégrateurs passe par un point d’entrée unique, avec comptes nominatifs, authentification forte et journalisation.
  • Comptes et mots de passe : pas d’identifiants par défaut ni de compte partagé entre intervenants.
  • Mises à jour : un inventaire des versions de micrologiciel et une procédure de mise à jour testée, avec sauvegarde des configurations et retour arrière.
  • Supervision : disponibilité des équipements dans l’outil de supervision existant (de type Zabbix) et journaux des passerelles et des pare-feu centralisés dans un SIEM (de type Wazuh).

Ces exigences rejoignent celles du Cyber Resilience Act, qui impose depuis septembre 2026 aux fabricants de signaler les vulnérabilités exploitées dans leurs produits, et celles de NIS2 pour les entités concernées. Les intégrer au cahier des charges de la GTB coûte peu. Les ajouter après la réception coûte beaucoup plus. Le détail de la démarche est sur la page cybersécurité et architecture Zero Trust.

Les données : une infrastructure à dimensionner

Conserver cinq ans de données mensuelles est le minimum réglementaire. Pour détecter une dérive d’efficacité, comparer deux saisons ou valider un réglage, on garde en pratique les données horaires, voire plus fines. Cela suppose une base de données dimensionnée, sauvegardée et supervisée comme n’importe quelle application de production : stockage, rétention, sauvegarde hors site (Veeam ou équivalent), plan de reprise. Le serveur de supervision a sa place dans l’infrastructure virtualisée du site, sous Proxmox VE ou VMware, plutôt que sur un PC posé dans le local technique.

Le jumeau numérique pour exploiter la GTB

Une fois les données accessibles et propres, un jumeau numérique du bâtiment permet de les lire dans leur contexte : chaque zone, chaque équipement, chaque capteur placé dans la maquette, avec son état en temps réel. Sous Unreal Engine 5, relié aux équipements en KNX, BACnet, Modbus et MQTT, il sert à repérer une dérive, à vérifier qu’un réglage a produit l’effet attendu, et à former les équipes d’exploitation sur un bâtiment qu’elles voient enfin dans son ensemble. Il oblige aussi à recenser chaque point communicant et chaque flux, ce qui fournit l’inventaire dont la sécurisation a besoin.

Utiliser les trois ans de délai

  1. 2026 : vérifier si le bâtiment est concerné (puissance nominale utile des systèmes de chauffage et de climatisation), inventorier l’existant (équipements, protocoles, réseau, accès distants) et faire le point sur la sécurité des réseaux techniques.
  2. 2027 : rédiger le cahier des charges avec les exigences d’interopérabilité, d’accès aux données et de cybersécurité, puis consulter.
  3. 2028 : déployer par lots, en commençant par les zones les plus consommatrices, avec segmentation et supervision dès le premier lot.
  4. 2029 : terminer le déploiement, valider les fonctions exigées par le décret, documenter et former les exploitants avant l’échéance du 1er janvier 2030.

Un audit de l’infrastructure du bâtiment est un bon point de départ : il couvre le réseau, la virtualisation, la sauvegarde et la sécurité, et il donne une base chiffrée pour le cahier des charges.

GTB, BACS, réseaux techniques : par où commencer ? J’interviens sur l’inventaire, l’interopérabilité des protocoles, la segmentation et le jumeau numérique du bâtiment. Voir l’offre jumeau numérique & Smart Building.

Sources