RTO et RPO sous DORA : le seul chiffre qui compte sort de votre dernier test de restauration

Le RTO d’une société de gestion est la durée chronométrée de sa dernière restauration réelle, du constat de la panne au premier gérant qui retravaille sur des données vérifiées. Le chiffre écrit dans le plan de continuité reste un objectif tant qu’aucun test ne l’a confirmé. Beaucoup de PCA affichent « RTO 4 h, RPO 24 h » sans qu’un seul chronomètre ait jamais tourné : voici pourquoi ce chiffre tombe au premier test, et la version qui tient devant un contrôleur.

Que signifient RTO et RPO pour une société de gestion ?

Le RTO (recovery time objective) est la durée maximale d’interruption qu’un service peut subir avant que l’activité n’en souffre de façon inacceptable. Le RPO (recovery point objective) est l’ancienneté maximale des données que l’on accepte de perdre : avec un RPO de quatre heures, il peut manquer au plus les quatre dernières heures de saisie après la restauration.

Ces deux chiffres se fixent service par service. La valorisation des fonds, le passage d’ordres, les échanges avec le dépositaire et le partage de fichiers n’ont ni la même urgence ni la même tolérance à la perte. L’article 12 du règlement DORA demande de déterminer ces objectifs pour chaque fonction, en tenant compte de son caractère critique ou important, et l’article 11 impose de tester les plans de continuité au moins une fois par an. Le texte s’applique aux sociétés de gestion depuis le vendredi 17 janvier 2025, sous le contrôle de l’AMF.

Le PCA qui promettait quatre heures

Prenons un plan de continuité tel qu’on en lit souvent. Il annonce un RTO de quatre heures pour tout le système d’information, repris de la fiche commerciale de la sauvegarde, et un RPO de vingt-quatre heures parce que la sauvegarde tourne chaque nuit. Le test annuel consiste à restaurer un dossier supprimé exprès sur le serveur de fichiers. Il réussit en vingt minutes.

Case cochée.

Le jour d’un rançongiciel, ce test ne sert à rien. Il faut reconstruire un environnement sain et isolé, rétablir les comptes et la double authentification, retrouver la licence du logiciel de valorisation attachée à une machine qui n’existe plus, puis réinstaller les postes. Les quatre heures mesuraient la copie des données ; la reprise de l’activité se compte en jours.

Pourquoi le chiffre du PCA ne résiste-t-il pas au premier test ?

Le chronomètre s’arrête au mauvais endroit. On le coupe quand la dernière donnée est copiée, alors que le service n’est rendu qu’au moment où un utilisateur travaille de nouveau, avec ses droits, sur des chiffres rapprochés. Et le périmètre testé est un fichier, quand le PCA promet un service qui dépend de l’annuaire, du réseau, des licences et d’un éditeur externe.

Un dirigeant objectera : « on sauvegarde toutes les nuits, notre RPO est donc de vingt-quatre heures ». Pas tout à fait. Le RPO se mesure sur la dernière sauvegarde restaurable, pas sur la planification : trois nuits d’échec silencieux et le RPO réel passe à soixante-douze heures, sans que personne l’ait décidé.

La version qui tient : un procès-verbal par service

Le test qui résiste à un contrôle se prépare service par service, sur un scénario daté, dans un environnement séparé de la production, comme l’article 12 l’exige pour les restaurations faites sur ses propres systèmes. Le procès-verbal tient sur une page. Il nomme le service restauré et le scénario joué, porte l’heure du constat et celle à laquelle le premier utilisateur a rouvert son application sur des données vérifiées, indique l’âge des données récupérées, compare ces deux mesures aux objectifs du PCA et se termine par l’action corrective décidée en cas d’écart, signée par le responsable du service. Nous le rangeons sous un nom qui se retrouve sans chercher, du type PV-restauration-valorisation-2026-T4.pdf, à côté du plan qu’il vérifie.

Le RTO inscrit au PCA devient alors la dernière mesure, arrondie au-dessus. Quand le test donne neuf heures pour un objectif de quatre, on corrige l’architecture ou l’objectif. Pour estimer ce que coûte chaque heure au-delà de l’objectif, notre calculateur du coût d’un arrêt informatique donne un ordre de grandeur à présenter au comité de direction. Nous appliquons la même logique de mesure publiée à nos SLA d’infogérance sous DORA.

Ce que DORA ne tranche pas

Le règlement ne fixe aucune valeur de RTO ni de RPO, et ne définit pas ce qu’est un test probant. Rien n’indique si la restauration d’une seule fonction critique par an suffit, ni si un exercice sur table compte. Notre lecture : chaque fonction critique ou importante restaurée réellement au moins une fois par an, et la mention « non testé » écrite en clair dans le PCA plutôt qu’un chiffre emprunté. Certains dirigeants trouvent cette mention gênante devant leur conseil ; nous la jugeons plus défendable qu’un objectif que personne n’a vérifié.

Le programme de travail 2027 des autorités européennes de supervision, publié le 13 octobre, prévoit de soutenir une éventuelle révision de DORA (ESMA). Mieux vaut l’aborder avec deux procès-verbaux archivés.

Gregory vous reçoit pendant trente minutes pour relire les RTO de votre plan de continuité et choisir le premier service à chronométrer : réserver ce rendez-vous. Échange sans engagement, aucune relance ensuite.

Gregory Moulis, directeur général chez ITAIA

Sources

• EUR-Lex, Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier (DORA) : article 11 (test annuel des plans de continuité) et article 12 (objectifs de délai et de point de reprise par fonction, restauration sur des systèmes séparés).
• AMF, DORA : application du règlement aux acteurs supervisés par l’AMF.
• ESMA, European Supervisory Authorities set priorities for 2027 : programme de travail 2027 des autorités européennes de supervision, publié le 13 octobre 2026.