Conformité DORA pour les fintechs : calendrier, coûts et les six pièges les plus coûteux

Marcus, Solution Architect

Depuis le 17 janvier 2025, DORA est d'application obligatoire. Pas de période transitoire, pas de délai de grâce, pas de "nous étudions encore la question". Les Autorités Européennes de Surveillance attendent une conformité totale, et la BaFin a clairement indiqué qu'elle appliquera le règlement de manière active. Qui débat encore aujourd'hui de la pertinence de DORA pour sa fintech pose la mauvaise question.

La bonne question est la suivante : lequel des cinq domaines fondamentaux de DORA représente le risque le plus élevé pour votre entreprise, et comment priorisez-vous les douze prochains mois ?

Cet article ne donne pas de réponses diplomatiques. Il vous offre une évaluation honnête des coûts, un calendrier réaliste et une identification claire des pièges dans lesquels la majorité des fintechs de taille intermédiaire tombent par expérience. Le conseil conformité DORA dont votre organisation a besoin ne commence pas par un deck de présentation sur les cinq piliers du règlement. Il commence par nommer honnêtement votre point de départ et ce qu'une mise en conformité complète coûte réellement.

DORA n'est pas une mise à niveau de BAIT

Beaucoup de RSSI, en particulier dans les organisations déjà soumises au régime KAIT/BAIT de la BaFin, commettent la même erreur : ils traitent DORA comme une sorte de mise à niveau de leur gouvernance IT existante. C'est une erreur, et cette méprise est coûteuse.

BAIT et KAIT définissent des exigences minimales en matière de sécurité informatique pour les banques et les assurances en Allemagne. DORA définit un cadre harmonisé à l'échelle de l'UE pour la résilience opérationnelle numérique. Le règlement s'articule autour de cinq domaines fondamentaux : la gestion des risques liés aux TIC, le signalement des incidents liés aux TIC, les tests de résilience opérationnelle numérique, la gestion des risques liés aux prestataires tiers de services TIC et l'échange d'informations sur les cybermenaces.^[1]

La différence entre BAIT et DORA n'est pas de degré, elle est de nature. BAIT demande : "Avez-vous une politique de sécurité informatique documentée ?" DORA demande : "Pouvez-vous démontrer que l'ensemble de votre chaîne d'approvisionnement TIC reste opérationnellement résiliente dans un scénario de perturbation réaliste, et dans le cas contraire, pourquoi avez-vous accepté ce risque résiduel et qui au niveau de la direction a documenté cette acceptation ?"

DORA ancre la responsabilité ultime de la gestion des risques TIC explicitement au niveau de l'organe de direction.^[1] Ce n'est pas un point de détail à l'article 5. C'est l'exigence fondamentale de gouvernance à laquelle de nombreux projets DORA échouent, parce que personne ne la prend vraiment au sérieux jusqu'à ce qu'un auditeur pose la question.

Cela s'applique à toutes les entités financières dans le champ d'application du règlement : établissements de crédit, établissements de paiement, établissements de monnaie électronique, entreprises d'investissement, prestataires de services sur crypto-actifs (PSCA), entreprises d'assurance et un certain nombre d'autres entités réglementées. Pour les fintechs, cela signifie concrètement : presque toute entreprise titulaire d'un agrément BaFin ou d'un passeport délivré par un autre État membre de l'UE est soumise à DORA. L'argument "nous sommes trop petits" n'existe pas dans le règlement ; il n'existe qu'une clause de proportionnalité pour les entités non significatives, permettant l'application du cadre simplifié de gestion des risques TIC prévu à l'article 16.

Ce que le calendrier signifie vraiment

Le calendrier officiel se lit techniquement de façon simple : DORA a été publié au Journal officiel de l'UE le 27 décembre 2022, est entré en vigueur le 16 janvier 2023 et est applicable depuis le 17 janvier 2025.^[1] À cela s'ajoutaient des normes techniques de réglementation (RTS) et des normes techniques d'exécution (ITS) des Autorités Européennes de Surveillance, adoptées en plusieurs vagues jusqu'à fin 2024.^[3]

