Retour au glossaire
R
Définition

RTO Définition IT

Recovery Time Objective : durée maximale d'interruption tolérée pour un service IT avant que son indisponibilité ne devienne critique pour l'activité. C'est l'objectif de délai de remise en service après un sinistre.

Le RTO (Recovery Time Objective, ou objectif de délai de rétablissement) est la durée maximale acceptable entre la survenue d'une interruption et le retour à un service opérationnel. Il répond à une question simple : « combien de temps pouvons-nous rester sans ce service avant que l'impact ne devienne insupportable ? »

Le RTO est, avec le RPO, l'un des deux indicateurs qui structurent tout Plan de Reprise d'Activité (PRA) et qui sont contractualisés dans les SLA.

Comment fixer un RTO

Le RTO se détermine application par application, lors de l'analyse d'impact métier (BIA) du PCA. Plus un service est critique, plus son RTO est court :

  • Quelques minutes: : site e-commerce, système de paiement, messagerie temps réel.
  • Quelques heures: : ERP, CRM, applications métier de back-office.
  • Plusieurs jours: : outils internes secondaires, reporting non urgent.

RTO et coût

Le RTO est le principal levier de coût d'un PRA : viser un RTO de 5 minutes (bascule automatique, infrastructure active-active) coûte plusieurs fois plus cher qu'un RTO de plusieurs heures (restauration depuis sauvegarde). L'enjeu est d'aligner le RTO sur la criticité réelle, sans surinvestir sur des services non essentiels.

RTO ≠ RPO

Le RTO mesure un temps de rétablissement ; le RPO mesure une perte de données acceptable. Un service peut tolérer une longue indisponibilité (RTO élevé) tout en n'acceptant aucune perte de données (RPO proche de zéro), ou l'inverse.

Questions fréquentes

Quelle est la différence entre RTO et RPO ?

+

Le RTO (Recovery Time Objective) est le délai maximal pour rétablir un service après une interruption. Le RPO (Recovery Point Objective) est la quantité maximale de données que l'on accepte de perdre, exprimée en temps. Le RTO se mesure en durée d'indisponibilité, le RPO en volume de données perdues depuis la dernière sauvegarde exploitable.

Comment définir le bon RTO ?

+

Le RTO se fixe lors de l'analyse d'impact métier (BIA), application par application, en fonction de la criticité du service. Un service générant du chiffre d'affaires en temps réel exige un RTO de quelques minutes, tandis qu'un outil interne secondaire peut tolérer plusieurs jours. Le RTO conditionne directement le coût de l'architecture de reprise.

Besoin d'aide pour cartographier votre SI ?

Kabeen vous aide à inventorier, analyser et optimiser votre portefeuille d'applications.

Essayer gratuitement