Entre DORA et NIS2, la différence pour les établissements financiers est une règle de priorité. DORA est un règlement sectoriel : pour les banques et autres entités financières, ses règles sur le risque informatique, les incidents, les tests et les prestataires remplacent celles de NIS2. Les banques restent citées dans NIS2 et leurs notifications parviennent aux autorités NIS2. Le tableau compare DORA, NIS2, le CRA et l'AI Act.
En droit de l'Union, la lex specialis désigne le texte plus spécifique qui s'applique à la place du texte général sur un même sujet. NIS2 pose la règle à son article 4 et DORA l'actionne à son article 1er, paragraphe 2. Le Cyber Resilience Act (CRA) est un règlement sur les produits matériels et logiciels connectés, et l'AI Act est un règlement fondé sur les risques des systèmes d'IA et des modèles d'IA à usage général. Ces deux textes s'ajoutent à DORA et à NIS2, sans les remplacer.
Cette page donne la vue d'ensemble des quatre textes. Pour l'analyse détaillée de DORA face à NIS2, lisez DORA vs NIS2.
DORA, NIS2, CRA et AI Act côte à côte
| DORA | NIS2 | CRA | AI Act | |
|---|---|---|---|---|
| Nature et référence | Règlement (UE) 2022/2554, d'application directe. Règles détaillées dans des normes techniques, par exemple les règlements délégués (UE) 2024/1772, 2025/301 et 2025/1190 et le règlement d'exécution (UE) 2024/2956 | Directive (UE) 2022/2555. Elle s'applique par les lois nationales de transposition, dont le détail varie d'un État membre à l'autre | Règlement (UE) 2024/2847, d'application directe | Règlement (UE) 2024/1689, d'application directe. Modifié par le règlement (UE) 2026/1744 (« omnibus numérique » sur l'IA) |
| Qui est concerné | 20 catégories d'entités financières (art. 2, § 1, a) à t)) : établissements de crédit, de paiement et de monnaie électronique, entreprises d'investissement, prestataires de services sur crypto-actifs, assureurs, institutions de retraite professionnelle, gestionnaires de fonds, infrastructures de marché, etc. Les prestataires tiers de services TIC, par les contrats et, s'ils sont désignés critiques, par une supervision directe au niveau de l'Union | Entités moyennes et grandes (certaines quelle que soit leur taille) de 18 secteurs énumérés aux annexes I et II, classées « essentielles » ou « importantes ». Le secteur bancaire et les infrastructures des marchés financiers figurent à l'annexe I | Fabricants, importateurs et distributeurs de produits comportant des éléments numériques dotés d'une connexion de données à un appareil ou à un réseau (art. 2, § 1). Le cloud et le SaaS relèvent de NIS2, sauf s'ils constituent le traitement de données à distance d'un produit (considérants 11 et 12) | Fournisseurs, déployeurs, importateurs et distributeurs de systèmes d'IA, et fournisseurs de modèles d'IA à usage général, y compris hors Union lorsque les résultats sont utilisés dans l'Union (art. 2, § 1) |
| Ce que le texte protège | La résilience opérationnelle numérique des entités financières et du système financier | La sécurité des réseaux et systèmes d'information qui portent des services importants pour la société et l'économie | La cybersécurité des produits sur tout leur cycle de vie, période d'assistance comprise | La santé, la sécurité et les droits fondamentaux face aux risques de l'IA |
| Obligations principales | Cadre de gestion du risque lié aux TIC (art. 5 à 16), gestion et classification des incidents (art. 17 et 18), tests de résilience (art. 24 à 27), risque lié aux prestataires tiers, dont le registre d'informations (art. 28, § 3) et les clauses contractuelles (art. 30) | Gouvernance (art. 20) et au moins dix mesures de gestion des risques selon une approche « tous risques » (art. 21, § 2, a) à j)) : gestion des incidents, continuité d'activité, sécurité de la chaîne d'approvisionnement, authentification multifacteur, etc. | Exigences essentielles de cybersécurité (annexe I, partie I), gestion des vulnérabilités avec nomenclature des logiciels (SBOM) (annexe I, partie II), évaluation de la conformité et marquage CE | Pratiques interdites (art. 5), mesures de maîtrise de l'IA (art. 4), exigences pour les systèmes à haut risque (art. 9 à 15), obligations des déployeurs (art. 26), analyse d'impact sur les droits fondamentaux (art. 27), transparence (art. 50), obligations des modèles d'IA à usage général (art. 53 à 55) |
| Notification des incidents ou vulnérabilités et délais | Incidents majeurs liés aux TIC, notifiés à l'autorité de supervision financière. Notification initiale dans les 4 heures suivant la classification comme majeur et au plus tard 24 heures après la prise de connaissance. Rapport intermédiaire dans les 72 heures suivant la notification initiale. Rapport final dans le mois suivant le dernier rapport intermédiaire (art. 19 ; règlement délégué (UE) 2025/301, art. 5) | Incidents importants, notifiés au CSIRT ou à l'autorité compétente. Alerte précoce dans les 24 heures suivant la prise de connaissance. Notification d'incident dans les 72 heures. Rapport intermédiaire sur demande. Rapport final dans le mois suivant la notification (art. 23, § 4) | Vulnérabilités activement exploitées et incidents graves, notifiés par le fabricant via la plateforme unique de signalement de l'ENISA. Alerte précoce dans les 24 heures. Notification dans les 72 heures. Rapport final 14 jours après la mise à disposition d'un correctif (vulnérabilité) ou un mois après la notification (incident) (art. 14) | Incidents graves impliquant un système d'IA à haut risque, signalés par le fournisseur à l'autorité de surveillance du marché. Signalement dès qu'un lien de causalité est établi et au plus tard dans les 15 jours. Sous 2 jours en cas d'infraction de grande ampleur ou de perturbation grave d'une infrastructure critique. Sous 10 jours en cas de décès (art. 73) |
| Responsabilité de l'organe de direction | L'organe de direction définit, approuve et supervise le cadre de gestion du risque TIC et en assume la responsabilité ultime (art. 5, § 2). Formation régulière (art. 5, § 4). Les sanctions nationales peuvent viser les membres de l'organe de direction (art. 50, § 5) | Les organes de direction approuvent et supervisent les mesures de l'article 21 et peuvent être tenus responsables (art. 20, § 1). Formation obligatoire (art. 20, § 2). Pour les entités essentielles, interdiction temporaire d'exercer des fonctions de direction possible (art. 32, § 5, b)) | Aucune disposition propre à la direction. Les obligations pèsent sur l'opérateur économique | Aucune disposition propre à la direction. Fournisseurs et déployeurs prennent des mesures de maîtrise de l'IA pour leur personnel (art. 4) |
| Prestataires et chaîne d'approvisionnement | Stratégie de risque lié aux prestataires TIC, registre d'informations (art. 28, § 3 ; règlement d'exécution (UE) 2024/2956), clauses contractuelles obligatoires (art. 30), stratégies de sortie. Les AES supervisent les prestataires tiers critiques de services TIC (art. 31 à 44) et ont publié leur liste initiale de prestataires désignés le 18 novembre 2025 | Sécurité de la chaîne d'approvisionnement, y compris les relations avec les fournisseurs directs, la qualité de leurs produits et leurs pratiques de développement (art. 21, § 2, d), et § 3). Évaluations coordonnées des risques des chaînes d'approvisionnement critiques au niveau de l'Union (art. 22) | Diligence raisonnable sur les composants de tiers, open source compris (art. 13, § 5). SBOM couvrant au moins les dépendances de premier niveau. Obligations des importateurs (art. 19) et des distributeurs (art. 20) | Obligations réparties le long de la chaîne de valeur de l'IA (art. 25). Le fournisseur d'un système à haut risque et ses fournisseurs de modèles, d'outils et de composants concluent un accord écrit (art. 25, § 4), que le règlement (UE) 2026/1744 a ajouté aux obligations passibles d'amende (art. 99, § 4, da)) |
| Tests | Programme de tests de résilience pour toutes les entités (art. 24 et 25). Tests de pénétration fondés sur la menace (TLPT) au moins tous les 3 ans pour les entités identifiées (art. 26 ; règlement délégué (UE) 2025/1190) | Procédures pour évaluer l'efficacité des mesures (art. 21, § 2, f)). Les autorités peuvent imposer audits et scans de sécurité (art. 32, § 2) | Tests et examens de sécurité efficaces et réguliers (annexe I, partie II, point 3). Évaluation de la conformité par un tiers pour certaines catégories de produits (art. 32) | Tests des systèmes à haut risque avant leur mise sur le marché (art. 9). Exactitude, robustesse et cybersécurité (art. 15). Tests adverses des modèles d'IA à usage général présentant un risque systémique (art. 55) |
| Sanctions (amendes maximales) | Montants fixés par le droit national (art. 50) ; pas de plafond européen pour les entités financières. Pour les prestataires TIC critiques, astreinte journalière jusqu'à 1 % du chiffre d'affaires mondial journalier moyen, pendant 6 mois au plus (art. 35, § 6 à 8) | Entités essentielles : maximum d'au moins 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Entités importantes : au moins 7 millions d'euros ou 1,4 % (art. 34, § 4 et 5). Les lois nationales peuvent prévoir davantage | 15 millions d'euros ou 2,5 % (exigences essentielles, art. 13 et 14). 10 millions d'euros ou 2 % (autres obligations énumérées). 5 millions d'euros ou 1 % (informations inexactes ou trompeuses). Le montant le plus élevé étant retenu (art. 64) | 35 millions d'euros ou 7 % (pratiques interdites). 15 millions d'euros ou 3 % (la plupart des autres obligations, transparence comprise). 7,5 millions d'euros ou 1 % (informations inexactes). Le montant le plus élevé, mais le plus bas pour les PME et, depuis 2026, pour les petites entreprises à moyenne capitalisation hors pratiques interdites (art. 99). La Commission inflige aux fournisseurs de modèles d'IA à usage général jusqu'à 15 millions d'euros ou 3 % (art. 101) |
| Autorités de contrôle | Autorités de supervision financière nationales (art. 46), par exemple la BNB et la FSMA en Belgique. Pour les établissements de crédit importants, les rapports sont transmis à la BCE. Les AES (ABE, AEAPP, AEMF) sont superviseurs principaux des prestataires TIC critiques | Autorités compétentes nationales, CSIRT et points de contact uniques, par exemple le CCB en Belgique. Groupe de coopération et réseau des CSIRT au niveau de l'Union | Autorités nationales de surveillance du marché (art. 52). Les notifications vont aux CSIRT désignés comme coordinateurs et à l'ENISA. Organismes notifiés pour les évaluations par un tiers | Autorités nationales de surveillance du marché. Pour l'IA utilisée par les établissements financiers dans leurs services financiers, l'autorité de supervision financière (art. 74, § 6). Le Bureau de l'IA (Commission) pour les modèles d'IA à usage général |
| Dates d'application | Entrée en vigueur le 16 janvier 2023 ; application depuis le 17 janvier 2025 (art. 64) | Entrée en vigueur le 16 janvier 2023 ; transposition au plus tard le 17 octobre 2024, mesures nationales applicables depuis le 18 octobre 2024 (art. 41) | Entrée en vigueur le 10 décembre 2024. Chapitre sur les organismes notifiés : 11 juin 2026. Notifications (art. 14) : 11 septembre 2026. Le reste : 11 décembre 2027 (art. 71) | Entrée en vigueur le 1er août 2024. Interdictions et maîtrise de l'IA : 2 février 2025. Modèles d'IA à usage général et sanctions : 2 août 2025. Date générale, transparence comprise : 2 août 2026. Systèmes à haut risque : 2 décembre 2027 (annexe III) et 2 août 2028 (annexe I), après la modification de 2026 |
Qu'est-ce qui a changé en 2025 et 2026 : droit en vigueur ou proposition ?
| Élément | Statut au 4 novembre 2026 |
|---|---|
| Omnibus numérique sur l'IA, règlement (UE) 2026/1744 | Droit en vigueur. Publié le 24 juillet 2026, en vigueur depuis le 27 juillet 2026. Il reporte les obligations des systèmes à haut risque au 2 décembre 2027 (annexe III) et au 2 août 2028 (annexe I). Il remplace l'article 10, § 5, par un nouvel article 4 bis sur la détection des biais. La maîtrise de l'IA devient une obligation de « prendre des mesures pour favoriser » son développement. L'analyse d'impact sur les droits fondamentaux peut renvoyer à l'AIPD. Deux nouvelles interdictions, visant les systèmes d'IA qui génèrent des images intimes non consenties de personnes identifiables ou du matériel pédopornographique, s'appliquent à partir du 2 décembre 2026 |
| Notifications CRA (art. 14) | Applicables depuis le 11 septembre 2026, via la plateforme unique de signalement de l'ENISA. Elles visent aussi les produits déjà sur le marché (art. 69, § 3) |
| Supervision DORA des prestataires TIC critiques | En place. Les AES ont publié leur liste initiale de prestataires désignés le 18 novembre 2025 |
| Omnibus numérique sur les données et la notification des incidents, COM(2025) 837, procédure 2025/0360(COD) | Proposition. La Commission (19 novembre 2025) a proposé un point d'entrée unique géré par l'ENISA pour les notifications au titre de NIS2, du RGPD, de DORA, d'eIDAS et de la directive CER. Les violations de données ne seraient notifiées que si elles présentent un risque élevé, dans les 96 heures. Le 21 octobre 2026, le Conseil a arrêté son mandat de négociation, qui remplace le point d'entrée européen par des points d'entrée nationaux. Le Parlement n'a pas encore adopté sa position. D'ici l'adoption, chaque notification garde son canal et son délai (RGPD : 72 heures) |
| Modifications ciblées de NIS2, COM(2026) 13, procédure 2026/0012(COD) | Proposition (janvier 2026, dans le paquet de révision du Cybersecurity Act). Le Parlement en est au stade de la commission |
Quelle différence entre DORA et NIS2 pour les établissements financiers ?
L'article 4, § 1, de NIS2 prévoit que, lorsqu'un acte sectoriel de l'Union impose des mesures de gestion des risques ou des notifications d'incidents dont l'effet est « au moins équivalent » à celui des obligations de NIS2, les dispositions correspondantes de NIS2, y compris la supervision et l'exécution, ne s'appliquent pas. L'article 1er, § 2, de DORA se déclare acte sectoriel pour les entités financières identifiées au titre de NIS2. Le considérant 28 de NIS2 le dit expressément : les règles de DORA sur le risque TIC, les incidents, les tests, le partage d'informations et les prestataires tiers s'appliquent à la place.
Ce que NIS2 change encore pour une banque ou une infrastructure de marché :
- Elle reste dans NIS2 sur le papier. Le secteur bancaire et les infrastructures des marchés financiers figurent à l'annexe I, et l'article 1er, § 2, de DORA vise les entités financières identifiées selon les règles nationales de NIS2. La manière dont chaque État membre procède à cette identification varie.
- Ses notifications atteignent les autorités cyber. L'autorité de supervision financière transmet les rapports DORA aux CSIRT, autorités compétentes ou points de contact uniques NIS2 (art. 19, § 6, c), de DORA). Un État membre peut aussi exiger une copie directe (art. 19, § 1).
- Pas de report au jour ouvrable suivant. Les établissements de crédit, contreparties centrales, plates-formes de négociation et toute autre entité financière identifiée au titre de NIS2 ne peuvent pas reporter la notification initiale ni le rapport intermédiaire d'un week-end ou d'un jour férié au lendemain midi (règlement délégué (UE) 2025/301, art. 5, § 5).
- Le groupe peut rester soumis à NIS2. Les filiales non financières, par exemple une société de services informatiques interne, suivent la loi NIS2 nationale, tout comme beaucoup de fournisseurs de la banque (cloud, centres de données, services gérés).
- Les autorités coopèrent. Lorsqu'elles supervisent une entité qui est aussi un prestataire TIC critique désigné, les autorités NIS2 en informent le forum de supervision de DORA (art. 32, § 10, et 33, § 6, de NIS2).
Pour aller plus loin : cadre DORA et cadre NIS2.
Quelle différence entre le Cyber Resilience Act et NIS2 ?
NIS2 encadre des entités : la manière dont une organisation sécurise les réseaux et systèmes qui portent ses services. Le CRA encadre des produits : ce qu'un fabricant peut mettre sur le marché de l'Union et la manière dont il les maintient. Beaucoup d'organisations sont concernées par les deux, et les textes s'emboîtent :
- Un vocabulaire et des canaux communs. Le CRA reprend les définitions d'« incident » et d'« incident évité » de NIS2. Les notifications CRA vont aux CSIRT désignés comme coordinateurs au titre de l'article 12, § 1, de NIS2, ainsi qu'à l'ENISA.
- La chaîne d'approvisionnement. NIS2 impose de tenir compte des vulnérabilités propres à chaque fournisseur direct, de la qualité de ses produits et de ses pratiques de développement sécurisé (art. 21, § 3). Selon le considérant 24 du CRA, des produits sécurisés dès la conception et mis à jour à temps doivent aider les entités à respecter ces exigences. En pratique, le marquage CE, la SBOM et la période d'assistance déclarée deviennent des pièces d'achat.
- La certification. L'article 24 de NIS2 permet aux États membres d'imposer des produits TIC certifiés selon des schémas européens. L'article 8 du CRA permet à la Commission d'exiger un certificat européen de cybersécurité pour les produits critiques (annexe IV). Les deux reposent sur les schémas adoptés en vertu du Cybersecurity Act (règlement (UE) 2019/881).
- Le cloud et le SaaS. NIS2 couvre les services cloud, dont le SaaS, le PaaS et l'IaaS. Le CRA ne couvre le traitement à distance que lorsqu'un produit en a besoin pour fonctionner (considérants 11 et 12 du CRA).
- La double exposition. Un fabricant moyen ou grand de produits informatiques, électroniques et optiques relève de NIS2 (annexe II) et du CRA. Une attaque qui exploite une faille de son produit et touche son propre réseau peut déclencher une notification CRA (art. 14) et une notification NIS2 (art. 23).
Pour les contrats avec les fournisseurs de produits numériques, voir les clauses CRA.
Comment l'AI Act et le RGPD s'articulent-ils ?
Le RGPD continue de s'appliquer pleinement. L'article 2, § 7, de l'AI Act, dans sa version issue du règlement (UE) 2026/1744, prévoit que le droit de l'Union sur la protection des données s'applique et que l'AI Act « n'a pas d'incidence sur » le RGPD, sans préjudice de l'article 4 bis et de l'article 59 (bacs à sable réglementaires). Un déployeur au sens de l'AI Act est en général aussi responsable du traitement au sens du RGPD : base légale, transparence et droits des personnes restent dus.
Les catégories particulières de données pour détecter les biais. L'article 10, § 5, permettait aux fournisseurs de systèmes à haut risque de traiter des catégories particulières de données, dans la stricte mesure nécessaire pour détecter et corriger les biais, sous six conditions cumulatives : pseudonymisation, aucune transmission à des tiers, effacement une fois le biais corrigé, justification écrite de l'impossibilité d'utiliser d'autres données, entre autres. Le règlement (UE) 2026/1744 a déplacé cette base juridique dans un nouvel article 4 bis, applicable depuis le 27 juillet 2026. Le paragraphe 1 conserve les conditions pour les fournisseurs de systèmes à haut risque. Le paragraphe 2 étend la base aux fournisseurs et déployeurs d'autres systèmes et modèles d'IA, ainsi qu'aux déployeurs de systèmes à haut risque, avec les mêmes garanties et le même critère de stricte nécessité. Il ne crée aucune obligation de détecter les biais.
AIPD et analyse d'impact sur les droits fondamentaux. Les déployeurs de systèmes à haut risque utilisent la notice du fournisseur (art. 13) pour leur analyse d'impact relative à la protection des données (AIPD) (art. 26, § 9, de l'AI Act ; art. 35 du RGPD). L'article 27 ajoute une analyse d'impact sur les droits fondamentaux, menée avant le déploiement, pour les organismes de droit public, les entités privées qui fournissent des services publics et les déployeurs des systèmes visés à l'annexe III, point 5, b) et c) : évaluation de la solvabilité et note de crédit, évaluation des risques et tarification en assurance vie et santé. Banques et assureurs sont donc directement concernés. Depuis 2026, cette analyse peut renvoyer à l'AIPD ou en reprendre des parties (art. 27, § 4), et le Bureau de l'IA doit fournir un modèle de questionnaire (art. 27, § 5). Elle s'applique à partir du 2 décembre 2027 pour les systèmes de l'annexe III.
La position du Comité européen de la protection des données (EDPB). Sa déclaration 3/2024 (16 juillet 2024) recommande de désigner les autorités de protection des données comme autorités de surveillance du marché pour les systèmes à haut risque énumérés à l'article 74, § 8. Son avis 28/2024 (17 décembre 2024) indique que les modèles d'IA entraînés sur des données personnelles ne sont pas toujours anonymes et propose un test en trois étapes pour l'intérêt légitime. Dans l'avis conjoint 1/2026 avec le Contrôleur européen de la protection des données (21 janvier 2026), il demandait de limiter l'extension du traitement pour la détection des biais. L'article 4 bis adopté conserve le critère de stricte nécessité.
Encore au stade de proposition : les modifications du RGPD prévues par l'omnibus numérique COM(2025) 837, dont une dérogation pour le traitement résiduel de catégories particulières de données pendant le développement de l'IA (voir le tableau des statuts plus haut).
Où les quatre textes se recoupent-ils pour une entreprise soumise à plusieurs d'entre eux ?
Prenons un groupe financier qui vend un logiciel connecté, utilise un système d'IA de notation de crédit et s'appuie sur des prestataires cloud.
Un incident, plusieurs notifications. Un rançongiciel exploite une faille du logiciel du groupe, perturbe les paiements et expose des données de clients. Cet événement unique peut lancer jusqu'à quatre chronomètres :
| Notification | Destinataire | Délai le plus court |
|---|---|---|
| DORA, incident majeur lié aux TIC | Autorité de supervision financière, qui transmet aux autorités NIS2 | 4 heures après la classification, 24 heures au plus après la prise de connaissance |
| RGPD, violation de données à caractère personnel | Autorité de protection des données | 72 heures, sauf si la violation n'est pas susceptible d'engendrer un risque (art. 33) |
| CRA, vulnérabilité activement exploitée ou incident grave | CSIRT coordinateur et ENISA, via la plateforme unique de signalement | 24 heures |
| AI Act, incident grave (à partir du 2 décembre 2027, si un système à haut risque qu'il fournit est en cause) | Autorité de surveillance du marché, c'est-à-dire l'autorité de supervision financière pour les services financiers (art. 74, § 6) | 15 jours au plus, moins dans certains cas |
Deux règles limitent le cumul des sanctions : l'article 35, § 2, de NIS2 exclut une amende NIS2 pour un comportement déjà sanctionné au titre du RGPD, et l'article 99, § 7, c), de l'AI Act impose de tenir compte des amendes infligées par d'autres autorités pour la même activité. L'article 73, § 9, de l'AI Act limite en outre le signalement des systèmes de l'annexe III aux atteintes aux droits fondamentaux lorsque le fournisseur notifie déjà au titre de règles de l'Union équivalentes. Que DORA compte comme règle équivalente doit s'apprécier au cas par cas.
Un seul cadre de risques. Les textes récompensent une base de contrôles unique :
- Faire du cadre de gestion du risque TIC de DORA (art. 6) la colonne vertébrale. Il peut accueillir les mesures de l'article 21 de NIS2 pour les entités non financières du groupe, le processus de sécurité des produits exigé par le CRA et le système de gestion des risques de l'AI Act (art. 9).
- S'appuyer sur les équivalences prévues par l'AI Act pour le secteur financier. Les établissements financiers remplissent l'essentiel du système de gestion de la qualité (art. 17, § 4) et l'obligation de surveillance des déployeurs (art. 26, § 5) par leurs règles de gouvernance sectorielles.
- Tenir un seul inventaire des fournisseurs. Le registre d'informations de DORA (art. 28, § 3) peut aussi consigner les évaluations de fournisseurs NIS2, les accords écrits exigés par l'article 25, § 4, de l'AI Act et les SBOM reçues au titre du CRA.
- Rédiger une seule procédure d'incident, avec une étape de qualification par texte et les délais ci-dessus.
ResiPlan évalue chaque contrôle une seule fois et le met en correspondance avec DORA, NIS2, le CRA, le RGPD et d'autres référentiels : référentiels de conformité.
Questions fréquentes (FAQ)
Une banque doit-elle notifier le même incident au titre de DORA et de NIS2 ?
Non. Elle notifie au titre de DORA à son autorité de supervision financière, qui transmet aux autorités NIS2 (art. 19, § 6, de DORA). Un État membre peut exiger en plus une copie directe. La notification d'une violation de données au titre du RGPD reste distincte.
Le Cyber Resilience Act s'applique-t-il au SaaS ?
En règle générale, non. NIS2 couvre les services cloud, dont le SaaS. Le CRA ne vise le traitement de données à distance que lorsqu'un produit en a besoin pour remplir l'une de ses fonctions.
Les obligations « haut risque » de l'AI Act sont-elles reportées ?
Oui, par la loi. Le règlement (UE) 2026/1744 fixe le 2 décembre 2027 pour les systèmes de l'annexe III et le 2 août 2028 pour ceux de l'annexe I. Les interdictions, la maîtrise de l'IA, les règles des modèles d'IA à usage général et la transparence (art. 50) s'appliquent déjà. Les systèmes génératifs mis sur le marché avant le 2 août 2026 ont jusqu'au 2 décembre 2026 pour marquer leurs contenus (art. 50, § 2, et 111, § 4).
Existe-t-il un portail européen unique pour notifier les incidents ?
Pas encore. La plateforme unique de signalement de l'ENISA ne sert qu'aux notifications des fabricants au titre du CRA. Le point d'entrée unique pour NIS2, le RGPD, DORA et d'autres textes reste une proposition (COM(2025) 837), et le Conseil préfère des points d'entrée nationaux.
Comment se comparent les amendes maximales ?
L'AI Act va jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires mondial pour les pratiques interdites. Viennent ensuite le RGPD (20 millions d'euros ou 4 %), le CRA (15 millions d'euros ou 2,5 %) et NIS2 (au moins 10 millions d'euros ou 2 % pour les entités essentielles). DORA laisse les montants applicables aux entités financières au droit national.
Sources
- Règlement (UE) 2022/2554 (DORA), art. 1er, 2, 5, 19, 26, 28, 30, 35, 46, 50 et 64
- Règlement délégué (UE) 2025/301 (contenu et délais des notifications d'incidents), art. 5
- Règlement délégué (UE) 2024/1772 (classification des incidents)
- Règlement délégué (UE) 2025/1190 (tests de pénétration fondés sur la menace)
- Règlement d'exécution (UE) 2024/2956 (modèles du registre d'informations)
- AES : désignation des prestataires tiers critiques de services TIC, 18 novembre 2025 (en anglais)
- Directive (UE) 2022/2555 (NIS2), considérant 28, art. 4, 20, 21, 23, 24, 32 à 35 et 41, annexes I et II
- Règlement (UE) 2024/2847 (Cyber Resilience Act), considérants 11, 12 et 24, art. 2, 8, 13, 14, 64, 69 et 71, annexe I
- ENISA : plateforme unique de signalement du CRA (Single Reporting Platform, en anglais)
- Commission européenne : obligations de notification du CRA (en anglais)
- Règlement (UE) 2024/1689 (AI Act), art. 2, 17, 25 à 27, 73, 74, 99, 101 et 113, annexe III
- Règlement (UE) 2026/1744 (omnibus numérique sur l'IA)
- Règlement (UE) 2016/679 (RGPD), art. 33, 35 et 83
- Proposition de la Commission COM(2025) 837 (omnibus numérique) et fiche de procédure du Parlement européen 2025/0360(COD)
- Fiche de procédure du Parlement européen 2026/0012(COD) (modifications ciblées de NIS2)
- EDPB : déclaration 3/2024 sur le rôle des autorités de protection des données dans le cadre de l'AI Act (en anglais)
- EDPB : avis 28/2024 sur les modèles d'IA
- EDPB et EDPS : avis conjoint 1/2026 sur l'omnibus numérique sur l'IA, communiqué du 21 janvier 2026 (en anglais)