Enseigner NIS2, DORA et le Cyber Resilience Act en une journée de cours

Pourquoi regrouper NIS2, DORA et CRA dans une même journée ?

La réglementation cybersécurité de l'Union européenne s'est considérablement densifiée depuis 2022. Les étudiants en cybersécurité, en droit du numérique ou en management des risques doivent désormais comprendre au moins trois textes majeurs : la directive NIS2, le règlement DORA et le Cyber Resilience Act (CRA). Chacun a son périmètre propre, ses obligations spécifiques et ses délais.

Traiter ces textes séparément, dans des modules distincts, présente un risque pédagogique réel : les étudiants ne voient pas les liens, les recoupements et les tensions entre les textes. Ils sortent du cours avec une connaissance fragmentée, incapables de raisonner sur un cas pratique qui croise plusieurs obligations.

Une journée thématique « réglementation UE cyber » répond à cet enjeu. Elle n'ambitionne pas de former des juristes — c'est une erreur classique de conception — mais de donner aux futurs professionnels un modèle mental opérationnel : qui est concerné, par quoi, et avec quelles conséquences pratiques.

Ce format est particulièrement adapté aux cursus GRC, aux masters management de la sécurité, et aux parcours de formation continue pour professionnels.

Panorama express : ce que chaque texte impose (et à qui)

Avant d'entrer dans la pédagogie, voici les faits réglementaires que vous devez maîtriser et transmettre avec précision.

NIS2 : la directive sécurité des réseaux et systèmes d'information

La Directive (UE) 2022/2555 — dite NIS2 — a été transposée en France par la Loi n° 2024-449 du 21 mai 2024. Elle élargit considérablement le champ de la précédente directive NIS en couvrant 18 secteurs d'activité (énergie, transports, banque, santé, eau, infrastructure numérique, etc.) et en distinguant deux catégories d'entités :

• Entités essentielles (EE) : grandes organisations dans des secteurs critiques
• Entités importantes (EI) : organisations moyennes dans les mêmes secteurs ou dans des secteurs étendus

Les obligations clés : mettre en place des mesures de sécurité proportionnées (gouvernance, gestion des risques, sécurité de la chaîne d'approvisionnement), notifier les incidents significatifs dans un délai de 24 heures pour l'alerte précoce et 72 heures pour la notification complète, et désigner un responsable de la sécurité au niveau de la direction.

DORA : la résilience opérationnelle numérique du secteur financier

Le Règlement (UE) 2022/2554 — DORA, Digital Operational Resilience Act — est directement applicable dans tous les États membres depuis le 17 janvier 2025, sans transposition nécessaire. Il s'adresse aux entités financières (banques, compagnies d'assurance, sociétés de gestion, établissements de paiement) et à leurs prestataires de services ICT critiques.

Ses piliers : gestion des risques ICT, signalement des incidents opérationnels majeurs, tests de résilience opérationnelle numérique (dont les tests de pénétration à pilotage par la menace, TLPT), gestion du risque lié aux tiers, et partage d'informations.

Point pédagogique clé : DORA concerne non seulement les banques, mais aussi leurs fournisseurs technologiques — une dimension supply chain souvent sous-estimée.

Cyber Resilience Act : la sécurité des produits numériques

Le Règlement (UE) 2024/2847 — Cyber Resilience Act — a été publié au Journal officiel de l'Union européenne le 20 novembre 2024 et est entré en vigueur le 11 décembre 2024. Il s'applique aux produits comportant des éléments numériques mis sur le marché de l'UE : objets connectés, logiciels, applications mobiles, composants matériels avec firmware.

Les obligations principales : concevoir des produits secure-by-default, fournir un SBOM (Software Bill of Materials), signaler les vulnérabilités activement exploitées dans un délai de 24 heures à l'ENISA et à l'autorité nationale compétente, assurer le support sécurité pendant toute la durée de vie du produit (au minimum 5 ans).

Le CRA est une révolution pour l'enseignement du développement logiciel : il rend la sécurité obligatoire dès la conception, et non plus optionnelle ou ajoutée en post-production.

Tableau comparatif

Séquence pédagogique : 7 heures structurées

Voici un déroulé opérationnel pour une journée complète (9h–17h30, avec pauses).

9h00 – 9h45 : Introduction et mise en contexte (45 min)

Commencez par ancrer la journée dans la réalité professionnelle des étudiants. La question centrale : pourquoi un ingénieur, un consultant ou un manager de la sécurité doit-il comprendre la réglementation ?

