NIS2 et AI Act : ce qui change quand une entité régulée déploie de l'IA

Un report réel pour l'AI Act, sans effet sur NIS2

Le 8 juillet 2026, le législateur européen a adopté le règlement (UE) 2026/1744 (dit « omnibus IA »), publié le 24 juillet et en vigueur depuis le 27. Il modifie l'AI Act et décale nettement ses échéances les plus lourdes :

• systèmes à haut risque de l'annexe III (emploi, crédit, éducation, services essentiels…) : du 2 août 2026 au 2 décembre 2027 ;
• systèmes à haut risque de l'annexe I (produits déjà soumis à une réglementation sectorielle) : du 2 août 2027 au 2 août 2028 ;
• bacs à sable réglementaires : reportés au 2 août 2027.

Ce sont désormais des dates fixes : le mécanisme conditionnel initialement proposé, qui liait l'entrée en application à la disponibilité des normes harmonisées, a été abandonné dans le texte final. En revanche, l'application générale du règlement au 2 août 2026 reste acquise : obligations de transparence de l'article 50, gouvernance, pouvoirs des autorités.

Beaucoup de directions ont lu cela comme seize mois de répit. C'est une erreur de lecture, pour une raison qui n'a rien à voir avec l'AI Act.

Le point aveugle

Dans la plupart des organisations que j'accompagne, deux chantiers avancent sans se voir. D'un côté, la DSI et le RSSI préparent NIS2. De l'autre, les métiers déploient de l'IA : un copilote de rédaction ici, un modèle de scoring là, un agent de support client ailleurs. Ces deux chantiers ont des sponsors différents, des budgets différents, et souvent aucune réunion commune.

C'est un problème, pour une raison simple : du point de vue de NIS2, un système d'IA n'est pas une catégorie à part. La directive parle de réseaux et de systèmes d'information. Un modèle en production, ses données d'entraînement, l'API du fournisseur, les journaux d'appels : tout cela est du système d'information. Il n'existe aucune exemption.

Autrement dit : votre périmètre NIS2 s'est étendu chaque fois qu'un métier a mis un projet d'IA en production, et personne ne l'a inscrit au registre. Le report de l'AI Act ne suspend rien de tout cela. Il déplace une échéance de conformité produit ; il ne retire pas un serveur, une API ou un modèle de votre système d'information.

Ce que NIS2 exige, appliqué à un système d'IA

L'article 21 de la directive (UE) 2022/2555 (NIS2) impose aux entités essentielles et importantes de prendre des mesures « techniques, opérationnelles et organisationnelles appropriées et proportionnées » pour gérer les risques. Le paragraphe 2 en liste dix catégories minimales. Quatre d'entre elles se comportent différemment dès qu'on les applique à un système d'IA.

L'analyse de risques. Un système d'IA introduit des modes de défaillance que les grilles de risque classiques ne couvrent pas : dérive du modèle dans le temps, empoisonnement des données d'entraînement, extraction d'informations confidentielles par la seule interaction, injection d'instructions dans un contenu traité par le modèle. Une matrice de risques conçue pour des serveurs et des applications ne les voit pas. Le problème n'est pas qu'elle les évalue mal : elle ne pose tout simplement pas la question.

La sécurité de la chaîne d'approvisionnement. C'est le point le plus sous-estimé. Utiliser l'API d'un fournisseur d'IA, c'est faire entrer un fournisseur au cœur de vos traitements, souvent sans passage par la case achats, parce qu'un abonnement à quelques dizaines d'euros par mois ne déclenche aucun processus. NIS2 demande de tenir compte des vulnérabilités propres à chaque fournisseur direct et de la qualité de ses pratiques de sécurité. La question à se poser n'est pas « ce fournisseur est-il sérieux ? » mais « que se passe-t-il concrètement pour nous s'il subit une compromission, une interruption prolongée, ou s'il modifie unilatéralement son modèle ? »

