RTO et RPO : Comprendre les piliers de la reprise après sinistre
Découvrez les différences entre RTO (Recovery Time Objective) et RPO (Recovery Point Objective) pour optimiser votre plan de reprise d’activité (PRA)
Dans un monde où les entreprises dépendent fortement de leurs systèmes informatiques, la continuité d’activité devient un enjeu stratégique.
Que ce soit une panne de serveur, une cyberattaque ou un incendie, chaque incident peut avoir un impact critique.
Pour y faire face efficacement, deux indicateurs essentiels doivent être définis : le RPO (Recovery Point Objective) et le RTO (Recovery Time Objective).
Mais que signifient vraiment ces termes ? En quoi sont-ils différents et complémentaires ? Et surtout, comment les définir pour son entreprise ?
Qu'est-ce que le RPO ?
Le RPO, ou Recovery Point Objective, désigne la période maximale de données que l’on est prêt à perdre en cas d’incident.
Exemple du RPO :
Si votre RPO est de 4 heures, cela signifie que vous acceptez de perdre jusqu’à 4 heures de données. Vos sauvegardes devront donc être programmées toutes les 4 heures au minimum pour respecter cet objectif.
RPO en résumé :
-
Unité de mesure : durée (heures, minutes)
-
Impact : volume de données perdues
-
Lié à : fréquence de sauvegarde et stratégie de réplication
Qu'est-ce que le RTO ?
Le RTO, ou Recovery Time Objective, désigne le temps maximal acceptable pour restaurer un système après une panne ou un sinistre.
Exemple du RTO :
Si votre RTO est de 2 heures, votre infrastructure informatique doit être remise en service et opérationnelle dans ce délai, au-delà duquel les conséquences pour l’entreprise deviennent inacceptables (pertes financières, réputation, sécurité...).
RTO en résumé :
-
Unité de mesure : durée (heures, minutes)
-
Impact : indisponibilité des services
-
Lié à : performances du plan de reprise (PRA), redondance, automatisation
Différence entre RPO et RTO
| Critère | RPO (Recovery Point Objective) | RTO (Recovery Time Objective) |
|---|---|---|
| Définition | Quantité de données pouvant être perdues | Temps maximal pour la reprise |
| Objectif | Minimiser la perte de données | Réduire le temps d’arrêt |
| Exemple concret | Sauvegardes toutes les 15 min | Redémarrage complet en 1 heure |
| Lié à | Stratégie de sauvegarde | Stratégie de reprise (PRA/PCA) |
Pourquoi ces notions sont-elles cruciales ?
1. Évaluer les risques
Connaître vos RPO et RTO permet de mesurer les risques réels pour votre activité en cas d’incident.
2. Dimensionner votre infrastructure
Un RTO faible implique souvent un coût élevé (réplication temps réel, serveurs redondants...). Il faut donc adapter la technologie au besoin métier.
3. Mettre en place une stratégie cohérente
Définir des RPO/RTO réalistes est la base d’un Plan de Reprise d’Activité (PRA) et/ou Plan de Continuité d’Activité (PCA) efficace.
Comment définir vos RPO et RTO ?
Étapes recommandées :
-
Cartographier vos applications : identifiez les systèmes critiques (ERP, messagerie, site e-commerce...).
-
Évaluer l’impact métier d’une perte de données ou d’une indisponibilité.
-
Prioriser les applications selon leur criticité.
-
Fixer des objectifs RPO et RTO spécifiques pour chaque application ou service.
-
Tester régulièrement votre PRA pour vérifier que ces objectifs sont bien atteignables.
Services associés