Alerte IA de Robert M. Lee : les infrastructures critiques adoptent l’IA plus vite qu’elles ne peuvent en percevoir les risques

Robert M. Lee a lancé une alerte sur l’IA après que Dragos a constaté que seulement 30 % des réseaux de technologie opérationnelle disposaient d’une visibilité sur leurs environnements. L’alerte IA de Robert M. Lee cible un conflit grandissant au sein des services publics, des usines, des centres de données et des systèmes énergétiques. Les opérateurs ajoutent des logiciels autonomes avant que nombre d’entre eux puissent observer de manière fiable leurs équipements existants.

Lee, PDG et cofondateur de Dragos, affirme que l’adoption de l’IA progresse plus vite que la surveillance de la sécurité dans les environnements de technologie opérationnelle. La technologie opérationnelle, ou OT, comprend le matériel et les logiciels qui contrôlent les processus physiques. Contrairement à une application bureautique classique, une défaillance OT peut interrompre l’électricité, l’approvisionnement en eau, la production industrielle, les transports ou un autre service essentiel.

Il ne s’agit pas simplement d’un nouvel avertissement sur l’usage de l’IA par les criminels. Le problème plus difficile vient de l’intégration de l’IA dans des environnements qui contiennent déjà des équipements anciens, des inventaires incomplets et une surveillance insuffisante. L’IA peut améliorer les prévisions et l’efficacité, mais elle peut aussi masquer les raisons pour lesquelles un processus physique a changé.

Ce compromis place les opérateurs d’infrastructures entre la pression en faveur d’une automatisation plus rapide et la discipline d’ingénierie requise pour des opérations sûres. Les attaquants étudient également les systèmes de contrôle de plus près. La course n’oppose donc pas l’adoption de l’IA à la résistance face à la technologie. Elle oppose l’automatisation rapide à la visibilité opérationnelle.

L’avertissement de Lee déplace le débat sur l’IA vers les opérations physiques

Le changement important est que l’IA passe d’outils d’aide à la décision à des systèmes capables d’influencer les processus physiques.

Lee a présenté son argumentation dans une analyse des infrastructures du 11 septembre 2026 publiée par le Forum économique mondial. Il a décrit des applications d’IA entrant dans les usines de fabrication, les réseaux électriques, les centres de données, les parcs de batteries, les sites d’énergie renouvelable et les exploitations minières.

Certains déploiements aident encore les personnes à examiner les données ou à prévoir les besoins de maintenance. D’autres se rapprochent de la boucle de contrôle, le processus de rétroaction reliant les capteurs, les décisions et les équipements physiques. Cette évolution modifie les conséquences possibles d’une erreur.

Une recommandation erronée dans un tableau de bord peut être examinée avant toute action. Un contrôleur automatisé peut modifier le comportement d’un équipement avant qu’un opérateur ne comprenne le raisonnement. Une plus grande autonomie réduit la distance entre la sortie d’un modèle et un résultat physique.

Les conseils d’administration et les dirigeants ont de solides raisons de poursuivre ces systèmes. L’IA peut aider à prévoir la demande, optimiser l’utilisation de l’énergie, détecter les comportements anormaux des équipements et prioriser la maintenance. Les opérateurs d’infrastructures sont également confrontés à des pénuries de personnel, à des équipements vieillissants et à des exigences accrues d’efficacité.

Ces avantages créent une pression pour raccourcir les calendriers de validation. Lee avertit que cette même pression peut réduire l’examen des nouveaux fournisseurs et accroître la complexité des systèmes. L’organisation gagne une couche de décision supplémentaire alors que son équipe de sécurité peut toujours manquer d’un inventaire complet des actifs.

Les systèmes sous-jacents ont déjà connu plusieurs transitions technologiques. Les contrôles mécaniques sont devenus des systèmes numériques. Les réseaux industriels isolés ont été connectés aux réseaux d’entreprise, aux services distants et aux appareils utilisant le protocole Internet.

Chaque transition a créé des capacités utiles et de nouvelles dépendances. De nombreuses organisations n’ont pas atteint une visibilité complète avant l’arrivée de la transition suivante. L’IA entre désormais dans cet environnement inachevé.

