Infrastructures critiques : le DHS répartit les responsabilités de l’IA

L’intelligence artificielle peut aider à détecter une anomalie sur un réseau, à trier de grandes quantités d’informations ou à assister des agents dans leur formation. Mais lorsqu’elle s’invite dans les services dont dépend la vie quotidienne, de l’énergie aux télécommunications en passant par les transports et l’eau, une erreur technique, une attaque ou une décision mal encadrée peut aussi avoir des conséquences considérables. C’est à ce point de rencontre entre innovation et continuité des services que s’attaque le Département de la sécurité intérieure des États-Unis, le DHS.

Le 14 novembre 2024, l’administration américaine a présenté le document intitulé « Roles and Responsibilities Framework for Artificial Intelligence in Critical Infrastructure ». Ce cadre définit des responsabilités pratiques et volontaires pour les acteurs amenés à concevoir, fournir, déployer ou surveiller de l’IA dans les infrastructures critiques américaines. L’ambition n’est pas de fournir un nouveau logiciel de défense, mais d’organiser ce que chacun doit faire pour que l’IA ne devienne pas elle-même un nouveau point de faiblesse.

Pourquoi l’IA concerne les infrastructures critiques

Aux États-Unis, l’État fédéral regroupe 16 secteurs sous l’appellation d’infrastructures critiques. Ils comprennent notamment l’énergie, les transports, les communications, les services financiers, la santé, l’eau et les eaux usées, les services d’urgence ou encore les technologies de l’information. Leurs réalités techniques diffèrent, mais tous assurent des fonctions essentielles au fonctionnement du pays.

Dans ces environnements, l’IA peut servir à analyser des alertes, à anticiper des besoins de maintenance, à assister des équipes face à des flux d’information volumineux ou à améliorer des processus administratifs. L’enjeu ne se limite donc pas aux modèles d’IA eux-mêmes. Il englobe aussi les données qui les alimentent, les infrastructures cloud et informatiques qui les hébergent, les personnes qui les utilisent et les procédures prévues lorsqu’un système se trompe ou se comporte de façon inattendue.

Le DHS insiste ainsi sur un principe simple : la sécurité ne peut pas reposer sur le seul développeur d’un modèle. Un système peut être conçu avec des précautions, puis être mal intégré par un opérateur. Inversement, un opérateur rigoureux peut rester exposé si son fournisseur de calcul ou son outil d’IA présente une faille. La protection suppose une chaîne de responsabilités cohérente.

Cinq groupes appelés à agir ensemble

Le cadre du DHS répartit les rôles entre cinq groupes principaux. Cette répartition répond à la diversité des acteurs de l’IA : une entreprise qui fournit du stockage et de la puissance de calcul n’a pas la même prise sur les risques qu’un concepteur de modèle ou qu’un exploitant de réseau électrique.

Le document aborde les environnements cloud, la conception des modèles et des systèmes, la gouvernance des données et les conditions de déploiement. Il met également l’accent sur la surveillance de l’usage de l’IA après sa mise en service. Cette dernière étape est déterminante : un outil qui fonctionne dans un test contrôlé peut produire des effets différents lorsqu’il est confronté aux données, aux contraintes et aux décisions réelles d’une organisation.

La formulation volontaire du cadre est importante. Le DHS ne crée pas, par ce document, une obligation légale générale applicable à toutes les entreprises. Il propose une base commune de pratiques, tout en rappelant que les agences publiques peuvent mobiliser les lois et les réglementations existantes afin de faire progresser les normes d’IA et de défendre les droits des personnes et des communautés.

Les trois risques identifiés par la CISA

La Cybersecurity and Infrastructure Security Agency, la CISA, distingue trois familles de risques liés à l’IA dans les infrastructures critiques. Cette grille permet de ne pas réduire le sujet à la seule question des cyberattaques : une technologie peut être détournée par un adversaire, directement prise pour cible ou échouer à cause de défauts de conception et d’intégration.

Cette distinction a une conséquence pratique. La réponse ne peut pas être uniquement technique. Se protéger des attaques utilisant l’IA demande, par exemple, d’améliorer les défenses contre l’automatisation malveillante et les opérations de tromperie. Se protéger des attaques visant un système d’IA suppose de sécuriser les données, les accès et les environnements d’exécution. Réduire les défaillances de conception implique enfin des tests, une documentation, une supervision humaine et des règles claires quant aux décisions qui peuvent, ou non, être confiées à un outil.

Pour les propriétaires d’infrastructures critiques, comprendre ces vulnérabilités est d’abord un enjeu de continuité de service. La question pertinente n’est pas seulement « l’outil est-il performant ? », mais aussi « que se passe-t-il s’il se trompe, s’il est indisponible ou s’il est manipulé ? ». Dans un secteur essentiel, prévoir ce scénario fait partie de la sécurité.

Un guide pratique plutôt qu’un exercice théorique

