Beaucoup de RSSI français commettent aujourd’hui l’erreur de traiter la conformité NIS2 comme un simple exercice de mise à jour documentaire, sans mesurer l’impact concret que l’intégration des systèmes d’intelligence artificielle fait peser sur leur périmètre de sécurité. Or, dès lors qu’un composant IA — qu’il s’agisse d’un LLM embarqué, d’un moteur de détection d’anomalies ou d’une brique d’automatisation décisionnelle — s’insère dans la chaîne de valeur d’une entité essentielle ou importante au sens de la directive, le niveau d’exigence monte d’un cran. La directive NIS2, transposée en droit français par la loi de transposition publiée au Journal officiel, impose des obligations de gestion des risques cyber qui ne font pas de distinction technologique : un système IA critique est soumis aux mêmes règles qu’une infrastructure réseau traditionnelle. Ce que peu d’organisations ont vraiment anticipé.
Ce que NIS2 exige concrètement des entités déployant de l’IA
La directive NIS2 structure ses exigences autour de quatre piliers : la gouvernance du risque, les mesures techniques et organisationnelles, la gestion des incidents et la sécurité de la chaîne d’approvisionnement. Chacun de ces piliers prend une dimension particulière lorsqu’un système IA est en jeu. Prenons la gouvernance : NIS2 impose que les organes de direction valident et supervisent les mesures de gestion des risques cyber. En France, un grand groupe industriel comme un acteur de l’énergie ou de la logistique qui déploie un outil d’optimisation basé sur du machine learning doit désormais pouvoir démontrer que son conseil d’administration a pris connaissance des risques associés à ce système et en assure le suivi. Ce n’est plus une affaire de DSI uniquement.
Du côté des mesures techniques, NIS2 exige notamment la gestion des vulnérabilités, le contrôle d’accès, le chiffrement et la continuité d’activité. Appliquées à un système IA, ces exigences impliquent des actions spécifiques : cartographier les dépendances du modèle (bibliothèques open source, APIs tierces, jeux de données d’entraînement), sécuriser les endpoints d’inférence, isoler les environnements de production des pipelines MLOps, et documenter les procédures de rollback en cas de comportement anormal du modèle. L’ANSSI, dans ses guides sur la sécurité des systèmes d’IA, insiste d’ailleurs sur la nécessité de traiter les modèles comme des actifs critiques à part entière, avec un cycle de vie sécurisé de bout en bout. Sécuriser une application LLM multi-tenant : isolation des données et contrôle des accès
Les risques spécifiques à la chaîne d’approvisionnement IA sous NIS2
L’un des angles les plus sous-estimés par les RSSI concerne la sécurité de la supply chain logicielle appliquée aux composants IA. NIS2 impose une évaluation rigoureuse des fournisseurs et prestataires qui contribuent à la sécurité des systèmes d’information. Dans un contexte IA, cela englobe les fournisseurs de modèles fondamentaux (OpenAI, Mistral, Anthropic…), les plateformes MLOps comme Hugging Face ou Vertex AI, et les bibliothèques de traitement comme LangChain ou LlamaIndex. Un incident de type empoisonnement de modèle ou injection de prompt côté fournisseur peut se propager immédiatement dans votre chaîne de valeur — exactement le type de risque systémique que NIS2 cherche à contenir. Pour approfondir ce sujet, notre analyse des attaques sur la supply chain logicielle et les stratégies de protection donne un cadre opérationnel utile.
Cas concret : un opérateur de transport français de taille intermédiaire (entité importante au sens NIS2) a intégré un système de détection de fraude basé sur un LLM externe pour analyser les bons de commande. Ce système appelle une API tierce hébergée hors UE pour les inférences. Sous NIS2, cet opérateur doit : qualifier ce fournisseur comme tiers critique, exiger des garanties contractuelles de sécurité, prévoir un plan de continuité en cas d’indisponibilité du service, et documenter les flux de données sensibles transmis à l’API. Si cet opérateur n’a pas réalisé ce travail, il s’expose à des sanctions administratives pouvant atteindre 2 % du chiffre d’affaires mondial pour les entités importantes. La problématique des nouvelles menaces sur les API et comment les anticiper est directement liée à cette réalité terrain.
Gouvernance IA et obligations NIS2 : construire une feuille de route RSSI
La bonne approche pour un RSSI en France n’est pas de traiter la conformité NIS2 et la sécurité des systèmes IA comme deux chantiers parallèles. La synergie entre les deux est évidente : les processus de gestion des risques exigés par NIS2 constituent exactement le cadre dans lequel inscrire la gouvernance des systèmes IA. Concrètement, la feuille de route devrait s’articuler en trois phases. D’abord, l’inventaire et la classification : recenser tous les systèmes IA en production ou en cours de déploiement, les classer selon leur criticité pour les processus métier couverts par NIS2, et identifier les dépendances externes. Ensuite, l’évaluation des risques : appliquer une méthodologie reconnue — EBIOS RM pour les entités soumises à l’ANSSI est la référence incontournable — en intégrant des scénarios de menace propres à l’IA (adversarial attacks, data poisoning, model theft, prompt injection à grande échelle).
La troisième phase concerne le plan de traitement et la documentation. NIS2 exige que les mesures mises en place soient proportionnées et documentées. Pour les systèmes IA, cela se traduit par des politiques de sécurité dédiées (politique d’utilisation des LLM, procédure de qualification des modèles tiers, processus de détection des dérives comportementales), des clauses contractuelles renforcées avec les fournisseurs IA, et des procédures de notification d’incident adaptées. Rappel utile : NIS2 impose une notification initiale à l’ANSSI dans les 24 heures suivant la détection d’un incident significatif, et un rapport détaillé sous 72 heures. Un incident sur un système IA critique — dégradation non détectée d’un modèle de détection d’intrusion, par exemple — entre pleinement dans ce périmètre. Pour comprendre le cadre réglementaire dans sa globalité, notre décryptage des nouvelles règles NIS2 et ce que les entreprises doivent savoir pose les fondations indispensables.
Vers une convergence NIS2, AI Act et sécurité opérationnelle
Les RSSI les plus avisés ont déjà compris que NIS2 n’est pas le seul texte à intégrer dans leur stratégie : l’AI Act européen, entré en application progressive, impose des exigences de transparence, de robustesse et de supervision humaine pour les systèmes IA dits à haut risque. Plusieurs catégories d’entités couvertes par NIS2 exploitent précisément des systèmes IA classés à haut risque selon l’AI Act — dans les infrastructures critiques, la gestion du trafic, la santé, la finance. La convergence entre les deux cadres réglementaires n’est pas un hasard : elle reflète une volonté européenne cohérente d’élever le niveau de sécurité et de fiabilité des systèmes numériques critiques. Pour le RSSI français, cela signifie qu’une gouvernance IA robuste construite pour répondre à l’AI Act sera en grande partie réutilisable pour satisfaire les exigences NIS2, et vice-versa. Traiter ces deux chantiers en silo serait une erreur stratégique et une perte de ressources manifeste.
Ma recommandation franche, issue de plusieurs missions d’accompagnement auprès d’ETI et de grands comptes français : ne sous-traitez pas la conformité NIS2 IA à un cabinet juridique sans implication technique forte. Les risques réels — dérive de modèle, exfiltration de données via une API LLM, attaque sur le pipeline d’entraînement — ne se gèrent pas avec des clauses contractuelles seules. Ils nécessitent des contrôles techniques spécifiques, une surveillance continue et une culture de sécurité étendue aux équipes data et IA. Les RSSI qui s’empareront de ce sujet en amont auront un avantage décisif, non seulement sur le plan réglementaire, mais aussi dans la relation de confiance avec leur direction générale et leurs clients.
FAQ : Conformité NIS2 et systèmes IA
- Q : Un système IA interne, non exposé sur internet, est-il quand même concerné par les exigences NIS2 ?
- R : Oui, dès lors que ce système contribue à un processus critique couvert par NIS2 (continuité d’activité, gestion d’infrastructure, détection de menaces…), son exposition sur internet n’est pas le critère déterminant. C’est sa criticité fonctionnelle pour les services essentiels ou importants de l’entité qui prime. Un outil IA interne d’aide à la décision pour la gestion d’une infrastructure énergétique, par exemple, doit être intégré dans l’analyse de risque NIS2 même s’il n’est accessible qu’en intranet.
- Q : Comment l’ANSSI accompagne-t-elle les entités françaises sur la sécurisation des systèmes IA dans le cadre NIS2 ?
- R : L’ANSSI publie des guides sectoriels et des fiches pratiques sur la sécurité des systèmes d’IA, notamment autour des risques liés aux modèles de machine learning et aux LLM. Elle propose également des prestataires de service qualifiés (PRIS, PDIS) capables d’accompagner les entités NIS2 dans leurs audits et leurs plans de remédiation. La consultation du référentiel EBIOS RM, ainsi que des travaux ENISA sur la cybersécurité de l’IA, constitue un point de départ structurant pour tout RSSI souhaitant construire une démarche outillée et défendable.
- Q : Quelle est la différence entre les obligations NIS2 d’une entité essentielle et celles d’une entité importante en matière de systèmes IA ?
- R : Les exigences de fond sont similaires, mais le niveau de surveillance et les sanctions diffèrent. Les entités essentielles sont soumises à une supervision a priori (audits proactifs, inspections) et s’exposent à des amendes pouvant atteindre 10 millions d’euros ou 2 % du CA mondial. Les entités importantes font l’objet d’une supervision a posteriori (contrôle en cas d’incident ou de signalement) avec un plafond à 7 millions d’euros ou 1,4 % du CA mondial. Dans les deux cas, la documentation des mesures de sécurité appliquées aux systèmes IA critiques doit être disponible et à jour pour tout contrôle.