Ce que ce calendrier signifie dans la pratique est une autre histoire.

Les RTS sur le cadre de gestion des risques TIC n'ont été finalisées qu'en janvier 2024. Les RTS sur les tests de pénétration fondés sur les menaces (TLPT) ont suivi en mars 2024. Cela signifie que les fintechs ont disposé de moins de douze mois pour une grande partie du travail d'implémentation concret, alors que DORA offrait formellement deux ans de délai.^[3]

À cela s'ajoute un problème structurel : les exigences relatives au registre d'informations sur les prestataires tiers étaient moins précisément spécifiées dans le règlement DORA initial que dans les règlements d'exécution ultérieurs. Ceux qui ont commencé à construire ce registre en 2023 ont souvent dû en revoir complètement la structure en 2024, car les AES ont fourni dans le cadre des ITS des modèles très détaillés qui différaient considérablement des développements propres antérieurs.

Le troisième aspect absent de nombreux calendriers : DORA ne prévoit pas une conformité "une fois pour toutes". Le règlement exige un régime opérationnel permanent avec des tests de résilience annuels, une révision régulière du cadre de gestion des risques TIC et une surveillance continue des prestataires tiers. Qui traite DORA comme un projet ponctuel n'a pas compris le règlement.

Ce qui s'applique concrètement depuis janvier 2025 :

Le cadre complet de gestion des risques TIC conformément aux articles 5 à 16 doit être mis en œuvre et documenté.^[1] Les obligations de déclaration en cas d'incidents TIC majeurs sont actives : la déclaration initiale doit intervenir dans les quatre heures suivant la détection d'un incident majeur, la déclaration intermédiaire suit au plus tard 72 heures plus tard, et la déclaration finale est due au bout d'un mois.^[1] Le registre d'informations sur tous les prestataires tiers de services TIC doit être complet et à jour. Les exigences contractuelles prévues à l'article 30 de DORA doivent être intégrées dans tous les contrats de services TIC pertinents. Un programme annuel de tests de résilience doit être réalisé et documenté.

Pour les établissements d'importance systémique s'ajoutent les exigences renforcées en matière de tests de pénétration fondés sur les menaces, qui doivent être effectués tous les trois ans.

DORA et NIS2 : démarcation

Un point qui sème la confusion dans de nombreuses organisations est la relation entre DORA et la directive NIS2. La réponse courte : pour les entités financières soumises à DORA, DORA s'applique en tant que lex specialis ; dans ces cas, NIS2 s'efface.^[1]

Cela paraît plus simple que cela n'est. Les fintechs qui exercent simultanément des activités de services financiers réglementés et exploitent des infrastructures critiques au sens de NIS2 doivent procéder à une démarcation soigneuse. Un prestataire de services de paiement qui exploite sa propre infrastructure de télécommunications pour son produit ne peut pas invoquer DORA de façon générale.

La recommandation pratique : faites documenter explicitement l'attribution réglementaire pour chacune de vos unités opérationnelles. DORA ou NIS2 n'est pas une question académique ; les différences d'exigences portent sur des points concrets tels que les voies de signalement, les définitions des incidents majeurs et les autorités compétentes.

Ce que les deux règlements ont en commun : ils font évoluer la logique de conformité de "qu'est-ce que nous pouvons documenter ?" vers "pouvons-nous prouver que nos mesures de sécurité fonctionnent réellement ?"^[2] C'est un changement culturel fondamental pour les organisations qui, jusqu'à présent, pensaient en termes de politiques et de documents de processus sans en vérifier l'efficacité opérationnelle.

Les coûts réels

Toute estimation de coût pour la conformité DORA qui répond par un seul chiffre rond manque de sérieux. Les coûts dépendent de trop de variables : niveau de départ de la gouvernance IT, complexité de la chaîne d'approvisionnement TIC, nombre de prestataires tiers critiques, maturité du processus de gestion des incidents existant et personnel interne disponible.

