Florian Amette

Florian Amette

June 27, 2026

Directive DORA : enseigner la résilience numérique dans les cursus finance & tech

DORArésilience numériqueréglementationfinancegestion de crise
Directive DORA : enseigner la résilience numérique dans les cursus finance & tech

Directive DORA : enseigner la résilience numérique dans les cursus finance & tech

Depuis le 17 janvier 2025, le règlement DORA (Digital Operational Resilience Act, règlement UE 2022/2554) s'applique à l'ensemble du secteur financier européen. Pour vos étudiants en master finance, en école de commerce ou en école d'ingénieurs orientée banque/fintech, c'est devenu un sujet incontournable : ils le rencontreront dès leurs premiers stages en conformité, en risk management ou en sécurité opérationnelle.

Le problème pédagogique est connu. DORA est un texte dense, transversal, à cheval entre le droit, la finance et la cybersécurité. Enseigné de façon purement juridique, il endort une salle. Enseigné de façon trop technique, il perd un public finance. Cet article propose une approche concrète : vulgariser les concepts, les relier à la continuité d'activité, les incarner dans un cas banque/prestataire, et les faire vivre par un exercice de crise jouable en deux heures.

Concepts DORA vulgarisés pour étudiants

Commencez toujours par le pourquoi. Avant DORA, la réglementation financière encadrait surtout le capital, la liquidité et le risque de marché. Le risque informatique restait traité de manière fragmentée, secteur par secteur, pays par pays. Or une panne ou une cyberattaque sur un système de paiement peut paralyser une banque aussi sûrement qu'une crise de liquidité. DORA comble ce vide : il impose un cadre unique et harmonisé de résilience opérationnelle numérique à toute l'Europe financière.

Première chose à clarifier en cours : DORA est un règlement, pas une directive. Contrairement à NIS2 et la formation cyber, qui doit être transposée dans chaque droit national, un règlement s'applique directement, à la même date, dans les 27 États membres. C'est une excellente occasion d'enseigner la différence règlement/directive, souvent floue pour les étudiants.

Le « qui » : DORA vise une vingtaine de catégories d'entités financières — banques, assureurs, entreprises d'investissement, établissements de paiement et de monnaie électronique, prestataires de services sur crypto-actifs, agences de notation, gestionnaires de fonds. Et, point central pour la suite, il s'étend à leurs prestataires de services TIC critiques (technologies de l'information et de la communication), notamment les grands fournisseurs cloud lorsqu'ils sont désignés comme critiques.

Présentez ensuite l'architecture du texte autour de ses cinq piliers. C'est la colonne vertébrale de tout votre cours.

  • 1. Gestion du risque lié aux TIC. L'entité doit cartographier ses systèmes, identifier ses fonctions critiques, évaluer ses risques et mettre en place un cadre de gouvernance. La responsabilité finale incombe à l'organe de direction — un point fort à souligner : DORA fait remonter le risque IT au niveau du conseil d'administration.
  • 2. Notification des incidents liés aux TIC. Les incidents majeurs doivent être classifiés et déclarés aux autorités compétentes selon un calendrier précis (notification initiale, intermédiaire, finale). L'objectif : donner aux régulateurs une vue en temps quasi réel des chocs sur le système financier.
  • 3. Tests de résilience opérationnelle numérique. Les entités testent régulièrement leurs systèmes. Les plus significatives doivent réaliser des TLPT (Threat-Led Penetration Testing), des tests d'intrusion fondés sur des scénarios de menace réalistes.
  • 4. Gestion du risque lié aux tiers TIC. L'entité reste responsable même quand elle externalise. DORA encadre les contrats, exige des clauses minimales, impose un registre des prestataires et instaure une supervision directe des fournisseurs critiques par les autorités européennes.
  • 5. Partage d'informations. DORA encourage l'échange volontaire de renseignements sur les cybermenaces entre entités financières, pour élever le niveau collectif.

Une formule simple à donner aux étudiants : les piliers 1 et 2 organisent la maison, le pilier 3 la met à l'épreuve, le pilier 4 surveille les voisins, le pilier 5 fait circuler l'alerte.

Liens avec continuité d'activité et tests de résilience

DORA n'invente pas la résilience à partir de rien : il durcit et généralise des pratiques que vos étudiants doivent déjà connaître. C'est l'occasion de raccrocher le règlement à un socle de continuité d'activité classique.

BCP, DRP et les indicateurs RTO/RPO

