Quels RTO et RPO sont réalistes ?
Publié sur LinkedIn le 07 aout 2026
Dans beaucoup de PRA, on trouve des objectifs très ambitieux :
RTO de 2 heures.
RPO de 15 minutes.
Parfois même : aucune perte de données.
Mais un RTO ou un RPO n’est pas réaliste parce qu’il a été validé en comité. Il l’est si le métier en a réellement besoin, que l’architecture peut le tenir et qu’un test l’a démontré.
Le RTO est le délai cible pour rétablir un service après une interruption.
Le RPO représente la quantité de données que l’organisation accepte de perdre, exprimée en durée. Un RPO de quatre heures signifie qu’après la reprise, il peut manquer jusqu’à quatre heures de données.
Première erreur : définir les mêmes objectifs pour toutes les applications.
Toutes les activités ne sont pas critiques au même niveau. Une plateforme de paiement, une messagerie interne, un portail RH et un outil d’archivage n’ont pas les mêmes impacts en cas d’arrêt.
Les objectifs doivent venir du BIA et des besoins métier :
quand l’interruption devient-elle intolérable ?
quelles opérations peuvent continuer en mode dégradé ?
quelles données peuvent être ressaisies ?
quelles obligations contractuelles ou réglementaires s’appliquent ?
quel est le coût réel de chaque heure d’arrêt ?
Deuxième erreur : confondre objectif métier et capacité technique.
Demander un RTO de deux heures ne crée pas automatiquement une reprise en deux heures.
Il faut intégrer la détection, l’escalade, la décision, la mobilisation des équipes, l’accès aux outils, la restauration, le redémarrage des dépendances, les contrôles d’intégrité, les tests fonctionnels et la validation métier.
Si la restauration technique prend déjà six heures, un RTO de deux heures n’est pas un objectif.
C’est une fiction.
Même logique pour le RPO.
Un RPO proche de zéro exige réplication, journalisation continue, architecture adaptée, protection contre la corruption et souvent des investissements élevés. Et une réplication immédiate peut aussi propager une erreur ou un chiffrement malveillant.
Le bon RPO n’est donc pas le plus bas possible.
C’est celui qui équilibre l’impact de la perte, le coût, la complexité et la capacité de récupérer des données fiables.
Un RTO/RPO réaliste doit être :
défini avec le métier,
décliné par service,
aligné avec les dépendances,
financé,
documenté,
testé,
mesuré,
corrigé après exercice.
La meilleure preuve n’est pas une matrice colorée.
C’est un test horodaté montrant le délai réel de reprise et le point réel de restauration.
La bonne question n’est donc pas :
“Quel RTO voulons-nous afficher ?”
Mais :
“Quel niveau de reprise devons-nous garantir, et sommes-nous capables de le démontrer ?”
Un RTO/RPO crédible n’est pas une promesse.
C’est une capacité métier et technique testée.
PS : Si vous découvrez mon contenu (veille CERT, Post), je vous invite à me suivre ici sur LinkedIn
#RTO #RPO #PRA #PCA #RésilienceIT #CyberRésilience #ContinuitéDActivité #ProductionIT #DSI #RSSI
