NIS2, DORA et l’AI Act européen : pourquoi les organisations européennes peinent à suivre

Les organisations européennes ne manquent pas d’engagement en matière de conformité réglementaire. Elles peinent à s’y conformer parce que trois grands cadres réglementaires sont entrés en vigueur quasiment en même temps, avec des exigences qui se recoupent mais restent distinctes, des calendriers d’application incohérents selon les États membres, et des obligations de conformité qui imposent chacune leur propre documentation, audits et chaînes de preuves. Résultat : un environnement de conformité non seulement exigeant, mais aussi structurellement mal aligné avec la façon dont la plupart des organisations ont bâti leurs programmes de sécurité et de gouvernance.

Lors de la conférence Span Cyber Security Arena, l’experte en gouvernance de la cybersécurité Antonija Vojnović a chiffré le problème : 96 % des entreprises de services financiers en EMEA déclarent que leur résilience des données n’atteint pas encore les attentes de DORA. Ce chiffre ne concerne pas les organisations les moins préparées. Il reflète un quasi-consensus dans un secteur qui consacre pourtant d’importantes ressources à la conformité depuis des décennies.

NIS2, DORA et le règlement européen sur l’IA partagent un objectif commun : protéger les organisations et les personnes dont elles traitent les données contre les risques systémiques liés à la cybersécurité et à l’IA. Mais chacun l’opérationnalise avec des périmètres, des exigences de preuve et des organismes de contrôle différents. Pour les organisations soumises aux trois, la charge de conformité ne s’additionne pas : elle se multiplie.

5 points clés à retenir

1. Trois grands cadres réglementaires de l’UE sont appliqués simultanément, chacun avec des directives partielles seulement.

L’application de NIS2 varie selon les États membres. Les normes techniques RTS de DORA sont encore en cours de finalisation. L’échéance d’août 2026 pour les systèmes à haut risque du règlement IA est repoussée pour certaines catégories. Les organisations ne peuvent pas attendre que tout soit clarifié : elles doivent mettre en place leur infrastructure de conformité dès maintenant, alors même que les exigences évoluent encore.

2. 96 % des entreprises de services financiers EMEA estiment que leur résilience des données ne répond pas aux attentes de DORA.

DORA n’est pas une norme à atteindre, mais une norme opérationnelle, avec des exigences précises en matière de gestion des risques TIC, de classification et de notification des incidents, de supervision des prestataires tiers et de tests de résilience opérationnelle numérique. Un taux d’échec de 96 % signifie que le secteur part d’un déficit important — et que les contrôles manquants sont les mêmes que ceux exigés par NIS2 et le règlement IA.

3. La mise en œuvre de NIS2 varie fortement selon les États membres de l’UE.

Les multinationales opérant dans plusieurs pays font face à des calendriers d’audit différents, à des processus d’autorités nationales compétentes distincts, et à des interprétations parfois divergentes d’un même texte. L’obligation de notification préliminaire sous 24 heures ne s’adapte pas à ces variations : le dossier d’audit doit exister avant l’incident, pas être assemblé pendant celui-ci.

4. L’échéance d’août 2026 pour le traitement à haut risque du règlement IA approche, alors que la sensibilisation aux risques de fuite de données IA reste faible.

Les dépenses de l’UE en IA devraient atteindre 290 milliards de dollars d’ici 2029. Les organisations qui n’ont pas recensé les usages de l’IA sur des données réglementées sont déjà en retard sur une obligation qui expose à des amendes pouvant aller jusqu’à 7 % du chiffre d’affaires mondial. Le shadow AI — des outils utilisés hors du cadre de gouvernance — est directement concerné, car le règlement exige un inventaire documenté de l’IA comme étape préalable.

5. La solution architecturale consiste à utiliser une plateforme unique générant des preuves de conformité pour les trois cadres simultanément.

NIS2, DORA et le règlement IA exigent tous des contrôles d’accès, le chiffrement des données, la journalisation des incidents et des pistes d’audit. Les organisations qui mettent en œuvre ces contrôles une seule fois, sur une plateforme unifiée, répondent aux exigences des trois — sans devoir maintenir trois chaînes de preuves distinctes qui multiplient les coûts et les risques d’audit.

Ce que NIS2 exige réellement des organisations européennes

