Les tableaux de bord d’IA de haute technologie ne sont que des illusions coûteuses s’ils ignorent la technologie héritée non corrigée qui maintient en vie l’ensemble de votre chaîne de production.
J’ai passé deux jours dans une sous-station reliant un important parc éolien offshore au réseau. La salle de contrôle comprenait trois nouveaux tableaux de bord prêts pour l’IA et un mandat du conseil d’administration visant à « tirer parti de l’apprentissage automatique pour la résilience ». Il y avait également un ordinateur portable de maintenance fonctionnant sous Windows 7, littéralement scotché à l’intérieur d’une armoire parce que le Velcro était tombé en panne.
Cet ordinateur portable était le seul appareil du bâtiment capable de communiquer avec les anciens relais de protection qui gardaient la connexion au réseau. Aucun correctif depuis 2017. Pas d’EDR. Aucun chemin vers un modèle de sécurité basé sur un agent.
J’ai découvert une certaine version de cette scène dans des services publics d’énergie, des usines automobiles et des sites pharmaceutiques, dans tous les secteurs et dans tous les pays, depuis une décennie. Les tableaux de bord changent ; l’ordinateur portable « oublié » reste. Il s’agit d’un énorme déficit de visibilité qu’aucun grand modèle linguistique ne peut combler. Selon le rapport Dragos OT Cybersecurity Year in Review 2026, moins de 10 % des réseaux OT dans le monde disposent actuellement d’une surveillance réseau significative. Dans 30 % des cas de réponse aux incidents de l’année dernière, les enquêtes ont commencé non pas par une alerte de détection, mais par une personne dans l’usine remarquant que « quelque chose ne semblait pas normal ».
Si vous êtes un dirigeant de niveau C qui planifie une stratégie de sécurité basée sur l’IA, vous devez comprendre : votre stratégie n’échouera pas parce que l’IA n’est pas assez intelligente. Il échouera car votre télémétrie la plus critique ne l’atteindra jamais.
La triade inversée de la CIA : là où l’IA hallucine le risque
En informatique, nous priorisons la confidentialité, l’intégrité et la disponibilité. En OT – technologie opérationnelle – la triade est inversée : la disponibilité est primordiale.
C’est dans cette inversion que les outils de sécurité basés sur l’IA se brisent discrètement. Un modèle formé à la télémétrie d’entreprise (journaux d’événements HTTP, DNS et Windows) examinera un segment Modbus ou PROFINET et signalera le trafic industriel parfaitement normal comme une anomalie. Si cette IA est intégrée à un playbook de réponse automatisé, vous avez construit un système capable d’arrêter une ligne de production plus rapidement que n’importe quel pirate informatique.
Lors d’une simulation que j’ai réalisée pour un équipementier automobile de premier rang, j’ai observé une plateforme SOAR tenter exactement cela. Le responsable informatique a été enthousiasmé par le « temps de réponse en millisecondes ». Le directeur de l’usine est devenu gris lorsqu’il a réalisé que l’IA venait de simuler un événement de temps d’arrêt à six chiffres par heure en isolant un API critique. Dans le monde industriel, une commande automatisée « isoler l’hôte » est souvent impossible à distinguer d’une attaque par déni de service.
Surveillance passive ou piquer le contrôleur
Lorsque j’ai évalué des plateformes de surveillance OT comme Nozomi Networks, Claroty ou Microsoft Defender for IoT, les différences techniques importaient souvent moins qu’une question critique : cet outil nécessite-t-il des requêtes actives ?
Dans une salle de conférence, le « scanning actif » semble efficace. Dans une usine en fonctionnement, pousser un Siemens S7-300 de 15 ans ou un contrôleur Rockwell Automation pour extraire des métadonnées peut provoquer un crash de l’appareil. J’ai vu la moitié d’une liste restreinte éliminée parce que les moteurs d’IA des fournisseurs nécessitaient une interrogation active que le directeur des opérations refusait d’approuver.
Pour que l’IA fonctionne en OT, elle doit être alimentée par une surveillance passive du réseau. Vous avez besoin du trafic brut des niveaux 0 à 2 de l’architecture de référence Purdue Enterprise, le modèle en couches qui définit la frontière entre les systèmes informatiques et opérationnels. Sans cette télémétrie, vous effectuez une modélisation linguistique sur un corpus vide. Vous ne voyez pas les protocoles S7Comm ou DNP3 qui gèrent réellement le monde physique.
Les joyaux de la couronne sont plus simples que vous ne le pensez
Les projets que je vois réussir ne commencent pas par une feuille de route de 300 pages pour l’IA. Ils commencent par une concentration impitoyable sur ce que j’appelle les joyaux de la couronne.
Je pose toujours la même question aux directeurs d’usine : quels sont les trois processus que vous ne pouvez absolument pas vous permettre de perdre ne serait-ce qu’une heure ? Dans un service public d’électricité, ce n’est pas le système de facturation qui compte ; ce sont les relais de protection. Sur un site pharmaceutique, il s’agit d’une seule ligne de fermentation. Dans une usine automobile, c’est la cellule de soudage qui alimente l’ensemble de l’atelier de carrosserie.
Une fois ces éléments identifiés, le champ d’application de l’IA passe de « tout » à « les choses qui comptent ». Nous appliquons ensuite des correctifs virtuels pour protéger les machines Windows 7 non patchables et segmentons le réseau afin que la machine à café intelligente de la salle de repos – qui reçoit plus de mises à jour de sécurité que les robots industriels – ne puisse pas atteindre l’interface homme-machine.
Voici ce qui surprend la plupart des DSI : la liste des joyaux de la couronne est presque toujours plus courte que ce que prédit l’équipe de sécurité et presque toujours plus longue que ce que l’équipe des opérations admet. Sur un site sur lequel j’ai travaillé l’année dernière, la sécurité avait dénombré 47 systèmes « critiques » sur une feuille de calcul. Le directeur de l’usine, après vingt minutes de conversation honnête, en a nommé six. Les 41 autres étaient importants, mais ils ne constituaient pas des joyaux de la couronne. Ils n’avaient pas besoin d’une détection d’anomalies en temps réel basée sur l’IA. Ils avaient besoin de rapports de conformité mensuels. La combinaison de ces deux exigences explique comment les budgets de sécurité des OT sont dépensés sans réduction mesurable des risques.
Le changement de culture : du phishing à la physique
L’atelier le plus productif que j’ai organisé cette année n’impliquait pas un seul fournisseur d’IA. Il s’agissait d’un exercice théorique retraçant le chemin d’un ransomware depuis un e-mail de phishing jusqu’à la clé USB d’un entrepreneur, puis jusqu’à l’ordinateur portable de maintenance et enfin aux automates.
Nous l’avons cartographié minute par minute. Minute zéro : un commis aux achats ouvre une pièce jointe à une facture. Huitième minute : le malware atteint l’ordinateur portable de l’entrepreneur sur le réseau du bureau. Quatorzième minute : l’entrepreneur branche le même ordinateur portable sur le VLAN de maintenance pour mettre à jour le firmware de l’IHM, comme il le fait tous les mardis. Vingt-troisième minute : le ransomware crypte le poste d’ingénierie. Trente et un minutes : les opérateurs remarquent que les écrans s’assombrissent, mais la production continue de fonctionner sur les automates eux-mêmes, car les contrôleurs OT n’ont pas besoin de Windows pour faire leur travail. L’illusion de normalité dure près d’une heure. Ensuite, quelqu’un essaie de pousser un changement de point de consigne, et rien ne se passe.
C’est à ce moment-là que la pièce a changé. Le chef de production avait passé la matinée à demander pourquoi nous avions besoin d’un énième projet de sécurité. Il demandait maintenant combien de temps il leur faudrait pour détecter la huitième minute, avant que l’ordinateur portable de l’entrepreneur ne touche le réseau de maintenance. Le responsable informatique, qui défendait depuis des années son rituel du « patch Tuesday à 2 heures du matin », a enfin compris pourquoi ce rituel est impossible dans un établissement qui fonctionne 24h/24 et 7j/7. Différents vocabulaires, même problème.
Pour la première fois lors d’une réunion sur ce site, un responsable OT et un responsable informatique ont quitté la salle avec une chronologie commune des incidents plutôt qu’une carte commune des responsabilités. Voilà à quoi ressemble réellement le changement de culture en matière de sécurité industrielle : non pas un document politique, mais une table de travail suffisamment précise pour que personne ne puisse se cacher derrière son propre jargon.
Conclusion pour les DSI et les OSC
Alors que des acteurs étatiques comme Volt Typhoon utilisent de plus en plus des techniques de « vivre de la terre » pour s’intégrer dans des infrastructures critiques, comme le détaillent les récents avis de la CISA, le luxe d’ignorer les usines a disparu. L’IA peut nous aider à détecter ces menaces, mais seulement si la télémétrie est réelle. Si vous souhaitez que l’IA apporte une réelle valeur commerciale dans les environnements industriels, l’ordre des opérations n’est pas négociable.
Tout d’abord, faites l’inventaire : cartographiez le sol, pas les diapositives. Deuxièmement, la segmentation : supprimez les routes allant de la salle de repos au PLC. Troisièmement, la télémétrie passive : alimentez l’IA avec de véritables protocoles industriels des niveaux Purdue 0 à 2. Ensuite, et alors seulement, superposez le modèle de langage par-dessus.
Ignorez-les et vous aurez créé un tableau de bord très coûteux pour un réseau que vous ne pouvez toujours pas voir.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
