Sécuriser les bâtiments connectés avec l’IA, enfin

Un chiffre suffit à poser le décor : lors de Black Hat Europe 2025, un chercheur a expliqué qu’un seul éditeur de système de gestion technique du bâtiment (GTB/BMS) est déployé dans plus de 1 000 bâtiments… tout en s’appuyant sur une plateforme logicielle cumulant une longue liste de failles et, pire, exposée sur des adresses IP publiques. Autrement dit : certains immeubles « intelligents » sont pilotables depuis Internet, parfois à travers une simple page de connexion.

Ce n’est pas un problème “IoT” abstrait. C’est un problème très concret de cybersécurité opérationnelle : chauffage, ventilation, climatisation, contrôle d’accès, alarmes incendie, ascenseurs, salles serveurs… Tout ce qui fait tenir une activité au quotidien. Et si vous êtes RSSI, DSI, responsable sûreté, gestionnaire immobilier ou simplement dirigeant, la question n’est pas “est-ce que ça peut arriver ?” mais quand un mauvais paramétrage, une faille ou un compte compromis deviendra votre incident.

Dans notre série « Intelligence artificielle dans la cybersécurité », ce cas est parfait : il montre une réalité souvent ignorée (les systèmes hérités), et il met en lumière ce que l’IA sait bien faire en 2025 : détecter, corréler et prioriser des signaux faibles sur des environnements hybrides (IT + OT + bâtiment) avant qu’ils ne se transforment en crise.

Le vrai scandale : des systèmes “pas faits pour Internet” en façade

La leçon la plus importante de la conférence n’est pas “il y a des vulnérabilités”. Des vulnérabilités, il y en aura toujours. La leçon, c’est celle-ci : certains équipements n’ont jamais été conçus pour être accessibles depuis Internet.

On l’a déjà vu dans les systèmes industriels (ICS) : des protocoles historiques, prévus pour des réseaux fermés, se retrouvent routés, NATés, exposés. Le bâtiment suit la même pente. Une GTB n’est pas un site e-commerce : elle n’a pas été pensée pour encaisser des scans automatisés, des tentatives de brute force, des attaques par chaînes de vulnérabilités (RCE, élévation de privilèges, rebonds internes), ou des détournements d’authentification.

“On mettra ça derrière un VPN” : nécessaire, mais insuffisant

Dans le cas présenté à Black Hat, le fournisseur recommande de placer la solution derrière un VPN. C’est un bon réflexe : réduire la surface d’exposition, imposer une authentification forte, limiter l’accès.

Mais dans les faits, on rencontre souvent :

• des VPN partagés entre prestataires, sans segmentation fine ;
• des exceptions temporaires qui deviennent permanentes (« juste pour le chantier ») ;
• des accès “à la demande” non journalisés ;
• des comptes techniques qui ne changent jamais.

Le VPN est une ceinture. Il ne remplace pas les freins : durcissement, gestion des identités, segmentation réseau, surveillance, et traitement des vulnérabilités.

Pourquoi les bâtiments deviennent des cibles : effet “Mission: Impossible”… mais réaliste

Voici ce qui rend la GTB dangereuse quand elle est compromise : l’impact est physique.

Un attaquant qui prend la main sur une partie de la gestion du bâtiment peut :

• dégrader une salle serveur en modifiant la température ou la ventilation (arrêt de services, vieillissement accéléré, pannes) ;
• déverrouiller des portes via des scénarios incendie ou des automatismes mal isolés ;
• perturber des zones sensibles (laboratoires, archives, salles blanches) ;
• créer un brouillard opérationnel (alarmes, capteurs, faux positifs) pour couvrir une intrusion.

Ce n’est pas de la science-fiction. C’est le résultat classique d’un système conçu pour l’efficacité (supervision centralisée) mais administré comme un sous-projet (prestataire, contrat, “ça marche donc on n’y touche pas”).

Le facteur humain et contractuel : propriétaire vs locataire

Un point souvent sous-estimé : qui porte le risque, qui contrôle la solution ?

Dans beaucoup d’immeubles, la GTB appartient au bailleur ou au gestionnaire, tandis que l’entreprise locataire supporte le risque business (arrêt d’activité, fuite, sûreté). Résultat : personne n’a une vision complète, et la cybersécurité “bâtiment” reste hors radar.

Ma position est simple : un bâtiment connecté fait partie du SI étendu. Il mérite les mêmes exigences qu’un outil métier critique.

L’angle M&A : 18 ans de code qui survivent à tout… sauf aux attaques

Le talk évoque une cause fréquente en environnement critique : une faille dont l’origine remonte à un firmware vieux de 18 ans, traîné au fil de rachats et d’intégrations, sans audit de sécurité sérieux.

Les fusions-acquisitions (M&A) créent un cocktail explosif :

• empilement de composants “legacy” ;
• dette technique acceptée pour tenir les délais ;
• documentation incomplète ;
• responsabilités floues entre équipes ;
• patchs correctifs qui traitent les symptômes, pas la racine.

Le résultat ? Des corrections successives qui colmatent une vulnérabilité… tout en laissant le défaut structurel intact, donc prêt à ressortir sous une autre forme.

Où l’IA devient utile, concrètement

L’IA ne remplace pas un audit de code, ni une refonte d’architecture. En revanche, elle change la donne sur trois points très pratiques :

1. Découverte d’actifs : cartographier ce qui existe réellement (versions, services, dépendances, expositions) dans un parc hétérogène.
2. Priorisation du risque : trier les vulnérabilités “théoriques” de celles qui sont exploitables dans votre contexte (exposition Internet, chemin d’attaque, privilèges obtenus).
3. Détection de signaux faibles : identifier des comportements anormaux (accès de maintenance à 03h12, changement de consigne, lecture/écriture inhabituelle, latéralisation).

