Pourquoi la GTB constitue-t-elle un système cyber-physique ?
La gestion technique du bâtiment relie logiciels, réseaux, automates, capteurs et actionneurs. Une commande numérique peut modifier une consigne de température, arrêter une ventilation, masquer une alarme ou perturber une séquence de froid. Les conséquences dépassent donc la confidentialité des données : disponibilité, sécurité des personnes, qualité des produits, consommation énergétique et continuité d’exploitation sont en jeu. L’ANSSI a publié le 4 juin 2026 un guide spécifiquement consacré à la sécurité des GTB/GTC. Le document rappelle que ces systèmes sont souvent exploités par des prestataires et peuvent devenir critiques selon le bâtiment. Cette réalité impose une gouvernance claire entre propriétaire, exploitant, intégrateur, mainteneur et direction informatique. Aucun acteur ne doit supposer que la sécurité est entièrement prise en charge par un autre.
Commencer par l’inventaire et les responsabilités
On ne protège correctement que ce qui est connu. L’inventaire doit identifier serveurs, postes de supervision, automates, passerelles, switches, routeurs, pare-feu, accès distants, protocoles, versions, licences, sauvegardes et dépendances. Ajoutez l’emplacement, le propriétaire fonctionnel, le mainteneur, la criticité et la possibilité réelle de mise à jour. Un export automatique du réseau ne suffit pas : certains bus ou équipements anciens ne se déclarent pas proprement. Associez chaque fonction à une conséquence métier. La perte d’un écran de supervision peut être tolérable si les automatismes locaux poursuivent leur fonctionnement. La perte d’un automate froid peut menacer des marchandises. Une passerelle de comptage a un impact différent d’une commande de désenfumage. Cette classification oriente la segmentation, la redondance, les délais d’intervention et les essais à mener.
Segmenter sans isoler l’exploitation
La GTB ne doit pas partager un réseau plat avec les postes bureautiques, le Wi-Fi invité ou des équipements non maîtrisés. Une architecture robuste sépare les zones selon les fonctions et la criticité : supervision, serveurs, automatismes, équipements terrain, accès prestataires et interfaces avec le système d’information. Les flux autorisés sont explicitement documentés ; le reste est bloqué. Les échanges entre zones passent par des équipements administrables et journalisés. La segmentation n’implique pas de couper toute interopérabilité. Le responsable énergie peut avoir besoin d’exports, la GMAO de recevoir des défauts et l’hypervision de collecter des données multisites. Chaque interface doit toutefois avoir une finalité, un sens de flux, un protocole et un propriétaire. Une passerelle ne doit pas devenir une ouverture permanente et indifférenciée entre l’IT et l’OT.
Sécuriser les accès distants de maintenance
Les accès distants sont souvent nécessaires pour diagnostiquer rapidement un défaut ou maintenir plusieurs sites. Ils ne doivent pas reposer sur un outil installé sans gouvernance ni sur un mot de passe partagé. Utilisez un point d’entrée contrôlé, une authentification forte lorsque l’architecture le permet, des comptes nominatifs, des droits limités, une activation temporaire et une journalisation. Les accès dormants sont supprimés lorsque le contrat ou l’intervention se termine. Le propriétaire doit savoir qui peut se connecter, à quoi, quand et pour quelle raison. Un prestataire n’a pas besoin d’un accès permanent à l’ensemble de la supervision pour intervenir sur un sous-système. Prévoyez une procédure d’urgence qui n’oblige pas à contourner les règles. Si la connexion distante tombe, l’installation doit conserver les automatismes locaux nécessaires et un mode d’exploitation documenté.
Maîtriser les comptes, les mots de passe et les postes
Supprimez les comptes par défaut ou changez leurs secrets avant la réception. Les comptes partagés compliquent la traçabilité ; réservez-les aux cas techniques justifiés et encadrez leur usage. Les droits suivent le principe du besoin d’en connaître : consultation, acquittement, modification de consigne, programmation et administration ne sont pas équivalents. Une revue régulière compare les comptes actifs aux personnes et contrats réellement en place. Les postes de supervision doivent être dédiés autant que possible. Navigation libre, messagerie, clés USB inconnues et installations non maîtrisées augmentent la surface d’attaque. Les mises à jour sont préparées avec l’intégrateur et testées selon la criticité ; un système OT ne se traite pas comme un ordinateur standard que l’on redémarre immédiatement. Le plan de maintien en condition de sécurité doit respecter les contraintes d’exploitation.
Sauvegarder ce qui permet réellement de reconstruire
Une sauvegarde utile ne se limite pas à la base graphique. Elle comprend les programmes automates, configurations, licences, machines virtuelles, historiques nécessaires, comptes de service, certificats, paramètres réseau, listes de points et documents de correspondance. Conservez une copie hors ligne ou isolée et protégez-la contre l’altération. La fréquence dépend du rythme des modifications et de la perte acceptable. Testez la restauration. Une archive présente sur un serveur n’a aucune valeur démontrée tant qu’elle n’a pas permis de reconstruire un élément dans un environnement contrôlé. Documentez la version du logiciel, les prérequis, les clés de licence, la personne habilitée et le temps estimé. Pour un patrimoine multisite, standardisez l’arborescence et vérifiez que chaque site alimente réellement le référentiel central.
Journaliser et détecter sans noyer l’exploitant
Les journaux doivent permettre d’identifier les connexions, modifications de configuration, changements de consigne, échecs d’authentification et événements réseau significatifs. Ils sont horodatés avec une référence commune et conservés selon une durée définie. L’objectif n’est pas de collecter tout ce qui est techniquement possible, mais de rendre une investigation possible et d’identifier rapidement un comportement anormal. Les alarmes cyber rejoignent la stratégie globale d’alarmes GTB. Une perte de communication, un compte verrouillé ou un changement massif de consignes n’ont pas la même criticité. Définissez destinataire, délai, action attendue et escalade. Une alerte sans procédure finit par être ignorée ; une alerte correctement contextualisée aide l’exploitant à distinguer un incident cyber, une panne réseau et une intervention planifiée.
Tester les scénarios dégradés
Le commissioning cyber vérifie les contrôles sans mettre le site en danger. Testez l’expiration d’un accès prestataire, la coupure d’une liaison d’hypervision, le fonctionnement local sans serveur central, la restauration d’une sauvegarde et la remontée d’une alerte. Les essais sont préparés avec l’exploitation, réalisés dans une fenêtre adaptée et accompagnés de critères d’acceptation. Ils ne consistent pas à improviser une attaque sur un bâtiment en service. Vérifiez aussi le retour à la normale. Une liaison rétablie ne doit pas provoquer une avalanche de commandes, perdre des historiques ou écraser des consignes locales. Les mécanismes de reprise, de synchronisation et de priorité sont décrits dans l’analyse fonctionnelle. Cette discipline relie cybersécurité, automatismes et continuité d’exploitation au lieu de traiter trois sujets séparés.
Intégrer la cybersécurité dès la consultation
Un projet neuf ou une rénovation doit traduire les exigences en livrables vérifiables : schéma d’architecture, matrice de flux, règles d’accès, inventaire, politique de sauvegarde, durcissement, gestion des vulnérabilités, journaux, tests et dossier final. Demandez des protocoles ouverts et des exports documentés, mais encadrez leur exposition. La propriété des données et des configurations doit être claire dès le marché. En exploitation, organisez une revue périodique associant technique et informatique : nouveaux équipements, comptes, versions, incidents, sauvegardes et changements de prestataire. La cybersécurité GTB n’est pas un lot livré une fois. C’est une capacité à maintenir un bâtiment compréhensible, contrôlable et reconstructible malgré les changements de personnes, de logiciels et d’usages.
Construire une feuille de route proportionnée
Commencez par les mesures à fort effet : inventaire, suppression des accès inutiles, sauvegardes vérifiées, segmentation des zones critiques et procédure d’incident. Traitez ensuite la journalisation avancée, le renouvellement des équipements obsolètes et l’alignement multisite. La priorité dépend du risque métier, pas de la visibilité du matériel. Un ancien automate stable et isolé peut être moins exposé qu’un serveur récent accessible depuis Internet. La bonne architecture ne cherche pas à rendre toute connexion impossible. Elle limite les chemins, rend les responsabilités visibles et préserve les automatismes indispensables. Une GTB sécurisée reste exploitable par les équipes autorisées, fonctionne en mode dégradé, conserve des preuves et peut être restaurée. C’est cette combinaison — sécurité, continuité et maintenabilité — qui protège réellement la valeur du bâtiment.
Coordonner cybersécurité, maintenance et contrats
Les exigences techniques échouent souvent lorsqu’elles ne figurent pas dans les contrats. Précisez les délais de révocation des comptes, la notification des vulnérabilités, la fourniture des sauvegardes, la restitution des configurations et la participation aux essais. Définissez aussi les responsabilités en cas d’incident : qui isole un équipement, qui autorise une coupure, qui informe l’exploitation et qui conserve les preuves ? Cette préparation réduit les décisions improvisées sous pression. Lors d’un changement de mainteneur ou d’intégrateur, organisez une réversibilité formelle. Inventaire, comptes, licences, programmes sources, certificats, historiques et documentation doivent être transférés puis vérifiés. Les accès de l’ancien prestataire sont supprimés après validation. Un bâtiment peut fonctionner correctement tout en dépendant dangereusement d’une personne ou d’un ordinateur non documenté. La réversibilité fait donc partie de la résilience cyber et de la maîtrise patrimoniale.
Piloter la sécurité d’un patrimoine multisite
Pour plusieurs bâtiments, adoptez un socle commun : nomenclature, zones réseau, règles d’accès, politique de sauvegarde, format d’inventaire et niveaux de criticité. L’objectif n’est pas de rendre les sites identiques, mais de faciliter la comparaison et l’intervention. Les exceptions sont documentées avec leur justification et leur date de réexamen. Une hypervision ne doit pas supprimer l’autonomie locale ni créer un point unique capable de commander sans limite tout le patrimoine.