NIS2 a des dents : comment la directive change la donne pour l'IA

NIS2 en 30 secondes

La directive NIS2 ((UE) 2022/2555) remplace la directive NIS de 2016 et s'applique à deux catégories d'organisations dans 18 secteurs : les entités essentielles (énergie, transports, banque, infrastructures de marché financier, santé, eau potable, eaux usées, infrastructure numérique, gestion des services TIC, administration publique, espace) et les entités importantes (services postaux, gestion des déchets, chimie, alimentation, fabrication de dispositifs médicaux et d'électronique, fournisseurs numériques, recherche). Les États membres avaient jusqu'au 17 octobre 2024 pour la transposer. La France l'a fait via la loi de résilience adoptée fin 2024 et la LPM, qui désigne l'ANSSI comme autorité compétente. L'Allemagne n'a finalisé le NIS2UmsuCG qu'en 2025. La Belgique, les Pays-Bas, la Pologne et l'Irlande étaient en retard. La Commission européenne a ouvert des procédures d'infraction en novembre 2024.

Le fait que votre transposition nationale soit tardive ne vous protège pas : la directive elle-même est applicable depuis octobre 2024, et les autorités de contrôle rédigent déjà leurs guides d'application. Les fuites de données vers les outils d'IA s'inscrivent pleinement dans les nouvelles obligations de notification, et la plupart des équipes sécurité ne les ont pas encore modélisées.

Qui est concerné

Deux seuils comptent. La règle de taille : toute organisation de plus de 50 salariés ou de plus de 10 M€ de chiffre d'affaires annuel opérant dans un secteur couvert est dans le périmètre par défaut. Cela englobe beaucoup d'ETI qui croyaient NIS réservée aux OIV. La règle sectorielle : certains fournisseurs numériques sont concernés quelle que soit leur taille. Tout opérateur de DNS, registre de TLD, fournisseur cloud, exploitant de centre de données, CDN, MSP et MSSP est concerné. Une MSP de 12 personnes à Lyon est concernée. Un cabinet de conseil cybersécurité à Bordeaux aussi.

Si vous exploitez un outillage IA pour un client couvert dans le cadre d'un contrat d'infogérance, vous héritez des obligations de notification pour les incidents survenus sur ce périmètre. Beaucoup d'intégrateurs IA tombent de leur chaise en le découvrant.

Le calendrier de notification qui prend tout le monde de court

NIS2 introduit une horloge à trois étapes pour tout incident significatif. Manquer une étape vous expose.

L'horloge des 24 heures part du moment où l'organisation prend connaissance de l'incident, pas du moment où il s'est produit. La distinction est lourde de conséquences quand l'incident est un commercial qui colle une liste de clients dans ChatGPT à 23 h 14 un vendredi soir. Si votre DLP le détecte lundi à 9 h 00, votre horloge démarre à 9 h 00. Si vous n'avez pas de DLP et que vous l'apprenez trois semaines plus tard par une plainte client, attendez-vous à des questions inconfortables sur la maturité de votre détection.

Qu'est-ce qu'un incident significatif pour le traitement de données IA

La directive définit l'incident significatif par son impact, pas par son mécanisme. Un incident est significatif s'il a causé ou est susceptible de causer une perturbation opérationnelle grave, une perte financière, ou un préjudice matériel ou immatériel à d'autres personnes. Pour les fuites IA, trois schémas franchissent le seuil de manière fiable :

• Données personnelles de plus de 100 personnes sortant du contrôle de l'organisation — un CSV client collé dans Claude, un transcript de support envoyé à un résumeur tiers. Cela déclenche en parallèle la notification RGPD de 72 heures au titre de l'article 33.
• Données d'affaires confidentielles à impact opérationnel ou financier : grilles tarifaires, documents M&A, code source de systèmes en production, comptes rendus de conseil — sortant via un outil IA, sanctionné ou non.
• Identifiants permettant une nouvelle compromission : clés API, JWT, chaînes de connexion, clés privées, jetons OAuth — exfiltrés dans un prompt LLM où les journaux du fournisseur sont désormais hors de votre portée.

Exemple concret : un membre de l'équipe finance colle 500 enregistrements clients dans ChatGPT pour reformater un rapport. Incident significatif au sens de NIS2, violation de données personnelles au sens du RGPD, et très probablement manquement contractuel envers les clients concernés. Trois régimes, un seul copier-coller.

Les preuves que le régulateur va demander

Les CSIRT convergent vers un dossier de preuves standard pour les incidents liés à l'IA. Attendez-vous à devoir produire :

1. Horodatage du prompt et de la détection, avec fuseau horaire.
2. Identité de l'utilisateur et contexte d'authentification (session SSO, terminal, géolocalisation).
3. Outil de destination — ChatGPT, Claude, Gemini, Copilot, Perplexity, Mistral, DeepSeek, ou un outil shadow non sanctionné ?
4. Aperçu masqué du contenu fuité — généralement les 200 premiers caractères avec les PII masquées, juste assez pour caractériser le type de données.
5. Classification — credit_card, IBAN, NIR, api_key, password, JWT, source_code, etc.
6. Action prise — bloqué, anonymisé, simplement monitoré.
7. Évaluation du périmètre — combien d'enregistrements, quelles personnes concernées, quel sous-traitant détient désormais la donnée.
8. Remédiation — identifiants rotés, clients notifiés, sous-traitant contacté pour suppression.

Le journal d'incidents de Zeuslock a été conçu contre cette liste exacte. Chaque événement de la console opérateur à app.zeuslock.ai capture ces champs par défaut et s'exporte en un CSV qui se mappe un pour un sur le gabarit du CERT-FR. Quand le régulateur demande les preuves au 72e heure, vous ne devriez pas les rédiger à partir de zéro.

Qui dépose le rapport et comment le flux se déroule

NIS2 ne nomme pas un rôle unique, mais la pratique converge vers un triptyque : le RSSI porte le rapport technique, le DPO traite la notification RGPD parallèle quand des données personnelles sont en jeu, et la direction juridique revoit l'exposition avant envoi. En coulisse, le rapport part au CSIRT national.

• France : ANSSI opère le CERT-FR et la loi de résilience désigne l'ANSSI comme autorité de contrôle. La notification passe par le portail MonServiceSécurisé.
• Allemagne : le BSI reçoit les notifications via le Meldeportal, étendu pour NIS2UmsuCG.
• Espagne : INCIBE-CERT pour les secteurs non critiques, CCN-CERT pour le secteur public.
• Belgique, Pays-Bas, Italie : CCB CERT.be, NCSC-NL, CSIRT Italia.
• Le Royaume-Uni est hors champ depuis le Brexit mais maintient un régime parallèle (NIS Regulations 2018) supervisé par le NCSC et l'ICO.

Si l'incident a un impact transfrontalier — une organisation française fait fuir des données de résidents allemands vers un LLM hébergé aux États-Unis — le CSIRT chef de file informe les autorités homologues via le réseau EU-CyCLONe. Vous ne notifiez qu'une fois, à votre CSIRT chef de file, mais préparez-vous à des questions venues d'ailleurs.

Sanctions et responsabilité personnelle

Les chiffres font les gros titres mais méritent d'être répétés car ils ont nettement augmenté :

Le vrai changement, c'est l'article 32. Pour la première fois au niveau européen, NIS2 prévoit explicitement la responsabilité personnelle des organes de direction. Les dirigeants et cadres supérieurs peuvent être tenus personnellement responsables des manquements à la mise en œuvre des mesures de gestion des risques cyber. Les États membres peuvent les suspendre de fonctions de direction et leur infliger des amendes individuelles. C'est pour cela que votre comité exécutif vous interroge soudain sur les fuites IA à chaque revue trimestrielle. Ce n'est pas de la paranoïa : ils lisent la directive.

Ce qu'il faut faire ce trimestre

À défaut d'autre chose, faites ces trois actions avant la clôture du prochain trimestre.

1. Cartographiez votre surface IA. Listez tous les outils IA utilisés dans l'organisation, sanctionnés ou shadow. ChatGPT, Claude, Gemini, Copilot, Cursor, Aider, Claude Code, Copilot CLI, DeepSeek, pipelines RAG internes, agents connectés via MCP. Une extension navigateur Zeuslock plus un agent desktop plus la CLI Zeuslock pour les terminaux développeurs feront remonter environ 95 % du paysage en deux semaines de télémétrie. Ce que vous ne voyez pas, vous ne pouvez pas le notifier.
2. Construisez un pipeline d'incident qui se déclenche en moins de 24 heures. Détection → triage → notification CSIRT doit être un workflow unique avec un responsable nommé et un suppléant. Webhook DLP vers Slack et PagerDuty avec vérification HMAC, routage des incidents significatifs vers un canal dédié, et préremplissage du gabarit CERT-FR depuis le journal d'incidents. Répétez le chemin de bout en bout. Si votre premier exercice prend 36 heures, vous avez un problème de 24 heures.
3. Faites un tabletop sur une fuite par prompt. Une fois par trimestre, jouez un scénario où un ingénieur avant-vente colle un tableau client de 2 000 lignes dans Gemini à 22 h 30 un vendredi. Juridique, DPO, RSSI et un responsable communication autour de la table. Rédigez l'alerte CERT-FR. Rédigez la notification RGPD article 33. Rédigez l'avis client. Chronométrez le tout. La première fois que vous le ferez en conditions réelles ne doit pas être le jour J.

NIS2 ne sera pas appliquée avec douceur. La première vague de sanctions tombe déjà en Allemagne et aux Pays-Bas pour défaut de notification sous le régime précédent. Prenez l'horloge des 24 heures au sérieux, concevez votre traitement de données IA autour d'elle, et tenez prêt un dossier de preuves que vous seriez à l'aise de remettre à un régulateur à 9 h 00 le lendemain matin.