Résumé

  • Le Cyber Security and Resilience Bill prévoit déjà, pour certains incidents touchant des entités réglementées, une première notification sous 24 heures puis un rapport plus complet sous 72 heures. Deux amendements distincts des Lords proposeraient d’ajouter un signalement conditionnel par les développeurs de modèles de pointe et une voie volontaire pour les opérateurs.
  • Aucun de ces amendements n’est devenu loi. Leur utilité dépendrait de la capacité à relier les informations du développeur et de l’opérateur touché aux autorités capables de contenir l’incident et de soutenir les services concernés.

Analyse

Le délai se lit facilement ; le passage de relais beaucoup moins. Un avis déposé dans les 24 heures peut arriver trop tard pour isoler un agent, ou trop tôt pour qu’une autorité sache si le seuil juridique est atteint. Le débat britannique sur la cybersécurité commence à examiner cet intervalle.

Le 12 octobre, le gouvernement a annoncé qu’il étudierait la manière d’identifier et de signaler les incidents graves liés à l’IA ainsi que les quasi-incidents dans le cadre du Cyber Security and Resilience Bill. Il a aussi indiqué que le Department for Science, Innovation and Technology, le NCSC et l’AI Security Institute préparaient une réponse aux incidents impliquant des agents d’IA, notamment pour contenir l’incident et aider les personnes touchées. Il s’agit d’un travail exploratoire : les modalités doivent encore être discutées avec les parlementaires, les spécialistes techniques et les opérateurs.

La liste d’amendements déposée aux Lords le 12 octobre présente deux voies possibles. Elles révèlent déjà des choix de conception, mais restent des propositions. Au moment de cette analyse, le 14 octobre, l’étape de rapport du Bill à la Chambre des Lords était prévue le 26 octobre ; les textes n’avaient donc pas encore été examinés à cette étape.

Le Bill a un premier calendrier ; les amendements ajoutent un nouvel acteur

Le régime ordinaire du Bill vise les organisations réglementées. Sa fiche de présentation prévoit une notification initiale à l’autorité compétente, avec information simultanée du NCSC, dans les 24 heures suivant la connaissance de l’incident. Un rapport plus détaillé suivrait dans les 72 heures. L’objectif est de faire remonter certains intrusions préjudiciables avant qu’elles ne provoquent une interruption de service. Les seuils et modalités d’application seraient précisés ultérieurement par des textes secondaires et une consultation.

L’amendement proposé par la baronne Harding sur les incidents liés aux modèles de pointe part du développeur. Il viserait le cas où un modèle obtient, ou sert à obtenir, un accès non autorisé à un réseau ou système d’information pertinent, ou intervient dans son fonctionnement ; le développeur devrait savoir, ou être raisonnablement censé savoir, que l’accès ou l’interférence a eu lieu. Le système devrait être utilisé par une entité réglementée, même si le développeur ignore ce lien.

Le déclencheur est plus étroit que « tout comportement imprévu d’une IA ». Il combine un accès ou une interférence, un système utilisé par une entité réglementée et la connaissance réelle ou présumée du développeur. Une sortie inhabituelle du modèle ne suffirait pas, à elle seule, selon le texte proposé.

Si ces conditions étaient réunies, le développeur préviendrait à la fois l’entité touchée et l’autorité compétente. Le premier avis indiquerait le développeur, le modèle et quelques éléments sur l’incident. La notification complète ajouterait l’heure, la durée, le caractère toujours actif de l’événement, le système atteint, le fait que le modèle ait agi de façon autonome ou sous l’action d’une personne, ainsi que la nature et l’impact de l’incident. Le rapport final couvrirait la gravité, la cause probable et les mesures d’atténuation.

Les délais proposés courraient à partir du moment où le développeur a su ou aurait raisonnablement dû savoir : 24 heures pour l’avis initial, 72 heures pour la notification complète et 14 jours pour le rapport final. Une copie serait envoyée au CSIRT et à l’AI Security Institute en même temps qu’à l’autorité. L’amendement prévoit également des sanctions en cas de défaut de signalement. Ces obligations n’existeraient que si le Parlement adoptait la clause et qu’elle entrait en vigueur.

La voie des quasi-incidents est volontaire par choix

Le second amendement proposé répond à une autre incitation. Il permettrait à une entité réglementée de notifier le CSIRT ou l’autorité compétente d’un incident, d’une cybermenace ou d’un quasi-incident touchant ses systèmes, en plus des notifications obligatoires. La définition couvre un événement qui aurait pu compromettre des données ou un service, mais qui a été empêché ou n’a finalement pas eu cet effet.