La gestion des incidents. L'article 23 impose une alerte précoce sous 24 heures, une notification d'incident sous 72 heures, un rapport final sous un mois. Ces délais sont courts. Ils supposent qu'on soit capable de détecter l'incident. Or la plupart des déploiements d'IA n'ont aucune supervision au sens sécurité du terme. Combien d'organisations sauraient dire, aujourd'hui, qu'un de leurs systèmes d'IA produit depuis trois semaines des réponses manipulées par un contenu injecté ?

La sécurité du développement et de la maintenance. Un modèle évolue sans que vous ayez rien changé : le fournisseur met à jour sa version, et le comportement se déplace. Le cycle de vie classique (développement, recette, mise en production, gestion des changements) ne capture pas ce mouvement. Il faut le compléter, pas le remplacer.

Ce que l'AI Act ajoute par-dessus

Le règlement (UE) 2024/1689, tel que modifié par le règlement (UE) 2026/1744, s'applique par paliers. Les obligations « haut risque » de l'annexe III deviennent exigibles le 2 décembre 2027.

Premier réflexe utile : la majorité des usages d'IA en entreprise ne sont pas à haut risque. Un assistant de rédaction interne, un outil de synthèse documentaire, un classificateur de tickets ne relèvent en général que d'obligations de transparence. Il ne sert à rien de traiter tout un parc comme s'il était critique.

L'annexe III énumère huit domaines : biométrie ; infrastructures critiques ; éducation et formation professionnelle ; emploi, gestion de la main-d'œuvre et accès à l'emploi indépendant ; accès aux services privés essentiels et aux services publics essentiels (dont l'évaluation de solvabilité et la tarification en assurance vie et santé) ; répression ; migration, asile et contrôle aux frontières ; administration de la justice et processus démocratiques. Dans le secteur privé, ce sont surtout le quatrième et le cinquième qui mordent : le tri de candidatures, l'évaluation ou l'affectation de salariés, le scoring de crédit. Beaucoup d'organisations en exploitent un sans l'avoir identifié comme tel.

Pour ces systèmes, l'AI Act exige notamment un système de gestion des risques documenté (article 9), une gouvernance des données, une journalisation permettant la traçabilité, un contrôle humain effectif, et un niveau approprié d'exactitude, de robustesse et de cybersécurité (article 15), celui-ci visant expressément la résistance à l'empoisonnement des données d'entraînement et des modèles, ainsi qu'aux exemples adverses.

Une précision qui compte pour la planification : ce report est un décalage d'exigibilité, pas une dispense. Un système à haut risque mis en service en 2027 devra être conforme à sa mise sur le marché. Seize mois, pour construire une gouvernance des données et une documentation technique sur un système déjà en production, ne sont pas de trop.

Où les deux textes se recouvrent, et où ils divergent

Ce tableau est la raison d'être de cet article. Les colonnes « gestion des risques », « documentation » et « incidents » décrivent, à 70 % près, le même travail. Le mener deux fois, avec deux prestataires, deux vocabulaires et deux jeux de livrables, est un gaspillage que je vois régulièrement, et qui se paie ensuite en double lors des audits.

Les points où il ne faut surtout pas mutualiser sont en revanche nets : les chaînes de notification. Autorités différentes, délais différents, seuils de déclenchement différents. Un dispositif d'alerte unique qui « couvrirait les deux » finit systématiquement par manquer l'un des deux.

Ce que je recommande de faire, dans cet ordre

