Les 5 piliers de DORA expliqués simplement (avec exemples concrets)

Le règlement DORA (Digital Operational Resilience Act, règlement UE 2022/2554) est entré en application le 17 janvier 2025. Il impose un socle commun de résilience opérationnelle numérique à l'ensemble du secteur financier européen — une vingtaine de catégories d'entités, des grandes banques aux sociétés de gestion en passant par les établissements de paiement et les assureurs.

Derrière l'acronyme, une architecture claire : cinq piliers. Les comprendre, c'est comprendre l'essentiel de ce que le régulateur attend. Voici chacun d'eux, expliqué simplement et illustré.

Pilier 1 — La gestion du risque lié aux TIC

C'est le socle. DORA impose à chaque entité de disposer d'un cadre de gestion du risque TIC : identifier ses actifs informatiques, cartographier ses dépendances, protéger ses systèmes, détecter les anomalies, et organiser la reprise en cas de défaillance.

Point clé souvent sous-estimé : ce cadre relève de la responsabilité de l'organe de direction. Ce n'est pas un sujet qu'on délègue entièrement à la DSI. Le conseil ou le comité de direction doit approuver la stratégie de résilience, définir l'appétence au risque TIC et suivre les arbitrages.

Exemple concret. Une société de gestion doit être capable de dire quelles fonctions critiques (valorisation, passage d'ordres, reporting réglementaire) reposent sur quels systèmes et quels prestataires — et ce que devient l'activité si l'un d'eux tombe.

Pilier 2 — La gestion, la classification et la notification des incidents

DORA harmonise la façon dont les incidents liés aux TIC sont détectés, classifiés et signalés. Lorsqu'un incident est qualifié de majeur selon les critères réglementaires, l'entité doit le notifier à son autorité compétente selon un calendrier strict : une notification initiale rapide après la classification, un rapport intermédiaire à mesure que la situation évolue, puis un rapport final une fois l'analyse des causes terminée.

Le compteur démarre au moment de la classification, pas de la détection — un point technique lourd de conséquences. Sans processus outillé, tenir les délais en pleine crise relève de l'improvisation.

Exemple concret. Un établissement de paiement subit une panne de son prestataire cloud affectant ses services de paiement. Même si l'incident vient d'un tiers, c'est bien l'entité financière qui porte l'obligation de notification.

Pilier 3 — Les tests de résilience opérationnelle numérique

DORA impose un programme de tests proportionné : tests de base réguliers pour toutes les entités, et tests avancés de type TLPT (Threat-Led Penetration Testing) pour les acteurs les plus significatifs. L'idée : ne pas attendre l'incident réel pour découvrir ses points de rupture.

Le régulateur attend un plan de tests annuel, des scénarios de menace crédibles, des résultats tracés et un suivi des correctifs. Un test réalisé mais non documenté ne vaut, aux yeux du superviseur, presque rien.

Exemple concret. Tester la restauration de ses données après une attaque simulée, mesurer le temps de reprise réel (RTO) et le comparer à l'objectif fixé.

Pilier 4 — La gestion du risque lié aux prestataires tiers de services TIC

C'est le pilier qui a posé le plus de difficultés, et de loin. DORA encadre la relation avec les prestataires ICT à toutes les étapes : due diligence avant contractualisation, clauses contractuelles minimales obligatoires (droits d'audit, localisation des données, coopération avec les autorités, réversibilité, gestion de la sous-traitance), et suivi continu.

Deux exigences structurantes en découlent : la tenue d'un registre d'information recensant tous les accords contractuels ICT, et l'analyse du risque de concentration — le fait que plusieurs fonctions critiques dépendent d'un même prestataire, ou d'un petit nombre.

Exemple concret. Si votre outil de gestion, votre hébergement et votre solution de reporting reposent tous sur le même groupe technologique, vous avez une concentration que le régulateur veut voir identifiée — avant lui.

Pilier 5 — Le partage d'informations sur les cybermenaces

Plus souple que les autres, ce pilier encourage les entités financières à échanger, sur une base volontaire, des informations opérationnelles sur les menaces cyber et les vulnérabilités. DORA prévoit même la possibilité de notifier volontairement une cybermenace significative, avant même qu'elle ne se matérialise en incident.

Exemple concret. Une entité détecte une tentative d'intrusion sophistiquée stoppée par ses défenses ; elle peut choisir de la signaler à son autorité pour alimenter la connaissance collective de la menace.

Comment ces piliers s'articulent en pratique

L'erreur fréquente est de traiter ces cinq piliers comme cinq chantiers séparés. En réalité, ils partagent les mêmes données. Un incident (pilier 2) implique souvent un tiers (pilier 4), affecte un actif géré dans le cadre de risque (pilier 1), et nourrit le programme de tests de l'année suivante (pilier 3). Cloisonner ces informations dans des fichiers distincts, c'est se condamner à des retraitements permanents et à des incohérences que le superviseur repère immédiatement.

Le rôle d'Axenia. Axenia réunit les données des cinq piliers sur un même socle relié : les tiers, contrats, actifs, politiques, risques et incidents ne sont plus des silos, mais les facettes d'un dispositif unique, maintenu à jour et démontrable.

---

Cet article a une vocation pédagogique et ne constitue pas un avis juridique. Référez-vous aux textes officiels pour toute décision de conformité.

Voir comment Axenia relie vos cinq piliers DORA. Réserver une démo →