Un logiciel de conformité DORA aide une entité financière à tenir son registre d’information sur les prestataires TIC, à gérer le cycle de vie de ces prestataires, à classifier et déclarer les incidents dans les délais réglementaires et à piloter les tests de résilience. Le règlement DORA s’applique depuis le 17 janvier 2025 à un large périmètre — banques, assurances, entreprises d’investissement, prestataires de services sur crypto-actifs — sous la supervision, en France, de l’ACPR et de l’AMF. Aucun outil n’est imposé, mais le registre d’information et le reporting d’incidents sont si structurés qu’ils se prêtent mal à un pilotage sur tableur au-delà de quelques prestataires. Trois familles d’outils répondent au besoin : les plateformes GRC financières, les outils de gestion des risques tiers (TPRM) et les plateformes multi-référentiels reliant DORA au RGPD.
Voici le comparatif, les fonctions décisives, et l’ancrage sur la supervision française.
Points clés
- Le règlement DORA s’applique depuis le 17 janvier 2025 au secteur financier de l’Union.
- Obligations clés : registre d’information sur les prestataires TIC, gestion du risque TIC, reporting d’incidents, tests de résilience (TLPT pour les plus critiques).
- En France, la supervision relève de l’ACPR et de l’AMF.
- DORA recoupe NIS2 et le RGPD : une plateforme multi-référentiels évite de dupliquer registre et gestion des prestataires.
Ce que DORA impose au secteur financier
DORA (Digital Operational Resilience Act) structure la résilience opérationnelle numérique des entités financières autour de cinq piliers. La gestion du risque TIC (art. 5-16), qui impose un cadre de gouvernance et de maîtrise des risques informatiques. Le reporting des incidents majeurs (art. 17-23), avec classification et notification aux autorités dans des délais définis. Les tests de résilience (art. 24-27), dont les tests de pénétration fondés sur la menace (TLPT) pour les entités les plus critiques. La gestion du risque lié aux prestataires TIC (art. 28-44), qui inclut le fameux registre d’information. Enfin, le partage d’informations sur les cybermenaces.
Notre guide DORA pour la France détaille le périmètre et les obligations. Le point le plus opérationnel est le registre d’information : chaque entité doit recenser l’ensemble de ses prestataires TIC, les fonctions supportées, leur criticité et les dispositions contractuelles. Ce registre est transmis aux autorités et doit être tenu à jour — voir notre modèle de registre d’information DORA.
Ce qu’un logiciel de conformité DORA doit couvrir
Cinq fonctions distinguent un outil réellement adapté à DORA.
Le registre d’information structuré. C’est le cœur. L’outil doit gérer le modèle de données imposé par les normes techniques des autorités européennes de surveillance, avec l’export attendu par le régulateur.
La gestion du cycle de vie des prestataires TIC. Évaluation avant contractualisation, suivi des clauses obligatoires, stratégie de sortie, concentration des risques. Notre guide sur les prestataires TIC tierce partie sous DORA détaille ces exigences.
La classification et le reporting d’incidents. L’outil doit appliquer les critères de classification des incidents majeurs et structurer les notifications dans les délais réglementaires.
Le pilotage des tests de résilience. Programmation, suivi des vulnérabilités, remédiation — jusqu’aux tests d’intrusion TLPT pour les entités concernées.
La gouvernance et la preuve. L’organe de direction est responsable du cadre de gestion du risque TIC ; l’outil trace validations et revues.
Comparatif des approches
| Approche | Ce qu’elle apporte | Profil cible | Coût indicatif / an |
|---|---|---|---|
| Plateforme GRC financière | Cadre risque TIC, preuves, reporting | Banques, assurances, grands acteurs | Élevé, sur devis |
| Outil TPRM (risque tiers) | Registre d’information, prestataires | Toutes entités DORA | Variable |
| Plateforme multi-référentiels | DORA + RGPD + NIS2 reliés | Groupes multi-obligations | Sur devis |
| Module registre dédié | Registre d’information seul | Petites entités financières | Modéré |
Deux observations. D’abord, le registre d’information est la brique commune : même une petite entité financière a besoin d’un outil qui le structure correctement, car son format est contraint. Ensuite, DORA ne vit pas isolé : une banque ou une assurance est aussi soumise au RGPD sur les données clients et à la DSP2 sur les données bancaires. Une plateforme multi-référentiels évite de tenir un registre TIC côté DORA et un registre de traitements côté RGPD sans les relier. Notre guide sur le logiciel de conformité banque-assurance traite précisément cette convergence, et une plateforme comme Legiscope permet de relier la gestion des prestataires TIC au registre RGPD.
L’ancrage sur la supervision ACPR et AMF
En France, la conformité DORA se joue sous le regard de l’ACPR (banque, assurance) et de l’AMF (marchés). Ces autorités relaient les attentes des autorités européennes de surveillance (EBA, EIOPA, ESMA) et contrôlent la mise en œuvre du règlement DORA.
Le point pratique : le registre d’information est appelé à être transmis et exploité par les superviseurs, ce qui rend son exactitude et son format déterminants. Un outil qui produit un export conforme aux normes techniques réduit le risque de non-conformité formelle. DORA recoupant NIS2 pour les entités financières relevant des deux régimes, un logiciel de conformité NIS2 et un outil DORA gagnent à partager la même cartographie des actifs et des fournisseurs. La supervision de l’ACPR s’inscrit dans ce cadre européen : mieux vaut un référentiel unique qu’une accumulation d’outils cloisonnés.
Le registre d’information : là où les projets DORA échouent
Sur le terrain, le point qui fait dérailler les projets DORA n’est pas la stratégie de gestion du risque TIC, c’est le registre d’information. Son format est contraint par les normes techniques d’exécution des autorités européennes de surveillance, avec des dizaines de champs interconnectés : entités du groupe, fonctions supportées, prestataires TIC directs et sous-traitants en cascade, criticité, dispositions contractuelles. Reconstituer cette structure sur un tableur mène presque toujours à des incohérences que les superviseurs repèrent immédiatement.
Trois difficultés reviennent. D’abord, la cascade de sous-traitance : DORA impose de tracer non seulement le prestataire direct, mais la chaîne en dessous, ce qu’un tableur peine à modéliser. Ensuite, la cohérence des identifiants : chaque prestataire et chaque fonction doivent être référencés de façon stable, sous peine de rejet à la transmission. Enfin, la mise à jour continue : le registre n’est pas un instantané annuel, il doit refléter la réalité contractuelle à tout moment.
Un outil qui applique nativement le modèle de données réglementaire supprime ces écueils : il contraint la saisie, vérifie la cohérence et produit l’export attendu. C’est la première fonction à évaluer dans un logiciel DORA, avant même les modules de tests ou de reporting. Une entité qui maîtrise son registre d’information a franchi la marche la plus haute de la conformité DORA ; une entité qui le bricole s’expose à un constat de non-conformité formelle dès le premier contrôle, indépendamment de la qualité réelle de sa sécurité.
Deux exigences connexes se jouent au même endroit et méritent d’être outillées d’emblée. La stratégie de sortie : DORA impose, pour chaque prestataire TIC critique, un plan de réversibilité documenté, permettant de changer de fournisseur ou de réinternaliser sans rupture de service. Cette obligation, souvent négligée, suppose de relier chaque fonction critique du registre à un scénario de sortie testé. La gestion de la concentration : une entité qui dépend d’un même hébergeur cloud pour plusieurs fonctions critiques doit identifier ce risque de concentration et le documenter. Le registre d’information est précisément l’outil qui rend ces analyses possibles, à condition qu’il modélise les dépendances plutôt qu’une simple liste plate de prestataires. C’est pourquoi le choix de bâtir son registre sur tableur ou de s’appuyer sur un outil dédié n’est pas neutre : un tableur peine à représenter les dépendances en cascade, à signaler une concentration excessive ou à relier une fonction à sa stratégie de sortie. Un outil conçu pour DORA porte nativement cette logique relationnelle, et c’est précisément ce qui sépare un registre simplement rempli, qui coche une case, d’un registre réellement exploitable et opposable devant un superviseur.
FAQ
Un logiciel de conformité DORA est-il obligatoire ?
Non. DORA impose des obligations — cadre de gestion du risque TIC, registre d’information, reporting d’incidents, tests de résilience — pas un outil précis. Un logiciel devient nécessaire en pratique car le registre d’information et le reporting sont trop structurés et trop contrôlés pour un pilotage fiable sur tableur au-delà de quelques prestataires.
Qu’est-ce que le registre d’information DORA ?
C’est le recensement, imposé par DORA, de l’ensemble des prestataires TIC d’une entité financière : fonctions supportées, criticité, dispositions contractuelles. Il suit un format défini par les normes techniques des autorités européennes et doit être tenu à jour et transmis aux superviseurs. C’est la pièce maîtresse de la gestion du risque tiers.
DORA et NIS2 se cumulent-ils ?
Pour une entité financière relevant des deux, oui, mais DORA prime en tant que lex specialis sur les aspects qu’il couvre. En pratique, mesures de sécurité, gestion des incidents et cartographie se recoupent largement. Une plateforme multi-référentiels qui partage une cartographie commune évite les doublons entre les deux régimes.
Qui supervise DORA en France ?
L’ACPR pour la banque et l’assurance, l’AMF pour les marchés financiers. Elles relaient les attentes des autorités européennes de surveillance (EBA, EIOPA, ESMA) et contrôlent la mise en œuvre du règlement, notamment l’exactitude du registre d’information et la qualité du reporting d’incidents.
See Legiscope in action
AI-powered GDPR compliance that saves 340+ hours/year. Trusted by compliance professionals across Europe.
Request a demo