L'Expert de vos Sauvegardes et de la Protection de vos Données !La Solution adaptée à vos besoins
PRA et PCA
Qu'est-ce qu'un RTO ?
Le RTO (Recovery Time Objective, objectif de délai de reprise) est la durée maximale pendant laquelle un service peut rester indisponible. Il se mesure de l’incident, ou de la décision de basculer, jusqu’au moment où un utilisateur fait à nouveau un geste métier normal. Pas jusqu’à l’allumage d’une machine dont l’application n’est pas encore vérifiée.
L’essentiel
- Le RTO additionne six délais : détection, décision, recherche des accès, temps technique, vérification métier, retour des utilisateurs.
- Le NIST le distingue de la durée maximale d’interruption tolérable (MTD) : le RTO doit normalement être plus court que la MTD.
- Un RTO s’écrit par service : le standard téléphonique et les archives n’ont pas le même.
- Seul un essai chronométré dit si le RTO écrit est tenu.
- Les horaires de l’assistance et l’absence d’astreinte font partie du RTO réel.
Définition officielle
Le NIST définit le RTO comme la durée maximale pendant laquelle une ressource du système d’information peut rester indisponible avant que l’impact devienne inacceptable pour les activités qu’elle supporte. Il le distingue de la durée maximale d’interruption tolérable (MTD), qui est la durée d’arrêt totale que la direction accepte pour une activité. Le RTO doit garantir que la MTD n’est pas dépassée : il est donc normalement plus court.
L’ANSSI emploie le terme de durée maximale d’interruption admissible (DMIA). Elle demande qu’une stratégie de sauvegarde en tienne compte pour chaque valeur métier, et qu’un ordre de restauration soit défini à l’avance, en fonction des dépendances (DNS, annuaire…) et de la criticité des applications.
De quoi le RTO est la somme
Pour une restauration classique :
- le temps pour s’apercevoir de la panne ;
- le temps pour décider et joindre la personne qui sait faire ;
- le temps pour trouver clés, mots de passe et procédure ;
- le temps technique de copie ou de démarrage ;
- le temps de vérification par quelqu’un du métier ;
- le temps pour que les postes ou les clients distants retrouvent le service (DNS, VPN, IP).
Un RTO « de deux heures » annoncé par un logiciel ne compte souvent que l’étape 4, dans des conditions de laboratoire. Le RTO réel additionne les six. La nuit et le week-end, l’étape 2 peut à elle seule dépasser deux heures si personne n’est d’astreinte.
Pour un PCA, les étapes 4 et 6 sont préparées à l’avance. Il reste la détection et le risque d’une bascule que personne n’ose valider.
RTO et RPO ne se négocient pas l’un contre l’autre
On peut avoir un RPO court (copies fréquentes) et un RTO long (restauration lente d’un gros volume). On peut avoir un RTO court (secours déjà allumé) et un RPO médiocre si le secours a deux heures de retard. Les deux chiffres s’écrivent tous les deux.
RPOPerte de données maximale acceptable
RTOTemps d’arrêt maximal acceptable
se mesure en arrière
se mesure en avant
Données avant l’incident
!Incident
Redémarrage des services
| RPO | RTO | |
|---|---|---|
| Question posée | Combien de travail peut-on perdre ? | Combien de temps peut-on rester arrêté ? |
| Se mesure | En arrière, depuis l’incident | En avant, depuis l’incident |
| Se règle par | La fréquence des copies | La préparation du secours |
| Se vérifie par | La date de la dernière copie réussie | Un essai chronométré |
Un RTO par service
Le standard téléphonique et la GED des archives n’ont pas le même RTO. Écrire « RTO 4 heures » pour toute l’entreprise force soit à surpayer la GED, soit à mentir sur le standard. Une ligne par service suffit.
Comment savoir si le RTO est tenu
Uniquement par un chronomètre lors d’un essai. Si l’essai a duré six heures et que le RTO écrit est de deux heures, c’est le RTO écrit qui est faux, jusqu’à ce que l’architecture change. On ne « vise » pas un RTO que la dernière mesure a démenti. L’ANSSI insiste sur ce point : une procédure de restauration doit être rédigée et régulièrement mise en œuvre. Le rythme des essais est discuté dans À quelle fréquence tester son PRA ?.
Chez WeDoBack
Aucun RTO chiffré unique n’est publié sur le site, et il serait trompeur d’en inventer un : il dépend du volume, du lien, de la taille d’instance et de la disponibilité des personnes côté client. Ce que l’architecture change, c’est la nature du délai. En restauration simple, il faut ramener les données et éventuellement réinstaller. Avec le PRA, les serveurs redémarrent sur des instances de secours à partir de la version choisie : le délai technique est celui de ce redémarrage, pas celui d’un achat de serveur. Un test de démarrage a lieu chaque mois, sans toucher à la production. Avec le PCA, des instances cloud sont allumées en permanence et relayées par un agent sur le réseau du client, sans changement d’adresse IP : le RTO résiduel est surtout celui de la détection et de la décision. La réplication ou la synchronisation des données entre l’instance PCA et le serveur d’origine n’est pas native : elle passe par un processus spécifique, adapté au besoin, que WeDoBack peut mettre en place sur devis. Dans les trois cas, la vérification métier reste dans le chronomètre. L’assistance humaine est joignable de 9 h à 13 h et de 14 h à 17 h 30 (heure de Paris).
Questions fréquentes
Quelle différence entre RTO et MTD ?
La MTD (Maximum Tolerable Downtime) est la durée d’arrêt totale que la direction accepte pour une activité, tous impacts compris. Le RTO est le délai de remise en service d’une ressource informatique. Le NIST précise que le RTO doit normalement être plus court que la MTD, pour laisser la marge des autres étapes de reprise.
Un logiciel annonce un RTO de quelques minutes. Est-ce réaliste ?
Ce chiffre ne compte généralement que le temps technique de démarrage, en laboratoire. Il n’inclut ni la détection, ni le temps de joindre la personne habilitée, ni la vérification par un utilisateur. Votre RTO réel est celui que vous avez mesuré lors de votre dernier essai, de la déclaration d’incident au premier geste métier réussi.
Le RTO est-il une obligation légale ?
Aucun texte n’impose une durée chiffrée à une PME. En revanche, le RGPD (article 32) demande des moyens permettant de rétablir la disponibilité des données personnelles et l’accès à celles-ci « dans des délais appropriés » en cas d’incident. Le RTO est la façon concrète de définir ce délai approprié.
Pour aller plus loin
Sources
Documents consultés en octobre 2026.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Sauvegarde des systèmes d’information – Les fondamentaux (ANSSI-BP-100, v1.1, 27 novembre 2025) — ANSSI
- CHAPITRE IV – Responsable du traitement et sous-traitant (RGPD, article 32) — CNIL
- Offre PRA : reprise d’activité après sinistre — WeDoBack
Un projet de sauvegarde, de PRA ou de PCA ?
Plus de 20 ans d’expérience dans la protection des données des entreprises.
Demander un devis09 72 50 78 28Protégez vos données avec WeDoBack
Sauvegarde chiffrée hors site, stockage immuable, PRA et PCA : décrivez-nous vos serveurs, nous vous proposons la bonne combinaison.