Bâtiments connectés : l’IA contre les failles invisibles

La plupart des entreprises pensent protéger leur activité avec un EDR, un pare-feu solide et une bonne hygiène MFA. Et pourtant, beaucoup laissent une porte latérale grande ouverte : le bâtiment lui-même. En décembre 2025, une présentation remarquée à Black Hat Europe a remis le sujet sur le devant de la scène : des systèmes de gestion technique du bâtiment (GTB/BMS), hérités d’anciennes acquisitions et de firmwares très anciens, restent exposés directement sur Internet.

Le point qui dérange, c’est qu’on ne parle pas d’un “petit risque IoT”. On parle d’infrastructures qui pilotent chauffage, ventilation, contrôle d’accès, sécurité incendie, parfois même des salles serveurs. Quand ces systèmes vieillissent, s’empilent et se patchent “au cas par cas”, ils deviennent un angle mort. Et c’est exactement là que l’intelligence artificielle en cybersécurité a un rôle concret : détecter l’incohérence, la dérive, les chemins d’attaque, avant l’incident.

Le vrai problème : des systèmes jamais prévus pour Internet

Réponse directe : beaucoup de systèmes de bâtiment et d’ICS ont été conçus pour des réseaux fermés, pas pour être joignables depuis une IP publique.

Dans la présentation évoquée à Black Hat Europe 2025, le chercheur s’est concentré sur un fournisseur de BMS dont l’évolution (rachats successifs, couches logicielles ajoutées, code ancien conservé) a produit un résultat classique : une plateforme devenue fragile, avec une longue liste de vulnérabilités, et déployée dans plus d’un millier de bâtiments à l’échelle mondiale.

Le détail le plus parlant : l’origine d’une vulnérabilité remonterait à un code firmware vieux de 18 ans. Ce n’est pas rare. Dans les environnements OT (Operational Technology), on rencontre encore des composants pensés pour durer 15 à 25 ans, alors que le modèle de menace, lui, change tous les trimestres.

“Patch” n’est pas synonyme de “correction”

Réponse directe : corriger un symptôme sans corriger la cause racine fabrique une dette de sécurité.

La divulgation coordonnée a entraîné des correctifs, mais avec un effet pervers bien connu : on ferme une faille visible, puis une autre apparaît parce que la cause racine (architecture, authentification, gestion des sessions, validation d’entrées, composants hérités) n’a pas été traitée.

Un patch qui colmate sans refondre, c’est un pansement sur une canalisation sous pression.

Pour les organisations, le message est simple et exigeant : après notification d’une vulnérabilité sérieuse, il faut viser l’audit complet, pas la rustine.

Pourquoi une GTB compromise peut impacter le business (vraiment)

Réponse directe : une GTB exposée peut provoquer un arrêt d’activité, une intrusion physique, ou une compromission IT indirecte.

Quand on parle de cybersécurité, on pense d’abord données et rançongiciels. Les systèmes de bâtiment ajoutent une dimension très concrète : la continuité d’activité dépend aussi de la température, des portes, des alarmes, des automates.

Voici trois scénarios réalistes, observés ou plausibles dans des environnements modernes :

1. Surchauffe d’une salle serveurs : en modifiant consignes HVAC/CRAC, un attaquant peut créer des arrêts, des dégradations matérielles, ou déclencher des bascules d’urgence.
2. Intrusion facilitée : certaines intégrations entre GTB et contrôle d’accès permettent de déverrouiller des zones, ou d’altérer des horaires et règles d’accès.
3. Pivot vers l’IT : si la GTB partage des segments réseau, des identifiants, ou un annuaire mal isolé, elle devient un tremplin vers le SI (et donc vers les données).

Le plus piégeux : le risque est parfois dilué entre propriétaire et locataire. Le bailleur gère la GTB, le locataire gère le SI. Et chacun suppose que “l’autre” s’en occupe.

L’erreur la plus fréquente : l’exposition sur IP publique

Réponse directe : si contourner un écran de login donne accès à l’application ou au réseau, il faut une couche de sécurité supplémentaire.

Mettre une console GTB, un serveur d’administration, ou un accès distant directement sur Internet, c’est accepter un fait : quelqu’un tentera.

• Vulnérabilité exploitable
• Identifiants récupérés par phishing
• Bruteforce sur des comptes faibles
• Accès via un prestataire

Dans beaucoup de cas, la mesure de base est connue (et souvent recommandée par les fournisseurs eux-mêmes) : placer l’accès derrière un VPN ou une passerelle d’accès sécurisée, avec MFA et journalisation.

Et pourtant, comme pour les serveurs RDP encore exposés sans MFA, on continue d’en trouver.

Là où l’IA change la donne : voir l’angle mort avant l’attaque

Réponse directe : l’IA aide à détecter des expositions, des comportements anormaux et des risques hérités que les contrôles classiques ratent.

Dans notre série “Intelligence artificielle dans la cybersécurité”, on insiste sur un point : l’IA n’est pas un gadget, c’est une capacité d’observation et de corrélation à l’échelle.

Sur les bâtiments connectés, l’IA est particulièrement utile parce que l’environnement est :

• hétérogène (automates, passerelles, serveurs Windows/Linux, protocoles OT)
• longue durée (matériel ancien, cycles de patch irréguliers)
• difficile à tester (arrêter un automate ou un système HVAC n’est pas anodin)

1) Découvrir ce qui est réellement exposé (attaque surface management)