Ce que je peux affirmer après plusieurs implémentations DORA : pour une fintech de taille intermédiaire comptant entre 50 et 250 collaborateurs, qui souhaite sérieusement se mettre en conformité et pas seulement sur le papier, l'effort réel se situe entre 250.000 et 800.000 euros la première année. Cela inclut le conseil externe, les outils et l'effort interne.

Ce chiffre choque de nombreuses directions générales. Il reste néanmoins réaliste. Qui budgétise 100.000 euros en croyant parvenir à une conformité complète s'achète une analyse d'écart et un beau deck de présentation. Il ne s'achète pas la conformité.

Les postes de coûts en détail :

Cadre de gestion des risques TIC : 40.000 à 120.000 euros pour le développement et la mise en œuvre. Cela comprend la création d'un cadre complet incluant l'inventaire des actifs, l'évaluation des risques, l'analyse d'impact sur l'activité et la documentation. Qui exploite déjà un SMSI selon ISO 27001 se situera en bas de cette fourchette. Qui repart de zéro, en haut.

Gestion des risques liés aux prestataires tiers : 60.000 à 200.000 euros. C'est pour la plupart des fintechs le poste individuel le plus coûteux de l'ensemble de la mise en œuvre DORA. Les fintechs cloud-native comptent régulièrement entre 15 et 40 prestataires tiers de services TIC, dont des fournisseurs critiques comme AWS, GCP ou Azure, ainsi que des prestataires spécialisés en paiement, KYC et détection de fraude. Chacun de ces prestataires doit être évalué, encadré contractuellement selon les exigences DORA et intégré au registre d'informations.

Gestion des incidents et infrastructure de reporting : 30.000 à 80.000 euros. Mise en place ou refonte des processus de détection, de classification et de signalement des incidents TIC majeurs. Le délai de 4 heures pour la déclaration initiale n'est pas un simple processus papier. Il requiert des systèmes d'alarme techniques opérationnels, des voies d'escalade clairement définies et du personnel capable d'utiliser ces voies sous pression.

Programme de tests de résilience : 50.000 à 150.000 euros par an. Tests de base tels que les évaluations de vulnérabilités et les tests de pénétration, plus la gouvernance formelle et la documentation de ces tests au niveau de la direction.

Outillage GRC : 20.000 à 80.000 euros par an. Plateformes GRC, systèmes SIEM, outils de gestion des risques liés aux prestataires tiers. De nombreuses fintechs essaient d'économiser ici et se retrouvent avec un chaos de tableurs qui sera jugé insuffisant lors du prochain audit.

Charge de travail interne : Ce poste est absent de presque toutes les estimations de coûts présentées par des consultants externes. De façon réaliste, entre 0,5 et 2,0 équivalents temps plein sont mobilisés la première année pour les activités DORA et ne sont plus disponibles pour le développement produit. C'est le poste de coût le plus invisible, mais souvent le plus douloureux, car il n'apparaît dans aucun budget de projet.

Un autre point systématiquement sous-estimé : la conformité DORA doit être financée de façon permanente. Après la première année de mise en œuvre, des coûts récurrents de 80.000 à 180.000 euros par an sont réalistes pour les tests, la maintenance du registre, la surveillance des prestataires tiers et le reporting réglementaire.

Les six pièges les plus coûteux

Piège 1 : Traiter l'inventaire des actifs TIC comme une réflexion secondaire

L'inventaire des actifs TIC représente en pratique régulièrement le goulot d'étranglement le plus critique de l'ensemble de la mise en œuvre DORA. Le règlement exige que les entités financières identifient et documentent tous leurs actifs TIC ainsi que leurs configurations et dépendances.^[1] Cela paraît trivial. Ce ne l'est pas.

