Lire la préparation de 2024 avec le recul de 2026
Le titre situe la décision avant janvier 2025 ; il ne prétend pas que ce dossier a été publié en 2024. Cette analyse rétrospective est écrite depuis 2026. DORA, le règlement européen sur la résilience opérationnelle numérique du secteur financier, est applicable depuis le 17 janvier 2025. Les rôles, périmètres et obligations exacts doivent être examinés pour chaque entité. Ce dossier s'intéresse au travail de programme : transformer des exigences de résilience en responsabilités, dépendances et tests utilisables.
En 2024, le danger n'était pas seulement de manquer une politique. Une organisation pouvait disposer d'un inventaire d'applications, de contrats et de sauvegardes tout en ignorant combien de temps un service métier pouvait rester indisponible et qui prendrait la décision de reprise. La préparation utile partait du service rendu, puis remontait vers ses systèmes et ses fournisseurs. En 2026, cette même logique reste pertinente pour examiner la réalité des dispositifs établis.
Scénario illustratif : cinq applications disponibles, un service arrêté
Le scénario suivant, ses personnages et ses chiffres sont pédagogiques, sans résultat client CYTIZEN revendiqué. Anne, responsable d'un service de paiement, doit vérifier sa capacité à reprendre après une interruption du fournisseur d'identité. Les tableaux techniques sont verts : bases disponibles, réseau disponible, logiciel disponible. Pourtant, les opérateurs ne peuvent plus se connecter et les instructions en attente continuent à s'accumuler.
Julien, coordinateur du programme, réunit le métier, l'exploitation, la sécurité et le fournisseur. Le service doit retrouver une capacité limitée de traitement en deux heures selon un objectif local décidé pour l'exercice. Le plan technique prévoit une restauration en quatre-vingt-dix minutes. Il ne décrit ni la remise des accès, ni le contrôle des transactions en attente, ni la décision autorisant la reprise.
Le premier exercice n'est donc pas déclaré réussi à la restauration de la base. Anne veut voir une transaction autorisée, sa trace et son rapprochement. Le programme transforme le test en parcours de reprise de service. La tolérance de deux heures est une hypothèse du scénario ; elle ne constitue ni un seuil DORA universel ni une obligation applicable à tout paiement.
Construire la carte d'un service critique
Un service reçoit un propriétaire métier et une description de son issue. La carte identifie les applications, données, équipes, fournisseurs et dépendances transverses nécessaires. Elle inclut les services souvent oubliés : identité, certificats, connectivité, supervision et canaux de communication. Le périmètre n'est pas seulement celui du contrat principal ; les points de rupture peuvent se situer dans une dépendance commune à plusieurs fournisseurs.
| Élément du scénario | Question opérationnelle | Preuve attendue |
|---|---|---|
| Autorisation de paiement | Qui peut décider une reprise partielle ? | Mandat et conditions signés par le propriétaire métier |
| Identité | Les opérateurs disposent-ils d'un accès de secours contrôlé ? | Test des accès avec journalisation et procédure de retrait |
| File de transactions | Comment reconnaître une opération déjà exécutée ? | Rapprochement et traitement des doublons démontrés |
| Fournisseur externe | Quel contact peut agir hors horaires ordinaires ? | Escalade exercée, délais constatés |
| Communication | Qui informe utilisateurs et instances concernées ? | Message préparé, canal indépendant disponible |
La carte ne doit pas devenir un schéma géant impossible à maintenir. Commencer par un parcours sensible, montrer les dépendances qui peuvent l'arrêter et nommer les responsables. L'architecture technique peut rester détaillée dans ses propres référentiels ; la carte de programme doit rendre visibles les décisions et les relations dont dépend la reprise.
Ne pas confondre sauvegarde, reprise technique et résultat métier
Le délai de reprise technique indique quand une composante peut fonctionner. La perte de données admissible concerne ce qui doit être retrouvé ou reconstitué. La reprise du service suppose aussi des accès, des procédures, des contrôles et une autorisation métier. Les trois notions sont reliées, mais aucune ne remplace les autres.
Dans l'exercice, la base est restaurée à 10 h 20. Les accès sont disponibles à 10 h 45. Le rapprochement des opérations prend quarante minutes ; la première transaction contrôlée passe à 11 h 30. Si le début d'interruption était 9 h, le service a repris après deux heures trente, même si la restauration de base a duré quatre-vingts minutes. Le compte rendu doit garder les deux mesures, pas choisir celle qui respecte le mieux la cible.
Définir à l'avance le début et la fin du chronomètre, les exclusions et la preuve de succès. Si le métier accepte une reprise limitée, préciser quelles opérations sont admises, quel volume est supportable et quel contrôle supplémentaire est nécessaire. Une reprise partielle sans limite connue peut introduire une nouvelle erreur au moment même où l'organisation cherche à réduire l'incident.
Préparer un exercice qui peut révéler un échec
Le test possède un scénario, un animateur, des observateurs, des critères et un responsable d'arrêt. Les acteurs reçoivent les informations disponibles au moment simulé, pas la solution complète. Dans notre cas, l'animateur annonce l'indisponibilité de l'identité, puis un contact fournisseur absent et un écart dans la file de transactions. Les observateurs notent qui décide et à partir de quelles données.
Une première répétition sur table peut exposer des lacunes sans toucher la production. Un test technique de restauration apporte une autre preuve. Une démonstration de bout en bout relie ensuite ces éléments, dans un environnement et un cadre autorisés. Aucun exercice isolé ne démontre toutes les capacités. Le programme planifie leur combinaison selon le risque et les contraintes de sécurité.
Le dossier de résultat contient la chronologie, les actions, les décisions, les contrôles et les écarts. Pour chaque écart, nommer un propriétaire, une date et une preuve de clôture. « Procédure à améliorer » est insuffisant. « Vérifier les accès de secours sur deux opérateurs habilités et documenter leur retrait après l'exercice » peut être observé et retesté.
Les fournisseurs : un contrat n'est pas une capacité démontrée
Le responsable achats rassemble les engagements et les droits pertinents. L'IT vérifie leur correspondance avec la dépendance réelle. Le métier décrit la conséquence d'une interruption. Le juridique examine les dispositions applicables au contrat et au rôle de l'entité. La direction de programme coordonne les écarts sans se substituer à ces avis.
Dans le scénario, le contrat promet une réponse en une heure, mais l'équipe utilise une adresse de support standard. L'exercice révèle que l'escalade urgente exige un numéro et une référence différents. L'action de clôture n'est pas de recopier le contrat : elle consiste à mettre à jour la procédure, tester l'escalade et vérifier que le fournisseur reconnaît la demande.
Examiner également les dépendances concentrées : deux fournisseurs peuvent reposer sur le même service d'identité ou la même région technique. Additionner deux contrats ne crée pas automatiquement une solution de secours indépendante. Le programme doit expliquer le scénario couvert et celui qui reste sans alternative.
Un dossier de preuve compact et maintenable
Pour un service, réunir une fiche de périmètre, une carte de dépendances, les objectifs locaux approuvés, les procédures nécessaires, les références contractuelles, les exercices et le registre des écarts. Chaque pièce possède une version et un propriétaire. Les liens doivent permettre de retrouver la preuve actuelle sans dupliquer tous les fichiers dans plusieurs répertoires.
La revue examine trois taux distincts : services critiques avec propriétaire et dépendances validées, scénarios prévus effectivement exercés, écarts importants clos avec retest. Dans un portefeuille illustratif de dix services, huit cartes validées, six exercices réalisés et quatre retests ne doivent pas être résumés en « 80 % prêt ». Les dénominateurs et la criticité des deux services manquants comptent davantage qu'un score global.
Un changement de fournisseur, d'architecture ou de processus métier déclenche la mise à jour des preuves concernées. Un dossier complet en janvier peut devenir obsolète en juin. La responsabilité de maintenance doit appartenir au service après la clôture du programme, avec accès aux informations et calendrier de revue approprié.
La décision que le sponsor doit réellement prendre
Dans notre scénario, la revue conclut : « Objectif local de reprise non démontré. Maintenir le plan de secours existant et corriger accès et rapprochement. Anne valide le parcours métier ; exploitation responsable du test technique ; fournisseur sollicité sur l'escalade. Retest avant autorisation d'une dépendance supplémentaire. » Cette formulation porte un choix et des responsabilités, pas simplement une couleur rouge.
Le sponsor peut accepter temporairement un risque dans les limites de son mandat et du cadre applicable. Il doit connaître sa conséquence, les mesures compensatoires et la date de réexamen. Le mot « conformité » ne doit pas remplacer cette description. Une décision interne n'efface pas une obligation juridique ni les responsabilités des organes compétents.
Adapter la preuve à la fonction financière
Pour un paiement, la reprise inclut intégrité, doublons et état des opérations, pas seulement accès à l'application. Pour une assurance, le service de gestion des sinistres nécessite les données de dossier et les habilitations adaptées ; un mode manuel doit conserver les contrôles et la traçabilité. Pour un prestataire technologique, distinguer ses engagements envers le client et les exigences qui lui sont effectivement applicables selon son rôle et son éventuelle désignation.
DORA ne doit pas être présenté comme un règlement imposant exactement le même dispositif à toutes les entreprises industrielles. Ces organisations peuvent s'inspirer de la démarche de service et de test, mais leur cadre réglementaire doit être qualifié séparément.
Sources, méthode et limites
Sources primaires consultées le 4 octobre 2026 : EIOPA, présentation de DORA ; EBA, résilience opérationnelle numérique ; ACPR, cadre DORA. Le règlement cité par ces autorités constitue la référence juridique ; ce dossier est une analyse de préparation opérationnelle.
Les objectifs, volumes et délais du scénario sont illustratifs et ne constituent pas des minima réglementaires. La méthode suit un service jusqu'à son résultat métier, relie les dépendances aux responsables et examine les écarts par test. Les obligations exactes, tests exigés et responsabilités contractuelles nécessitent une qualification compétente de l'entité et du service. Aucun avis juridique certifié ou certificat de conformité n'est fourni.