RPO/RTO expliqué sans jargon

En bref : RPO = combien de données vous acceptez de perdre. RTO = combien de temps vous acceptez d’être à l’arrêt. Ces deux chiffres pilotent toute votre stratégie de sauvegarde et de reprise.


Le problème

Quand on parle de sauvegardes et de plan de reprise, deux questions reviennent toujours :

  • “On peut perdre combien de données ?”
  • “On sera arrêté combien de temps ?”

Sans réponse claire, impossible de dimensionner les sauvegardes, de choisir les outils, ou de savoir si le plan tient la route.


Pourquoi c’est important

  • Un RPO de 24 h signifie que si le sinistre arrive à 17 h, vous perdez tout ce qui a été fait depuis la sauvegarde de la nuit précédente. Pour un service de facturation, ça peut représenter des milliers d’euros.
  • Un RTO de 4 h signifie que vos clients, vos employés et vos partenaires n’ont plus accès au service pendant 4 heures. Au-delà, les conséquences commerciales et opérationnelles s’accumulent.

La solution en pratique

RPO — Recovery Point Objective

“Combien de données puis-je me permettre de perdre ?”

RPOSignificationSauvegarde nécessaire
24 hJe perds au maximum 1 journéeSauvegarde quotidienne (la nuit)
4 hJe perds au maximum 4 heuresSauvegarde toutes les 4 heures
1 hJe perds au maximum 1 heureSauvegarde horaire ou réplication
0Je ne perds rienRéplication synchrone (coûteux)

Analogie : le RPO, c’est la fréquence à laquelle vous faites “Ctrl+S”. Plus vous sauvegardez souvent, moins vous perdez en cas de crash.

RTO — Recovery Time Objective

“Combien de temps puis-je rester à l’arrêt ?”

RTOSignificationMécanisme nécessaire
8 hReprise dans la journéeRestauration classique (backup)
1 hReprise en 1 heureSnapshots + procédure rodée
15 minReprise quasi immédiateHaute disponibilité / failover
0Aucune interruptionRedondance active-active (coûteux)

Analogie : le RTO, c’est le temps que met le plombier à arriver quand il y a une fuite. Vous pouvez payer un plombier “de garde” (rapide mais cher) ou appeler le lendemain (lent mais économique).

Comment les définir ?

Pour chaque service critique, posez deux questions :

  1. Si je perds les données des X dernières heures, quel est l’impact métier ? → C’est votre RPO.
  2. Si le service est indisponible pendant X heures, quel est l’impact métier ? → C’est votre RTO.

Mini-checklist

  • J’ai listé mes services critiques (email, fichiers, application métier, etc.).
  • Pour chaque service, j’ai défini un RPO réaliste.
  • Pour chaque service, j’ai défini un RTO réaliste.
  • Ma stratégie de sauvegarde est dimensionnée en fonction du RPO (fréquence suffisante).
  • J’ai testé une restauration pour mesurer le RTO réel (pas théorique).
  • Mon RPO et mon RTO sont documentés et connus des décideurs.

Pour aller plus loin

  • Offre associée : Bundle A — Socle SI sécurisé — Définition RPO/RTO incluse dans le cadrage.
  • Preuve associée : PCA minimal — RPO/RTO définis et testés sur lab.
  • Méthode : PCA — Stratégie complète, scénarios, journaux de test.

Références