Réponse directe : avant de sécuriser, il faut voir.

Une organisation mature sait répondre, sans hésiter :

• Quels systèmes OT/GTB sont joignables depuis Internet ?
• Sur quelles IP, quels ports, quels certificats, quelles versions ?
• Quels prestataires ont des accès ?

Les approches assistées par IA (et automatisation) permettent de cartographier en continu l’exposition externe et de repérer des dérives : une nouvelle interface web d’administration, un port ouvert “temporairement”, un sous-domaine oublié.

2) Détecter l’anomalie opérationnelle (et pas seulement l’attaque)

Réponse directe : en OT, l’anomalie fonctionnelle est souvent le premier signal.

Les modèles d’IA appliqués aux logs, aux flux réseau et aux télémétries OT peuvent apprendre des profils “normaux” : plages horaires, séquences de commandes, volumes, relations entre équipements.

Exemples d’alertes utiles :

• Changement de consigne de température hors plage habituelle
• Commandes répétées sur des portes/alarme en dehors des horaires
• Connexion d’un poste d’ingénierie depuis un pays ou un ASN atypique
• Utilisation d’un protocole OT sur un segment réseau où il n’apparaît jamais

Le bénéfice concret : réduire le délai de détection. Dans les incidents OT, chaque heure compte, parce que l’impact est souvent physique et immédiat.

3) Prioriser les vulnérabilités “qui comptent”

Réponse directe : la criticité dépend du contexte, pas uniquement du score CVSS.

La cybersécurité des systèmes de bâtiment souffre d’une réalité : même si une vulnérabilité est connue, patcher peut être lent, parfois impossible sans arrêt, validation ou dépendance fournisseur.

L’IA peut aider à faire ce tri pragmatique :

• vulnérabilité + exposition Internet + privilèges élevés = priorité maximale
• vulnérabilité + accès VPN + segmentation stricte = priorité relative
• vulnérabilité sur composant non utilisé = surveillance renforcée

L’objectif n’est pas de “tout patcher vite” (souvent irréaliste), mais de réduire le risque réel.

Une stratégie simple et efficace pour sécuriser GTB/OT en 2026

Réponse directe : combinez isolation, accès fort, supervision et remédiation structurée.

Voici une approche que je recommande souvent, parce qu’elle fonctionne même quand le parc est ancien.

1) Mettre fin aux accès directs Internet (immédiatement)

• Supprimer les consoles d’administration exposées
• Forcer un accès via VPN ou passerelle ZTNA, avec MFA
• Limiter par IP, par horaires, par profils (surtout pour les prestataires)

2) Segmenter OT/GTB du SI (et contrôler les flux)

• VLAN dédiés, règles strictes est-ouest
• Bastion d’administration, comptes nominatifs
• Journalisation centralisée (SIEM) et rétention adaptée

3) Exiger une hygiène “fusion-acquisition” côté logiciel

Le cas présenté à Black Hat Europe est un rappel brutal : les rachats empilent du code.

Pour les organisations qui achètent (ou intègrent) des solutions bâtiment :

• demander un inventaire composants (SBOM) quand c’est possible
• imposer des audits de sécurité post-intégration
• contractualiser des SLA de patch et des fenêtres de maintenance

4) Ajouter une couche IA côté détection et réponse

• Détection d’anomalies réseau OT
• Corrélation SIEM + signaux OT (température, événements d’accès, alarmes)
• Playbooks de réponse : isoler un segment, couper un accès prestataire, basculer en mode manuel

Une bonne IA en cybersécurité ne “remplace” pas l’équipe : elle l’empêche d’être aveugle.

Questions que vos équipes devraient trancher dès janvier

Réponse directe : si vous ne pouvez pas répondre, vous avez probablement un angle mort.

• Qui est responsable de la cybersécurité de la GTB : DSI, RSSI, services généraux, prestataire ?
• A-t-on un inventaire à jour des équipements et logiciels GTB/OT ?
• Existe-t-il des accès distants prestataires ? Sont-ils MFA, journalisés, limités ?
• Quels systèmes critiques (serveur, laboratoire, production) dépendent du bâtiment ?
• Quel est le plan de continuité si la GTB doit être isolée d’urgence ?

Ces questions ne sont pas théoriques. En période hivernale (décembre), le chauffage, la ventilation et la gestion énergétique sont en charge maximale. Un incident sur la GTB en plein pic d’activité, c’est l’assurance de décisions sous stress.

Le point de vue à retenir : l’IA est un amplificateur de discipline

Les systèmes de bâtiment connectés illustrent parfaitement un paradoxe moderne : on ajoute du numérique pour optimiser (énergie, confort, supervision), puis on découvre que l’optimisation a créé une surface d’attaque.

La réponse n’est pas de “déconnecter” par réflexe. La réponse, c’est une approche structurée : réduire l’exposition, durcir les accès, segmenter, auditer, et utiliser l’IA pour repérer ce que l’humain ne peut pas suivre en continu.

Si vous deviez retenir une seule règle : un système qui n’a pas été conçu pour Internet ne doit pas se retrouver joignable depuis Internet. L’IA, elle, sert à vérifier que cette règle reste vraie, jour après jour.

Vous voulez savoir si vos bâtiments (ou ceux de vos sites publics/privés) ont une exposition invisible ? La prochaine bonne question n’est pas “Sommes-nous patchés ?”, mais : “Qu’est-ce qui est accessible, par qui, et avec quel niveau de preuve ?”