Le risque ne se limite pas à un modèle qui produit une réponse incorrecte. Le modèle peut dépendre de données externes, de services cloud, d’interfaces de programmation d’applications ou de mises à jour de fournisseurs. Chaque dépendance crée un nouveau chemin de défaillance que les opérateurs doivent comprendre.

Un service d’IA pourrait disparaître lors d’une défaillance de fournisseur ou d’une correction du marché. Une mise à jour de modèle pourrait modifier un comportement que les ingénieurs avaient précédemment testé. Des données compromises pourraient fausser les recommandations sans produire d’erreur logicielle manifeste.

Les infrastructures critiques ne peuvent pas traiter ces possibilités comme une indisponibilité ordinaire d’application. Les opérateurs doivent préserver des états sûrs, des procédures manuelles et des éléments de preuve fiables pour les enquêtes sur les incidents. L’alerte IA de Robert M. Lee place ces exigences opérationnelles au centre du débat.

Lee ne demande pas aux propriétaires d’infrastructures de rejeter l’IA. Il soutient que la gouvernance, la visibilité et la planification des défaillances doivent précéder une autonomie plus poussée. Dans le cas contraire, l’adoption peut accroître l’incertitude au sein de systèmes où celle-ci entraîne déjà des conséquences physiques.

Le risque IA pour les infrastructures selon Dragos commence par un manque de visibilité

L’IA ne crée pas toutes les faiblesses des infrastructures, mais elle peut multiplier les conséquences de faiblesses que les défenseurs ne peuvent pas voir.

Les conclusions sur les menaces de 2026 qui sous-tendent l’argument de Lee décrivent une grave lacune de visibilité. Dragos indique que seulement 30 % des réseaux OT évalués disposaient d’une visibilité suffisante sur leurs environnements. L’entreprise rapporte également que 56 % ne pouvaient pas voir au-delà de la frontière entre l’IT et l’OT.

L’entreprise affirme que 88 % rencontraient des difficultés en matière de détection et de réponse. Ces chiffres proviennent de Dragos, un fournisseur de sécurité OT, et non d’un recensement gouvernemental indépendant. Ils doivent être considérés comme des conclusions tirées des clients, des enquêtes et de la télémétrie de l’entreprise.

Même avec cette limite, le schéma observé est important. Une organisation ne peut pas protéger les actifs qu’elle n’a pas identifiés. Elle ne peut pas non plus enquêter sur une activité suspecte lorsque le trafic réseau, les modifications de contrôleurs et les actions d’ingénierie n’ont jamais été enregistrés.

Cela crée un risque IA distinct pour les infrastructures selon Dragos. Les nouveaux systèmes d’IA peuvent ajouter des flux de données, des composants logiciels, des identifiants et des connexions externes. Ils peuvent aussi prendre des décisions sur des équipements qui utilisent des protocoles industriels spécialisés.

La surveillance IT traditionnelle n’interprète pas toujours ces protocoles ou ces processus physiques. Une équipe de sécurité d’entreprise peut détecter une connexion inhabituelle sans comprendre si elle a modifié une pompe, un relais, une turbine ou une ligne de production. La surveillance native OT relie l’activité cybernétique au comportement attendu des équipements.

Dragos indique que les organisations dotées d’une visibilité OT complète ont détecté et contenu les incidents de ransomware en cinq jours en moyenne. Lee a comparé ce chiffre à une moyenne de 42 jours à l’échelle du secteur. Cette comparaison suggère que la visibilité peut réduire de manière significative la fenêtre d’action d’un attaquant.

Elle n’établit toutefois pas que la surveillance seule a causé cette différence. Les organisations disposant d’une visibilité plus large peuvent également bénéficier de meilleurs effectifs, d’une meilleure segmentation, de plans d’incident et d’un soutien des dirigeants. Les chiffres montrent une association qui mérite l’attention, et non une garantie universelle de performance.

Le problème de visibilité devient plus difficile lorsque l’IA introduit des décisions probabilistes plutôt que déterministes. La logique de contrôle traditionnelle suit généralement des règles définies que les ingénieurs peuvent inspecter. Un système d’apprentissage automatique peut répondre différemment lorsque ses entrées, son modèle ou son contexte environnant changent.

