Depuis le 17 janvier 2025, le règlement DORA (Digital Operational Resilience Act) est pleinement applicable dans les 27 États membres de l'Union européenne. Contrairement à une directive, il s'applique directement, sans transposition nationale. L'AMF et l'ACPR peuvent contrôler votre conformité dès maintenant.
Ce que les articles grand public couvrent : les cinq piliers, les tests d'intrusion, la gestion des tiers TIC. Ce qu'ils omettent presque systématiquement : la gouvernance des accès aux données, et notamment la maîtrise des droits sur les environnements collaboratifs comme Microsoft 365. C'est pourtant l'un des leviers les plus concrets, les plus rapides à activer, et les plus souvent négligés dans les plans de conformité.
Au programme :
DORA (Digital Operational Resilience Act) : règlement (UE) 2022/2554 du 14 décembre 2022, applicable depuis le 17 janvier 2025, imposant un cadre harmonisé de gestion des risques liés aux technologies de l'information et de la communication (TIC) à l'ensemble du secteur financier européen.
Le périmètre d'application est délibérément large. L'article 2(1) du règlement couvre 21 catégories d'entités, parmi lesquelles :
Ce dernier point mérite attention : si vous êtes un prestataire de services informatiques, un éditeur de logiciels ou un fournisseur cloud travaillant avec le secteur financier, DORA peut vous concerner directement.
Un principe de proportionnalité est prévu. Les micro-entreprises bénéficient d'obligations allégées, notamment des fréquences de tests réduites et des seuils adaptés pour la notification des incidents.
Enfin, DORA s'impose comme une lex specialis par rapport à NIS2 : pour les entités financières, c'est DORA qui constitue le référentiel principal en matière de risques TIC et de notification d'incidents, en lieu et place de NIS2.
Le règlement s'articule autour de cinq domaines d'exigences. Voici ce qu'ils impliquent en pratique.
Pilier 1 - Gestion des risques TIC
L'article 8 exige une cartographie exhaustive et tenue à jour de l'ensemble des actifs informationnels, des fonctions métiers critiques et des dépendances vis-à-vis des tiers. Cette cartographie n'est pas ponctuelle : elle doit être révisée au minimum une fois par an. Le règlement délégué (UE) 2024/1774, publié par la Commission le 13 mars 2024, précise les exigences en matière de contrôle d'accès aux actifs TIC à son article 21 : les responsabilités doivent être clairement attribuées et la surveillance des droits maintenue à tous les niveaux.
Pilier 2 - Gestion et notification des incidents majeurs
Un incident est qualifié de majeur lorsqu'il affecte les réseaux et systèmes soutenant des fonctions critiques ou importantes de l'entité. Les délais sont stricts : selon l'article 5 du règlement délégué (UE) 2025/301, la notification initiale doit être soumise dans les 4 heures suivant la classification de l'incident comme majeur. Si l'incident n'a pas été classé dans les 24 heures suivant sa détection, ce délai de 4 heures court à compter de la classification.
En France, les notifications s'effectuent auprès de l'ACPR via le portail OneGate.
Pilier 3 - Tests de résilience opérationnelle
Les entités doivent soumettre, au moins une fois par an, l'ensemble des systèmes et applications soutenant des fonctions critiques à des tests appropriés (article 24). Les entités significatives sont soumises à des tests de pénétration fondés sur la menace (TLPT) selon un calendrier plus contraignant.
Pilier 4 - Gestion des risques liés aux tiers TIC
Les entités doivent tenir un registre exhaustif de tous leurs prestataires TIC, distinguer les fonctions critiques, intégrer des clauses contractuelles spécifiques (droits d'audit, niveaux de service, stratégies de sortie) et le transmettre à l'ACPR. Ce registre doit être disponible à tout moment pour les régulateurs.
Pilier 5 - Partage d'informations sur les cybermenaces
Les entités peuvent notifier volontairement les cybermenaces importantes à l'ACPR (article 19(2)). Ce partage est encouragé, sans être obligatoire pour les menaces non classifiées comme incidents majeurs.
|
Pilier |
Obligation principale |
Référence |
|
Gestion des risques TIC |
Cartographie actifs + droits d'accès |
Article 8 + Règlement délégué 2024/1774 art. 21 |
|
Notification incidents |
4h après classification comme majeur |
Article 19 + Règlement délégué 2025/301 art. 5 |
|
Tests de résilience |
Tests annuels, TLPT pour entités significatives |
Article 24 |
|
Risques tiers TIC |
Registre + clauses contractuelles + transmission ACPR |
Article 28 et 30 |
|
Partage d'informations |
Notification volontaire des cybermenaces |
Article 19(2) |
La plupart des plans de conformité DORA se concentrent sur les tests d'intrusion et la gestion des prestataires TIC. C'est légitime. Mais l'article 8 impose quelque chose de plus fondamental et de plus difficile à traiter à grande échelle : savoir précisément qui a accès à quoi, dans quelles conditions, et avec quels droits.
Dans un environnement Microsoft 365, cela recouvre des milliers d'espaces collaboratifs. Chaque site SharePoint, chaque équipe Teams, chaque dossier OneDrive partagé représente un accès potentiel à des données sensibles. Les droits s'accumulent au fil du temps : anciens collaborateurs qui conservent des accès, partages anonymes oubliés, équipes configurées en mode public par erreur, accès accordés lors d'une collaboration externe qui n'ont pas été révoqué.
Ce n'est pas un problème marginal. Selon les données IDECSI issues de déploiements réels auprès de plus d'un million d'utilisateurs, chaque utilisateur M365 présente en moyenne 5 à 7 situations de droits à vérifier ou corriger lors d'un premier bilan de sécurité. 80% des violations de données proviennent d'erreurs internes, pas d'attaques externes.
Le lien avec DORA est direct. L'article 8 exige une cartographie des actifs informationnels et de leurs accès. Le règlement délégué 2024/1774 (article 21) impose une gestion formalisée des droits d'accès aux actifs TIC, avec attribution claire des responsabilités. Une entité qui ne sait pas qui accède à ses données sensibles dans M365 ne peut pas satisfaire ces exigences.
L'enjeu n'est pas seulement réglementaire. Dans le secteur financier, les données traitées au quotidien sont des données critiques, sensibles : plans financiers, dossiers clients, données de marché, documents contractuels. Un accès non maîtrisé sur ces données constitue un risque opérationnel réel, au sens même où DORA l'entend.
La mise en conformité DORA n'est pas un projet unique. C'est un programme structuré, qui doit s'inscrire dans la durée. Voici les actions prioritaires, classées par ordre logique.
1. Cartographier les actifs TIC et les droits associés
Recenser l'ensemble des systèmes, applications et environnements collaboratifs. Pour M365, cela inclut SharePoint, Teams, OneDrive, Exchange et les données classifiées via Microsoft Information Protection (MIP). L'objectif est d'avoir une vision complète de qui a accès à quoi, avec quels droits.
2. Identifier les propriétaires fonctionnels des données
La conformité DORA ne peut pas reposer uniquement sur l'équipe IT. Chaque espace collaboratif doit avoir un propriétaire fonctionnel identifié, responsable de la légitimité des accès. C'est ce que DORA appelle l'attribution claire des responsabilités.
3. Lancer une première revue des droits d'accès
C'est l'étape la plus opérationnelle. Elle consiste à soumettre aux propriétaires fonctionnels la liste des accès ouverts sur leurs données, et à les inviter à valider ou corriger. Cette recertification des habilitations est un prérequis direct de l'article 8 et du règlement délégué 2024/1774.
4. Mettre en place des campagnes périodiques
Une revue unique ne suffit pas. DORA exige une surveillance continue. Des campagnes planifiées, tous les 6 à 12 mois selon la criticité des données, permettent de maintenir une gouvernance des accès dans la durée.
5. Documenter pour les régulateurs
Chaque campagne de revue doit être traçable : quelles données ont été auditées, qui a validé quoi, quelles corrections ont été apportées. Cette documentation constitue la preuve de conformité que l'ACPR ou l'AMF peuvent demander lors d'un contrôle.
DORA est applicable depuis janvier 2025. Il n'y a pas de période de grâce formelle. L'article 50 du règlement habilite les autorités compétentes à exercer tous les pouvoirs de surveillance, d'enquête et de sanction nécessaires à l'application du règlement.
En France, l'AMF et l'ACPR disposent du pouvoir de prononcer des mesures correctives immédiates, des injonctions de mise en conformité et des suspensions temporaires d'activités. Les États membres fixent eux-mêmes les montants des sanctions pécuniaires, qui doivent être effectives, proportionnées et dissuasives.
Pour les prestataires tiers de services TIC désignés comme critiques, le règlement prévoit directement des astreintes journalières pouvant s'élever jusqu'à 1% du chiffre d'affaires mondial quotidien, pendant une durée maximale de six mois.
Au-delà des sanctions financières, une non-conformité documentée par les régulateurs peut avoir des conséquences sur la réputation et la relation avec les clients institutionnels, qui sont eux-mêmes soumis à des obligations d'audit de leurs prestataires TIC.
Dans le secteur financier, la conformité DORA ne s'improvise pas. BPCE-IT, la filiale IT du Groupe BPCE, en a fait l'expérience dans le cadre de son programme de cybersécurité Walkyrie : face à une adoption massive des outils collaboratifs et une volumétrie de données en croissance exponentielle, l'organisation devait reprendre le contrôle sur ses partages Microsoft 365, et le prouver.
Les objectifs étaient précisément ceux qu'impose DORA : réduire les risques d'exposition des données sensibles, déployer des revues régulières des droits d'accès, responsabiliser les utilisateurs et mesurer l'efficacité de la démarche via des KPIs clairs.
En s'appuyant sur la plateforme IDECSI, BPCE-IT a structuré des campagnes de revue de droits à grande échelle, impliquant directement les collaborateurs dans la correction de leurs propres partages. Résultat : 10 000 corrections apportées, un objectif atteint, et des utilisateurs qui saluent l'ergonomie de la solution.
"Ces campagnes nous ont permis de réduire l'exposition de nos données, 10 000 corrections ont été apportées, l'objectif est atteint. Les utilisateurs sont satisfaits par l'ergonomie de la solution et apprécient être au cœur de la démarche." — Vincent Rey, Leader Adjoint et responsable des solutions de protection de la donnée, BPCE-IT
C'est précisément ce que permet la plateforme IDECSI : transformer une exigence réglementaire en démarche opérationnelle concrète. Cartographier les droits sur M365, identifier les propriétaires fonctionnels, lancer des campagnes de remédiation à grande échelle, sans mobiliser des ressources IT importantes, avec des résultats mesurables et documentables pour les régulateurs. En quelques semaines, pas en plusieurs mois.
DORA est en vigueur. Les régulateurs contrôlent. Les entités qui ont concentré leurs efforts sur les tests d'intrusion et la gestion des tiers TIC ont bien fait. Mais la gouvernance des accès aux données, et en particulier la maîtrise des droits dans les environnements collaboratifs comme Microsoft 365, reste un angle mort dans de nombreux plans de conformité.
C'est précisément ce que permet de traiter la plateforme IDECSI : cartographier les droits d'accès sur M365, identifier les propriétaires fonctionnels, lancer des campagnes de revue de droits et des remédiations de masse, générer des rapports clairs, afin de prouver la conformité. En quelques semaines, sans mobiliser des ressources IT importantes, avec des résultats mesurables.
Demandez une démo pour voir comment IDECSI aide les entités financières à structurer leur gouvernance des accès dans M365 en conformité avec DORA.