En résumé : la doctrine officielle de l’État sur la sécurité des bâtiments connectés
Le 27 avril 2026, l’Agence nationale de la sécurité des systèmes d’information (ANSSI) a publié son guide de référence : « Recommandations de sécurité relatives à la gestion technique et centralisée du bâtiment (GTB/GTC) » (référence ANSSI-PA-110).
Ce document constitue la première doctrine publique de l’ANSSI spécifiquement consacrée à la cybersécurité des GTB/GTC. Alors que le Décret BACS impose l’installation de systèmes d’automatisation partout en France, l’ANSSI sort pour la première fois d’une logique purement « industrielle » pour traiter le bâtiment connecté comme une infrastructure critique à part entière. Avec 26 recommandations officielles classées par priorités (N1 à court terme, N2 à moyen terme), ce guide définit les règles strictes de cloisonnement, de filtrage des protocoles (BACnet/IP, Modbus) et de défense en profondeur pour protéger vos installations.
L’obligation d’installer des systèmes de régulation thermique pour atteindre la sobriété énergétique ne peut plus se faire au détriment de la sécurité des infrastructures. Les protocoles historiques de l’immobilier ont été conçus pour être interopérables, ouverts et simples d’accès, mais ils n’intègrent structurellement aucun mécanisme de chiffrement ou d’authentification native.
Lancer une transition énergétique sans sécuriser ses réseaux techniques, c’est ouvrir une porte d’entrée directe aux cyberattaquants au cœur du système d’information de l’entreprise. Ce guide vulgarise et décrypte les exigences techniques du nouveau référentiel de l’ANSSI pour vous aider à mettre en conformité votre patrimoine immobilier de façon sûre.
Section 1 : Pourquoi la GTB est-elle devenue une cible critique ?
Le guide de l’ANSSI rappelle une réalité opérationnelle majeure : la Gestion Technique du Bâtiment pilote des usages hautement sensibles. Si dans le secteur tertiaire classique, une compromission impacte le confort et les factures, dans certains environnements comme le milieu hospitalier, les laboratoires ou les sites industriels, les impacts peuvent être vitaux.
Le document liste explicitement les équipements critiques gérés par la GTB qu’il est urgent de protéger :
- • Les Centrales de Traitement de l’Air (CTA), notamment celles des blocs opératoires et des zones aseptiques, qui doivent réglementairement rester en surpression pour éviter le développement d’infections nosocomiales.
- • La surveillance des paramètres physiques de l’eau pour empêcher les baisses de température propices à la prolifération des légionnelles.
- • Les systèmes de distribution d’énergie, incluant les Tableaux Généraux Basse Tension (TGBT), les groupes frigorifiques, les onduleurs et la gestion des fluides médicaux (oxygène, protoxyde d’azote).
- • Les laboratoires confinés (comme les zones de virologie de niveau L3).
L’ANSSI souligne un problème principalement organisationnel : contrairement aux systèmes informatiques classiques (IT) gérés par une DSI, la GTB est l’objet d’une prestation souvent confiée à un prestataire externe via des contrats de maintenance. Pour faciliter les interventions de maintenance ou garantir la seule disponibilité immédiate du système, la sécurité est trop souvent sacrifiée, laissant des accès distants non maîtrisés ou ouverts en continu vers l’extérieur.
Section 2 : L’architecture type sécurisée selon la doctrine de l’État
Pour faire face à la vulnérabilité des protocoles de terrain, l’ANSSI impose le concept de défense en profondeur. Il ne s’agit plus seulement de mettre un pare-feu à la frontière du réseau, mais de sécuriser chaque couche du système.
1. Isolation stricte du réseau d’administration (R1, R2, R3)
C’est la recommandation prioritaire à court terme (N1). Les actions de configuration et de programmation de la GTB doivent obligatoirement s’effectuer depuis une station d’ingénierie dédiée et sécurisée. Tout accès à Internet (navigation web, messagerie électronique) y est strictement interdit, même en situation de mobilité.
Ce poste doit être isolé dans un réseau IP d’administration spécifique, cloisonné logiquement ou physiquement du reste de l’entreprise par des VLAN et un équipement de filtrage empêchant toute connexion directe depuis d’autres zones. Si les outils d’administration des constructeurs n’intègrent pas de chiffrement robuste, l’ANSSI impose d’encapsuler ces flux dans un tunnel VPN IPsec avec authentification mutuelle par certificats (Recommandation alternative R3-).
2. Cloisonnement par fonction technique (R4, R5)
Le guide met fin aux réseaux GTB « fourre-tout » où tous les équipements communiquent sans barrière. Vous devez segmenter vos installations techniques physiquement ou logiquement par l’utilisation de VLAN : la gestion du traitement de l’air (CTA) doit être cloisonnée logiquement de la gestion de l’eau ou de l’éclairage. Si des sous-systèmes techniques ont un besoin fonctionnel de communiquer entre eux, les flux doivent obligatoirement transiter par un pare-feu configuré pour filtrer les seuls messages strictement nécessaires.
3. Durcissement des infrastructures physiques et des ports (R9, R19, R20)
Le danger est aussi physique. L’ANSSI demande de configurer les commutateurs pour intégrer les ports Ethernet muraux publics dans un VLAN d’« accueil » et de désactiver l’ensemble des ports Ethernet non utilisés en les plaçant dans un VLAN de quarantaine.
De même, les ports USB des automates, des postes de supervision (SCADA) et d’ingénierie doivent être bloqués physiquement ou logiquement (R19) pour empêcher l’introduction de codes malveillants. Si l’utilisation d’un média amovible est requise pour une mise à jour, le support doit obligatoirement passer par un sas ou une station blanche (R21) régulièrement mise à jour en amont.
Section 3 : Analyse des protocoles : les annexes de filtrage Modbus et BACnet
Le cœur technique du guide se situe dans ses annexes de détection et de filtrage applicatif. L’ANSSI détaille comment configurer vos équipements de sécurité (comme les pare-feux Stormshield ou les sondes de détection open source Suricata) pour bloquer les commandes illégitimes.
Le protocole Modbus (Annexe A)
N’intégrant aucune fonction de cybersécurité native par défaut, le protocole Modbus doit faire l’objet d’un filtrage strict des codes fonctions en production. L’ANSSI recommande de filtrer ou de détecter les requêtes suivantes en situation d’exploitation normale :
ReportSlaveID (0x11) et Encapsulated Interface Transport (0x2B) : fonctions non utiles en production, exploitées par les outils de reconnaissance (comme le script NMAP modbus-discover.nse) pour cartographier le réseau.
ReadFileRecord (0x14) et WriteFileRecord (0x15) : permettent des lectures massives (à détecter) ou des écritures globales de registres (à filtrer) non requises en production.
- Cas particulier UMAS (0x5A) : ce protocole propriétaire d’administration (Schneider Electric) donne un contrôle total sur l’équipement de par ses fonctions d’administration. L’ANSSI impose de le filtrer ou de n’autoriser que les fonctions strictement nécessaires à la communication métier en production.
Le protocole BACnet/IP (Annexe B)
Le protocole BACnet/IP utilise des messages de diffusion (broadcast) limités au sous-réseau pour fonctionner (découverte via les services Who-Is / I-Am). Cela pose un problème pour le cloisonnement par VLAN, car un paquet IP de diffusion ne franchit pas son sous-réseau.
Pour résoudre cette contrainte, l’architecture doit déployer des modules BBMD (BACnet Broadcast Management Device) chargés de retransmettre en unicast les messages de diffusion aux autres BBMD configurés dans leur table BDT (Broadcast Distribution Table).
L’ANSSI met fermement en garde contre une fonctionnalité critique : le **Foreign Device (R7)**. Cette option permet à un équipement « étranger » et isolé de s’enregistrer auprès d’un BBMD pour recevoir l’intégralité des messages de diffusion du réseau. L’ANSSI demande de désactiver impérativement cette fonction en production, car un attaquant pourrait l’implémenter pour découvrir de manière illégitime l’ensemble des composants du réseau.
| Service BACnet (APDU) |
Action requise |
Justification de l’ANSSI |
| AtomicWriteFile (Code 7) |
FILTRER |
Permet d’écrire des fichiers de configuration à distance. Risque élevé de compromission ou d’altération de l’équipement. |
| DeviceCommunicationControl (Code 17) |
FILTRER |
Service hautement sensible permettant de couper la communication d’un composant. Son exécution illégitime provoque un déni de service (DoS) sur la GTB. |
| ReadProperty sur ID 4194303 |
FILTRER |
L’interrogation de cette valeur maximale d’identifiant est exploitée par les outils d’attaque (scripts NMAP) pour forcer la découverte de l’identifiant BACnet ID. Non utile en production. |
| TimeSynchronization (Code 7) |
FILTRER |
À bloquer dès lors qu’un protocole dédié de synchronisation horaire (NTPv4) est en place (R13). Évite la falsification de l’heure locale, qui perturberait la journalisation et les automatismes métiers. |
Section 4 : Concilier Décret BACS et cybersécurité : l’intégration des réseaux
L’ANSSI le spécifie dès l’introduction de son guide : cette version initiale tient compte des architectures actuellement déployées sur le marché. Une prochaine version étendra sa couverture aux infrastructures basées sur la norme récente BACnet/SC (Secure Connect).
Pour les gestionnaires de parcs immobiliers existants, appliquer l’intégralité de ces consignes de cloisonnement sur une GTB filaire traditionnelle peut s’avérer complexe et coûteux en ingénierie réseau. À ce titre, certaines architectures IoT modernes peuvent faciliter la mise en œuvre de certains principes recommandés par l’ANSSI, notamment le cloisonnement des réseaux techniques et la centralisation de la supervision.
Toutefois, le niveau de sécurité dépend avant tout de l’architecture globale, de la configuration et de l’exploitation du système. L’utilisation de passerelles protocolaires durcies et de superviseurs centralisés permet de décliner l’hygiène demandée par l’ANSSI :
- Désactivation des services réseau non utilisés (DHCP, FTP, TFTP, HTTP) au niveau des automates et passerelles pour limiter la surface d’attaque (R12, R16).
- Mise en œuvre d’une fonction de journalisation active (R18) pour la transmission d’événements de sécurité vers un serveur de collecte de journaux centralisé.
- Sécurisation stricte des accès distants pour les prestataires nomades via des VPN IPsec ou VPN TLS v1.3 associés à un mécanisme d’authentification multifacteur robuste.
FAQ – Vos questions directes sur la cybersécurité des GTB
Le guide de l’ANSSI est-il une obligation légale sanctionnée par la loi ?
Sauf disposition réglementaire contraire liée à des secteurs d’activité spécifiques, les recommandations de l’ANSSI n’ont pas de caractère normatif ou d’obligation légale contraignante par elles-mêmes. Néanmoins, ces recommandations constituent un référentiel reconnu de bonnes pratiques. En cas d’incident, elles peuvent être prises en compte dans l’analyse des mesures de sécurité mises en œuvre par l’organisation.
Peut-on sécuriser une GTB existante sans remplacer tous les automates ?
Oui, tout à fait. Une part importante de la défense en profondeur s’applique au réseau environnant : routage inter-VLAN filtré par un pare-feu, mise en œuvre de profils de sécurité applicatifs (IPS/IDS), verrouillage des ports USB physiques, changement systématique de tous les mots de passe d’usine et modification des configurations logicielles basiques comme l’interdiction du service Foreign Device.
Pourquoi la synchronisation horaire (NTP) est-elle considérée comme un élément de sécurité ?
L’ANSSI (Recommandation R13) préconise d’écarter les protocoles métiers pour la synchronisation horaire et de préférer le protocole **NTPv4** lié à un serveur de temps fiable commun à l’ensemble des infrastructures (IT, services techniques). En cas de gestion d’incident ou de levée de doutes, l’uniformisation temporelle est indispensable pour garantir l’intégrité, la corrélation et l’imputabilité des traces de journalisation.
Conclusion : La cybersécurité, condition sine qua non du bâtiment intelligent
La publication de cette doctrine officielle par l’ANSSI marque la fin de l’ère de l’insouciance pour l’immobilier connecté. La Gestion Technique du Bâtiment n’est plus un simple outil de confort relégué aux sous-sols des locaux techniques ; elle est désormais reconnue comme un maillon stratégique de l’infrastructure numérique des organisations.
Réussir la transition énergétique imposée par le Décret BACS implique d’adopter une vision transversale où la performance environnementale et la cybersécurité avancée avancent de pair pour protéger durablement la valeur et la résilience de votre patrimoine immobilier.
Vous souhaitez auditer l’architecture de votre système de gestion et concevoir une stratégie de pilotage à la fois sobre et sécurisée ?
Contactez nos ingénieurs experts Vesta-System pour une analyse personnalisée de vos installations techniques.
🌐 www.vesta-system.fr/nous-contacter/ | 📞 04 58 00 87 43
Source de référence : « Recommandations de sécurité relatives à la gestion technique et centralisée du bâtiment (GTB/GTC) », Guide ANSSI, v1.0 – 27/04/2026 (Référence ANSSI-PA-110). Document mis à disposition sous Licence Ouverte v2.0 (Etalab).