RPO et RTO en reprise après sinistre : définitions, exemples chiffrés, fixation des objectifs

Le RTO (recovery time objective) est la durée maximale pendant laquelle un système peut rester indisponible après une interruption. Le RPO (recovery point objective) est la quantité maximale de données que vous pouvez vous permettre de perdre, mesurée en temps écoulé depuis la dernière copie exploitable. Un RTO de 4 heures et un RPO de 15 minutes signifient : retour en ligne en moins de 4 heures, avec au plus 15 minutes de données perdues.

Points clés

• Le RTO regarde vers l'avant à partir de la panne (combien de temps avant le retour du service). Le RPO regarde vers l'arrière (quel âge a la dernière bonne copie des données).
• Les deux sont des décisions métier. Fixez-les système par système à l'issue d'une analyse d'impact sur l'activité (BIA), puis choisissez la technologie qui les atteint.
• La fréquence des sauvegardes plafonne votre RPO : avec une sauvegarde toutes les 4 heures, la perte de données maximale est d'environ 4 heures.
• Plus les objectifs sont bas, plus ils coûtent cher. Un RTO/RPO proche de zéro exige de la réplication et de la capacité de secours sur un second site.
• Des objectifs sur le papier ne valent pas grand-chose tant qu'un test n'a pas mesuré le temps de reprise et la perte de données réels.

Qu'est-ce que le RTO en reprise après sinistre ?

Le RTO est le délai maximal acceptable entre l'arrêt d'un service et son retour. AWS le définit comme « le délai maximal acceptable entre l'interruption du service et sa restauration » dans son livre blanc Disaster Recovery of Workloads on AWS (traduction libre). Le NIST l'aborde côté métier : le temps pendant lequel un système peut être en cours de reprise « avant d'avoir un impact négatif sur la mission de l'organisation ou sur ses processus métier » (traduction libre).

Le RTO couvre toute la reprise, pas seulement la restauration technique. La détection, la décision de déclencher le plan de reprise, la restauration des données, la validation de l'application et la bascule des utilisateurs comptent toutes. Les équipes qui ne chronomètrent que la restauration manquent généralement leur RTO lors d'un incident réel.

Qu'est-ce que le RPO en reprise après sinistre ?

Le RPO est la perte de données maximale acceptable, exprimée en temps. AWS le définit comme « la durée maximale acceptable depuis le dernier point de récupération des données » (traduction libre). Si votre RPO est d'une heure, vous devez, après une défaillance, pouvoir restaurer des données vieilles d'une heure au plus.

Le RPO dépend de la fréquence à laquelle vous copiez les données. Des sauvegardes nocturnes donnent un RPO maximal d'environ 24 heures. Des sauvegardes des journaux de base de données toutes les 15 minutes donnent environ 15 minutes. La réplication continue peut le ramener près de zéro, avec une réserve traitée plus bas : la réplication copie aussi les corruptions et les suppressions.

RTO et RPO : la différence en un coup d'œil

Exemples chiffrés

Exemple 1 : un système de commandes. Une boutique en ligne fixe un RTO de 4 heures et un RPO de 15 minutes. La base de données tombe à 10:00. La boutique doit reprendre les commandes d'ici 14:00, et seules les commandes passées entre 09:45 et 10:00 peuvent manquer. Des sauvegardes nocturnes ne suffisent pas ; la boutique a besoin de sauvegardes des journaux de transactions ou d'une réplication au moins toutes les 15 minutes, ainsi qu'un moyen scripté de reconstruire la couche applicative en moins de 4 heures.

Exemple 2 : vérifier un calendrier de sauvegarde. Un système financier est sauvegardé toutes les 6 heures et une restauration complète prend 3 heures. Si le métier demande un RPO d'une heure et un RTO de 2 heures, les deux objectifs échouent : la perte de données maximale est d'environ 6 heures et la restauration seule dépasse le RTO. La solution est soit des sauvegardes plus fréquentes avec une méthode de reprise plus rapide, soit une décision métier d'accepter des objectifs moins stricts.

Exemple 3 : classer un portefeuille en niveaux. La plupart des entreprises regroupent leurs systèmes en niveaux plutôt que de fixer des objectifs un par un. Les chiffres ci-dessous sont indicatifs et ne constituent pas une norme.

La colonne de stratégie suit les quatre approches du livre blanc d'AWS, où la sauvegarde et restauration assure une reprise en quelques heures et le multisite actif/actif une reprise en quasi temps réel. Notre guide du plan de reprise après sinistre explique chaque stratégie et comment choisir.

Quel lien entre RTO, RPO et interruption maximale tolérable ?

L'interruption maximale tolérable (MTD, maximum tolerable downtime) est la durée pendant laquelle un processus métier peut être perturbé avant que les dégâts ne deviennent graves. Le NIST SP 800-34 explique que le RTO « doit normalement être plus court que la MTD », car une fois les systèmes revenus, les équipes ont encore besoin de temps pour résorber le retard et ressaisir les données perdues (traduction libre). Le RPO ne fait pas partie de la MTD. Il décrit la quantité de données que le processus peut se permettre de perdre (NIST SP 800-34 Rev. 1).

