BRIEFING SÉCURITÉ · 13.08.2026 DEENFRES

Stratégie & Gouvernance

DORA en fonction : ce que la surveillance veut voir

Par Alec Chizhik · 29 juin 2026 · 8 min de lecture

DORA s’applique directement dans toute l’UE depuis janvier 2025, pourtant fin 2025, seule la moitié environ des établissements financiers avaient pleinement mis en œuvre ses exigences. En 2026, la pression devient opérationnelle : le registre des prestataires tiers ICT doit être finalisé, les tests d’intrusion basés sur les menaces sont à l’ordre du jour et les fournisseurs critiques de services cloud passent sous la supervision directe de l’UE.

Points clés

  • Le délai est arrivé : Le registre des prestataires tiers ICT devait être déclaré à la BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht – Autorité fédérale de supervision financière allemande) avant le 30 mars 2026 et doit être maintenu à jour en continu. Ceux qui le considèrent comme un exercice ponctuel échoueront lors du prochain audit.
  • Les tests deviennent sérieux : Pour les établissements d’importance systémique, des tests d’intrusion basés sur les menaces, couvrant l’ensemble de la chaîne d’approvisionnement ICT, sont désormais obligatoires. La BaFin précisera les exigences au cours de l’année.
  • Le cloud est concerné : 19 prestataires de services informatiques sont considérés comme des fournisseurs tiers critiques sous supervision directe de l’UE, parmi lesquels les grands hyperscalers. Cela modifie les responsabilités et le rapport de force dans les négociations.

À lire aussi :Quand le compte à rebours des délais de déclaration commence vraiment  /  Loi-cadre KRITIS : quand la résilience devient une obligation pour le RSSI

DORA s’applique, mais la mise en œuvre traîne

Qu’est-ce que DORA ? DORA (Digital Operational Resilience Act) est un règlement européen visant à renforcer la résilience opérationnelle numérique du secteur financier. Entré en vigueur le 17 janvier 2025, il s’applique directement et impose aux banques, aux assureurs ainsi qu’à leurs prestataires informatiques une gestion des risques traçable, une notification des incidents dans les délais et des tests réguliers de résilience.

Ce règlement est donc depuis longtemps une obligation légale. Pourtant, fin 2025, sa mise en œuvre restait incomplète dans de nombreux établissements : selon des enquêtes sectorielles, seule la moitié environ des institutions financières européennes avaient satisfait à toutes les exigences, tandis qu’une part importante avait reporté l’objectif de conformité à 2026. Pour les équipes de sécurité, cela signifie une chose : la preuve de conformité doit désormais être apportée en continu, dans le cadre des opérations courantes.

La gestion des risques doit être traçable

Le premier pilier repose sur une gestion documentée des risques ICT. DORA exige des preuves tangibles plutôt qu’un concept théorique : un inventaire des actifs bien tenu, des responsabilités clairement définies et des contrôles opérationnels en cas de crise. Sans un inventaire précis de ses systèmes critiques, impossible d’évaluer les risques ou de réussir un audit.

Dans la pratique, l’erreur la plus fréquente consiste à concevoir le cadre comme un simple document, déconnecté des opérations. Un registre des risques qui prend la poussière après l’audit ne sert à rien. Les autorités de surveillance recherchent des processus vivants. Ceux-ci se manifestent à travers les logs, les tickets et des plans de continuité testés.

environ 50 %
des institutions financières européennes avaient pleinement mis en œuvre les exigences DORA fin 2025.
Source : Enquêtes sectorielles sur la conformité DORA 2025.

Signaler les incidents avant l’expiration du délai

Le deuxième pilier est le signalement des incidents. DORA impose de classifier les incidents ICT graves et de les notifier dans les délais aux autorités de surveillance. Cela semble simple, mais échoue souvent en raison du manque de préparation. Si, en cas d’urgence, il faut d’abord déterminer qui signale, à qui et dans quel délai, les heures critiques sont déjà perdues.

C’est là que la routine éprouvée fait la différence. Un processus de signalement doit être testé comme une sauvegarde : simulé une fois par trimestre, avec des rôles clairs et des voies d’escalade définies. Les délais de notification varient selon les réglementations, d’où l’importance de bien définir le point de départ du compte à rebours.

Des tests qui impactent toute la chaîne d’approvisionnement

Le troisième pilier est le test d’intrusion guidé par les menaces, ou TLPT (Threat-Led Penetration Testing). Au-delà du pentest classique, DORA impose aux établissements concernés des simulations d’attaques réalistes, inspirées des méthodes des véritables cybercriminels et incluant la chaîne d’approvisionnement ICT. La fréquence et le périmètre des tests dépendent de la taille et de la criticité systémique de l’institution. La BaFin (l’autorité fédérale de supervision financière allemande) devrait préciser prochainement les exigences détaillées.

