Conformité DORA : le diagnostic technique, puis la remédiation

Par Cédric Barme · Fondateur de NSY

Le règlement européen DORA (Digital Operational Resilience Act, règlement UE 2022/2554), applicable depuis le 17 janvier 2025, impose aux entités financières de démontrer leur résilience numérique — pas seulement de la déclarer. La documentation juridique abonde ; ce qui manque le plus souvent, c'est le volet ingénierie : savoir ce que le système fait réellement, ce qui casse quand un maillon lâche, et ce qu'il faut corriger en premier. C'est ce volet que NSY prend en charge, en direct ou via une ESN référencée.

Le diagnostic DORA : ce que vous recevez

Un diagnostic court, ciblé d'abord sur vos fonctions critiques ou importantes, mené par entretiens avec les équipes, lecture de l'architecture réelle — pas celle des slides — et revue des procédures et des tests existants. Il produit cinq livrables :

• La cartographie des actifs, des flux et des dépendances TIC de chaque fonction critique, internes comme externes, avec sa criticité.
• Le registre d'informations des prestataires TIC : qui porte quoi, quelles concentrations, quelle réversibilité réelle — dans la structure attendue par les autorités.
• La matrice d'écarts par pilier du règlement, chaque écart qualifié par sa gravité et sa probabilité d'être relevé.
• Le plan de remédiation priorisé par impact, avec un ordre de grandeur de charge pour chaque chantier.
• La restitution à la direction, au RSSI et à la DSI, en langage de risque et d'ingénierie, pas en jargon réglementaire.

Le prix dépend du périmètre et se chiffre après un cadrage d'une heure ; réponse sous 48 h ouvrées. Puis, si vous le souhaitez, NSY exécute les remédiations avec vos équipes.

Les cinq piliers, traduits en travaux

• Gestion des risques TIC (articles 5 à 16) — inventaire et classification des actifs, politique de sauvegarde et de restauration réellement testée, gestion des changements et des vulnérabilités, journalisation exploitable. Le point de départ de tout le reste.
• Incidents liés aux TIC (articles 17 à 23) — détecter, qualifier, retracer la chronologie et notifier dans les délais : notification initiale dans les quatre heures suivant la classification en incident majeur et au plus tard vingt-quatre heures après sa détection, rapport intermédiaire sous soixante-douze heures, rapport final sous un mois. Sans observabilité, ces délais sont intenables.
• Tests de résilience opérationnelle (articles 24 à 27) — un programme de tests annuel sur les systèmes critiques, et pour les entités désignées un test de pénétration fondé sur la menace tous les trois ans. Le test compte moins que ce qu'on en fait : un plan de secours jamais rejoué n'existe pas.
• Risque lié aux prestataires TIC (articles 28 à 30) — registre d'informations, clauses contractuelles, analyse de concentration, stratégies de sortie documentées et testables. Le prestataire irremplaçable de fait est l'écart le plus courant, et le plus long à résorber.
• Partage d'informations (article 45) — participation volontaire aux échanges sur les menaces, qui suppose d'avoir quelque chose de structuré à partager.

Ce que DORA exige concrètement des équipes techniques

