Un plan de continuité d'activité qui n'a jamais été testé en conditions réalistes, c'est un document de fiction. Et pourtant, c'est exactement la situation de beaucoup d'entités financières. Des plans épais de 200 pages, validés par le board, rangés dans un tiroir — et qui s'effondrent au premier test sérieux parce que le numéro de téléphone du prestataire de secours a changé il y a trois ans.
DORA ne tolère pas cette approche. Les articles 11 et 12 imposent des exigences précises sur les plans de continuité et de reprise d'activité ICT, avec une obligation de test régulier et un reporting au comité de direction.
Ce que DORA exige — au-delà du PCA classique
La plupart des entités financières disposent déjà d'un PCA (plan de continuité d'activité) et d'un PRA (plan de reprise d'activité). DORA ne repart pas de zéro — mais il élargit et durcit les exigences, spécifiquement sur la composante ICT.
La politique de continuité des activités ICT
L'article 11 impose une politique de continuité des activités ICT intégrée dans le cadre de gestion des risques ICT. Cette politique doit couvrir :
| Composante | Exigence DORA |
|---|---|
| BIA (Business Impact Analysis) | Analyse d'impact pour chaque fonction critique, avec RTO et RPO définis |
| Scénarios de crise | Scénarios plausibles incluant cyberattaques, pannes prestataires, catastrophes naturelles |
| Plans de réponse | Procédures détaillées pour chaque scénario, avec rôles et responsabilités |
| Communication de crise | Plan de communication interne et externe, incluant la notification aux autorités |
| Plans de reprise | Procédures de restauration avec séquence de priorité et vérification d'intégrité |
| Sites de secours | Capacités de reprise alternatives, testées et opérationnelles |
Les RTO et RPO — pas de place pour le flou
DORA exige que les entités définissent des objectifs de reprise précis pour chaque fonction critique :
RTO (Recovery Time Objective) : le délai maximum acceptable entre la survenance de l'incident et la reprise du service. Pour un système de paiement, c'est souvent de l'ordre de 2 à 4 heures. Pour un outil de reporting, ça peut être 24 à 48 heures.
RPO (Recovery Point Objective) : la perte de données maximale acceptable. Un RPO de zéro signifie aucune perte de données — ce qui implique une réplication synchrone. Un RPO de 1 heure signifie qu'on accepte de perdre au maximum 1 heure de données.
Le point clé : ces objectifs ne doivent pas être théoriques. Ils doivent être vérifiés par des tests réguliers. Un RTO contractuel de 4 heures avec votre prestataire cloud ne vaut rien si votre dernier test de reprise a montré un RTO réel de 72 heures.
Les scénarios de crise DORA — penser l'impensable
DORA pousse les entités à envisager des scénarios de crise ICT qui vont au-delà de la simple panne technique :
Cyberattaque destructive. Un ransomware chiffre l'ensemble des systèmes, y compris les sauvegardes en ligne. Les sauvegardes offline sont-elles à jour et testées ?
Défaillance d'un prestataire ICT critique. Votre cloud provider principal subit une panne majeure de plusieurs jours. Pouvez-vous basculer sur une alternative ? Dans quel délai ?
Compromission de la chaîne d'approvisionnement. Un prestataire de mise à jour logicielle est compromis (scénario SolarWinds). Comment détectez-vous et contenez-vous la propagation ?
Catastrophe physique. Un incendie détruit votre datacenter principal (scénario OVH Strasbourg 2021). Le site de secours prend-il le relais automatiquement ?
Indisponibilité des équipes clés. Une pandémie rend indisponibles 50% de vos effectifs IT. Les procédures de reprise sont-elles documentées de manière suffisamment détaillée pour être exécutées par des équipes de backup ?
L'obligation de test — le moment de vérité
L'article 11(6) impose des tests réguliers des plans de continuité et de reprise. Les tests de résilience DORA incluent explicitement des exercices de continuité. La fréquence minimale : une fois par an pour les scénarios principaux.
Types de tests exigés
| Type de test | Description | Fréquence recommandée |
|---|---|---|
| Test sur table (tabletop) | Simulation théorique avec les équipes de direction | Semestriel |
| Test fonctionnel | Activation des procédures de bascule sans impact production | Annuel |
| Test de bascule réel | Basculement effectif sur le site de secours | Annuel (fonctions critiques) |
| Test de restauration | Restauration complète à partir des sauvegardes | Trimestriel |
| Exercice de crise complet | Simulation end-to-end incluant communication et notification | Annuel |
Le résultat des tests doit être documenté, les écarts identifiés, et un plan de remédiation établi. Le comité de direction doit être informé des résultats — pas un résumé édulcoré, mais les vrais chiffres : RTO cible vs RTO réel, RPO cible vs RPO réel.
La continuité des services ICT externalisés
La continuité ne s'arrête pas aux murs de l'entité. Pour les fonctions externalisées chez des prestataires ICT tiers, DORA impose que les plans de continuité couvrent également les scénarios de défaillance du prestataire.
Concrètement, cela implique de vérifier que le prestataire dispose lui-même de plans de continuité adéquats. De tester la bascule vers le prestataire de secours ou vers une solution interne alternative. De s'assurer que les plans de sortie sont opérationnels et testés.
Un point souvent négligé : la synchronisation des plans de continuité entre l'entité et ses prestataires. Si votre plan prévoit une bascule en 4 heures mais que votre prestataire a besoin de 12 heures pour activer son site de secours, les deux plans ne sont pas alignés.
La gouvernance de la continuité sous DORA
Le rôle du comité de direction
Le board ne se contente pas d'approuver le PCA une fois par an. Sous DORA, il doit activement superviser la résilience opérationnelle. Cela inclut la validation des RTO/RPO pour les fonctions critiques, l'examen des résultats de tests, l'approbation des budgets de résilience et la participation aux exercices de crise (au moins les tabletop).
La fonction de continuité
DORA n'impose pas explicitement un "responsable PCA" mais le cadre de gestion des risques ICT doit inclure des processus de continuité clairement attribués. En pratique, les entités matures désignent un responsable de la continuité (BCM — Business Continuity Manager) rattaché au RSSI ou au CRO.
Checklist de conformité PCA/PRA sous DORA
| Élément | Vérifié |
|---|---|
| BIA réalisée et à jour pour toutes les fonctions critiques | ☐ |
| RTO et RPO définis et validés par le board | ☐ |
| Scénarios de crise ICT documentés (cyber, panne tiers, catastrophe) | ☐ |
| Plans de réponse détaillés pour chaque scénario | ☐ |
| Plan de communication de crise opérationnel | ☐ |
| Site de secours opérationnel et testé | ☐ |
| Sauvegardes testées (y compris restauration complète) | ☐ |
| Plans de continuité des prestataires ICT vérifiés | ☐ |
| Test de bascule réalisé dans les 12 derniers mois | ☐ |
| Résultats de tests présentés au board | ☐ |
| Plan de remédiation des écarts en cours d'exécution | ☐ |
FAQ — Continuité d'activité DORA
DORA impose-t-il un site de secours physique ?
DORA n'impose pas de modalité technique spécifique. Le site de secours peut être physique, cloud-based ou hybride. L'important est qu'il permette de respecter les RTO/RPO définis et qu'il soit testé régulièrement.
Les sauvegardes en cloud sont-elles conformes ?
Oui, à condition que le provider cloud soit inclus dans le registre d'informations, que les données soient chiffrées, et que la restauration soit testée régulièrement. DORA recommande toutefois de maintenir des sauvegardes déconnectées (air-gapped) pour se protéger contre les ransomwares qui ciblent aussi les sauvegardes en ligne.
Quelle différence entre PCA et PRA dans le contexte DORA ?
DORA parle de "plans de continuité des activités ICT" et de "plans de réponse et de reprise". Le PCA couvre la continuité pendant l'incident (mode dégradé, bascule). Le PRA couvre le retour à la normale après l'incident (restauration complète, vérification d'intégrité). Les deux sont exigés et doivent être cohérents entre eux.
La continuité d'activité n'est pas un exercice théorique — c'est une assurance contre l'inévitable. Les incidents ICT majeurs arrivent. La question n'est pas si, mais quand. Les entités qui investissent dans des plans testés et réalistes protègent non seulement leur conformité DORA mais aussi leur capacité à survivre à une crise réelle. Pour une vue d'ensemble, consultez notre guide complet DORA.