Votre bâtiment fait-il partie de votre système d’information ?
GTB, climatisation, contrôle d’accès et maintenance peuvent conditionner directement la disponibilité du SI. La frontière utile de la cartographie dépasse parfois le périmètre informatique.
GTB, climatisation, contrôle d’accès et maintenance peuvent conditionner directement la disponibilité du SI. La frontière utile de la cartographie dépasse parfois le périmètre informatique.
Action : identifiez les actifs, dépendances et preuves concernés avant de traiter le sujet comme une exigence isolée.
Votre application métier fonctionne.
Les serveurs sont disponibles. Le réseau aussi. La base de données répond normalement.
Puis la climatisation de la salle informatique s’arrête.
Quelques dizaines de minutes plus tard, la température augmente, des équipements commencent à se mettre en sécurité et le service devient indisponible.
Aucun serveur n’a été attaqué. Aucun compte n’a été compromis. Aucun ransomware n’a été déployé.
Pourtant, le système d’information ne fonctionne plus.
Cette situation pose une question simple : où s’arrête réellement le système d’information ?
En septembre 2026, le NIST a publié une nouvelle version provisoire de son guide consacré à la sécurité des technologies opérationnelles. Son périmètre inclut explicitement les systèmes d’automatisation des bâtiments, les systèmes de contrôle d’accès physique et les dispositifs de surveillance de l’environnement.1
En France, l’ANSSI rappelle également que les systèmes de gestion technique du bâtiment peuvent être critiques, notamment dans les hôpitaux, laboratoires ou sites industriels.2
La frontière entre informatique, bâtiment et exploitation physique devient donc de moins en moins évidente.
Un équipement peut être hors de la DSI mais dans la chaîne de dépendance
Une cartographie classique peut représenter :
processus métier → application → base de données → serveur → réseau
Cette chaîne est utile.
Mais elle peut s’arrêter trop tôt.
Prenons une application hospitalière hébergée dans une salle informatique. Son fonctionnement dépend aussi de l’alimentation électrique, du refroidissement, parfois de dispositifs de détection incendie ou de contrôle d’accès physique.
La dépendance réelle peut alors devenir :
service de soins → application → serveurs → salle informatique → refroidissement → GTB
La GTB n’est pas une application métier.
Elle peut même être exploitée par les services techniques et non par la DSI.
Pourtant, si sa défaillance peut rendre le service numérique indisponible, elle appartient à la chaîne de dépendance opérationnelle du SI.
Le NIST élargit explicitement la notion d’OT
La quatrième révision du NIST SP 800-82 définit l’Operational Technology comme un ensemble très large de systèmes programmables interagissant avec l’environnement physique.
Le document cite notamment les systèmes industriels, l’automatisation des bâtiments, le transport, le contrôle d’accès physique et la surveillance de l’environnement.1
Cette définition entraîne un changement de perspective.
La question n’est plus seulement :
« Quels équipements industriels possédons-nous ? »
Mais :
« Quels systèmes numériques peuvent modifier, mesurer ou contrôler l’environnement physique dont dépend notre activité ? »
La réponse peut faire apparaître des équipements longtemps absents de la cartographie informatique.
La GTB est devenue un système numérique à part entière
Une gestion technique du bâtiment peut piloter ou superviser chauffage et climatisation, ventilation, alimentation électrique, éclairage, ascenseurs, sûreté ou certains équipements techniques spécialisés.
Ces environnements possèdent désormais des automates, serveurs, consoles, protocoles réseau, équipements IP, comptes utilisateurs et connexions distantes.
L’ANSSI souligne d’ailleurs que la GTB est fréquemment exploitée sous forme de prestation et qu’elle peut être critique dans certains contextes.2
Autrement dit, une partie de l’infrastructure dont dépend l’entreprise peut être :
numérique, connectée et administrable à distance, tout en restant largement hors du périmètre traditionnel de la DSI.
Le prestataire de maintenance fait aussi partie de l’architecture
Prenons une installation de climatisation supervisée par une GTB.
L’équipement est maintenu par une société extérieure.
Le technicien peut intervenir à distance.
La chaîne devient :
prestataire → accès distant → passerelle → réseau technique → GTB → automate → équipement physique
Cette représentation change considérablement l’analyse de risque.
Le prestataire n’est plus simplement un fournisseur contractuel.
Son accès constitue une relation technique permettant d’agir sur un système physique dont dépend le SI.
Le NIST a publié en juin 2026 une architecture de référence consacrée aux accès distants vers des environnements OT critiques. Elle met notamment l’accent sur l’authentification, le contrôle d’accès et l’architecture de connexion.3
IT et OT ne peuvent plus être analysés séparément
Pendant longtemps, la séparation était intuitive :
IT = données et applications
OT = machines et processus physiques
Cette distinction reste utile, mais elle ne suffit plus à représenter les dépendances.
Un système OT peut utiliser des annuaires, DNS, postes Windows, hyperviseurs, équipements réseau classiques, logiciels de supervision, connexions VPN ou services cloud.
Inversement, une application IT peut dépendre d’une infrastructure physique pilotée par l’OT.
On obtient alors une architecture circulaire :
IT → OT → environnement physique → disponibilité de l’IT
Le NIST SP 800-82 Rev.4 renforce précisément ses recommandations sur la gestion des actifs, la surveillance réseau et l’architecture de sécurité OT.1
Une cartographie des actifs ne suffit pas
Ajouter « GTB » ou « automate » dans un inventaire est une première étape.
Mais connaître un actif ne signifie pas comprendre son importance.
Il faut également représenter ses relations.
Par exemple :
GTB → pilote → climatisation
climatisation → protège → salle informatique
salle informatique → héberge → serveurs
serveurs → hébergent → application
application → supporte → processus métier
La dépendance importante n’est donc pas seulement :
« nous avons une GTB »
mais :
« cette GTB participe indirectement au maintien d’un service métier critique ».
Le projet NIST publié en juin 2026 sur la gestion des actifs OT rappelle qu’un inventaire incomplet réduit la capacité à comprendre les risques, gérer les configurations et les changements ou préparer la réponse aux incidents.4
Le cas du contrôle d’accès physique
Le même raisonnement s’applique à un autre système souvent considéré comme périphérique : le contrôle d’accès.
Imaginons une salle informatique accessible uniquement via un système de badges.
Ce système possède un serveur, une base d’identités, des contrôleurs, des lecteurs, un réseau et une console d’administration.
Une compromission peut permettre un accès physique indu.
Mais une panne peut également empêcher les équipes habilitées d’accéder à certaines zones pendant un incident.
Le système de badges peut donc être simultanément :
un équipement de sécurité physique, un système numérique et une dépendance opérationnelle du PRA.
Cette triple nature est précisément ce qu’une vision strictement applicative du SI risque de manquer.
Sauvegarder un automate n’est pas sauvegarder un serveur
La résilience OT possède également ses propres contraintes.
Le NIST rappelle dans son OT Backup Quick Start Guide que les sauvegardes OT doivent notamment être intégrées à la gestion des changements, réalisées régulièrement, testées et examinées lors des exercices de reprise.5
Une sauvegarde OT peut contenir configuration d’automate, programmes, paramètres, configuration d’IHM, règles de supervision ou configuration réseau spécialisée.
Cela implique une nouvelle relation à documenter :
actif OT → configuration → sauvegarde → procédure de restauration → compétence nécessaire
Car disposer du fichier de configuration ne garantit pas nécessairement que l’organisation saura remettre l’installation en service.
Cas construit : un hôpital
Prenons un établissement fictif.
Son dossier patient informatisé est identifié comme critique.
La cartographie informatique représente correctement :
DPI → base SQL → machines virtuelles → hyperviseur → stockage
Mais l’analyse opérationnelle fait apparaître :
hyperviseur → salle informatique
salle informatique → climatisation
climatisation → automate
automate → GTB
GTB → réseau technique
réseau technique → passerelle d’administration
passerelle → prestataire de maintenance
La nouvelle chaîne complète devient :
prestataire → accès distant → GTB → climatisation → salle informatique → serveurs → DPI → soins
Aucun de ces liens ne signifie qu’une attaque se propagerait automatiquement d’un bout à l’autre.
Mais la chaîne permet de poser les bonnes questions : quels composants peuvent interrompre le service ? qui peut les administrer ? quels accès existent ? quelles alternatives sont disponibles ? combien de temps peut-on fonctionner sans eux ?
Il faut cartographier plusieurs types de dépendances
Pour intégrer correctement les systèmes cyber-physiques, il est utile de distinguer au moins quatre relations.
Dépendance technique : A a besoin de B pour fonctionner.
Dépendance physique : B fournit à A une condition nécessaire comme alimentation, refroidissement ou environnement.
Dépendance d’administration : C peut modifier ou arrêter B.
Dépendance de maintenance : un acteur interne ou externe est nécessaire pour remettre B en fonctionnement.
La même infrastructure peut cumuler plusieurs relations.
Cette distinction évite de transformer la cartographie en simple liste de câbles et d’équipements.
Un test simple : retirer l’équipement de la carte
Une méthode pratique consiste à sélectionner un actif considéré comme « hors informatique » puis à poser la question :
« Si cet équipement disparaît pendant 24 heures, quel service numérique devient impossible ? »
Pour une GTB :
GTB indisponible → quelles fonctions du bâtiment disparaissent ?
Pour la climatisation :
refroidissement indisponible → quelles salles ou infrastructures sont affectées ?
Pour le contrôle d’accès :
système indisponible → quelles opérations deviennent impossibles ?
Pour une alimentation secourue :
équipement indisponible → combien de temps le SI reste-t-il exploitable ?
Si la réponse atteint un processus métier critique, l’équipement mérite probablement d’apparaître dans la représentation des dépendances du SI.
La frontière utile n’est pas organisationnelle
La DSI ne gère pas nécessairement le bâtiment.
Les services techniques ne gèrent pas nécessairement les applications.
Le prestataire GTB ne connaît pas nécessairement les processus métier.
Pourtant, tous peuvent participer à la même chaîne de disponibilité.
La frontière pertinente pour la cartographie n’est donc pas :
« qui possède cet équipement ? »
mais :
« de quoi notre activité dépend-elle réellement ? »
Le nouvel élargissement du périmètre OT proposé par le NIST et les recommandations françaises sur la GTB rendent cette question de plus en plus concrète.12
Une cartographie du système d’information devient alors moins une représentation de « l’informatique » qu’une représentation des dépendances numériques et physiques nécessaires au fonctionnement de l’organisation.
RÉFÉRENCES
Sources vérifiées le 29 septembre 2026 · 5 sources
- [1] Source officielleNIST — SP 800-82 Rev.4, Guide to Operational Technology (OT) Security
- [2] Source officielleANSSI — Recommandations de sécurité relatives à la gestion technique et centralisée du bâtiment (GTB/GTC)
- [3] Source officielleNIST — SP 1800-45, Cybersecurity for the Water and Wastewater Sector: Build Architecture (Operational Technology Remote Access)
- [4] Source officielleNIST — Asset Management as a Foundation for Operational Technology Cybersecurity
- [5] Source officielleNIST — SP 1339, OT Backup Quick Start Guide
Les références sont affichées pour permettre la vérification. Une source officielle ne signifie pas que Cybercoria lui attribue une conclusion qu’elle ne formule pas.