1. Inventorier les systèmes d'IA en production. Pas les projets : ce qui tourne. En pratique, cela veut dire aussi chercher les usages non déclarés : les abonnements payés sur carte bancaire de service, les extensions de navigateur, les connecteurs installés dans les outils bureautiques. Comptez une à deux semaines. Le résultat surprend presque toujours la direction.
2. Classer chaque système sur deux axes indépendants. Axe NIS2 : ce système soutient-il un service dans le périmètre ? Axe AI Act : cet usage relève-t-il de l'annexe III ? Un système peut être critique NIS2 et hors annexe III, ou l'inverse. Les deux classements ne se déduisent pas l'un de l'autre. C'est l'erreur la plus fréquente.
3. Étendre le registre des risques existant plutôt qu'en créer un second. Ajoutez les modes de défaillance propres à l'IA dans la matrice déjà en place. Un registre unique tenu à jour vaut mieux que deux registres parfaits dont un seul est vivant.
4. Traiter les fournisseurs d'IA comme des fournisseurs critiques. Clauses de sécurité, engagement de notification en cas d'incident, localisation et réversibilité des données, préavis en cas de changement de version du modèle. Si le contrat est un abonnement en ligne accepté d'un clic, vous n'avez aucune de ces garanties. C'est un constat, pas un jugement, et il doit figurer dans l'analyse de risques.
5. Tester la chaîne de notification. Un exercice sur table, deux heures, avec un scénario d'incident affectant un système d'IA. Qui détecte ? Qui décide de qualifier ? Qui signe l'alerte des 24 heures ? À quel numéro à 22 h un vendredi ? La première fois, cet exercice échoue toujours. C'est précisément à quoi il sert.

Où en est la France

À ce jour, la transposition de NIS2 en droit français n'est pas achevée. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité (qui transpose simultanément NIS2, la directive REC et le règlement DORA) a été adopté par le Sénat les 11 et 12 mars 2025, puis voté en commission spéciale à l'Assemblée nationale le 10 septembre 2025. L'examen en séance publique, envisagé pour juillet 2026, a été repoussé à la rentrée parlementaire de septembre 2026, le débat sur le chiffrement de bout en bout n'étant pas tranché.

Ce retard a un coût désormais chiffrable : après une mise en demeure le 28 novembre 2024 et un avis motivé le 7 mai 2025, la Commission européenne a saisi la Cour de justice de l'Union européenne le 8 juillet 2026 contre la France, l'Irlande, l'Espagne et les Pays-Bas, en demandant des sanctions financières (somme forfaitaire et astreintes journalières) jusqu'à notification d'une transposition complète.

Cette attente n'est pas une raison d'attendre, pour deux motifs. D'abord, les mesures concernées (analyse de risques, sauvegardes testées, authentification multifacteur, gestion des accès, plan de continuité) sont les mêmes quel que soit le texte final ; elles ne dépendent pas d'un décret. Ensuite, le délai entre la promulgation et les premières échéances de conformité se comptera en mois, pas en années. Les organisations qui commenceront ce jour-là auront un an de retard sur celles qui auront commencé maintenant.

L'ANSSI a d'ailleurs publié le Référentiel Cyber France (ReCyF), version 2.5 datée du 17 mars 2026 : il décrit les mesures recommandées pour atteindre les objectifs de sécurité de NIS2, organisés en 20 objectifs : les objectifs 1 à 15 s'appliquant aux entités importantes comme essentielles, les objectifs 16 à 20 aux seules entités essentielles. Il porte encore la mention « document de travail » et n'a pas de valeur contraignante : il ne l'acquerra qu'une fois annexé aux textes d'application. S'y aligner dès maintenant reste néanmoins le pari le moins risqué. La plateforme MonEspaceNIS2 de l'ANSSI permet par ailleurs de tester son assujettissement.

En résumé

Le report des échéances « haut risque » de l'AI Act est réel, et il est utile : il donne le temps de bien faire. Mais il ne déplace pas la ligne de départ. Si votre organisation est concernée par NIS2 et déploie de l'IA, la question n'est pas de savoir lequel des deux chantiers traiter en premier : c'est de constater qu'il s'agit d'un seul chantier avec deux régimes de preuve et deux calendriers, et de le piloter comme tel. Les organisations qui les séparent paient deux fois : une fois en projet, une fois en audit.

Fabrice Bonneville est RSSI & Risk Manager indépendant. Il accompagne les PME, ETI et collectivités territoriales sur leur conformité NIS2 et la gouvernance de leurs systèmes d'IA. Le contacter · bonneville.expert.

Pour aller plus loin