.w-dropdown-list { transition-delay: 0.15s; }

RTO et RPO DORA :
Exigences pour la Finance

Dernière mise à jour : Juillet 2026
Temps de lecture : 30 minutes
Conforme aux attentes DORA 2026

RTO et RPO sous DORA : ce que les entités financières doivent réellement documenter

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.

À retenir :

  • DORA (Article 11) exige des objectifs RTO/RPO documentés et fondés sur la criticité, pas des chiffres réglementaires fixes.
  • L'ACPR vérifie trois choses : les objectifs sont-ils documentés, sont-ils réalistes au regard de l'architecture réelle, ont-ils été testés.
  • Les repères sectoriels s'appuient sur les lignes directrices EBA/GL/2019/04, pas sur un seuil légal DORA.
  • Un RTO documenté mais jamais testé ne constitue pas une preuve de conformité recevable lors d'un contrôle.
  • Une architecture air-gappée bien dimensionnée atteint des RTO mesurés inférieurs à 10 minutes sur les environnements virtualisés critiques.

Pourquoi DORA ne fixe aucun chiffre de RTO ou RPO

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.

Comment calibrer vos objectifs par une analyse d'impact sur l'activité

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 :

  1. Lister les systèmes qui traitent des fonctions critiques : paiements, tenue de compte, passation d'ordres, données clients réglementées.
  2. Estimer l'impact d'une heure d'indisponibilité pour chacun : perte de revenus directe, pénalités contractuelles, obligations de notification déclenchées, risque réputationnel.
  3. En déduire un RTO cible : le délai maximal avant que cet impact devienne inacceptable pour la direction et les régulateurs.
  4. En déduire un RPO cible : la perte de données maximale tolérable, généralement liée à la fréquence des transactions du système concerné.

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.

Repères sectoriels observés pour les systèmes financiers

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.

Type de système
RTO courant observé
RPO courant observé
Systèmes de paiement critiques
Moins de 4 heures
Moins de 1 heure
Core banking non critique
Moins de 24 heures
Moins de 4 heures
Données clients et comptes
Moins de 8 heures
Moins de 2 heures
Infrastructure secondaire
Moins de 48 heures
Moins de 24 heures

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.

L'erreur la plus fréquente : un objectif jamais testé

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é.

Ce que l'ACPR attend comme preuve

Trois éléments constituent une preuve recevable de conformité sur les RTO/RPO :

  • Un document de politique de continuité qui liste les systèmes critiques avec un RTO et un RPO propre à chacun, pas un objectif générique pour l'ensemble du système d'information.
  • Un rapport de test de restauration daté, avec le RTO et le RPO effectivement mesurés lors du test, pas une estimation théorique.
  • Une traçabilité de la fréquence des tests, avec un minimum annuel pour les systèmes critiques, deux fois par an recommandé pour les établissements de paiement.

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.

Questions fréquentes

Conclusion

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.

Revoir votre architecture
de sauvegarde avec VYTALX
Un entretien dédié pour passer en revue vos workloads, vos contraintes 

(sites, bande passante, RPO/RTO) et confronter votre dispositif actuel 

aux capacités de notre plateforme de Backup managé.
Planifier une revue technique Backup