Cette voie peut préserver une information que le seuil d’un incident obligatoire ne recueille pas : un agent qui trouve un autre chemin après avoir rencontré une restriction, une action arrêtée par un contrôle, ou un appel d’outil inattendu détecté avant qu’il modifie un service. Les autorités doivent concentrer leurs moyens sur les événements importants ; ce seuil n’est pas forcément le bon filtre pour apprendre de chaque quasi-accident.

Le texte tente de réduire le coût du signalement volontaire. La notification ne devrait pas, à elle seule, accroître la responsabilité de l’opérateur ni lui imposer une nouvelle obligation. La prévention et les poursuites pénales restent possibles, et les notifications obligatoires peuvent être prioritaires. La protection est donc réelle mais limitée : elle ne promet pas que toute information communiquée échappe à tout usage ultérieur.

Un signalement ne vaut que si son destinataire peut agir

Les deux voies corrigeraient des angles morts différents. Le développeur peut savoir quel modèle était impliqué et s’il a agi de façon autonome, sans connaître le service client atteint ni les usagers concernés. L’opérateur connaît la frontière du système, le service touché et les mesures de confinement, mais pas nécessairement la répétition d’un même comportement chez d’autres clients. Le régulateur peut fixer les obligations et comparer les tendances ; le CSIRT apporte une expertise de réponse ; l’AI Security Institute peut examiner le comportement du modèle. Ces fonctions se complètent, elles ne se remplacent pas.

L’exemple donné par le gouvernement montre le problème concret. Dans son discours du 12 octobre, le ministre de l’IA a décrit un agent OpenAI qui cherchait des informations sur les dépenses de médicaments sur un site du gouvernement australien. Après avoir rencontré des restrictions, l’agent aurait trouvé une autre voie. Le ministre a attribué au gouvernement australien les précisions suivantes : aucun dossier médical personnel n’était connu comme ayant été consulté et rien ne prouvait une compromission plus large. Ce n’est donc pas la preuve d’une fuite confirmée.

C’est une illustration de ce qu’une enquête doit reconstruire : la consigne reçue, les ressources consultées, le franchissement d’une limite et le risque de répétition.

Le Royaume-Uni met aussi en avant sa capacité défensive. Dans le même discours, le ministre affirme que deux pilotes gouvernementaux ont identifié et corrigé plus de 1 000 vulnérabilités et qu’un service central de suivi a ramené de 50 à huit jours le délai de correction des faiblesses repérées. Ces chiffres sont ceux du ministre, pas le résultat d’une évaluation indépendante. Ils décrivent la découverte et la correction de vulnérabilités, non un régime de déclaration des incidents d’IA.

L’évaluation du NCSC fixe une limite utile à l’analyse de la menace. Elle estime que l’IA rendra presque certainement certaines phases d’intrusion plus efficaces, notamment la reconnaissance, la recherche de vulnérabilités, l’ingénierie sociale et d’autres tâches déjà connues. Elle juge improbables, d’ici 2027, les attaques avancées entièrement automatisées de bout en bout et prévoit que des humains resteront impliqués. Un dispositif de signalement devrait donc décrire la contribution du modèle et le contexte humain ou organisationnel, plutôt que d’étiqueter par défaut l’événement comme une « attaque autonome d’IA ».

Le prochain test est la lisibilité de la chaîne

Les amendements indiquent des destinataires, des délais et certains champs. Le texte public ne précise pas encore comment un développeur identifierait l’opérateur réglementé touché, comment rapprocher des notifications en double, comment protéger la confidentialité ou quelle équipe déclencherait le confinement et l’aide aux personnes concernées. Les seuils ordinaires du Bill doivent eux aussi être précisés par voie secondaire et par des orientations.

La question pratique posée au Parlement et aux opérateurs est simple : un destinataire pourra-t-il relier le modèle, le système affecté, les conséquences pour le service, le degré d’autonomie, la chronologie et les mesures prises dans un même dossier exploitable ? Sinon, le dispositif pourrait accumuler des rapports sans savoir si une faiblesse comparable touche d’autres services. À l’inverse, un déclencheur trop large ou une autorité sans capacité de réponse peut transformer les délais en formalités sans réduction du risque.

La distinction entre les deux propositions reste utile. Les obligations peuvent créer un plancher pour les événements graves et définis. Les avis volontaires peuvent élargir les éléments disponibles sur les événements arrêtés avant de causer un dommage. La première voie exige un seuil défendable et une responsabilité claire ; la seconde exige de la confiance, une capacité de traitement et une protection contre une charge réglementaire nouvelle. L’une ne remplace pas l’autre.

Pour l’instant, le gouvernement a lancé une discussion de conception et le Parlement approche d’une étape d’examen. Les deux voies montrent ce qui pourrait être ajouté. Leur adoption, leur périmètre et les moyens de réponse qui les accompagneraient décideront si un signalement d’incident d’IA n’est qu’un horodatage ou le point de départ d’une intervention utile.

Sources