Ces piliers se traduisent par des missions concrètes pour les équipes de sécurité.

Pilier DORA Ce que l’équipe sécurité doit fournir concrètement
Gestion des risques ICT Inventaire des actifs, contrôles, registre des risques actualisé
Signalement des incidents Classification, déclaration dans les délais, test du processus
Tests de résilience (TLPT) Pentests guidés par les menaces, incluant la chaîne d’approvisionnement
Tiers fournisseurs Maintien d’un registre, sécurisation des droits d’audit, plan de sortie opérationnel

Quand le fournisseur cloud lui-même est placé sous surveillance

Le quatrième volet concerne les prestataires tiers. Dix-neuf fournisseurs de services informatiques sont considérés comme des prestataires tiers critiques et relèvent directement de la supervision européenne, parmi lesquels les grands hyperscalers. Pour les établissements financiers, cela change la donne : la responsabilité de la résilience reste du ressort de l’institut, même lorsque le service provient du cloud.

Concrètement, cela signifie qu’il faut répertorier chaque service critique, doter les contrats de droits d’audit et de résiliation, et disposer d’un plan de sortie pour chaque fournisseur important. Une panne chez le fournisseur cloud n’exonère personne de l’obligation de déclaration.

Aperçu de la situation

Quiconque considère DORA comme un simple exercice de documentation s’en rendra compte au plus tard lors du premier incident réel. Le règlement exige une résilience vécue au quotidien.

Questions fréquentes

Chaque question est verrouillée. Un simple clic permet d’afficher la réponse.

Depuis quand DORA s’applique-t-il et à qui s’adresse-t-il ?

Le règlement DORA (Digital Operational Resilience Act) est directement applicable dans tous les États membres de l’UE depuis le 17 janvier 2025. Il concerne les banques, les assureurs, les entreprises d’investissement, les prestataires de services de paiement et de crypto-actifs, ainsi que leurs principaux fournisseurs de services informatiques. En tant que règlement européen, il n’a pas besoin d’être transposé en droit national et s’applique donc directement.

Que faut-il prendre en compte concernant le registre des prestataires tiers ICT ?

Ce registre recense tous les accords contractuels relatifs aux services informatiques et devait être communiqué à la BaFin (l’Autorité fédérale de supervision financière allemande) avant le 30 mars 2026. Il doit être mis à jour en continu, car les autorités de surveillance attendent une vue actualisée, et non un simple instantané ponctuel.

Que signifie concrètement TLPT ?

TLPT signifie *Threat-Led Penetration Testing*, soit des tests d’intrusion guidés par les menaces. Ces simulations s’inspirent des méthodes utilisées par les cyberattaquants réels et incluent l’ensemble de la chaîne d’approvisionnement ICT. Ils sont principalement exigés pour les institutions d’importance systémique, les détails précis étant définis par les autorités de régulation au cours de l’année.

Qui est responsable en cas de défaillance d’un fournisseur cloud ?

La responsabilité de la résilience opérationnelle reste entièrement du côté de l’institution financière. Même si un prestataire tiers critique est directement supervisé par les autorités européennes, l’établissement doit signaler les incidents, gérer les risques et disposer d’un plan de sortie. L’externalisation ne transfère pas cette obligation.

Quelles sanctions encourt-on en cas de non-respect ?

Les autorités de surveillance peuvent infliger des sanctions sévères, allant jusqu’à des astreintes quotidiennes équivalant à 1 % du chiffre d’affaires journalier mondial pour les prestataires tiers critiques, et ce sur une période prolongée. Cependant, au-delà des amendes, c’est souvent l’atteinte à la réputation et la perte de confiance qui pèsent le plus lourd après un incident déclaré.

Suggestions de lecture de la rédaction






Suggestion de lecture
Quand l’HCI transforme la sauvegarde en surface d’attaque







Suggestion de lecture
Comptes fantômes : l’angle mort de l’IAM lors du offboarding







Suggestion de lecture
DNS protecteur : la couche de sécurité souvent négligée

Plus d’articles du réseau MBF Media






cloudmagazin
Infrastructures critiques dans le cloud : ce qui sécurise la migration




Alec Chizhik

À propos de l'auteur Alec Chizhik

Alec est Chief Digital Officer chez Evernine et écrit sur les architectures cloud, la sécurité informatique et la pratique des opérations numériques.

Tous les articles →

Pour aller plus loin

Stratégie & Gouvernance · 17 juillet 2026

Parrainage NIS2 : Quatre États devant le CJUE

La Commission européenne poursuit l’Irlande, l’Espagne, la France et les Pays-Bas pour une mise en œuvre incomplète de NIS2. En quoi cela concerne-t-il les …

Un magazine d'Evernine Media GmbH