Plan de mise en conformité DORA

Pourquoi ce chapitre est le plus utile

Connaître les cinq piliers de DORA — gouvernance du risque TIC, gestion des incidents, tests de résilience, risque tiers, partage d'information — ne suffit pas à mettre une organisation en conformité. Le règlement est en application depuis janvier 2025 : la question n'est plus « faut-il s'y mettre » mais « où en est-on réellement, et par quoi combler l'écart en premier ». Ce chapitre fournit la méthode pour transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire une liste d'exigences réglementaires en plan d'exécution daté, budgété et suivi par la gouvernance.

Un plan de mise en conformité DORA qui reste dans un tableur juridique ne produit rien. Il doit se traduire en tickets assignés, en jalons vérifiables et en preuves horodatées. C'est cette mécanique de production de preuves, plus que la connaissance du texte, qui distingue une conformité déclarative d'une conformité opposable en contrôle. C'est aussi ce qui différencie un plan qui survit à un changement de RSSI ou de direction des risques d'un plan qui repart de zéro à chaque mouvement d'organigramme.

DORA est un règlement d'application directe, sans transposition nationale. Il n'y a pas de « délai de grâce » local : une entité financière européenne est théoriquement exposée dès aujourd'hui à un contrôle sur sa conformité. Un plan sans date de départ immédiate n'est pas un plan, c'est une intention.

Étape 1 — Gap analysis : mesurer l'écart avant de courir

La gap analysis est le socle de tout le reste. Elle consiste à confronter, pilier par pilier, l'état actuel du dispositif à l'exigence du règlement, puis à noter chaque écart selon sa gravité et sa complexité de remédiation.

En pratique, elle se mène en trois passes :

1. Inventaire documentaire — politiques existantes de gestion du risque TIC, procédures d'incident, contrats prestataires, derniers résultats de tests de continuité.
2. Entretiens ciblés — RSSI, DSI, direction des risques, juridique, achats. Chacun détient une part de la réponse ; aucun ne l'a en entier.
3. Cartographie des systèmes critiques — quelles fonctions supportent des services essentiels, quels prestataires TIC les hébergent ou les opèrent.

Le livrable n'est pas un rapport de cinquante pages mais une matrice exploitable : pilier, exigence, état actuel, écart, criticité, effort estimé. C'est cette matrice qui alimente directement la roadmap.

Pour prioriser sans arbitrage subjectif, il est utile de croiser chaque écart identifié sur deux axes : la criticité réglementaire et opérationnelle (que se passe-t-il si l'écart reste ouvert) et l'effort de remédiation (temps, budget, dépendance à des tiers). Un écart à forte criticité et faible effort — par exemple l'absence de politique de classification des incidents — devient un quick win prioritaire. Un écart à forte criticité et fort effort — la renégociation d'un contrat cloud majeur — doit être lancé le plus tôt possible dans la roadmap, précisément parce qu'il prendra du temps. À l'inverse, un écart à faible criticité et fort effort peut être repoussé sans risque disproportionné, ce qui évite de diluer les ressources sur des chantiers secondaires pendant que les priorités réelles attendent.

La gap analysis n'est pas un exercice one-shot. Elle doit être rejouée à chaque changement significatif — nouveau prestataire cloud critique, refonte du SI, fusion-acquisition — sous peine de devenir obsolète en quelques mois.

Étape 2 — Quick wins : les trois premiers mois

Avant d'attaquer les chantiers structurels, certains gains sont mobilisables rapidement et servent à la fois de preuve de mouvement pour le COMEX et de base pour la suite.

• Formaliser la politique de gestion des incidents TIC si elle n'existe qu'à l'état informel — c'est souvent un document de reformulation plus que de création.
• Aligner la classification des incidents sur les critères DORA (impact sur les clients, durée, donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire affectées, criticité des services touchés) pour éviter une reclassification a posteriori en cas d'incident majeur.
• Démarrer le registre des prestataires TIC, même incomplet : un registre à 60 % maintenu à jour vaut mieux qu'un registre à 100 % figé au jour de sa création.
• Revoir les clauses contractuelles types avec les prestataires critiques pour vérifier la présence des clauses minimales exigées par l'article 30 (droits d'audit, plans de sortie, localisation des données).