En pratique : si le processus de commande peut survivre 8 heures sans systèmes, et que le rattrapage prend 2 heures, le RTO informatique doit être de 6 heures ou moins.

Comment fixer le RTO et le RPO

1. Listez les processus métier et leurs dépendances. Associez chaque processus aux applications, bases de données, services d'identité et tiers dont il a besoin.
2. Estimez l'impact de l'indisponibilité et de la perte de données dans le temps. Chiffre d'affaires, pénalités contractuelles, exposition réglementaire, sécurité et réputation. AWS souligne que l'impact peut dépendre du moment : une panne de la paie juste avant le jour de paie pèse bien plus qu'une panne juste après.
3. Proposez des objectifs par niveau et faites-les valider par le responsable métier. L'informatique ne doit pas les choisir seule.
4. Chiffrez les options. AWS recommande que, si la stratégie de reprise coûte plus que la défaillance dont elle protège, elle « ne soit pas mise en place sauf s'il existe un moteur secondaire comme des exigences réglementaires » (traduction libre).
5. Concevez et testez. Construisez les mécanismes de sauvegarde, de réplication et de bascule, puis lancez un test et consignez le temps de reprise et le point de reprise obtenus.
6. Revoyez-les chaque année et après les changements majeurs. Les systèmes glissent d'un niveau à l'autre à mesure que l'activité évolue.

Quelles technologies pour quels objectifs ?

• Les sauvegardes et snapshots planifiés conviennent à des RPO de quelques heures. Ils protègent bien contre la corruption et la suppression, car chaque copie est un point fixe dans le temps.
• La restauration à un instant donné (sauvegardes des journaux de base de données) ramène le RPO à quelques minutes pour les bases de données.
• La réplication asynchrone vers une autre région donne un RPO de quelques secondes à quelques minutes, selon le retard de réplication.
• La réplication synchrone entre zones de disponibilité donne un RPO proche de zéro, au prix d'une latence d'écriture. Les recommandations Azure Well-Architected sur la reprise après sinistre de Microsoft suggèrent une réplication synchrone entre zones pour les données à haute priorité et une réplication asynchrone entre régions pour les données de moindre priorité.
• Les environnements de secours et l'automatisation (pilot light, warm standby, infrastructure as code, bascule DNS scriptée) réduisent le RTO.

Méfiez-vous du piège de la réplication. AWS note que la réplication continue « peut ne pas protéger contre des événements sinistres comme la corruption de données ou une attaque malveillante » aussi bien que des sauvegardes à un instant donné (traduction libre). Une base chiffrée par un ransomware se réplique aussi vite qu'une base saine : conservez donc des copies à un instant donné en plus des réplicas.

Comment prouver que vous atteignez vos objectifs

Mesurez, ne supposez pas. À chaque test de reprise, notez le début de la panne, le moment où le plan a été déclenché, le retour du service et l'horodatage de la dernière transaction récupérée. Vous obtenez ainsi vos RTO et RPO réels. Les recommandations de Microsoft préconisent un mélange d'exercices sur table, de répétitions hors production et d'exercices en conditions de production. Suivez les résultats dans le temps et corrigez d'abord l'étape la plus lente.

Comment Opsio vous accompagne

Opsio anime des ateliers d'analyse d'impact, fixe le RTO/RPO par niveau avec vos responsables métier, puis construit et teste la conception de reprise correspondante sur AWS et Azure grâce à son service de reprise après sinistre dans le cloud. Pour la plateforme SaaS de recrutement WorkBuster, une approche quasi sans interruption était une exigence forte lorsqu'Opsio a migré la plateforme vers AWS. La conception repose sur une base MySQL haute disponibilité multi-AZ sur Amazon RDS, avec l'infrastructure définie dans des modèles CloudFormation.

Questions fréquentes

Quelle est la différence entre RTO et RPO ?

Le RTO est la durée pendant laquelle un système peut être indisponible après une interruption. Le RPO est la quantité de données, mesurée en temps, que vous pouvez vous permettre de perdre. Le RTO concerne l'indisponibilité ; le RPO concerne la perte de données.

Quels sont de bons RTO et RPO ?

Il n'existe pas de valeur universelle. Un système de paiement peut exiger quelques minutes pour les deux, alors qu'un outil de reporting interne peut accepter 24 heures. Déduisez les objectifs du coût de l'indisponibilité et de la perte de données pour chaque processus métier, puis vérifiez le coût pour les atteindre.

Le RPO peut-il être nul ?

Proche de zéro, oui, avec la réplication synchrone ou des architectures multisites actif/actif. Une perte de données strictement nulle est difficile à garantir entre régions à cause de la distance et de la latence, et la réplication seule ne protège pas contre la corruption.

Le RTO est-il la même chose qu'un SLA ?

Non. Un SLA est un engagement envers les clients sur la disponibilité ou la réactivité. Le RTO est un objectif de reprise interne pour un scénario de sinistre. Votre RTO doit soutenir vos SLA, mais ils ne se mesurent pas de la même façon.

À quelle fréquence faut-il revoir les objectifs de reprise ?

Au moins une fois par an et après tout changement majeur des systèmes, des fournisseurs ou de l'activité. Remesurez-les à chaque test de reprise, car ce sont les valeurs obtenues qui comptent.