Cette variabilité ne rend pas automatiquement l’IA dangereuse. Elle rend les tests et la documentation plus exigeants. Les opérateurs ont besoin de registres indiquant quelle version de modèle a été exécutée, quelles données elle a reçues, quelle action elle a recommandée et si une personne l’a approuvée.

Ils doivent également distinguer le comportement du modèle d’une interférence malveillante. Une action inattendue peut provenir de données corrompues, d’un compte compromis, d’une instruction dangereuse, d’un défaut logiciel ou d’une variation normale du modèle. Sans journalisation suffisante, ces scénarios peuvent sembler identiques.

Les organisations d’infrastructures doivent donc cartographier chaque dépendance à l’IA avant de lui attribuer une autorité opérationnelle. Cette cartographie comprend les données d’entraînement et opérationnelles, les fournisseurs de modèles, les services cloud, les intégrations, les utilisateurs, les identifiants, les canaux de mise à jour et les actifs physiques concernés.

Ce travail ressemble à la création d’une base de connaissances techniques consultable, mais les exigences sont plus strictes. Les équipes ont besoin de dossiers contrôlés, de responsabilités claires et de procédures de récupération testées. Une base de connaissances d’ingénierie plus large peut soutenir la documentation, mais elle ne remplace pas la surveillance de sécurité OT.

La visibilité a également une dimension humaine. Les opérateurs doivent savoir quand l’automatisation est active et quelle autorité elle détient. Les équipes de sécurité doivent posséder suffisamment de connaissances sur les processus pour reconnaître lorsqu’une commande techniquement valide crée un état physique dangereux.

L’objectif n’est pas d’enregistrer davantage de données sans finalité. Il s’agit de conserver suffisamment de contexte pour la détection, l’intervention et l’analyse des causes profondes. La sécurité des infrastructures critiques face à l’IA dépend de ces éléments de preuve tout au long de la durée de fonctionnement du système.

Les attaquants cartographient les mêmes boucles de contrôle que l’IA intégrera

Les opérateurs d’infrastructures ajoutent de l’intelligence aux environnements de contrôle tandis que les adversaires apprennent comment ces environnements fonctionnent.

Dragos rapporte avoir suivi 26 groupes de menaces OT durant son cycle de rapport de 2026. L’entreprise affirme que les adversaires sont allés au-delà de l’accès de base et ont commencé à cartographier les boucles de contrôle. Ce travail incluait l’identification des postes de travail d’ingénierie et la collecte de fichiers de configuration ou de données d’alarme.

Un fichier de configuration peut révéler comment les équipements industriels communiquent et quelles limites régissent un processus. Les données d’alarme peuvent indiquer ce que les opérateurs considèrent comme anormal. Les postes de travail d’ingénierie fournissent souvent un accès privilégié aux contrôleurs et à d’autres actifs sensibles.

Cette reconnaissance est importante, car perturber un processus physique exige davantage que l’entrée dans un réseau. Les attaquants doivent comprendre les équipements, la synchronisation, les contrôles de sécurité et les dépendances opérationnelles. Une cartographie détaillée réduit cette barrière de connaissance.

Lee a cité ELECTRUM et KAMACITE comme exemples de groupes cherchant à acquérir cette compréhension plus approfondie. Il a déclaré que KAMACITE avait passé des mois à cartographier des boucles de contrôle au sein d’infrastructures américaines. ELECTRUM avait auparavant ciblé le réseau électrique ukrainien et continuait à développer des capacités contre les systèmes énergétiques.

Selon Lee, ELECTRUM a attaqué des ressources énergétiques distribuées en Pologne en décembre 2025. Ces ressources comprenaient des systèmes de gestion des énergies renouvelables. Elles ressemblent aux environnements dans lesquels les opérateurs souhaitent de plus en plus que l’IA optimise la production et le stockage.

Cela ne signifie pas que l’IA a provoqué cet incident. Cela montre que les environnements de contrôle sous-jacents attirent déjà des adversaires compétents. L’ajout d’une automatisation mal gouvernée pourrait augmenter le nombre de composants que les attaquants peuvent étudier ou manipuler.

