L’objectif de point de reprise (RPO) correspond à la quantité maximale de données — exprimée en temps — que votre organisation peut perdre à la suite d’une interruption imprévue tout en continuant à fonctionner dans des limites acceptables.

Considérez le RPO comme un compte à rebours de perte de données : il commence à décompter à partir du moment où survient une panne, une cyberattaque ou une erreur humaine, et s’arrête au niveau de votre dernier point de sauvegarde ou de réplication exploitable. Chaque seconde écoulée entre ces deux points représente des données que vous risquez de ne jamais récupérer.

NISTdéfinit le RPOc’est-à-dire « le moment jusqu’auquel les données doivent être restaurées après une panne ». Cette définition est d’une simplicité trompeuse. Dans la pratique, la définition d’un RPO adéquat soulève des questions importantes concernant les charges de travail prioritaires, la fréquence des sauvegardes et le niveau d’investissement dans l’infrastructure de réplication.

Les cyberattaques, les pannes du cloud et les suppressions accidentelles surviennent à des moments que vous ne pouvez pas contrôler. Les entreprises qui définissent des objectifs RPO clairs — et les appliquent grâce à une sauvegarde automatisée et régie par des règles — se donnent les moyens de se rétablir dans les limites de tolérance de l’activité, au lieu de devoir courir aux remèdes après coup.

Ce guide vous explique le fonctionnement du RPO, en quoi il diffère de l’objectif de temps de reprise (RTO), vous présente des exemples concrets, vous indique comment calculer le RPO et vous explique son rôle essentiel dans la cyber-résilience.

Le rôle du RPO dans la planification de la continuité des activités

Le RPO est le « seuil de perte de données » qui détermine la fréquence de vos sauvegardes. Si le RPO d’une base de données est d’une heure, les sauvegardes doivent être effectuées au moins toutes les 60 minutes. Si vous ne respectez pas cette cadence, vous risquez d’avoir déjà dépassé votre seuil de tolérance avant même qu’un incident ne se produise.

Dans un plan de continuité des activités, le RPO constitue, avec le RTO, l’un des deux piliers de la reprise après sinistre. Alors que le RTO répond à la question « En combien de temps pouvons-nous remettre les systèmes en service ? », le RPO répond à la question « Quel sera le degré d’actualité des données restaurées ? ». Ces deux éléments s’inscrivent dans le cadre plus large de la stratégie de reprise après sinistre — et tous deux doivent être validés par des tests réguliers, et non pas simplement consignés dans un classeur.

Le RPO peut également comporter un volet lié à la conformité :

• Les réglementations telles que la loi HIPAA exigent généralement que les établissements de santé conservent des copies récupérables des informations de santé électroniques des patients.
• La loi SOX contient des dispositions visant à garantir que les documents comptables restent vérifiables et intacts.
• Le RGPD prévoit que le traitement des données à caractère personnel doit pouvoir être rétabli dans un délai raisonnable après un incident technique.

Lorsqu’une attaque crypte les données de production, l’écart entre votre dernière sauvegarde intacte et l’horodatage du cryptage correspond aux données que vous perdez. Cet écart, c’est votre RPO en action – et il permet de déterminer si la restauration prendra quelques heures ou si elle se transformera en crise.

Conclusion pratique : le RPO n’est pas un chiffre que l’on définit une fois pour toutes. Il doit refléter les taux actuels de modification des données, les exigences de conformité et les réalités du paysage des menaces     et il doit être appliqué au moyen de politiques de sauvegarde automatisées.

RPO ou RTO : quelle est la différence ?

Le RPO et le RTO sont les deux faces d’une même médaille en matière de Recovery, mais ils mesurent des éléments différents.

Le RPO se situe rétrospectivement, à partir du moment où la panne s’est produite. Il pose la question suivante : « Quelle quantité de données pouvons-nous nous permettre de perdre ? » La réponse s’exprime en temps — minutes, heures ou jours — et correspond au délai écoulé entre la dernière sauvegarde valide et la panne.

Le RTO se projette dans l’avenir à partir du moment où la panne survient. Il pose la question suivante : « En combien de temps les systèmes doivent-ils être remis en service ? » La réponse s’exprime également en termes de temps, mais elle mesure la tolérance à l’indisponibilité plutôt que la tolérance à la perte de données.

Ces deux indicateurs doivent être définis conjointement. Une entreprise dont le RPO est de 15 minutes mais dont le RTO est de 24 heures se retrouve avec des données récentes qui restent inutilisées pendant une journée entière. À l’inverse, un RTO de quatre heures associé à un RPO de 24 heures signifie que les systèmes sont rapidement remis en service, mais avec des données obsolètes.

