Aller au contenu
Retour au glossaire
Continuité d'activité

Qu'est-ce que RTO (Recovery Time Objective) ?

Le RTO est la durée maximale acceptable d'interruption d'un service après un sinistre. Indicateur central de tout plan de reprise d'activité.

À quoi sert le RTO

Le Recovery Time Objective (RTO) est l'engagement de durée maximale entre un incident majeur (perte de datacenter, attaque ransomware, corruption de base) et la restauration complète du service. C'est une métrique business, pas technique : elle reflète le coût d'arrêt acceptable pour l'organisation, pas la performance des outils.

Concrètement, un RTO de 4 heures signifie : si un sinistre survient à 9h00, le service doit être à nouveau opérationnel pour les utilisateurs à 13h00 au plus tard. Le RTO inclut tout : détection de l'incident, décision d'activation du plan de reprise, restauration des données, redémarrage des applications, validation fonctionnelle, communication.

Comment fixer un RTO réaliste

Le RTO se décide en concertation entre la direction métier et l'équipe IT. La méthode usuelle suit trois étapes :

  1. Analyse d'impact business (BIA). Quantifier le coût horaire d'arrêt pour chaque application critique. Une plateforme e-commerce qui fait 50 000 CHF/heure ne peut pas tolérer un RTO de 24h ; un outil interne RH peut.

  2. Évaluation technique. Mesurer le RTO atteignable avec l'architecture actuelle. Cela implique des tests de restauration réels (pas juste théoriques), idéalement trimestriels.

  3. Investissement. Réduire le RTO coûte de l'argent : réplication temps réel, sites secondaires actifs, automatisation. Diviser un RTO par 2 multiplie typiquement les coûts d'infrastructure par 1.5 à 3.

Les niveaux de RTO en pratique

Catégorisation typique observée sur les missions Hidora :

  • RTO < 15 minutes : architecture active-active multi-région, bascule automatique. Coût élevé, justifié pour banques, e-commerce critique, télémédecine.
  • RTO 1 à 4 heures : sites secondaires chauds, restauration semi-automatisée. Standard pour la plupart des PME suisses avec activité significative en ligne.
  • RTO 4 à 24 heures : sauvegardes off-site, restauration manuelle planifiée. Adapté aux applications non temps-réel (BI, archivage, batch).
  • RTO > 24 heures : sauvegardes hors site, processus de restauration ad hoc. Acceptable pour les outils internes non critiques.

RTO et architectures cloud-native

Sur Kubernetes, le RTO se réduit drastiquement si l'application est conçue stateless. Les configurations sont en GitOps, les images dans un registry répliqué, les bases de données en réplication synchrone : restaurer un environnement complet sur un cluster de secours prend 10 à 30 minutes par déploiement automatisé.

À l'inverse, les workloads stateful avec dépendances complexes (clusters Postgres avec replications custom, fichiers partagés NFS, files d'attente Kafka avec retention longue) conservent un RTO élevé. Le travail d'architecture consiste à isoler progressivement ces composants et leur appliquer des stratégies de réplication adaptées.

RTO vs RPO

Le RTO mesure la durée d'interruption ; le RPO (Recovery Point Objective) mesure la perte de données acceptable. Une PME peut tolérer 4 heures d'indisponibilité (RTO) mais pas plus de 5 minutes de données perdues (RPO). Les deux indicateurs sont indépendants et se travaillent séparément.

Services Hidora associés

  • SLA Expert : engagements RTO contractuels sur incidents P1 avec déclenchement automatique du plan de reprise.
  • Consulting : audit BIA, conception d'un plan de reprise d'activité, tests de restauration trimestriels.
  • Managed Services : exécution opérationnelle du plan de reprise avec rapports mensuels de tests.
  • RPO, DRP, SLA : indicateurs et processus associés.