L’IA modifie également l’économie du travail offensif. Les modèles peuvent aider à l’analyse de code, à la reconnaissance, à la traduction, à l’examen de documentation et à la création de scripts. Ils peuvent aider des attaquants moins expérimentés à comprendre plus rapidement des équipements inconnus.

Des rapports récents suggèrent que l’IA accélère souvent des techniques existantes au lieu d’en inventer de complètement nouvelles. Les attaquants profitent toujours des appareils exposés, des identifiants par défaut, d’une segmentation insuffisante et des retards de correctifs. L’IA peut les aider à trouver et exploiter plus rapidement ces faiblesses familières.

Cette distinction évite que le récit ne dérive vers la science-fiction. Un service public n’a pas besoin d’affronter une superintelligence entièrement autonome avant de subir un danger lié à l’IA. Un groupe dirigé par des humains utilisant l’IA pour étendre une reconnaissance de routine peut créer une pression immédiate.

L’opportunité défensive est tout aussi réelle. L’IA peut aider les équipes de sécurité à prioriser les alertes, analyser de grands ensembles de données, identifier des séquences inhabituelles et retrouver du contexte technique. Ces usages peuvent être utiles lorsque des personnes qualifiées conservent l’autorité sur les actions à conséquence.

Le conflit apparaît lorsque les organisations traitent l’IA défensive comme un substitut aux contrôles fondamentaux. Un modèle d’alerte ne peut pas compenser un accès à distance non géré. L’analyse automatisée ne peut pas récupérer des journaux que l’organisation n’a jamais collectés.

Les principes de sécurité OT de la CISA mettent l’accent sur les décisions qui préservent des environnements opérationnels sûrs et sécurisés. Ces recommandations précèdent cet avertissement particulier, mais leurs priorités restent pertinentes.

Les propriétaires d’infrastructures ont toujours besoin d’inventaires précis des actifs, de configurations sécurisées, d’une segmentation réseau, d’un accès à distance contrôlé et d’une réponse aux incidents testée. L’IA doit fonctionner à l’intérieur de ces contrôles. Elle ne doit pas devenir un raccourci permettant de les contourner.

Le modèle de déploiement le plus solide confie à l’IA des responsabilités limitées et observables. Un modèle peut classer des dossiers de maintenance sans modifier directement les équipements. Il peut rédiger un résumé d’enquête pendant que des analystes vérifient ses éléments de preuve.

Les systèmes à risque plus élevé exigent des limites plus strictes. Les opérateurs peuvent restreindre les commandes, imposer des limites de sécurité déterministes, exiger une approbation humaine et isoler les fonctions critiques. Ils peuvent également tester le comportement du système lorsque les données deviennent indisponibles ou trompeuses.

Cette approche traite l’IA comme un composant d’un système de sécurité, et non comme l’opérateur incontesté du système. Elle préserve les bénéfices d’une analyse plus rapide tout en limitant le chemin qui mène d’une défaillance du modèle à une perturbation physique.

L’avertissement de Robert M. Lee sur l’IA révèle un compromis lié à l’automatisation

Le choix principal n’est pas d’utiliser ou non l’IA, mais de savoir si l’automatisation restera observable, réversible et subordonnée aux contrôles de sécurité.

L’avertissement de Robert M. Lee sur l’IA décrit un compromis que les déploiements ordinaires en entreprise peuvent masquer. Davantage d’autonomie peut réduire les charges de travail et les délais de réaction. Elle peut aussi réduire le temps dont dispose une personne pour contester une décision dangereuse.

Les opérateurs d’infrastructures gèrent depuis longtemps l’automatisation au moyen de revues d’ingénierie, de contrôles des changements, de redondance et d’une conception à sécurité intégrée. L’IA n’invalide pas ces pratiques. Elle accroît la nécessité de les appliquer avec rigueur.

Un déploiement doit commencer par un problème opérationnel clairement défini. Les équipes doivent préciser à quoi le modèle peut accéder, ce qu’il peut recommander et ce qu’il peut modifier. Elles doivent également identifier les actions que le modèle ne pourra jamais effectuer.

Ces limites doivent être appliquées techniquement. Un document de politique ne peut empêcher une intégration disposant de privilèges excessifs d’émettre des commandes. Les contrôles d’accès, l’architecture réseau et les systèmes de sécurité doivent limiter l’autorité réelle du modèle.