Aligner les objectifs RPO et RTO avant qu’un incident ne survienne — et les valider par des tests réguliers de reprise après sinistre — peut faire la différence entre une réponse maîtrisée et une situation de précipitation.

Niveaux de RPO et exemples concrets

Toutes les charges de travail ne justifient pas le même RPO. Hiérarchiser vos RPO en fonction de l’importance stratégique des activités permet d’assurer une protection rigoureuse là où cela compte et de maîtriser les coûts là où cela n’est pas indispensable.

Niveau 0 : RPO quasi nul (de quelques secondes à quelques minutes) : les bases de données de transactions financières, les dossiers médicaux électroniques des patients et les plateformes de négociation en temps réel nécessitent généralement une protection continue des données (CDP) ou une réplication synchrone. Ces charges de travail génèrent des revenus ou ont un impact réglementaire à chaque seconde ; par conséquent, même quelques minutes de perte de données peuvent être difficiles à supporter. Les organisations qui mettent en œuvre un RPO quasi nul utilisent généralement la CDP ou la réplication synchrone pour réduire au minimum la fenêtre de perte de données.

Niveau 1 : 1 à 4 heures : les systèmes de gestion de la relation client (CRM), les plateformes de messagerie électronique et les systèmes de traitement des commandes relèvent souvent de cette catégorie. Des sauvegardes incrémentielles fréquentes — toutes les 15 à 60 minutes — permettent de maintenir la perte de données dans des limites acceptables. Le coût est modéré, et l’impact commercial de la perte de quelques heures de messagerie électronique ou de mises à jour du CRM est généralement gérable grâce à une ressaisie manuelle.

Niveau 2 : 4 à 12 heures : les outils de collaboration interne, les environnements de développement et les plateformes de gestion de projet fonctionnent généralement dans cette fourchette. Des sauvegardes programmées toutes les 4 à 6 heures permettent de trouver un juste équilibre entre la protection des données et les coûts de stockage.

Niveau 3 : 12 à 24 heures : les archives d’analyse marketing, les journaux historiques et la documentation de référence peuvent souvent se contenter de sauvegardes quotidiennes dans le cloud. Les données évoluent lentement et leur reconstruction est possible, ce qui rend les sauvegardes quotidiennes rentables.

La hiérarchisation permet aux entreprises de concentrer leurs investissements sur la protection des charges de travail pour lesquelles chaque minute de perte de données entraîne un coût maximal, tout en évitant de dépenser inutilement pour des archives qui ne sont mises à jour qu’une fois par semaine.

RPO et cyber-résilience

Les ransomwares se moquent bien de votre calendrier de sauvegarde  – mais c’est votre RPO qui détermine l’ampleur du pouvoir de négociation dont disposent les attaquants. Un RPO serré signifie qu’il y a moins de données entre votre dernière sauvegarde immuable et l’événement de chiffrement, ce qui contribue à réduire la portée d’une attaque.

La cyber-résilience ne dépend pas uniquement de la fréquence des sauvegardes. Les copies de sauvegarde isolées physiquement et immuables contribuent à protéger contre les attaquants qui compromettent les environnements de production, en les empêchant d’accéder aux données de Recovery ou de les altérer. Lorsque ces sauvegardes sont stockées en dehors du compte cloud principal, vous ajoutez un niveau d’isolation que les ransomwares ne peuvent tout simplement pas franchir.

C’est là que Clumio by Commvault trouve sa place dans votre stratégie de RPO. AvecClumio, vous stockez vos données de sauvegarde dans un environnement isolé et entièrement géré, en dehors de votre compte AWS principal. La restauration granulaire à un instant donné vous permet de revenir à un moment précis antérieur à l’attaque  — ce qui contribue à limiter la perte de données au RPO que vous avez défini. Cette solution est conçue pour vous permettre de garder le contrôle de votre restauration sans dépendre de l’infrastructure compromise par l’attaquant.

Les entreprises qui respectent des délais de reprise après sinistre (RPO) stricts et disposent de sauvegardes immuables et isolées peuvent éviter de payer une rançon, car elles sont en mesure de restaurer elles-mêmes des données intactes.

La formule est simple : un RPO plus strict associé à des sauvegardes immuables et isolées se traduit généralement par une surface d’attaque réduite et une Recovery plus rapide et plus propre. C’est là le fondement de la cyber-résilience.