En entreprise, la moindre interruption de service peut coûter des millions et menacer la confiance des clients. Le Recovery Point Objective (RPO), fixe la quantité de données qu’une entreprise peut se permettre de perdre entre deux sauvegardes. Étroitement lié au RTO (Recovery Time Objective), il guide la politique de résilience des données, la conformité réglementaire et les plans de reprise d’activité. Entre définitions et bonnes pratiques cyber, découvrez comment évaluer, calculer et améliorer votre RPO afin de renforcer votre stratégie de continuité et de reprise après incident.
Le Recovery Point Objective, ou RPO, correspond à la quantité maximale de données qu’une organisation accepte de perdre entre deux sauvegardes lors d’un incident.
Par exemple, une entreprise qui effectue une sauvegarde toutes les quatre heures a un RPO de 4 h, ce qui signifie qu’en cas d’incident elle pourra perdre jusqu’à quatre heures de données.
En France, l’ANSSI emploie l’expression Perte de Données Maximale Admissible (PDMA)1. Cette notion complète le RTO (Recovery Time Objective), appelé Durée Maximale d’Interruption Admissible (DMIA), qui désigne le temps maximum d’interruption des services.
Lorsqu’on parle de cybersécurité en entreprise, ces deux indicateurs vont de pair pour assurer la continuité d’activité. Ils orientent les plans de reprise (PRA) et de continuité (PCA), en définissant les priorités de sauvegarde et de restauration.
Un RPO bien défini fixe, pour chaque service critique, la quantité maximale de données pouvant être perdue. Cette approche permet de maintenir un niveau de service acceptable même lors d’événements graves : panne d’un data center, corruption de bases de données ou attaque par ransomware.
Prenons l’exemple d’un site de commerce en ligne. S’il se contente d’une sauvegarde nocturne, il risque de perdre une journée complète de commandes. En revanche, un RPO de 15 minutes sur la base des transactions garantit que presque toutes les ventes seront conservées en cas d’incident.
La valeur d’un RPO court se mesure aussi en termes financiers et réputationnels. La perte de quelques milliers de dossiers médicaux ou de relevés bancaires peut entraîner des sanctions réglementaires, des indemnisations ou des ruptures de contrat.
Un RPO ambitieux contribue donc à protéger les informations les plus sensibles (paiements, données clients, propriété intellectuelle) et à éviter les frais liés aux interruptions de service.
Mais attention : pour être fiable, il doit s’appuyer sur des mécanismes solides de sauvegarde, de réplication et de chiffrement.
Le RPO constitue également une exigence de conformité face aux normes cyber :
À ces contraintes légales s’ajoutent les engagements contractuels pris avec les clients ou partenaires. Ces accords de niveau de service, ou SLA (Service Level Agreements), traduisent les objectifs RPO en obligations précises : par exemple, un fournisseur cloud peut s’engager à garantir un RPO de quelques minutes pour une base de données transactionnelle.
Le non-respect de ces engagements peut non seulement entraîner des pénalités financières, mais aussi la remise en cause de la relation commerciale.
La définition d’un RPO pertinent ne se résume pas à fixer une valeur chiffrée. Elle exige une analyse rigoureuse des données, des processus métiers, des interdépendances applicatives et du cadre réglementaire. L’objectif est de transformer un indicateur théorique en une capacité mesurable de reprise, alignée sur les enjeux réels de l’entreprise.
La première étape consiste à dresser l’inventaire précis de toutes les données et applications, qu’elles soient hébergées sur site, dans le cloud ou en environnement hybride.
À titre d’exemple, une entreprise industrielle distinguera ses données de contrôle de production, qui nécessitent une sauvegarde quasi temps réel, de ses archives comptables, pour lesquelles une sauvegarde quotidienne reste acceptable.
Sur la base de cette cartographie, l’entreprise détermine la Perte de Données Maximale Admissible (PDMA) :
Cette évaluation repose sur plusieurs paramètres :
Chaque processus métier est noté selon deux critères : impact métier et coût d’une perte de données.
Pour rendre l’analyse plus opérationnelle, nous vous conseillons de formaliser l’évaluation sous forme de tableau de scoring.
Processus métier |
Impact métier (1 à 5) |
Coût d’une perte (1 à 5) |
Score global |
Transactions financières |
5 |
5 |
25 |
Système de messagerie |
3 |
2 |
6 |
Archivage comptable |
2 |
1 |
2 |
Le RPO doit refléter les exigences propres au secteur, notamment :
Cette phase doit aussi tenir compte de la réalité opérationnelle : budgets, ressources humaines, maturité des infrastructures. Un RPO ambitieux mais irréaliste risque de ne jamais être atteint.
Une fois la PDMA fixée, il faut la traduire en fréquence de sauvegarde ou de réplication :
Des solutions comme Veeam, Rubrik ou Zerto aident à surveiller le respect de ces objectifs en temps réel, avec alertes automatiques en cas de dérive.
À noter : il est recommandé de formaliser ce RPO dans les plans de reprise d’activité (PRA) et plans de continuité (PCA), en précisant les procédures, les ressources techniques et les responsabilités.
Toutes les données n’ont pas la même importance ni les mêmes contraintes. Une stratégie à plusieurs niveaux optimise les coûts et la performance :
Cette hiérarchisation permet d’investir dans des solutions coûteuses (réplication synchrone, sauvegarde continue) uniquement pour les données stratégiques, tout en maintenant un niveau de protection approprié pour les autres.
L’ANSSI recommande d’ailleurs de documenter et auditer régulièrement ces différents niveaux pour garantir leur cohérence dans le temps.
Une fois les objectifs RPO définis, l’enjeu consiste à réduire l’écart entre la théorie et la pratique. Pour ce faire, il s’agit de bâtir une infrastructure résiliente, automatisée et sécurisée, capable de résister aux aléas techniques et aux menaces cyber.
Le choix de la technologie conditionne directement la capacité à réduire la perte de données.
Dans les environnements critiques, la réplication synchrone est privilégiée : chaque opération validée dans la base de production est immédiatement dupliquée sur un site secondaire. Ainsi, en cas de sinistre, aucune donnée n’est perdue.
La réplication asynchrone, moins onéreuse, introduit un léger décalage mais reste adaptée pour des RPO intermédiaires.
Cependant l’expérience montre que la fiabilité ne repose pas uniquement sur la technologie choisie, mais aussi sur sa capacité à être testée régulièrement. De nombreuses entreprises découvrent l’invalidité de leurs sauvegardes seulement après un incident. Des tests trimestriels, réalisés dans des environnements isolés, permettent de s’assurer que la restauration est rapide et cohérente avec les objectifs RPO.
On ne vous apprend rien : le facteur humain est souvent le maillon faible de la chaine cyber, et les plans de reprise n’y font pas exception.
Par exemple, un opérateur qui oublie de lancer une sauvegarde critique ou qui exécute mal une procédure de restauration peut compromettre le RPO. C’est pourquoi l’automatisation est indispensable !
Les entreprises les plus matures sur le plan cyber mettent en place des playbooks PRA/PCA, capables de déclencher automatiquement des séquences de sauvegarde, de réplication ou de bascule d’infrastructure en cas d’incident. Ces playbooks orchestrent les interactions entre serveurs, bases de données et applications, sans attendre une intervention manuelle.
Les consoles centralisées de supervision permettent quant à elles de :
Enfin, des tests de sinistre en conditions réelles complètent cette approche. Simuler une attaque par ransomware ou l’arrêt brutal d’un data center permet de mesurer la réactivité de l’organisation et de corriger les points faibles avant qu’un incident ne survienne réellement.
Améliorer le RPO ne consiste pas seulement à multiplier les sauvegardes. Il s’agit aussi de sécuriser l’environnement de stockage pour qu’il reste exploitable lors d’un incident majeur. Une approche cohérente combine plusieurs mesures :
Le saviez-vous ? 💡
L’usage d’un coffre-fort numérique comme LockFiles illustre cette logique : il permet de stocker des copies inaltérables, déconnectées des environnements de production, pour garantir que la reprise reste toujours possible. En cas d’attaque, même ciblant les sauvegardes, ces copies restent donc disponibles pour garantir une restauration rapide et conforme au RPO défini.
Un scénario de test de restauration vient ensuite valider la résilience de ce dispositif.
Par exemple :
_____
Sources :