Les tests doivent couvrir bien plus que la précision moyenne. Les opérateurs ont besoin de scénarios impliquant des capteurs manquants, des entrées corrompues, des instructions contradictoires, des services cloud indisponibles et des états inattendus des équipements. Ils doivent tester la reprise après une défaillance du composant IA.

Le cadre de gestion des risques liés à l’IA du NIST organise le travail sur les risques autour de la gouvernance, de la cartographie, de la mesure et de la gestion. En avril 2026, le NIST a également annoncé des travaux sur un profil d’infrastructure critique pour ce cadre.

Ce profil vise à aider les opérateurs d’infrastructures à traduire les principes d’une IA digne de confiance en pratiques propres à chaque secteur. Son élaboration montre que les politiques générales sur l’IA ne suffisent pas pour les opérations physiques. L’énergie, l’eau, les transports et l’industrie manufacturière font face à des conséquences et à des contraintes différentes.

Le NIST considère également la sécurité et la résilience comme des caractéristiques fondamentales d’une IA digne de confiance. La résilience signifie qu’un système peut résister aux problèmes et se rétablir sans causer de préjudice inacceptable. Dans un déploiement industriel, cela inclut la capacité à fonctionner en toute sécurité lorsque le modèle est indisponible.

L’exploitation manuelle demeure donc un test important. Les équipes doivent savoir si le personnel peut maintenir les services essentiels après la perte d’un fournisseur d’IA, d’un point de terminaison de modèle ou d’un jeu de données de soutien. Elles ont également besoin d’estimations réalistes de la durée de ce mode de repli.

Un repli manuel qui n’existe que dans la documentation peut échouer pendant une urgence. Les opérateurs doivent l’exercer dans des conditions contrôlées. Le renouvellement du personnel, les changements d’équipement et l’automatisation croissante peuvent discrètement rendre les anciennes procédures inutilisables.

La continuité des fournisseurs crée une autre préoccupation. Un opérateur d’infrastructure peut dépendre d’une startup, d’un modèle propriétaire ou d’une intégration cloud qui évolue rapidement. Les garanties contractuelles ne peuvent pas remplacer des plans de sortie techniques.

Les organisations doivent conserver les données et les configurations nécessaires pour passer à un autre fournisseur. Elles doivent comprendre quelles fonctions s’arrêtent lorsqu’un service disparaît. Elles ont aussi besoin de contrôles concernant les mises à jour susceptibles de modifier un comportement validé.

La gouvernance des données doit faire partie du même plan opérationnel. Les outils d’IA peuvent exposer des détails sensibles sur le réseau, la documentation des équipements ou des informations sur les incidents lorsque les équipes soumettent du matériel à des services externes. Des prompts non contrôlés peuvent devenir une autre voie d’exfiltration de données.

Un flux de travail informationnel gouverné peut aider les équipes à organiser les contenus approuvés et à réduire les traitements dispersés. Les opérateurs d’infrastructures critiques ont toujours besoin de contrôles propres à leur secteur régissant la classification, la conservation, l’accès et le traitement externe.

La question sceptique est de savoir si les fournisseurs et les opérateurs peuvent valider des modèles qui évoluent rapidement avec la rigueur attendue pour des équipements industriels conçus pour durer. Les modèles peuvent être mis à jour chaque mois alors que les systèmes de contrôle restent déployés pendant des décennies. Ces échéances ne s’alignent pas naturellement.

Aucun cadre ne peut éliminer cette incompatibilité. Les opérateurs doivent la gérer au moyen du contrôle des versions, de tests reproductibles, de déploiements progressifs, de la surveillance et de capacités de restauration. Ils doivent partir du principe que le comportement des modèles et les conditions de menace évolueront.

La sécurité des infrastructures critiques face à l’IA dépend donc de la limitation des surprises. Les équipes ne peuvent prédire toutes les défaillances, mais elles peuvent préserver les preuves, les limites d’autorité et des voies de reprise sûres. Ces capacités déterminent si une anomalie devient un incident gérable ou une panne inexpliquée.

La réglementation progresse, mais les opérateurs ne peuvent pas attendre un cadre parfait

