Qu'est-ce que le RTO ?
Le RTO, ou Recovery Time Objective, désigne le délai maximal fixé pour rétablir une application ou un service informatique après une interruption. Il permet de déterminer la rapidité avec laquelle l'activité doit reprendre après un incident.
En français, RTO signifie objectif de temps de reprise. Il s'exprime en minutes, en heures ou en jours, et il est fixé avant tout incident : panne, sinistre ou cyberattaque.
Le RTO peut varier d'une application à l'autre selon l'importance de chacune pour l'activité. Un logiciel de facturation et un outil d'archivage interne n'ont, en général, pas le même délai de reprise.
C'est un objectif, pas une mesure : il dit ce que l'entreprise vise. La durée d'interruption constatée après un incident permet ensuite de vérifier s'il a été tenu.
Comment le RTO s'articule-t-il avec le PRA et le PCA ?
Le RTO ne s'utilise pas seul : il sert de repère aux deux plans qui préparent l'entreprise aux incidents.
Le PRA, plan de reprise d'activité, décrit comment remettre les systèmes en route. Il s'appuie sur un RTO par application, qui guide le choix des moyens : une sauvegarde à restaurer peut suffire pour un délai de plusieurs heures, alors qu'un délai de quelques minutes demande souvent une haute disponibilité, avec un système de secours prêt à prendre le relais.
Le PCA, plan de continuité d'activité, vise à maintenir l'essentiel de l'activité pendant la panne, souvent en mode dégradé, c'est-à-dire avec des moyens réduits.
Le RTO doit enfin rester inférieur à la durée maximale d'interruption admissible (DMIA), au-delà de laquelle l'arrêt devient insupportable pour l'activité.
A quoi sert le RTO ?
Le RTO transforme une question floue, « combien de temps pouvons-nous nous passer de cet outil ? », en un objectif partagé entre la direction, les métiers et l'informatique. Il sert notamment à :
- Classer les applications selon l'effet de leur arrêt sur l'activité ;
- Choisir pour chacune une solution de sauvegarde ou de secours proportionnée.
Comment définir son RTO ?
- Lister les applications et services dont dépend l'activité, avec leurs dépendances (réseau, serveurs, prestataires)
- Évaluer l'effet d'une interruption avec les métiers : à partir de quand l'arrêt bloque les ventes, retarde la paie, gêne les clients ou crée un risque réglementaire ? La réponse varie selon les heures et les périodes de l'année
- Fixer un RTO par application en fonction de cet effet : deux applications jugées critiques peuvent recevoir des délais différents
- Choisir les moyens qui permettent de tenir ce délai : sauvegarde, réplication (copie continue des données sur un autre site), système de secours
- Tester la reprise et ajuster l'objectif ou les moyens si le délai n'est pas tenu
Exemple concret et erreurs à éviter
Une entreprise de distribution facture ses commandes chaque matin. Avec les métiers, la direction estime qu'au-delà de 4 heures d'arrêt les expéditions de la journée sont compromises : le RTO du logiciel de facturation est fixé à 4 heures. L'outil d'archivage, consulté quelques fois par mois, reçoit un RTO de 48 heures.
Trois erreurs à éviter :
- Fixer un seul RTO pour tout le système d'information
- Choisir un objectif sans consulter les métiers
- Ne jamais tester la reprise
Différences entre RTO et RPO
Le RTO mesure le temps maximal prévu pour restaurer un service, tandis que le RPO mesure la quantité de données que l'entreprise accepte potentiellement de perdre, exprimée en durée.