On gagne du temps là où l’humain se noie : trop d’alertes, trop d’inventaire, trop d’exceptions.

Comment l’IA protège une GTB : une approche “Answer First”

Réponse directe : l’IA protège une GTB en réduisant la surface d’attaque, en détectant les anomalies plus tôt et en accélérant la remédiation. Voici comment le traduire en actions réalistes.

1) Découvrir et classifier les systèmes exposés

Le premier risque, c’est l’inconnu. Une IA de cybersécurité (souvent via des capacités ASM/CAASM) peut :

• détecter des interfaces GTB accessibles depuis Internet ;
• identifier des signatures de produits/versions ;
• relever les ports/protocoles anormaux ;
• repérer des “shadow assets” créés par un prestataire.

Objectif mesurable : passer de “on pense que” à “on sait que”, avec une liste d’actifs, propriétaires, et chemins d’accès.

2) Corréler vulnérabilités + exposition + identité

Une CVE n’a pas le même poids si le service est interne, derrière une segmentation stricte, avec MFA et journalisation, versus accessible publiquement.

Les moteurs IA modernes corrèlent :

• vulnérabilités connues,
• configuration réelle (exposition, chiffrement, authentification),
• identité (comptes, rôles, accès prestataires),
• télémétrie (logs, flux réseau, comportements).

Phrase “snippet” : Une vulnérabilité devient critique quand elle rencontre une exposition et une identité faible.

3) Détecter les comportements impossibles

Sur une GTB, les opérations normales sont assez répétitives. C’est une excellente nouvelle pour la détection par IA.

Exemples d’anomalies hautement pertinentes :

• connexion d’un compte maintenance depuis un pays non attendu ;
• changement de consigne (température/pression) en dehors des horaires ;
• rafales de requêtes sur une interface web d’administration ;
• transfert inhabituel entre réseau GTB et réseau bureautique.

Le bon réflexe : ne cherchez pas 100% de visibilité parfaite. Cherchez 10 alertes vraiment actionnables.

4) Accélérer la réponse : du ticket à l’action contrôlée

Là où beaucoup d’organisations échouent : elles détectent… puis elles attendent.

Une stratégie IA utile, c’est :

• playbooks de réponse (isoler un segment, révoquer un accès, forcer MFA, fermer un port) ;
• gestion du changement (ne pas casser l’exploitation du bâtiment) ;
• traçabilité (qui a fait quoi, quand, pourquoi).

L’automatisation doit rester prudente en OT/bâtiment : on privilégie l’isolement réseau et la fermeture d’accès externes plutôt que l’arrêt brutal d’équipements.

Mesures prioritaires (sans budget “smart city”)

Réponse directe : vous réduisez 80% du risque GTB en appliquant 8 mesures. J’ai vu ces actions fonctionner même dans des contextes multi-sites et multi-prestataires.

1. Interdire l’exposition Internet des consoles GTB (principe : pas d’interface d’admin sur IP publique).
2. Accès distant via VPN + MFA, et idéalement via bastion (session enregistrée).
3. Segmentation réseau : GTB séparée du réseau bureautique, règles strictes, flux minimaux.
4. Inventaire à jour (actifs, versions, prestataires, contrats, fenêtres de maintenance).
5. Gestion des identités : comptes nominatifs, suppression des comptes partagés, rotation des secrets.
6. Patch management réaliste : cadence trimestrielle minimum + exceptions documentées.
7. Journalisation et supervision : logs centralisés, alertes sur actions sensibles.
8. Audit post-incident / post-divulgation : corriger la cause racine, pas juste le symptôme.

Une règle simple : si contourner l’écran de connexion donne accès direct à l’exploitation, il manque une couche de sécurité.

FAQ rapide (les questions qu’on me pose toujours)

“Notre GTB est gérée par un prestataire : on est couverts ?”

Non. Vous déléguez l’exploitation, pas la responsabilité du risque. Exigez des preuves : segmentation, MFA, journaux, comptes, procédure de patch.

“On ne peut pas patcher souvent, c’est trop risqué.”

Alors investissez dans la réduction d’exposition (VPN/bastion), la segmentation et la détection d’anomalies. Le risque n’est pas binaire : on peut le réduire sans tout casser.

“L’IA, c’est pour les grandes entreprises seulement.”

Faux en 2025. Les briques d’ASM, de détection comportementale et de priorisation existent aussi en mode service. Le vrai sujet, c’est la gouvernance : qui reçoit l’alerte et qui agit.

Ce que Black Hat Europe 2025 devrait changer dans vos priorités

La cyber des bâtiments connectés n’est plus un sujet “facility”. C’est un sujet cyber-risque au même titre que l’AD, la messagerie ou le cloud. Et le fait que des plateformes héritées se retrouvent exposées suite à des années d’acquisitions devrait vous pousser à durcir votre propre approche M&A : audit sécurité systématique, inventaire, plan de remédiation, et surveillance continue.

L’IA a un rôle clair dans cette équation : voir plus large (inventaire), comprendre plus vite (corrélation), agir plus tôt (détection + réponse). Pas pour faire joli dans une slide. Pour éviter le scénario le plus bête : une console GTB publique, un vieux firmware, et une intrusion qui commence par “juste un accès de maintenance”.

Si vous deviez lancer une seule action la semaine prochaine : faites la chasse aux accès GTB exposés, puis mettez en place une surveillance qui sait distinguer un prestataire légitime d’un attaquant patient.

La question qui reste, et qui vaut un atelier interne : quels systèmes, dans vos bâtiments, n’ont jamais été conçus pour Internet… mais y sont quand même ?