Le cadre a été élaboré avec l’appui de l’AI Safety and Security Board du DHS, un conseil consacré à la sûreté et à la sécurité de l’IA. Le recours à cette instance doit permettre de rapprocher les attentes de l’administration des réalités opérationnelles rencontrées par les entreprises technologiques, les opérateurs d’infrastructures et les acteurs de la société civile.

Le secrétaire à la Sécurité intérieure, Alejandro Mayorkas, a mis en avant l’engagement de l’industrie dans la préparation du document. Son message est que ces responsabilités ne doivent pas rester au stade de principes généraux. Elles ont vocation à guider des décisions concrètes : qui sécurise l’environnement informatique, qui évalue le comportement du système, qui contrôle les données, qui répond lorsqu’un incident survient et qui vérifie l’impact sur les personnes concernées.

Cette approche prend aussi acte d’une réalité américaine : une grande partie des infrastructures critiques est détenue ou exploitée par des organisations privées. La coopération entre pouvoirs publics et secteur privé n’est donc pas une option secondaire. Sans partage d’informations, sans objectifs communs et sans compréhension des contraintes de terrain, un cadre de sécurité risque de rester sans effet.

Quels enseignements tirés des projets pilotes du DHS ?

En parallèle de ce cadre, le DHS met en avant plusieurs projets pilotes afin d’évaluer l’intérêt réel de l’IA dans ses propres missions. Ces expérimentations illustrent une précaution essentielle : avant d’étendre une technologie à grande échelle, il faut définir son périmètre, observer ses effets et recueillir les retours des personnes qui l’utilisent.

L’un des projets cités utilise l’IA générative pour former des agents chargés de l’immigration. Le DHS précise que cet usage est exclusivement consacré à la formation et qu’il n’a aucune incidence sur les décisions d’éligibilité. Cette séparation est fondamentale. Elle distingue un outil d’apprentissage, qui peut assister un agent dans une mise en situation, d’un système intervenant directement dans une décision susceptible d’affecter les droits d’une personne.

Un autre projet a permis à Homeland Security Investigations d’expérimenter de grands modèles de langage afin d’améliorer l’efficacité de la rédaction de rapports. Le recours à des modèles open source apporte une flexibilité pour expérimenter et évaluer leur efficacité. Mais cette souplesse ne dispense pas d’une évaluation rigoureuse, particulièrement lorsqu’un outil traite des informations sensibles ou est utilisé dans un cadre d’enquête.

Le retour d’expérience de la Federal Emergency Management Agency, la FEMA, met pour sa part en lumière la valeur des avis d’utilisateurs. Dans une administration aussi vaste, un outil peut paraître pertinent à ses concepteurs tout en se révélant peu adapté aux pratiques locales. Sensibiliser les acteurs de terrain, comprendre leurs besoins et intégrer leurs remarques sont donc des conditions de l’adoption, pas de simples étapes de communication.

La protection des droits, une responsabilité publique

Le cadre ne traite pas uniquement de cybersécurité ou de performance. Il demande aussi aux entités publiques de veiller à ce que les acteurs privés protègent les droits des individus et des communautés. Dans le cas d’infrastructures critiques, les effets d’un système mal conçu peuvent en effet dépasser l’organisation qui l’utilise : ils peuvent toucher des usagers, des salariés, des habitants ou des territoires entiers.

Cette dimension concerne notamment la manière dont sont sélectionnées et gouvernées les données, la possibilité d’identifier des résultats discriminatoires et la capacité à contester ou examiner des décisions ayant des conséquences importantes. Le texte ne prétend pas résoudre à lui seul ces questions. Il rappelle néanmoins que l’innovation ne doit pas faire oublier les garanties fondamentales.

Pour le secteur public, le défi est double. Il s’agit d’encourager des usages qui peuvent améliorer l’efficacité et la résilience des services, sans créer une course au déploiement qui négligerait les garde-fous. Les leviers juridiques et réglementaires existants doivent, selon le cadre, servir à promouvoir des normes d’IA tout en préservant les droits.

Ce qu’il faut surveiller

La portée réelle de ce cadre dépendra de son appropriation par les cinq groupes qu’il vise. Parce qu’il repose principalement sur le volontariat, son efficacité se mesurera moins à l’existence du document qu’à la capacité des organisations à traduire ses principes en procédures de conception, d’achat, de déploiement et de contrôle.

La continuité politique représente également un point d’attention. Des interrogations existent sur le devenir des directives fédérales au fil des changements d’administration. Alejandro Mayorkas estime néanmoins que la participation des membres du conseil de sûreté et de sécurité de l’IA donne au cadre une assise susceptible de favoriser la cohérence de sa mise en œuvre.

Enfin, les projets pilotes du DHS rappellent une leçon plus générale : l’IA ne doit pas être évaluée seulement à l’aune de démonstrations techniques. Dans les infrastructures critiques, il faut examiner les conditions réelles d’utilisation, les mécanismes de recours, les effets sur les professionnels et la capacité à maintenir un service sûr en cas de défaillance. C’est ce travail patient de gouvernance, autant que les performances des modèles, qui déterminera si l’IA renforce véritablement la résilience des services essentiels.