Les recommandations gouvernementales reconnaissent de plus en plus le risque, mais la responsabilité incombe toujours aux opérateurs qui prennent aujourd’hui des décisions de déploiement.

La feuille de route de la CISA pour la sécurité de l’IA aborde explicitement l’adoption de l’IA dans les infrastructures critiques. L’agence a indiqué que le déploiement pourrait accroître l’exposition aux défaillances, aux attaques physiques et aux cyberattaques.

La feuille de route préconisait des pratiques de sécurité dès la conception, des exercices de red team, la gestion des vulnérabilités et l’engagement auprès des parties prenantes des infrastructures. Ces objectifs ont établi une orientation. Ils n’ont pas créé d’exigences techniques contraignantes pour chaque secteur ou déploiement.

La réglementation des infrastructures critiques est fragmentée parce que les secteurs diffèrent fortement. Un réseau électrique, un service des eaux, un hôpital, un pipeline et un réseau de transport ne partagent pas des technologies ni des modèles de risque identiques. La propriété et l’autorité réglementaire varient également.

Cette fragmentation peut produire une gouvernance de l’IA inégale. Un grand opérateur peut mettre en place un programme de revue spécialisé. Une petite régie municipale peut s’en remettre aux assurances d’un fournisseur faute d’expertise en sécurité de l’IA.

C’est ici que l’avertissement de Robert M. Lee sur l’IA fait pression sur les conseils d’administration et les équipes d’approvisionnement. Ils ne peuvent pas supposer que les régulateurs ou les fournisseurs de modèles ont résolu tous les risques opérationnels. Les décisions d’achat deviennent des décisions d’architecture de sécurité.

Les contrats doivent exiger une documentation sur les dépendances du modèle, les processus de mise à jour, les incidents de sécurité, la gestion des données et les obligations d’assistance. Les opérateurs doivent également avoir le droit de tester les systèmes et de recevoir des informations sur les changements significatifs.

Une évaluation indépendante peut aider, mais l’évaluateur doit comprendre l’OT. Une évaluation générique d’application peut négliger la sécurité des procédés, le comportement des contrôleurs ou la reprise opérationnelle. La sécurité des infrastructures exige une coopération entre spécialistes de la cybersécurité, ingénieurs, fournisseurs et opérateurs de terrain.

Les régulateurs peuvent améliorer la cohérence en définissant un niveau minimal de preuves pour les déploiements à risque élevé. Ces preuves pourraient inclure des modèles de menace, des résultats de validation, des exigences de contrôle humain, des signalements d’incidents et des procédures de repli démontrées.

Toutefois, la conformité ne doit pas devenir le seul objectif. Un système peut satisfaire une liste de contrôle tout en laissant d’importantes dépendances physiques inexplorées. La question pertinente est de savoir si l’organisation peut maintenir des opérations sûres lors d’une attaque, d’une erreur ou d’une perte de service.

Le défi économique reste considérable. De nombreuses organisations d’infrastructures disposent de personnel limité et d’équipements vieillissants. De nouvelles obligations sans financement ni soutien à la mise en œuvre peuvent créer de la paperasse sans réduction significative des risques.

C’est pourquoi les contrôles de base sont importants. Les objectifs de performance de la CISA donnent la priorité à des pratiques offrant une forte valeur de réduction des risques. Ils comprennent des protections pour les technologies de l’information comme pour les technologies opérationnelles.

Les opérateurs doivent établir ces fondations avant d’accorder à l’IA une autorité plus étendue. Une authentification forte, un accès à distance sécurisé, la segmentation, les sauvegardes, la journalisation et les plans de réponse protègent les systèmes, qu’un incident implique ou non l’IA.

Les politiques doivent également distinguer les catégories de risque liées à l’IA. Des attaquants peuvent utiliser l’IA contre des infrastructures. Des adversaires peuvent cibler un système d’IA ou ses données. Un déploiement d’IA peut aussi échouer sans qu’aucun attaquant ne soit impliqué.

Ces catégories exigent des contrôles différents. Le renseignement sur les menaces aide à contrer les activités malveillantes. L’évaluation des modèles traite les performances et les modes de défaillance. La gouvernance détermine qui peut approuver, surveiller, modifier ou désactiver le système.

