RTO : Recovery Time Objective
Infrastructure
RTO : Recovery Time Objective. « Objectif de délai de reprise », par analogie avec le temps qu'un restaurant s'accorde pour rouvrir après une coupure de courant avant que les clients n'aillent dîner ailleurs.
Définition : Durée maximale d'interruption jugée acceptable pour un service, mesurée entre l'incident et le retour à un fonctionnement utile. C'est un objectif fixé par le métier, pas une constatation technique.
Face au RPO : Le RTO mesure combien de temps le service peut rester arrêté ; le RPO mesure combien de données on accepte de perdre. Les deux dimensionnent ensemble le PRA : fréquence des sauvegardes, redondance, sites de secours.
Le vérifier : Un RTO n'a de valeur que s'il a été mesuré lors d'un test de restauration réel. Il existe deux sortes de délais de reprise : celui qui figure dans le document, et celui qu'on découvre le jour où il faut restaurer ; ils se rencontrent rarement.
Ce qui arrive si on s'en passe
Sans délai de reprise fixé par le métier, personne ne sait combien de temps un service peut rester arrêté, et redondance, sauvegardes et site de secours se dimensionnent au hasard ou au budget restant. Le jour de l'incident, chacun découvre en même temps que les autres qu'il n'existe aucune priorité entre les applications à relancer. Un RTO fixé mais jamais mesuré par un test de restauration réel ne vaut guère mieux : il décrit une intention. Les clients, eux, mesurent le délai réel sans concertation préalable et avec une précision remarquable, en allant dîner ailleurs.
Explication de la marmotte
Quand une panne arrive, la question n'est pas seulement de réparer, mais de savoir combien de temps on peut se permettre d'attendre. Une boulangerie peut peut-être rester fermée une matinée, pas une semaine. On fixe donc à l'avance un délai maximal pour que tout remarche. Ce chiffre sert ensuite à tout préparer : plus il est court, plus il faut prévoir de matériel de secours et de méthodes rapides pour tout remettre en route.
Où ce terme est utilisé
- Tester une restauration après sinistre simulé (8 occurrences)
- Continuité, sauvegardes, PRA/PCA et haute disponibilité (6 occurrences)
- Test de restauration des sauvegardes (5 occurrences)
- Configurer une sauvegarde restic résistante au ransomware (3 occurrences)
- DORA et résilience opérationnelle numérique financière (3 occurrences)
- Comment capitaliser et payer la dette de sécurité (2 occurrences)
- Comment écrire un rapport de vulnérabilité corrigé (2 occurrences)
- Gérer un désaccord technique sans bloquer un projet (2 occurrences)
- Gérer une crise cloud multi-tenant (2 occurrences)
- Justifier un budget sécurité à la direction financière (2 occurrences)