Distinguez clairement les deux plans :

  • Le PCA (plan de continuité d'activité, BCP) décrit comment l'organisation continue de fonctionner pendant une crise — locaux de repli, procédures dégradées, mobilisation des équipes.
  • Le PRA (plan de reprise d'activité, DRP) décrit comment on restaure les systèmes informatiques après un sinistre — bascule sur site secondaire, restauration de sauvegardes, remise en service.

Introduisez ensuite les deux indicateurs que tout étudiant doit savoir manier :

  • Le RTO (Recovery Time Objective) : la durée maximale d'interruption acceptable avant remise en service. « En combien de temps doit-on être de nouveau opérationnel ? »
  • Le RPO (Recovery Point Objective) : la quantité maximale de données que l'on accepte de perdre, exprimée en temps. « Jusqu'à quel point dans le passé doit-on pouvoir restaurer ? »

Un exercice de tableau efficace : faites estimer aux étudiants RTO et RPO pour différentes fonctions d'une banque (système de paiement, site vitrine, reporting interne). Ils comprennent vite qu'un système de paiement tolère quelques minutes là où un site vitrine tolère plusieurs heures — et que ces choix coûtent cher en architecture. Le métier qui pilote cette démarche est le responsable continuité, un débouché concret à mentionner.

Du test classique au TLPT

Le pilier 3 mérite une explication soignée. Tous les tests de résilience ne se valent pas. DORA reconnaît un éventail : analyse de vulnérabilités, tests de scénarios, tests de continuité, et au sommet le TLPT.

Le TLPT n'est pas un audit cosmétique. C'est une simulation d'attaque réaliste, menée par des testeurs externes qualifiés, fondée sur la threat intelligence propre à l'entité — quels groupes l'attaqueraient, avec quelles techniques. Le test cible les systèmes de production réels supportant les fonctions critiques. Il s'aligne sur le cadre européen TIBER-EU. Précisez aux étudiants que seules les entités les plus significatives y sont soumises, tous les trois ans environ : ce n'est pas une obligation universelle, contrairement à une idée répandue.

Cas banque / prestataire critique

Rien ne vaut un cas fil rouge. Voici un scénario à projeter et enrichir tout au long du cours.

Le décor. Banque Méridienne est une banque de taille moyenne, agréée en France, entité financière au sens de DORA. Pour réduire ses coûts, elle a migré son cœur applicatif de paiement et son moteur d'authentification chez NimbusCloud, un grand fournisseur d'infrastructure cloud. NimbusCloud héberge aussi des dizaines d'autres banques européennes : à ce titre, il a été désigné prestataire TIC tiers critique par les autorités de supervision.

Faites travailler les étudiants sur trois angles, un par groupe.

Angle gouvernance et tiers (pilier 4). Que doit contenir le contrat entre Méridienne et NimbusCloud ? Les étudiants listent les clauses imposées par DORA : droits d'audit, localisation des données, niveaux de service, coopération avec les autorités, stratégie de sortie (que se passe-t-il si l'on doit quitter NimbusCloud ?). Point clé à marteler : l'externalisation ne transfère pas la responsabilité. Méridienne reste comptable de la résilience devant son régulateur, même si la panne vient du prestataire. C'est le piège mental le plus fréquent chez les étudiants.

Angle concentration. NimbusCloud héberge des dizaines de banques. Demandez : quel est le risque que personne ne maîtrise individuellement ? Les étudiants découvrent le risque de concentration systémique — une seule défaillance technique peut frapper tout un pan du secteur financier en même temps. C'est précisément ce qui justifie la supervision directe des prestataires critiques par les autorités européennes au titre du pilier 4.

Angle incident (pilier 2). Un dimanche, une attaque par DDoS sature les passerelles de NimbusCloud. Les paiements de Méridienne tombent. Quand l'incident devient-il « majeur » ? Qui déclare quoi, à qui, dans quels délais ? Les étudiants reconstituent la chaîne de notification (initiale, intermédiaire, finale) vers l'autorité compétente, et mesurent la difficulté : au début d'une crise, on ne sait pas encore si c'est une attaque, une panne, ou les deux.

Ce cas unique permet de balayer quatre des cinq piliers sans changer de contexte — un atout pédagogique majeur pour ancrer la mémoire.

Exercices de crise en salle

Passez maintenant à l'action avec un exercice de crise sur table (tabletop) entièrement jouable en deux heures. Pas de matériel technique : papier, minuteur, et des injects que vous distribuez au fil du temps. L'objectif n'est pas de « gagner », mais de faire vivre la pression décisionnelle et de produire des livrables. Pour structurer votre animation, appuyez-vous sur les méthodes du cours gestion de crise.

Préparation et rôles

Constituez une cellule de crise de 6 à 8 étudiants. Attribuez les rôles suivants par carte distribuée :

  • Directeur de crise : préside, arbitre, décide. Garant du temps.
  • RSSI / responsable sécurité : analyse technique de l'incident.
  • Responsable continuité : active le PCA/PRA, suit RTO/RPO.
  • Responsable conformité / juridique : pilote la notification réglementaire DORA.
  • Communication : rédige les messages internes et externes.
  • Relation prestataire : seul point de contact avec NimbusCloud.
  • Secrétaire de crise : tient la main courante horodatée (livrable obligatoire).

Les autres étudiants forment un jury d'observation, grille en main.

Déroulé chronologique (injects)

Distribuez les injects à intervalles fixes. Annoncez à voix haute que le temps est compressé : chaque tranche de 15 minutes réelles représente plusieurs heures de crise.

  • T+0 (inject 1). « Lundi 09h12 — les paiements par carte de Banque Méridienne échouent en masse. Le support croule sous les appels clients. Cause inconnue. » La cellule s'organise et ouvre la main courante.
  • T+15 (inject 2). « NimbusCloud confirme un incident sur son infrastructure de la région européenne. Pas d'estimation de rétablissement. » La relation prestataire et la continuité entrent en jeu.
  • T+30 (inject 3). « Le RSSI identifie une attaque DDoS en cours, doublée d'un comportement anormal sur le moteur d'authentification : une exfiltration de données n'est pas exclue. » L'incident bascule potentiellement en violation de données.
  • T+45 (inject 4). « Un journaliste appelle. Des clients postent des captures d'écran sur les réseaux sociaux. L'autorité de supervision demande un premier point. » Communication et conformité sont sous tension simultanée.
  • T+60 (inject 5). « NimbusCloud annonce un rétablissement progressif sous 2 heures, mais recommande de réinitialiser les sessions d'authentification. » Décision : bascule en mode dégradé ou attente ?

Ce que les étudiants doivent produire

Imposez trois livrables concrets, remis en fin de séance :

  1. La main courante horodatée des décisions.
  2. Un projet de notification d'incident DORA : qualification (majeur ou non), faits connus, mesures prises, destinataire.
  3. Un message de communication externe de cinq lignes, validé par la cellule.

Débriefing

Réservez 20 minutes. Trois questions structurent le débrief : à quel moment a-t-on perdu le contrôle du temps ? La notification réglementaire a-t-elle été traitée trop tard, faute de la juger prioritaire ? La frontière entre « panne fournisseur » et « responsabilité de la banque » a-t-elle été assumée ? Ce débrief est souvent le moment où les concepts DORA s'ancrent durablement.

Ressources pour mise à jour annuelle du cours

DORA est un texte vivant. Le règlement de base est complété par des normes techniques — les RTS (Regulatory Technical Standards) et ITS (Implementing Technical Standards) — élaborées par les autorités européennes. Un cours figé devient faux en un ou deux ans. Prévoyez une révision annuelle, idéalement à l'été avant la rentrée.

Les sources à suivre en priorité :

  • Les trois ESAs (European Supervisory Authorities) : l'EBA (banques), l'EIOPA (assurances) et l'ESMA (marchés). Elles publient et mettent à jour les standards techniques et les guidelines DORA. Leurs sites hébergent les versions consolidées.
  • EUR-Lex pour le texte de référence du règlement 2022/2554 et de ses actes délégués.
  • L'ENISA, l'agence européenne de cybersécurité, pour les ressources sur la gestion d'incident et les menaces, utiles aux piliers 2 et 5.
  • En France, l'ACPR (superviseur banque/assurance) et l'AMF (marchés) pour la mise en œuvre nationale et les attentes des régulateurs.
  • Le cadre TIBER-EU publié par la BCE pour tout ce qui touche aux TLPT du pilier 3.

Côté certifications professionnelles, indiquez à vos étudiants que les référentiels d'audit des systèmes d'information comme le CISA recoupent largement les compétences attendues par DORA — gouvernance, gestion du risque tiers, continuité. C'est une passerelle naturelle vers l'emploi.

Astuce d'enseignant : tenez un fichier de veille daté. À chaque publication d'un RTS ou d'une guideline, notez la source, la date, et la diapositive du cours impactée. La mise à jour annuelle se fait alors en une après-midi plutôt qu'en une reconstruction complète.

Ce qu'il faut retenir

DORA n'est pas qu'un texte juridique de plus : c'est une grille de lecture qui relie cybersécurité, finance et gouvernance autour d'une idée simple, la résilience opérationnelle. Pour l'enseigner efficacement, partez du pourquoi, structurez tout autour des cinq piliers, raccrochez-les à la continuité d'activité (PCA/PRA, RTO/RPO), puis incarnez le tout dans un cas banque/prestataire et un exercice de crise jouable.

Vos étudiants n'ont pas besoin d'être des experts techniques pour comprendre DORA : ils ont besoin de saisir que la responsabilité ne s'externalise pas, que l'incident se déclare dans des délais contraints, et que la résilience se teste. C'est cette posture — concrète, décisionnelle, à jour — qui les rendra opérationnels dès leur premier poste en banque ou en fintech.

Vous construisez ou actualisez un module sur la résilience numérique ? Découvrez les ressources et l'accompagnement de Cyber Teachers pour enseigner la cybersécurité avec des cas réels et des exercices prêts à l'emploi.

Tous les articles →

Transformez vos formations cybersécurité avec des experts

Expert qualifié en 24h • Formation sur-mesure • Consultation gratuite

Cyber Teachers