Sam Newman décrit dans "Building Microservices" comment, dans les architectures distribuées, la connaissance des dépendances système se disperse entre de nombreuses équipes et dépôts sans jamais être consolidée dans un seul système.^[5] C'est précisément ce phénomène qui frappe particulièrement les fintechs : une architecture fintech moderne se compose de dizaines de microservices, de fonctions serverless, de services de bases de données gérées, d'API externes et de bibliothèques tierces. Considérés individuellement, aucun de ces éléments n'est non documenté. Consolidés et présentés de façon utilisable à des fins de conformité, ils le sont presque toujours.

La recommandation est claire : commencez par l'inventaire des actifs avant de démarrer tout autre flux de travail DORA. C'est le prérequis pour tout le reste : l'analyse des risques, l'identification des prestataires tiers et l'analyse d'impact sur l'activité. Qui commence la gestion des risques liés aux prestataires tiers sans cette base construit sur du sable.

Piège 2 : Réduire la gestion des risques liés aux prestataires tiers à un travail contractuel

DORA contient aux articles 28 à 44 des exigences détaillées sur la gestion des prestataires tiers de services TIC.^[1] La réaction la plus fréquente en pratique : le département juridique révise les MSA et SLA avec les principaux prestataires, et le sujet est considéré comme clos.

C'est une vision dangereusement courte. DORA n'exige pas seulement des contrats corrects. Il exige un régime de surveillance continue, des évaluations des risques régulières, des stratégies de sortie pour les prestataires critiques et la capacité à répondre opérationnellement aux incidents TIC chez les prestataires tiers.

Un contrat avec AWS contenant toutes les clauses DORA, mais sans plan de continuité en cas de panne régionale AWS, est conforme à DORA sur le papier et sans valeur opérationnelle.

La question que tout RSSI doit poser à ses équipes : "Si notre prestataire tiers de services TIC le plus critique tombe en panne demain pendant 48 heures, que se passe-t-il exactement, qui fait quoi et dans quel ordre ?" Si la réponse honnête est "on verra à ce moment-là", la gestion des risques liés aux prestataires tiers n'est pas conforme, quelle que soit la qualité des contrats.

Piège 3 : Sous-estimer les obligations de déclaration

Les obligations de déclaration DORA pour les incidents TIC majeurs sont largement sous-estimées dans leur complexité opérationnelle. La déclaration initiale doit intervenir dans les quatre heures suivant la détection d'un incident majeur, et dans cette déclaration initiale, l'entité financière doit déjà fournir le type d'incident, les services affectés et une première évaluation des impacts.^[1] La déclaration intermédiaire suit au plus tard 72 heures plus tard, la déclaration finale au bout d'un mois.

Cela ressemble à un travail de documentation bureaucratique. C'est en réalité un test de résistance pour l'ensemble de l'organisation de réponse aux incidents. Quiconque a déjà géré un vrai incident de sécurité sait que les quatre premières heures sont chaotiques. Les équipes se coordonnent, les faits ne sont pas clairs, les responsabilités sont au mieux à moitié définies.

Concrètement : vos playbooks de réponse aux incidents doivent intégrer la classification de signalement DORA comme partie intégrante du flux de travail, et non en annexe. Ce flux de travail doit être exercé, au minimum annuellement dans le cadre d'un exercice sur table incluant explicitement la procédure de signalement DORA. Qui s'entraîne pour la première fois à son processus de signalement conforme à DORA lors d'un vrai incident ratera le délai de 4 heures.

Piège 4 : Traiter les tests de résilience comme une case à cocher de conformité

DORA exige un programme de tests de résilience allant des évaluations de vulnérabilités de base aux tests de pénétration fondés sur les menaces. La tentation est grande de commander un test de pénétration annuel, de mettre le rapport dans un classeur et de considérer le sujet comme clos.