Traiter chaque problème comme une « cyberattaque IA » masque ces différences. Cela peut aussi encourager des achats coûteux qui ne répondent pas à la véritable faiblesse. Une classification claire des incidents deviendra de plus en plus importante à mesure que les déploiements se développeront.

Le test réglementaire consiste à savoir si les recommandations modifient le comportement opérationnel avant qu’une défaillance majeure n’impose la question. Publier un cadre supplémentaire ne suffit pas. Les revues d’adoption, les exigences d’approvisionnement, les exercices et les divulgations d’incidents montreront si la gouvernance devient réelle.

Trois signaux montreront si la visibilité rattrape son retard

Le prochain test consiste à savoir si les propriétaires d’infrastructures mettent en place des garanties mesurables avant que l’IA ne reçoive un contrôle plus étendu sur les systèmes physiques.

Le premier signal est le profil d’infrastructure critique du NIST pour le cadre de gestion des risques liés à l’IA. Ses recommandations devraient traduire les principes généraux en actions que les opérateurs peuvent tester. Des orientations précises sur les changements de modèle, la journalisation OT, les opérations de repli et les dépendances vis-à-vis des fournisseurs renforceraient l’argument de Lee.

Un profil vague laisserait les organisations interpréter les risques de manière différente. Un profil détaillé, en particulier s’il est adopté par les régulateurs sectoriels et les acheteurs, créerait une base commune. Cela réduirait la marge des déploiements précipités fondés uniquement sur les affirmations des fournisseurs.

Le deuxième signal concerne l’évolution des indicateurs de visibilité OT. Dragos indique actuellement que seulement 30 % des réseaux OT bénéficient d’une visibilité, tandis que 56 % ne peuvent pas voir au-delà de la frontière entre l’IT et l’OT. Les futurs rapports devraient montrer si ces chiffres s’améliorent à mesure que l’adoption de l’IA s’étend.

Une amélioration suggérerait que les organisations mettent en place une surveillance avant d’attribuer une plus grande autonomie. Une visibilité stagnante parallèlement à une adoption rapide renforcerait le risque lié aux infrastructures d’IA souligné par Dragos. Cela signifierait que la complexité augmente plus vite que la capacité des défenseurs à l’observer.

Le troisième signal est la première vague d’incidents OT liés à l’IA rendus publics. Les rapports doivent distinguer les usages malveillants, les attaques contre les modèles, les intégrations non sécurisées et les défaillances logicielles ordinaires. Sans ces précisions, les organisations ne peuvent pas déterminer quels contrôles ont échoué.

Un registre d’incidents transparent aiderait les opérateurs à tirer des enseignements avant de rencontrer le même problème. Il permettrait aussi de vérifier si la journalisation actuelle prend en charge une analyse pertinente des causes profondes. Des incidents restant à plusieurs reprises inexpliqués confirmeraient l’inquiétude de Lee face à l’extension des angles morts.

Les responsables des infrastructures ne devraient pas attendre les trois signaux. Ils peuvent dès maintenant recenser les déploiements d’IA, identifier les processus physiques concernés et vérifier qui détient l’autorité d’arrêt. Ils peuvent également tester les opérations sans le modèle ni ses services externes.

Les développeurs devraient exiger des interfaces claires, des autorisations limitées, des comportements versionnés et des pistes d’audit complètes. Les acheteurs en entreprise devraient demander aux fournisseurs des preuves plutôt que de vagues promesses de sécurité. Les travailleurs du savoir devraient éviter d’envoyer des informations sensibles sur les infrastructures dans des outils non approuvés.

L’avertissement de Robert M. Lee sur l’IA propose au final une règle de décision pragmatique. L’automatisation ne devrait pas acquérir une autorité opérationnelle plus vite que l’organisation n’acquiert de visibilité, de contrôle et de capacité de reprise.

L’IA peut toujours améliorer les services critiques. Toutefois, son déploiement doit rester suffisamment compréhensible pour être examiné et suffisamment encadré pour pouvoir être arrêté. Avant d’approuver la prochaine intégration, posez-vous une question : si elle agit de manière incorrecte demain, votre équipe pourra-t-elle comprendre pourquoi et rétablir la situation en toute sécurité ?