NIS2 élargit la directive initiale sur la sécurité des réseaux et des systèmes d’information aux secteurs de l’énergie, des transports, des infrastructures financières, de la santé et du numérique — et introduit une responsabilité directe des dirigeants en cas de manquement à la conformité. Les directeurs et cadres supérieurs des organisations concernées peuvent être tenus personnellement responsables de violations systématiques de NIS2, ce qui fait passer la gouvernance de la cybersécurité du service informatique au conseil d’administration.

Les exigences de fond de la directive incluent des mesures techniques et organisationnelles adaptées au risque, avec une attention particulière à la sécurité de la supply chain, au contrôle d’accès et au chiffrement des communications. Les organisations doivent notifier les autorités nationales compétentes dans les 24 heures après avoir pris connaissance d’un incident majeur, puis fournir un rapport plus détaillé sous 72 heures.

Les délais de notification de 24 et 72 heures sont le point de tension opérationnel. Pour les respecter, il faut disposer des journaux d’audit et des traces d’attribution avant qu’un incident ne survienne, et non les reconstituer pendant la crise. Les organisations qui s’appuient sur des journaux dispersés sur plusieurs plateformes — messagerie, transfert de fichiers, stockage cloud, MFT — pour reconstituer la chronologie d’une violation constateront que 24 heures passent très vite lorsqu’on les consacre à agréger des logs plutôt qu’à analyser l’incident.

La conformité NIS2 est aussi une obligation supply chain. Les organisations concernées doivent vérifier que leurs prestataires TIC critiques respectent des standards de sécurité équivalents — évaluations fournisseurs, exigences contractuelles de sécurité et capacité à démontrer que la posture de conformité s’étend aux dépendances tierces.

Ce que DORA exige et que la plupart des entreprises financières n’ont pas encore

DORA s’applique aux entités financières régulées au niveau européen — banques, sociétés d’investissement, compagnies d’assurance, établissements de paiement, ainsi qu’à leurs prestataires TIC critiques — et instaure un cadre unifié pour la résilience opérationnelle numérique dans le secteur financier de l’UE. Contrairement à NIS2, qui fixe des exigences minimales et laisse les États membres les renforcer, DORA est un règlement, non une directive. Ses exigences s’appliquent directement et uniformément dans tous les États membres.

Le taux d’échec de 96 % en EMEA reflète l’écart entre les attentes opérationnelles de DORA et la façon dont la plupart des institutions financières ont historiquement structuré leur gestion des risques TIC. DORA impose un cadre de gestion des risques TIC couvrant l’identification, la protection, la détection, la réponse et la reprise. Les organisations doivent classer les incidents TIC selon les critères de DORA et signaler les incidents majeurs dans des délais précis.

Les exigences de DORA en matière de gestion des risques TIC s’étendent à la gestion des données en transit et au repos sur tous les canaux opérationnels. Les systèmes de transfert sécurisé de fichiers chiffrés par lesquels les institutions financières échangent des données sensibles avec des contreparties, régulateurs et prestataires doivent répondre aux standards de sécurité de DORA. Beaucoup découvrent que leur infrastructure MFT existante, conçue pour la performance plus que pour la conformité, ne fournit pas la profondeur de piste d’audit exigée par DORA.

Les dispositions de DORA sur les risques liés aux tiers imposent aux entités financières de tenir un registre de tous les prestataires TIC soutenant des fonctions critiques ou importantes, de réaliser des due diligences, d’inclure des clauses contractuelles spécifiques sur la sécurité et la notification des incidents, et de démontrer un suivi continu de la performance des prestataires. Pour les organisations habituées à des relations fournisseurs informelles, constituer ce registre et l’infrastructure contractuelle requise représente un travail de plusieurs mois.

Pourquoi le règlement IA arrive dans un environnement déjà sous tension

Le règlement européen sur l’IA ajoute une troisième dimension de conformité à un environnement déjà mis à l’épreuve par NIS2 et DORA. Ses exigences pour les systèmes d’IA à haut risque — couvrant l’IA utilisée dans l’emploi, le crédit, l’éducation, l’application de la loi et la gestion des infrastructures critiques — imposent des obligations en matière de gestion des risques, de gouvernance des données, de transparence et de supervision humaine, le tout dans un cadre juridique et avec des mécanismes de contrôle différents.