DORA exige quelque chose de plus fondamental : les résultats des tests doivent être intégrés dans le cadre de gestion des risques TIC, les vulnérabilités identifiées doivent être corrigées selon un processus défini avec des propriétaires et des délais clairement assignés, et la gouvernance de ces tests doit être ancrée au niveau de la direction.

Martin Fowler décrit dans "Patterns of Enterprise Application Architecture" comment les dettes techniques s'accumulent dans les systèmes lorsqu'aucune résorption systématique n'est organisationnellement imposée.^[6] Il en va de même pour les failles de sécurité. Un test de pénétration dont les résultats n'atterrissent dans aucun système de suivi avec propriétaire et délai n'est pas seulement inutile. Il est activement nuisible, car il génère une fausse impression de sécurité et doit servir lors du prochain audit de preuve que des vulnérabilités connues ont été ignorées.

Piège 5 : Traiter DORA comme un projet IT plutôt que comme un sujet de gouvernance

C'est le piège culturel, et il est particulièrement répandu dans les fintechs de taille intermédiaire. DORA atterrit chez le RSSI ou le DSI, qui en fait un projet avec un backlog. Le résultat : la conformité DORA comme une branche de fonctionnalité qui devra un jour être fusionnée dans le tronc principal de l'organisation.

Cela ne fonctionne pas, pour une raison structurelle que le règlement adresse explicitement : la responsabilité ultime de la gestion des risques TIC incombe à l'organe de direction de l'entité financière.^[1] Cela signifie le conseil d'administration ou la direction générale, pas le DSI, pas le RSSI.

Les conséquences pratiques : la structure de gouvernance doit garantir que la direction est régulièrement informée de l'état de la gestion des risques TIC, que les décisions d'acceptation des risques sont prises et documentées au niveau de la direction, et que les politiques pertinentes pour DORA sont approuvées par la direction générale. Qui traite DORA comme un pur projet IT sans ancrer ces éléments de gouvernance se retrouvera en grande difficulté lors du premier entretien de supervision.

Piège 6 : Traiter le registre d'informations des prestataires tiers comme un document statique

Le registre d'informations est l'une des exigences DORA les plus anodines techniquement, mais les plus lourdes opérationnellement. Il requiert une documentation complète et actualisée de tous les prestataires tiers de services TIC, incluant les détails contractuels, les fonctions soutenues, les localisations géographiques du stockage et du traitement des données, ainsi qu'une évaluation de la criticité.^[3]

Les AES ont fourni des modèles précis pour ce registre, avec plus de 50 champs de données par prestataire. Une fintech de taille intermédiaire comptant 25 prestataires tiers de services TIC qui remplit ce registre correctement mobilise initialement plusieurs mois-personnes.

L'erreur que j'observe encore et encore : le registre est traité comme un projet ponctuel et n'est plus tenu à jour après le remplissage initial. DORA exige que ce registre soit mis à jour lors de changements significatifs et fasse l'objet d'une révision complète au moins annuellement. Un registre obsolète n'est pas un registre ; c'est un risque de conformité qui sera immédiatement repéré lors d'un contrôle.^[2]

Un plan de mise en œuvre pragmatique

Pour une fintech souhaitant aborder sa conformité DORA de façon structurée, je recommande la priorisation suivante. Cet ordre n'est pas académique ; il suit les dépendances réelles qui bloquent les projets en pratique.

Phase 1 (mois 1 à 3) : fondations

L'inventaire des actifs TIC vient en premier. Aucun autre flux de travail ne peut progresser utilement sans cette base. En parallèle : analyse d'écart par rapport au catalogue des exigences DORA et aux RTS finales, identification des prestataires tiers de services TIC critiques, mise en place de la structure de gouvernance DORA avec ancrage explicite au niveau de la direction et désignation d'un responsable de programme avec accès direct à la direction générale.

Budget réaliste pour la phase 1 : 60.000 à 150.000 euros.

Phase 2 (mois 4 à 8) : conformité essentielle