Les quick wins doivent être choisis pour leur visibilité autant que pour leur impact réglementaire. Un registre des prestataires initié et un premier reporting d'incident conforme donnent au COMEX une preuve tangible que le sujet avance, ce qui facilite l'obtention du budget pour les chantiers plus lourds.

Étape 3 — Construire la roadmap 18 mois

La roadmap découpe le travail en quatre phases dont la durée dépend de la taille de l'organisation et de sa maturité initiale, mais qui suivent toujours la même logique : cadrer, sécuriser rapidement, remédier en profondeur, industrialiser.

La phase de remédiation (M6-M12) est généralement la plus lourde, car elle porte sur le risque tiers TIC : renégocier des contrats avec des hyperscalers ou des éditeurs en position de force prend du temps, et les tests de résilience — a fortiori les tests de pénétration fondés sur la menace (TLPT) pour les entités qui y sont soumises — nécessitent une planification avec des prestataires spécialisés.

Ne sous-estimez pas le délai de renégociation contractuelle avec les grands prestataires cloud. Un fournisseur en position dominante peut mettre plusieurs mois à accepter une clause d'audit ou un plan de sortie standardisé. Intégrez ce délai dans la roadmap dès la phase de cadrage, sans quoi la phase 3 déborde systématiquement sur la phase 4.

Cadrer les ressources et les rôles

Une roadmap sans porteurs identifiés reste un document d'intention. Avant de lancer la phase de cadrage, il faut associer à chaque grand bloc de travail un responsable clair, faute de quoi les arbitrages inter-directions ralentissent tout le projet. Une répartition simplifiée fonctionne pour la plupart des organisations :

• Chef de projet DORA — rattaché à la direction des risques ou à la conformité, il pilote le calendrier, consolide l'avancement et prépare les points COMEX. C'est le point d'entrée unique pour toutes les parties prenantes.
• RSSI référent — responsable des aspects techniques : cartographie des systèmes critiques, tests de résilience, remédiation des vulnérabilités.
• Juridique et achats — pilotent la revue et la renégociation des clauses contractuelles avec les prestataires TIC, en lien étroit avec le RSSI référent sur les exigences techniques à intégrer.
• Direction des risques — valide la matrice de criticité, arbitre les priorités en cas de ressources contraintes, et porte le reporting réglementaire vers l'ACPR ou l'AMF.
• Sponsor exécutif — membre du COMEX, il tranche les arbitrages budgétaires et inter-directions que le chef de projet ne peut résoudre seul.

Ce découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire n'a pas besoin d'être formalisé en organigramme complexe : un tableau à deux colonnes — bloc de travail et responsable désigné — validé en comité de lancement suffit à éviter les zones grises qui, en pratique, sont la première cause de retard sur ce type de plan transverse.

Étape 4 — Constituer le dossier de preuves d'audit

Un plan de conformité qui ne produit pas de preuves opposables ne protège pas l'organisation en cas de contrôle. Le dossier de preuves doit être pensé dès le lancement du plan, pas reconstitué a posteriori.

Une entité contrôlée par l'ACPR doit pouvoir produire, en quelques jours, la chronologie complète d'un incident majeur survenu six mois plus tôt : détection, classification, notification, mesures correctives, clôture. Si cette chronologie n'existe que dans des échanges d'e-mails dispersés entre trois équipes, le dossier ne tiendra pas le contrôle — même si l'incident a été correctement traité sur le fond.

La règle pratique : chaque jalon de la roadmap doit produire un artefact daté et archivé — compte-rendu de comité, export de registre, rapport de test signé — versé dans un espace centralisé accessible à l'audit interne, à la conformité et, in fine, au superviseur.

Piloter le plan dans la durée : indicateurs clés

Un plan qui n'est mesuré qu'au moment du pitch COMEX perd sa valeur de pilotage entre deux présentations. Quelques indicateurs simples, suivis mensuellement, suffisent à détecter un dérapage avant qu'il ne devienne un problème de contrôle :