L’observation de Vojnović — la faible sensibilisation aux risques de fuite de données liés à l’IA d’entreprise — est significative. Les organisations soumises au règlement IA doivent non seulement gouverner les systèmes d’IA qu’elles déploient intentionnellement, mais aussi prendre en compte l’IA qui s’introduit dans leur environnement via des fonctionnalités intégrées à des logiciels d’entreprise, des intégrations tierces et des outils adoptés par les employés. Le problème du shadow AI est crucial, car le règlement impose un inventaire documenté de l’IA comme étape préalable à toute autre obligation.

Le problème des preuves qui se recoupent

Ce qui rend l’environnement NIS2-DORA-règlement IA particulièrement difficile, ce n’est pas que les exigences soient individuellement irréalistes. Le problème est opérationnel : répondre aux trois simultanément impose de générer des preuves selon trois vocabulaires réglementaires, à partir de trois ensembles de systèmes techniques, pour trois processus d’audit distincts.

NIS2 exige des traces de détection et de notification d’incidents. DORA réclame une documentation sur la gestion des risques TIC et des journaux de classification des incidents. Le règlement IA requiert des évaluations de risques sur les systèmes d’IA et une documentation sur la gouvernance des données. Les contrôles sous-jacents qui produisent ces preuves — journalisation des accès, chiffrement des données, pistes d’audit, procédures de réponse aux incidents — sont pour l’essentiel identiques. Le problème, c’est que la plupart des organisations ont mis en place ces contrôles en silos : un jeu de logs pour la messagerie, un autre pour le transfert de fichiers, un troisième pour le stockage cloud, sans dossier unifié permettant de satisfaire les trois cadres à partir d’une source unique et fiable.

L’architecture Zero trust répond à ce défi en considérant chaque accès ou échange de données comme une décision de politique à authentifier, autoriser, attribuer et journaliser. Dans un environnement Zero trust, la piste d’audit est continue et complète par conception, et non reconstituée a posteriori : elle fournit les preuves exigées par NIS2 pour la notification d’incident, par DORA pour la gestion des risques TIC, et par le règlement IA pour la gouvernance des données, à partir d’un seul dossier avec une attribution cohérente.

Ce que change l’approche plateforme unifiée

La plateforme Kiteworks propose des fonctions de conformité NIS2, DORA et RGPD à partir d’une architecture unique. Le chiffrement validé FIPS 140-3, les contrôles d’accès appliqués par ABAC et la journalisation inviolable s’appliquent à chaque échange de contenu — messagerie électronique, SFTP, transfert sécurisé de fichiers, partage sécurisé de fichiers — via le même moteur de règles et la même piste d’audit.

Pour DORA, les preuves de classification des incidents TIC, les logs de communication avec les tiers et la documentation sur le contrôle d’accès que les autorités de supervision demanderont lors d’un audit DORA sont déjà présents dans la piste d’audit Kiteworks. Pour NIS2, les délais de notification préliminaire de 24 heures et de rapport détaillé sous 72 heures deviennent gérables lorsque la piste d’audit existe déjà. Pour le règlement IA, le Kiteworks Secure MCP Server et l’AI Data Gateway régissent les accès des agents IA et journalisent chaque interaction dans le même dossier inviolable que les interactions humaines.

L’objectif n’est pas de traiter chaque règlement comme un projet d’implémentation distinct. Il s’agit de bâtir l’infrastructure de sécurité et de gouvernance requise par les trois cadres, une seule fois, et de générer les preuves attendues à partir de cette fondation unique. Le Réseau de données privé Kiteworks constitue cette base.

Pour en savoir plus sur la façon de prouver la conformité à ces réglementations et à d’autres en matière de protection des données, réservez votre démo sans attendre !

Ressources complémentaires

• Article de blog Guerre d’influence sur vos données : comment les lois CLOUD et SHIELD opposent sécurité et confidentialité
• Article de blog Sécurisez les données sensibles en alignant le DSPM sur vos objectifs de conformité
• Brief Top 3 des violations FERPA et comment les éviter
• Article de blog Executive Order 14117 : protéger les données personnelles sensibles des Américains
• Article de blog Besoin de conformité NIS2 ? Commencez par ISO 27001