• Cartographier les risques TIC — inventaire des actifs, des flux et des dépendances (internes et prestataires), criticité de chaque fonction : impossible à faire sérieusement sans comprendre l'architecture réelle.
• Tester la résilience — pas des plans sur papier : des scénarios de panne exécutés (perte d'un site, d'un broker de messagerie, d'un fournisseur cloud), avec mesure des temps de rétablissement réels face aux engagements.
• Maîtriser les prestataires TIC — réversibilité, portabilité des données, stratégies de sortie testables : des exigences qui se traduisent en choix d'architecture (voir cloud privé et hybride), pas seulement en clauses contractuelles.
• Notifier les incidents majeurs — ce qui suppose de les détecter, de les qualifier et d'en retracer la chronologie : l'observabilité n'est plus un confort, c'est une obligation.

La démarche NSY

NSY intervient là où le juridique s'arrête : traduire les exigences en travaux d'ingénierie priorisés. Le diagnostic d'abord. Puis l'exécution : durcissement des points faibles identifiés — souvent la messagerie (voir Kafka et Artemis), les socles applicatifs vieillissants (voir la migration Java EE et WildFly / JBoss EAP), les dépendances cloud non maîtrisées (voir OpenShift et Kubernetes) —, tests de bascule rejoués jusqu'à tenir les objectifs, et documentation qui décrit le système tel qu'il est.

Pourquoi un regard extérieur indépendant

Les écarts DORA les plus coûteux sont ceux que l'on ne voit plus de l'intérieur : la dépendance « temporaire » devenue structurelle, le plan de secours jamais rejoué, le prestataire irremplaçable de fait. Un consultant indépendant, habitué aux environnements ACPR et AMF depuis 2018 et sans lien avec vos fournisseurs, n'a aucun intérêt à minimiser un écart — ni à en inventer. Les questions fréquentes précisent le cadre d'intervention.

Ce que ce diagnostic n'est pas

• Un avis juridique. L'interprétation du règlement et des normes techniques de réglementation reste l'affaire de votre conformité et de vos conseils ; NSY en fait la traduction technique.
• Une certification. DORA n'en prévoit aucune : personne ne « certifie DORA », et un prestataire qui le promet vend autre chose.
• Un test de pénétration. Le test fondé sur la menace se confie à des testeurs qualifiés ; NSY prépare le périmètre, corrige ce qui est trouvé et rejoue les scénarios.

Questions fréquentes

Qu’est-ce qu’un diagnostic DORA ?

Une lecture technique de votre système d’information au regard des cinq piliers du règlement : cartographie réelle des actifs, flux et dépendances des fonctions critiques, registre des prestataires TIC, écarts par exigence avec leur gravité, et plan de remédiation priorisé par impact et chiffré. Ce n’est ni un avis juridique ni une certification : c’est la traduction des exigences en travaux d’ingénierie.

Combien coûte un diagnostic DORA et combien de temps dure-t-il ?

Le prix dépend du périmètre : nombre de fonctions critiques, d’applications et de prestataires à couvrir. Il est chiffré après un cadrage d’une heure, avec une réponse sous 48 h ouvrées. Un premier périmètre ciblé sur les fonctions critiques se traite en quelques semaines ; NSY intervient en direct ou via une ESN référencée.

DORA s’applique-t-il à un prestataire informatique ?

Indirectement, et fortement. Les entités financières doivent imposer à leurs prestataires TIC des exigences contractuelles précises : niveaux de service, accès aux données, audit, réversibilité et stratégie de sortie. Les prestataires jugés critiques au niveau européen sont en plus supervisés directement par les autorités européennes de surveillance. Un éditeur ou un hébergeur qui sert la finance a donc tout intérêt à savoir répondre à un registre d’informations.

Quelle différence entre DORA et NIS 2 ?

DORA est le texte spécifique du secteur financier : pour une banque, un assureur ou un gestionnaire d’actifs, c’est DORA qui s’applique en priorité sur la résilience numérique. NIS 2 couvre les autres secteurs essentiels et importants. Les deux partagent la logique : gérer le risque, notifier les incidents, maîtriser la chaîne de sous-traitance.

Peut-on démarrer par un périmètre réduit ?

Oui, et c’est recommandé : commencer par les fonctions critiques ou importantes, celles dont l’interruption aurait un impact sur les clients ou le marché, puis étendre. Un diagnostic court sur ce périmètre donne déjà la carte des risques techniques et les premières remédiations à engager.

Par où commencer

Décrivez votre périmètre via le formulaire — réponse sous 48 heures ouvrées, avec une lecture honnête de ce qui relève de l'urgence et de ce qui peut attendre.