• Taux de complétion du registre des prestataires — pourcentage des prestataires critiques identifiés dont la fiche est complète et à jour.
• Part des contrats critiques conformes — proportion des contrats intégrant les clauses minimales de l'article 30, sur le total des contrats prestataires critiques recensés.
• Délai moyen de notification d'incident — temps écoulé entre la détection d'un incident majeur et sa notification formelle, comparé aux seuils réglementaires.
• Couverture des tests de résilience — proportion des systèmes critiques ayant fait l'objet d'un test dans les douze derniers mois.
• Taux de clôture des actions de remédiation — pourcentage des vulnérabilités identifiées en test dont le correctif a été appliqué et vérifié.

Ces indicateurs alimentent à la fois le reporting opérationnel du chef de projet et le tableau de bord présenté au COMEX. Ils ont surtout un rôle d'alerte précoce : un taux de complétion du registre qui stagne à 60 % pendant deux trimestres consécutifs signale un blocage structurel — souvent un manque de ressources ou un arbitrage non tranché — bien avant qu'un contrôle externe ne le révèle.

Étape 5 — Pitcher le plan au COMEX

Le COMEX n'a pas besoin du détail réglementaire, il a besoin de trois choses : le niveau de risque actuel, le coût de l'inaction, et la trajectoire proposée avec ses jalons de décision.

Un pitch efficace suit une structure resserrée :

1. Le risque en une phrase — « Notre registre de prestataires critiques est incomplet à 40 %, ce qui nous expose à une non-conformité constatable dès le prochain contrôle ACPR. »
2. Ce qui a déjà été fait — les quick wins livrés, avec preuve à l'appui (screenshot du registre, extrait de politique validée).
3. La trajectoire chiffrée — roadmap 18 mois avec jalons, effort en jours-homme, budget prestataires externes si nécessaire (tests de résilience, audit contractuel).
4. La décision demandée — sponsor exécutif nommé, budget validé, fréquence de reporting (trimestrielle recommandée).

Évitez de présenter DORA comme un projet IT isolé. Le COMEX réagit davantage à un cadrage en termes de risque opérationnel et de responsabilité des dirigeants — l'article 5 de DORA engage explicitement l'organe de direction sur la gouvernance du risque TIC, ce qui rend le sujet directement pertinent pour chaque membre du COMEX, pas seulement pour la DSI.

Pièges fréquents

• Traiter DORA comme un projet IT alors que le règlement engage la gouvernance et les fonctions métier au même titre que la DSI — un plan porté uniquement par la DSI peine à obtenir la coopération du juridique et des achats sur les clauses contractuelles.
• Confondre gap analysis et audit de sécurité : DORA porte sur la résilience opérationnelle, pas uniquement sur la cybersécurité technique, ce qui implique d'évaluer aussi la gouvernance, les processus de continuité et la gestion contractuelle des tiers.
• Sous-dimensionner le registre des prestataires en se limitant aux fournisseurs cloud visibles, en oubliant les sous-traitants de rang 2 et les éditeurs de logiciels critiques qui hébergent ou traitent des données essentielles sans être des interlocuteurs directs.
• Lancer les tests de résilience sans plan de remédiation préétabli — un test qui révèle des failles sans budget de correction prévu devient une preuve à charge plutôt qu'un outil de progrès.
• Ne pas nommer de sponsor exécutif unique, ce qui dilue la responsabilité et ralentit les arbitrages budgétaires entre directions, en particulier lorsque les priorités du RSSI et celles des achats entrent en tension sur le calendrier de renégociation contractuelle.

Checklist de clôture du plan

• Gap analysis formalisée et validée par la direction des risques.
• Registre des prestataires TIC critiques à jour, incluant les sous-traitants de rang 2 identifiés.
• Politique de gestion des incidents alignée sur la classification DORA.
• Au moins un cycle de tests de résilience réalisé, avec plan de remédiation associé.
• Dossier de preuves centralisé et accessible à l'audit interne.
• Sponsor exécutif nommé et reporting COMEX trimestriel instauré.

Un plan qui coche ces six points n'est pas une conformité définitivement acquise — DORA impose une amélioration continue — mais il constitue une base défendable face à un contrôle, et surtout un dispositif qui réduit réellement l'exposition opérationnelle de l'organisation aux défaillances de ses prestataires numériques.