DORA : votre plan de reprise fonctionne-t-il quand plusieurs systèmes tombent ?

Une application peut redémarrer sans que le service métier soit de nouveau opérationnel. Dans le secteur financier, préparer la reprise exige de tester les dépendances réelles entre systèmes, données, accès et prestataires.1

Restaurer des serveurs ne suffit pas

Une banque peut disposer de sauvegardes quotidiennes, d'une infrastructure redondante et d'un plan de reprise documenté. Pourtant, après un incident majeur, le service de paiement peut rester indisponible. L'application a redémarré, mais l'annuaire d'identités est inaccessible ; la base de données fonctionne, mais les échanges avec un prestataire sont interrompus ; ou les données restaurées ne permettent pas de reprendre les transactions de manière fiable.

Il faut distinguer trois étapes : restaurer les composants techniques, rétablir leurs dépendances, puis vérifier que la fonction métier peut réellement être exécutée.

Ce que prévoit DORA

Le règlement (UE) 2022/2554, applicable depuis le 17 janvier 2025, encadre la continuité des activités TIC, les mécanismes de réponse et de rétablissement, les sauvegardes et les tests de résilience. Ses articles 11 et 12 sont particulièrement pertinents pour les plans de continuité et de reprise ; son article 24 traite du programme de tests de résilience opérationnelle numérique.1

Le règlement délégué (UE) 2024/1774 précise les politiques et procédures de gestion du risque TIC. Il insiste notamment sur les scénarios pertinents, la prise en compte des prestataires et les essais de bascule vers les capacités de secours.2

Ces textes n'imposent pas une méthode universelle identique à toutes les organisations : les mesures et les exercices doivent être adaptés aux obligations applicables, à la criticité des fonctions et aux risques.

Partir de la fonction critique plutôt que du serveur

Pour préparer un test, l'équipe commence par choisir une fonction métier, par exemple l'exécution des paiements. Elle identifie ensuite les applications, bases de données, identités, flux réseau, services d'infrastructure et fournisseurs TIC indispensables. Une dépendance partagée peut devenir un point de défaillance commun à plusieurs fonctions.

Cette analyse permet de définir un ordre de reprise cohérent. Restaurer une application avant le service d'authentification dont elle dépend ne suffit pas à remettre la fonction à disposition des utilisateurs.

Cas pratique : l'annuaire central est compromis

Imaginons une banque dont l'annuaire central est compromis alors que les serveurs de paiement et leurs bases de données sont toujours disponibles. Les collaborateurs ne peuvent plus accéder aux outils nécessaires à l'exécution des opérations.

L'exercice de reprise doit répondre à plusieurs questions : les comptes d'administration de secours restent-ils utilisables ? L'infrastructure de reprise dépend-elle du même annuaire ? Les procédures sont-elles accessibles aux équipes en situation dégradée ? Les transactions de contrôle fonctionnent-elles une fois les accès restaurés ? Les prestataires concernés peuvent-ils intervenir dans les délais prévus ?

Ce scénario est fictif. Son intérêt est de montrer qu'une reprise ne peut être jugée réussie à partir du seul redémarrage des machines.

Cinq vérifications pendant l'exercice

1. Définir le service attendu : quelle opération métier doit redevenir possible et pour quels utilisateurs ?
2. Identifier les dépendances : quels composants internes et externes sont indispensables ?
3. Tester l'ordre de rétablissement : quelles étapes bloquent les suivantes ?
4. Vérifier l'intégrité : les données et les transactions restaurées sont-elles cohérentes ?
5. Documenter les écarts : délais réels, obstacles, responsables et actions correctives.

Une vérification métier, par exemple une transaction de contrôle réalisée dans un environnement autorisé, apporte une preuve différente d'un simple voyant technique au vert.

Trois mesures utiles, sans les confondre avec des seuils réglementaires

Le temps réel nécessaire pour rétablir la fonction, l'intégrité des données restaurées et la proportion des dépendances effectivement vérifiées constituent trois mesures pratiques pour analyser un exercice. Elles ne sont pas, en elles-mêmes, une grille officielle de conformité DORA.

Les résultats doivent être rapprochés des objectifs de rétablissement définis par l'organisation, de son analyse d'impact et des obligations qui lui sont applicables.

Ce que révèle un test de bout en bout

Une cartographie des dépendances utile à la reprise n'est pas une simple liste d'actifs. Elle doit permettre de relier une fonction métier aux composants qui la soutiennent et de comprendre les défaillances communes possibles. Elle doit aussi rester à jour : une dépendance oubliée peut invalider un scénario de test.

La bonne question n'est donc pas seulement : « chaque système peut-il redémarrer ? », mais : « la fonction critique peut-elle reprendre dans des conditions vérifiées ? »