Développement et mise en œuvre du cadre de gestion des risques TIC, révision des contrats avec les prestataires tiers critiques selon l'article 30 de DORA, construction du registre d'informations selon le modèle AES, implémentation des processus de gestion des incidents incluant la classification DORA et les voies de signalement à la BaFin.

Budget réaliste pour la phase 2 : 120.000 à 350.000 euros.

Phase 3 (mois 9 à 12) : tests et opérationnalisation

Réalisation du premier programme complet de tests de résilience, exercices sur table pour la réponse aux incidents avec procédure de signalement DORA explicite, révision et finalisation de la documentation, premier contrôle interne de préparation à l'audit.

Budget réaliste pour la phase 3 : 70.000 à 200.000 euros.

Fonctionnement permanent à partir du mois 13 : 80.000 à 180.000 euros par an pour les tests continus, la maintenance du registre, la surveillance des prestataires tiers et le reporting réglementaire.

Ces phases peuvent être accélérées ou ralenties selon le niveau de maturité initial. Ce qui ne peut pas être accéléré, c'est l'ancrage organisationnel. Les structures de gouvernance qu'exige DORA ont besoin de temps pour s'intégrer dans l'exploitation opérationnelle.

Ce qu'un bon conseil conformité DORA apporte vraiment

Le marché des prestations de conseil DORA a fortement progressé depuis 2023. Toutes les grandes sociétés de conseil et de nombreux prestataires spécialisés proposent des offres DORA. Les différences de qualité sont considérables.

Ce qui caractérise un conseil conformité DORA sérieux peut se résumer à trois critères :

Profondeur technique dans l'évaluation des risques liés aux prestataires tiers : Un consultant qui réduit la gestion des risques liés aux prestataires tiers à une optimisation contractuelle sans comprendre les dépendances techniques et les architectures ne fournit qu'un travail à moitié fait. L'évaluation des prestataires tiers de services TIC critiques requiert une compréhension de l'intégration technique, pas seulement des fondements juridiques. Qui ne comprend pas comment une architecture multi-cloud est construite avec ses dépendances ne peut pas établir un profil de risque prestataire tiers pertinent.

Orientation opérationnelle plutôt qu'optimisation documentaire : La conformité DORA ne naît pas de politiques et de procédures parfaites, mais de processus qui fonctionnent. Un consultant qui produit principalement des documents sans accompagner la mise en œuvre opérationnelle résout le mauvais problème. La question déterminante n'est pas de savoir si le manuel de réponse aux incidents couvre formellement les exigences DORA, mais si l'organisation agit réellement de cette façon lors d'un vrai incident.

Compréhension de la logique de contrôle prudentiel : La BaFin et les AES ne contrôlent pas DORA avec une approche par liste de contrôle statique. Elles vérifient si les processus internes et la structure de gouvernance sont réellement adaptés pour atteindre les objectifs du règlement.^[2] Un consultant qui connaît seulement la lettre du règlement mais pas la philosophie de contrôle de l'autorité de supervision allemande prépare son client à une image de conformité qui s'effondre lors du premier entretien de supervision.

DORA et l'architecture technique

Un aspect souvent insuffisamment traité dans de nombreuses implémentations DORA : le règlement a des implications directes sur les décisions d'architecture technique.

Cela s'applique en particulier aux exigences relatives à la continuité d'activité et à la reprise. DORA exige que les entités financières définissent des objectifs de temps de reprise (RTO) et des objectifs de point de reprise (RPO) pour les fonctions critiques et les valident par des tests réels.^[1] Ce n'est pas un exercice de documentation ; c'est une contrainte d'architecture.

Un système qui déclare un RTO de deux heures pour des fonctions de paiement critiques, mais qui fonctionne sur une architecture de déploiement mono-région sans basculement automatisé, n'est pas conforme à DORA. L'architecture doit pouvoir techniquement supporter les RTO et RPO déclarés. Qui ne met pas les deux en cohérence rédige délibérément des documents de conformité qui ne pourront pas être respectés lors d'un vrai incident.

