RTO vs RPO — calibrer ses objectifs de reprise sans erreur
Définitions, matrice d'exigences par criticité, benchmarks 2026 par secteur, NFR techniques associés. Le guide pour ne plus confondre RTO, RPO, MTPD, MTO.
Définitions précises
Recovery Time Objective — temps maximal acceptable d'indisponibilité
Combien de temps puis-je tolérer que mon application/service soit indisponible avant que ce soit catastrophique ? Mesuré en minutes, heures, jours. Engage le coût de l'infrastructure (redondance, hot standby, sauvegardes).
Recovery Point Objective — pertes de données acceptables
Combien de données puis-je tolérer de perdre lors d'un sinistre ? RPO = 0 implique de la réplication synchrone (chère), RPO = 24 h implique des sauvegardes journalières (peu chères).
Maximum Tolerable Period of Disruption
Plafond absolu : au-delà, l'organisation est en péril (faillite, perte d'agrément, sanctions). Inscrit dans le BIA. RTO ≤ MTPD obligatoirement.
Maximum Tolerable Outage / Maximum Time Objective
Synonyme parfois utilisé pour MTPD selon les référentiels (ISO 22301 vs ITIL).
Matrice d'exigences
| Criticité | RTO | RPO | Architecture |
|---|---|---|---|
| Critique (P0) | < 1 h | < 5 min | Active-active multi-région, réplication synchrone, hot standby |
| Élevée (P1) | < 4 h | < 1 h | Active-passive, réplication semi-synchrone, snapshots horaires |
| Moyenne (P2) | < 24 h | < 24 h | Sauvegardes journalières, restauration manuelle |
| Basse (P3) | < 72 h | < 7 j | Sauvegardes hebdomadaires, recovery on-demand |
Benchmarks 2026 par secteur
| Secteur | RTO | RPO | Driver |
|---|---|---|---|
| Banque tier-1 (paiements, marchés) | < 30 min | < 30 sec | DORA Art. 11, ACPR, FSB |
| Santé / hôpital (urgences) | < 1 h | < 15 min | HDS, NIS2 essentielle |
| E-commerce mid-cap | < 4 h | < 1 h | Coût client perdu, image |
| Industrie / production | < 8 h | < 4 h | Pénalités contractuelles JIT |
| Service public / collectivité | < 48 h | < 24 h | Continuité service public |
Questions fréquentes RTO/RPO
Quelle est la différence entre RTO et RPO ?
RTO mesure le temps acceptable d'indisponibilité (combien d'heures sans service). RPO mesure les pertes de données acceptables (combien d'heures de transactions peuvent être perdues). RTO court → infrastructure redondante chère. RPO court → réplication synchrone chère. Un service critique a typiquement RTO < 1h et RPO < 5min.
Comment construire une matrice d'exigences RTO/RPO ?
1) Classer les processus métiers par criticité (4 niveaux) via le BIA. 2) Affecter pour chaque niveau un RTO et un RPO cibles (P0 < 1h, P1 < 4h, P2 < 24h, P3 < 72h). 3) Vérifier la cohérence avec les MTPD documentés. 4) Décliner en exigences NFR techniques (réplication, sauvegardes, hot standby). 5) Faire valider par la direction métier.
Quels sont les benchmarks RTO/RPO internationaux par secteur ?
Banque tier-1 : RTO < 30 min, RPO < 30 sec (DORA, FSB). Santé : RTO < 1h, RPO < 15 min (HDS, NIS2). E-commerce : RTO < 4h, RPO < 1h. Industrie : RTO < 8h, RPO < 4h. Service public : RTO < 48h, RPO < 24h. Ces benchmarks 2026 sont indicatifs ; chaque organisation calibre selon ses MTPD et son budget.
Comment intégrer RTO/RPO dans les NFR (non-functional requirements) ?
Les NFR techniques découlent du RTO/RPO : disponibilité cible (99.9% → 8h/an de coupure tolérée), chiffrement (at-rest, in-transit), capacité (CPU/RAM/IO en mode dégradé), audit (rétention logs), sauvegardes (fréquence, sites de stockage). Documenter dans la fiche NFR de chaque application. Voir notre [module BIA] pour la traçabilité bout-en-bout.
Quelle infrastructure pour un RTO < 30 minutes ?
RTO < 30 min implique typiquement : architecture active-active multi-région (AWS Multi-AZ + Multi-Region, ou OVH 3DC), réplication synchrone (RPO ≈ 0), DNS auto-failover, monitoring 24/7 avec alerting < 5 min, runbooks testés mensuellement, équipe d'astreinte. Coût infra ×3 à ×5 par rapport à un setup mono-DC.
Le RTO/RPO change-t-il en cas de cyber crise ou de pénurie énergétique ?
Oui, on parle alors de RTO/RPO « mode crise » (recalibrés à froid). Ex : un RTO nominal de 4h passe à 24h pendant une crise énergétique car les data centers sont dégradés. Inscrire ces objectifs dégradés dans le plan de continuité, avec validation client (force majeure, SLA suspendus). Voir notre [scénario Hormuz] pour un exemple complet.
Comment ResiPlan automatise-t-il le calcul RTO/RPO ?
Lors du BIA, ResiPlan demande des entrées simples (impact financier/heure de coupure, criticité métier, dépendances) et déduit RTO/RPO recommandés via une matrice. Vous validez ou ajustez. Le système trace ensuite la cohérence avec les MTPD, les NFR techniques, et alerte si un test d'exercice ne tient pas le RTO cible. Voir [/features/bia].
Calibrer vos RTO/RPO en 2 heures avec ResiPlan
Essai gratuit 14 jours. BIA guidé par l'IA, matrice d'exigences pré-câblée, benchmark sectoriel intégré, vérification automatique de cohérence avec vos MTPD.