.w-dropdown-list { transition-delay: 1.00s; }
DORA n'impose aucun chiffre précis de RTO (Recovery Time Objective) ou de RPO (Recovery Point Objective). L'Article 11 du règlement exige des objectifs de récupération documentés, fondés sur la criticité de chaque système, et démontrés par des tests réels. C'est l'absence de chiffre imposé, justement,
qui piège le plus d'entités financières lors d'un contrôle ACPR.
L'Article 11 impose aux entités financières de disposer d'une politique de continuité des activités incluant des "objectifs de temps de récupération et de point de récupération documentés et fondés sur la criticité des systèmes concernés". Le texte s'arrête là sur le plan chiffré.
Ce choix n'est pas un oubli. Un hôpital, une société de gestion et une banque de paiement n'ont pas la même tolérance à l'indisponibilité. Un chiffre unique imposé par le règlement serait soit trop laxiste pour les systèmes de paiement critiques, soit disproportionné pour une infrastructure secondaire. DORA délègue donc la définition du chiffre à l'entité, et concentre son exigence sur la méthode : documentation, justification par la criticité, et preuve par le test.
Lors d'un contrôle, l'ACPR vérifie trois éléments dans cet ordre : l'existence d'objectifs documentés par système, leur cohérence avec l'architecture réellement déployée, et la preuve qu'ils ont été atteints lors d'un test récent. Un RTO ambitieux affiché dans une politique, sans test à l'appui, ne passe pas ce filtre.
La méthode attendue commence par une analyse d'impact sur l'activité, ou BIA (Business Impact Analysis).
Elle consiste à classer chaque système selon la conséquence réelle de son indisponibilité, pas selon une intuition technique.
Quatre étapes suffisent pour une première itération exploitable :
Un système de paiement qui traite des milliers d'opérations par heure tolère un RPO de quelques minutes. Un serveur de fichiers bureautique interne tolère un RPO d'une journée sans conséquence réglementaire ou commerciale majeure.
Sans seuil imposé par DORA, les entités s'appuient en pratique sur des repères alignés avec les lignes directrices EBA/GL/2019/04 sur la gestion des risques liés aux TIC. Ces repères servent de point de comparaison pour challenger vos propres objectifs.
Un objectif RTO nettement supérieur à ces repères, sans justification documentée liée à la criticité réelle du système, attire l'attention d'un auditeur ACPR. À l'inverse, un objectif plus ambitieux que ces repères n'est un problème que s'il n'est pas tenu en conditions réelles.
Sur le terrain, la faille la plus courante est l'absence de vérification. Une politique de sauvegarde peut afficher un RTO de 4 heures pour les systèmes de paiement depuis des plusieurs années, sans qu'aucun test de restauration n'ait jamais mesuré ce délai en conditions réelles.
Exemple : Camille, DAF d'un établissement de paiement de 55 personnes, a découvert ce problème lors d'un audit de préparation DORA fin 2025. Le document de politique de continuité affichait un RTO de 4 heures pour le système de traitement des paiements depuis 2022. Le dernier test de restauration réel remontait à plus de deux ans, et son résultat mesuré était de 11 heures, largement supérieur à l'objectif documenté. Le RTO écrit sur le papier n'avait jamais correspondu à la réalité opérationnelle.
Ce type d'écart, découvert par l'entité elle-même avant un contrôle, reste gérable. Découvert par l'ACPR pendant un contrôle, il devient un manquement documenté.
Trois éléments constituent une preuve recevable de conformité sur les RTO/RPO :
Une architecture de sauvegarde air-gappée bien dimensionnée permet d'atteindre des RTO mesurés inférieurs à 10 minutes pour un environnement virtualisé Hyper-V ou VMware, et environ 6 minutes pour un serveur Windows. Documentés dans un rapport de test daté, ces chiffres deviennent une preuve de conformité directement exploitable lors d'un contrôle ACPR, bien en dessous des repères sectoriels courants.
Pour la méthodologie complète de test de restauration attendue par l'ACPR, consultez notre Guide DORA et sauvegarde, qui détaille aussi les exigences d'isolation physique de l'Article 12 liées à ces objectifs de récupération.
Vous voulez comparer vos RTO/RPO actuels aux repères sectoriels avant un contrôle ? Planifiez un point technique de 30 minutes) pour évaluer l'écart entre vos objectifs documentés et votre architecture réelle.
Non. L'Article 11 exige des objectifs documentés et fondés sur la criticité des systèmes, sans fixer de chiffre réglementaire. Chaque entité définit ses propres objectifs, que l'ACPR évalue ensuite sur leur réalisme et leur vérification par des tests.
Les repères sectoriels observés se situent sous 4 heures pour le RTO et sous 1 heure pour le RPO, alignés avec les lignes directrices EBA sur la gestion des risques TIC. Ce ne sont pas des seuils légaux, mais des points de comparaison pour challenger vos propres objectifs.
Par un rapport de test de restauration daté, réalisé en conditions réelles sur un système isolé de la production, avec le délai effectivement mesuré.
Un objectif jamais testé n'est pas une preuve recevable lors d'un contrôle ACPR.
Le RTO (Recovery Time Objective) mesure le délai maximal avant rétablissement du système après un incident. Le RPO (Recovery Point Objective) mesure la perte de données maximale tolérable, c'est-à-dire l'ancienneté de la dernière sauvegarde exploitable. DORA exige que les deux soient documentés et testés pour chaque système critique.
Non. DORA attend une gradation fondée sur la criticité réelle de chaque système, établie via une analyse d'impact sur l'activité.
Un système de paiement critique et un serveur bureautique interne n'ont pas la même tolérance à l'indisponibilité, et ne doivent pas partager le même objectif.
Les RTO et RPO sous DORA ne se résument pas à un chiffre à trouver dans le texte réglementaire, ils se construisent à partir d'une analyse d'impact sur l'activité, se documentent par système, et se prouvent par des tests réguliers. L'écart le plus fréquent entre les entités financières françaises n'est pas un mauvais choix d'objectif, c'est l'absence de vérification réelle de cet objectif.
Une architecture de sauvegarde air-gappée avec des RTO mesurés sous 10 minutes constitue une marge de sécurité confortable face aux repères sectoriels, et une preuve directement exploitable lors d'un contrôle ACPR.