Vaughn Vernon, dont les travaux sur la pratique du Domain-Driven Design ont fondamentalement influencé la conception stratégique des systèmes distribués, montre que la délimitation rigoureuse des Bounded Contexts n'est pas seulement un outil sémantique, mais a des effets directs sur la propagation des défaillances dans les architectures distribuées. Cette approche est directement pertinente pour les implémentations DORA : une architecture fintech dans laquelle la panne d'un seul service de paiement impacte l'ensemble du système présente un problème structurel qu'aucune documentation de gouvernance ne peut résoudre.

La recommandation est claire : intégrez les architectes techniques dans la mise en œuvre DORA, non pas comme observateurs, mais comme acteurs actifs. Les définitions de RTO/RPO doivent être confrontées aux capacités architecturales réelles. Si l'architecture ne peut pas satisfaire les objectifs définis, il faut soit adapter l'architecture, soit corriger les objectifs de façon réaliste. L'une ou l'autre option, mais ne pas laisser les deux en suspens.

Conclusion : la conformité comme état opérationnel permanent

DORA n'est pas un investissement ponctuel et ne constitue pas un projet avec une date de fin. C'est un régime opérationnel permanent qui exige une attention, des ressources et une gouvernance continues. Les fintechs qui le perçoivent comme une pure charge de coûts seront frustrées. Celles qui le comprennent comme un indicateur de maturité de leur organisation IT opérationnelle constateront que de nombreuses exigences DORA conduisent à une exploitation réellement plus résiliente, indépendamment des exigences prudentielles.

Ce qui fait la différence entre "conforme sur le papier" et "vraiment conforme" se résume en une phrase : la véritable conformité DORA signifie que votre organisation peut détecter un incident TIC majeur, le classifier, le signaler aux autorités de surveillance et y faire face opérationnellement, sans que quiconque ait besoin d'ouvrir un manuel.

C'est l'objectif réel du règlement. La documentation en est la preuve, pas l'objectif lui-même.

Si vous souhaitez savoir où votre organisation en est concrètement, commencez par une analyse d'écart structurée par rapport aux RTS et ITS finalisées, non pas par rapport au règlement DORA initial de 2022, mais par rapport à l'état que les AES ont défini dans leurs normes finales de 2024.^[3] Cet écart seul génère des surprises dans un projet sur deux.

Sources

[1] Règlement (UE) 2022/2554 du Parlement européen et du Conseil du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier et modifiant les règlements (CE) n° 1060/2009, (UE) n° 648/2012, (UE) n° 600/2014, (UE) n° 909/2014 et (UE) 2016/1011. Journal officiel de l'UE, L 333, 27 décembre 2022. https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32022R2554

[2] BaFin, "DORA: Digital Operational Resilience Act, Wichtige Informationen für beaufsichtigte Unternehmen", Merkblatt, mis à jour en 2025. https://www.bafin.de/DE/Aufsicht/DigitaleFinanzdienstleistungen/DORA/dora_node.html

[3] Autorités Européennes de Surveillance (ABE, AEAPP, AEMF), "Final Report: Draft Regulatory Technical Standards on ICT risk management framework and on simplified ICT risk management framework under Articles 15 and 16 DORA", JC 2023 86, janvier 2024. https://www.eba.europa.eu/regulation-and-policy/operational-resilience/digital-operational-resilience-act-dora-policy-products

[4] ENISA, "Technical Guidance on the Digital Operational Resilience Act (DORA) for Financial Entities", Agence de l'Union européenne pour la cybersécurité, 2024. https://www.enisa.europa.eu/topics/digital-operational-resilience

[5] Sam Newman, "Building Microservices: Designing Fine-Grained Systems", 2e édition, O'Reilly Media, 2021, ISBN 978-1492034025.

[6] Martin Fowler, "Patterns of Enterprise Application Architecture", Addison-Wesley Professional, 2002, ISBN 978-0321127426.