• Tour de table rapide : qui a déjà rencontré NIS2, DORA ou CRA dans un stage, une alternance, une actualité ?
• Mise en situation : présenter un cas fictif d'organisation multi-profil (ESN qui développe des logiciels pour des banques, donc potentiellement concernée par les trois textes)
• Cartographie rapide : dessiner au tableau le paysage réglementaire UE cyber (NIS2 + DORA + CRA + RGPD + AI Act) pour situer les trois textes du jour

10h00 – 11h30 : NIS2 en détail (90 min)

Structure recommandée :

• 20 min : panorama (périmètre, catégories d'entités, calendrier)
• 30 min : obligations opérationnelles (gouvernance, gestion des risques, supply chain, signalement)
• 20 min : quiz interactif de positionnement (« cette entreprise est-elle entité essentielle ou importante ? »)
• 20 min : atelier micro-groupe — identifier les obligations applicables à une entité fictive du secteur santé

Ressource à préparer : une fiche de décision en une page (secteur → catégorie → obligations prioritaires).

11h30 – 13h00 : DORA en détail (90 min)

Structure recommandée :

• 20 min : panorama (champ d'application, piliers, articulation avec NIS2)
• 30 min : focus sur le risque tiers ICT et les TLPT
• 20 min : cas pratique — un prestataire cloud héberge les données d'une banque, que se passe-t-il en cas d'incident ?
• 20 min : discussion — les implications pour les étudiants qui rejoindront le secteur financier ou les ESN

Lien pédagogique avec le cours sur la gestion de crise : DORA impose des tests de résilience qui ressemblent à des exercices de crise — si les étudiants ont déjà suivi ce module, faites le lien explicitement.

14h00 – 15h30 : Cyber Resilience Act en détail (90 min)

Structure recommandée :

• 20 min : panorama (produits concernés, obligations fabricants, cycle de vie)
• 30 min : focus sur le SBOM et le secure-by-default (concepts techniques à bien expliquer)
• 20 min : démonstration rapide — générer un SBOM avec un outil open source à partir d'un projet simple
• 20 min : atelier — identifier les obligations CRA applicables à un objet connecté fictif (caméra de surveillance, routeur, application mobile)

Le CRA est un bon point d'entrée pour les étudiants de profil développeur : il ancre la réglementation dans leur pratique quotidienne plutôt que dans des abstractions organisationnelles.

15h45 – 16h45 : Synthèse et convergences (60 min)

C'est la partie la plus pédagogiquement riche de la journée. Les étudiants ont maintenant les trois textes en tête ; il s'agit de construire une vision intégrée.

Points de convergence à souligner :

• Les trois textes partagent une logique de gestion des risques : identifier, mesurer, traiter, documenter
• Les délais de signalement sont courts dans les trois cas — cela implique des processus préparés à l'avance
• La supply chain est un fil rouge commun : NIS2 impose de contrôler les fournisseurs, DORA impose de contrôler les prestataires ICT, le CRA impose de contrôler les composants logiciels

Points de divergence :

• NIS2 est une directive (transposition nationale), DORA et CRA sont des règlements (application directe) — implication pratique : des différences d'implémentation peuvent exister entre pays UE pour NIS2
• Les autorités compétentes diffèrent : ANSSI pour NIS2 en France, autorités de supervision financière pour DORA, ENISA/ANSSI pour CRA
• Le CRA s'applique aux produits, NIS2 et DORA aux organisations — un même acteur peut relever des trois régimes simultanément

17h00 – 17h30 : Clôture et mise en perspective (30 min)

• Retour sur la mise en situation initiale : maintenant que vous connaissez les trois textes, comment qualifiez-vous l'ESN du matin ?
• Questions ouvertes sur les évolutions attendues (actes délégués DORA, phase d'application progressive du CRA)
• Ressources pour rester à jour (voir section dédiée)

Ateliers pratiques : cas école par type d'organisation

Pour rendre la journée plus concrète, préparez trois fiches de cas adaptées aux profils d'organisations :

Cas 1 : L'hôpital régional (NIS2, secteur santé)

Scénario : l'hôpital est entité essentielle. Il utilise un logiciel de gestion des patients développé par une ESN externe. La semaine dernière, un incident a touché le logiciel : accès non autorisé à des données de planification chirurgicale. Questions : L'hôpital doit-il notifier ? Dans quel délai ? Qui notifie ? La chaîne d'approvisionnement est-elle en cause ?

Cas 2 : La néobanque (DORA, secteur financier)

Scénario : la néobanque utilise trois fournisseurs cloud critiques pour ses opérations de paiement. L'un d'eux subit une panne majeure pendant 4 heures. Questions : S'agit-il d'un incident opérationnel majeur à notifier ? Quelles obligations de test de résilience cette relation implique-t-elle ? La néobanque devait-elle avoir un plan de continuité pour ce scénario ?

Cas 3 : La startup IoT (CRA, fabricant de produit numérique)

Scénario : la startup commercialise un capteur industriel connecté avec firmware mis à jour à distance. Une vulnérabilité critique est découverte dans le composant Bluetooth. Questions : La startup doit-elle notifier ? Dans quel délai ? Comment prouver que le produit était secure-by-default à sa sortie ? Dispose-t-elle d'un SBOM ?

Les points de convergence et de divergence à souligner

Au-delà des ateliers, voici les messages clés à ancrer chez les étudiants.

Ce que les trois textes ont en commun

La doctrine de la responsabilité proactive. Les trois régimes partagent une même philosophie : l'organisation ou le fabricant ne peut plus se contenter de réagir à un incident. Il doit démontrer ex ante qu'il a pris les mesures appropriées. Cette logique de preuve documentaire est fondamentale : tenir un registre des risques, conserver les résultats des tests, journaliser les décisions de sécurité.

Le signalement rapide comme obligation structurante. Vingt-quatre heures est un délai très court pour des organisations qui n'ont pas préparé leurs processus en amont. L'enseignement à retenir : les procédures de signalement doivent être conçues avant l'incident, testées régulièrement, et connues de toutes les parties prenantes.

La certification CISM comme référentiel de compétence pour les professionnels qui gèrent la conformité à ces textes : elle couvre exactement les compétences de gouvernance, de gestion des risques et de réponse à incident attendues par NIS2 et DORA.

Ce qui différencie les trois régimes

La portée sectorielle est la principale différence opérationnelle. NIS2 est horizontal (couvre de nombreux secteurs), DORA est vertical (finance uniquement, mais très profond), le CRA est transversal (tous les produits numériques). Un prestataire cloud qui sert des banques peut se retrouver dans le périmètre de DORA même s'il n'est pas lui-même une entité financière — c'est un point que beaucoup d'organisations ont sous-estimé.

Pour aller plus loin, l'article dédié à enseigner la résilience numérique avec DORA détaille les ateliers spécifiques à ce règlement.

Ressources officielles et mises à jour

Les sources à utiliser en cours

• ANSSI (anssi.gouv.fr) : transposition NIS2, guides sectoriels, base de connaissance
• BCE et ESA (eba.europa.eu, esma.europa.eu) : normes techniques réglementaires DORA (RTS/ITS)
• Commission européenne (digital-strategy.ec.europa.eu) : textes consolidés CRA, questions-réponses
• ENISA (enisa.europa.eu) : rapports de menaces, lignes directrices CRA

Maintenir le cours à jour sans le refaire entièrement

Le squelette pédagogique de cette journée — la séquence, les cas pratiques, les exercices de convergence — est stable. Ce qui évolue, ce sont les actes délégués (DORA publie régulièrement des RTS), les délais d'application progressive du CRA, et les premières décisions de sanction sous NIS2.

Planifiez 30 minutes de mise à jour annuelle : vérifier les actes délégués DORA publiés depuis la dernière version, mettre à jour la date d'application CRA si une phase a démarré, vérifier si des sanctions NIS2 ont été prononcées et utilisables comme cas.

Cette maintenance est documentée et délégable à un étudiant en master qui peut faire ce travail de veille dans le cadre d'un projet tutoré — c'est en soi un bon exercice de veille réglementaire.

Ce qu'il faut retenir

• NIS2, DORA et CRA ne s'excluent pas : une organisation peut relever des trois simultanément. La journée doit construire cette vision intégrée, pas trois silos.
• L'objectif n'est pas de former des juristes mais de donner un modèle opérationnel : qui est concerné, par quoi, avec quels délais.
• La séquence des 7 heures — panorama, détail par texte, synthèse des convergences — est reproductible et maintient les étudiants engagés grâce aux ateliers pratiques intercalés.
• Les faits réglementaires doivent être exacts : dates d'entrée en vigueur, délais de signalement, autorités compétentes. Une erreur factuelle devant une promo de futurs professionnels fragilise toute la crédibilité du cours.
• Maintenez le cours à jour : prévoir 30 minutes annuelles de mise à jour, délégables à un étudiant dans le cadre d'un projet de veille.

Vous cherchez un intervenant capable d'animer cette journée réglementaire avec la rigueur et le dynamisme qu'elle exige ? Cyber Teachers vous connecte avec des formateurs spécialisés en GRC et réglementation UE cyber.