RTO et RPO expliqués simplement (et comment fixer les vôtres)
Le RTO (Recovery Time Objective) est la durée d'interruption maximale que vous acceptez pour un système : « combien de temps sans l'application ? ». Le RPO (Recovery Point Objective) est l'ancienneté maximale de la dernière sauvegarde utilisable : « combien de travail perdu ? ». Les deux se fixent avec les métiers, application par application — jamais globalement.
RTO et RPO : les définitions
Le RTO : combien de temps sans le système ?
Le RTO est la durée maximale entre l'incident et le retour à un fonctionnement acceptable. Un RTO de quatre heures signifie : quatre heures au plus après la panne, l'application doit de nouveau servir les utilisateurs. Le levier principal est l'architecture — serveur de secours, réplication, procédures de bascule automatisées — et il se vérifie en chronométrant une bascule réelle.
Le RPO : combien de données perdues ?
Le RPO se mesure aussi en temps, mais il regarde vers le passé : c'est l'écart maximal admissible entre le dernier point de restauration et l'instant de l'incident. Un RPO d'une heure signifie : au pire, on rejoue une heure de travail. Le levier principal est la fréquence des sauvegardes, jusqu'à la réplication continue pour un RPO proche de zéro.
La différence en une phrase
Le RTO mesure l'indisponibilité tolérable vers l'avant ; le RPO mesure la perte de données tolérable vers l'arrière. Les deux sont indépendants : un système peut tolérer une journée d'arrêt mais aucune perte de données (RTO long, RPO court), et l'inverse existe aussi.
Des exemples par type d'application
Les ordres de grandeur ci-dessous sont illustratifs, à ajuster selon votre contexte — ce ne sont pas des normes :
| Type d'application | RTO typique | RPO typique | Pourquoi |
|---|---|---|---|
| Paiement, e-commerce | Minutes | Quasi nul | Chaque transaction perdue est irrécupérable |
| ERP, facturation | Quelques heures | Une heure ou moins | Ressaisir une journée de saisie coûte très cher |
| Messagerie | Quelques heures | Quelques heures | Gênant, mais contournable brièvement |
| Serveur de fichiers | Une journée | Quelques heures | Dépend des documents en cours de travail |
| Archives, décisionnel | Plusieurs jours | Une journée | Consultation différable sans dommage |
La leçon de ce tableau : une entreprise n'a pas un RTO et un RPO, elle en a par application. En pratique, trois niveaux de criticité suffisent presque toujours à classer tout le parc — et évitent de payer pour le niveau « paiement » ce qui relève du niveau « archives ».
La méthode pour fixer les vôtres avec les métiers
- Inventorier les processus critiques, pas les serveurs : encaisser, produire, expédier, payer les salaires. Les applications viennent ensuite, comme supports de ces processus.
- Interroger les métiers sur la tolérance réelle : « à partir de combien de temps une interruption devient-elle grave ? », « que représenterait la perte des quatre dernières heures de saisie ? ». Les premières réponses — « zéro interruption, zéro perte » — se corrigent d'elles-mêmes quand on introduit le coût de chaque palier.
- Traduire en RTO et RPO par application, en suivant les dépendances : l'application de caisse ne sert à rien si la base de données, le réseau ou l'annuaire ne sont pas eux-mêmes couverts par des objectifs au moins équivalents.
- Confronter chaque palier à son coût, en face du coût d'arrêt calculé — la méthode du coût d'une heure d'arrêt fournit le chiffre à mettre en face.
- Arbitrer, documenter et faire signer la direction : un RTO est une décision d'entreprise qui engage un budget, pas un paramètre technique.
- Vérifier par des tests que les objectifs sont réellement tenus. Un RTO jamais testé est une hypothèse, pas un objectif.
Le lien avec le coût
Réduire un RTO ou un RPO coûte de façon non linéaire. Passer d'une journée à quelques heures s'obtient souvent avec de bonnes sauvegardes et des procédures claires. Passer de quelques heures à quelques minutes exige de la réplication continue, une infrastructure de secours dimensionnée et une bascule automatisée. Viser le quasi-zéro impose des architectures redondantes actives dont le coût ne se justifie que pour une minorité d'applications.
C'est pourquoi la classification par niveaux est la décision la plus rentable de tout l'exercice : elle concentre l'investissement là où l'arrêt coûte vraiment. Ces objectifs deviennent ensuite les engagements chiffrés de votre SLA, le cahier des charges de votre plan de reprise d'activité — et le critère d'évaluation d'une infrastructure de reprise digne de ce nom.
Récapitulatif
| Critère | RTO | RPO |
|---|---|---|
| Question posée | Combien de temps sans le système ? | Combien de travail perdu ? |
| Direction du regard | Vers l'avant : durée de la panne | Vers l'arrière : ancienneté de la sauvegarde |
| Unité | Temps d'indisponibilité | Ancienneté des données restaurées |
| Levier principal | Architecture de secours, bascule | Fréquence de sauvegarde, réplication |
| Qui décide | Métiers et direction | Métiers et direction |
| Comment vérifier | Test de bascule chronométré | Restauration testée et horodatée |
Comment SOVALYX peut vous aider
Les missions PRA de SOVALYX commencent précisément par cet exercice : définir avec vos métiers des RTO et RPO par application, puis dimensionner la réplication et les sauvegardes pour les tenir — et le prouver par des tests de bascule réguliers et chronométrés. Les objectifs sont inscrits dans un SLA mesurable, pas dans une plaquette commerciale.
Parler PRA avec un ingénieur🧰 L'outil qui va avec : Simulateur RTO/RPO : quel niveau de PRA pour votre application ? — gratuit · 2 minutes.
Relu et optimisé par IA.