RPO : qu'est-ce que le Recovery Point Objective ?

Ce qu'il faut retenir

Le RPO (Recovery Point Objective) mesure la quantité de données qu'une organisation perdra réellement lors d'un sinistre, exprimée en temps. C'est une capacité technique mesurée, pas un souhait. Le besoin exprimé par le métier porte un autre nom : le BRPO (Business Recovery Point Objective). Le RPO se distingue aussi du RTO (Recovery Time Objective), qui porte sur le délai de redémarrage d'une application, pas sur la donnée perdue. La chaîne est simple : le BIA (Bilan d'Impact sur l'Activité) identifie les activités critiques, le métier exprime son besoin de fraîcheur des données, la direction des systèmes d'information y répond avec une capacité. Et seul un test de restauration confirme le chiffre.

Qu'est-ce que le RPO (Recovery Point Objective) ?

Une question simple, et pourtant rarement posée clairement dans les plans de continuité d'activité (PCA) : si vos systèmes tombent maintenant, combien d'heures de données allez-vous perdre ?

Le RPO, ou Recovery Point Objective, est la quantité de données qu'une organisation perdra en cas de sinistre, mesurée en temps. C'est l'écart entre le moment de l'incident et la dernière sauvegarde réellement exploitable.

Une précision qui change tout, et qui manque dans la plupart des définitions publiées. Le RPO est une capacité, pas un souhait. Ce que le métier estime pouvoir perdre comme donnée porte un autre nom : le BRPO, ou Business Recovery Point Objective. Le métier exprime un besoin, la direction des systèmes d'information (DSI) y répond avec une capacité mesurée. Un dispositif sain est celui où le RPO rejoint le BRPO.

Concrètement, le RPO répond à trois questions. Combien de données seront perdues après un incident majeur. À quelle fréquence les sauvegardes doivent tourner pour tenir cet objectif. Quelles ressources techniques doivent être disponibles pour restaurer les données une fois l'incident passé.

Le RPO travaille toujours en tandem avec le RTO. Les deux mesures forment ensemble la colonne vertébrale d'une stratégie de reprise après sinistre. Si vous cherchez la définition complète du RTO, je l'ai détaillée dans mon article sur le RTO.

Quelle est la différence entre le RPO et le RTO ?

Ces deux indicateurs sont souvent calculés ensemble dans un plan de reprise après sinistre. Ils travaillent en tandem, mais ils ne mesurent pas la même chose.

Le RPO

Le RPO indique la quantité de données réellement perdue pendant un sinistre. Il se mesure en temps : l'écart entre l'incident majeur et la dernière sauvegarde exploitable. Pour chaque système critique, l'organisation part du besoin exprimé par le métier, puis vérifie ce que la fréquence de sauvegarde en place permet effectivement de tenir.

Le RTO

Le RTO porte sur le délai de redémarrage d'une application après une panne. Il ne dit rien sur la donnée perdue. Une application peut redémarrer en quinze minutes avec vingt-quatre heures de données manquantes. Les deux indicateurs sont donc complémentaires, jamais interchangeables.

Pourquoi le RPO est-il important ?

À l'ère du numérique, les organisations naviguent entre cyberattaques, pannes techniques et défaillances humaines. Un RPO bien mesuré ne se contente pas de remplir une colonne dans un tableau. Il évite des dégâts réels le jour où l'incident survient.

Exemple terrain. En janvier 2017, GitLab perd six heures de données de production, incluant tickets, demandes de fusion et commentaires utilisateurs. La seule sauvegarde exploitable date de six heures avant l'incident. Sur cinq mécanismes de sauvegarde et de réplication déployés, aucun ne fonctionne de façon fiable au moment où l'organisation en a besoin. La restauration prend près d'une journée entière. Depuis, GitLab a beaucoup investi dans la fiabilité de ses sauvegardes. L'entreprise a notamment réduit le temps de sauvegarde de son plus gros dépôt de 48 heures à 41 minutes, ce qui permet des sauvegardes bien plus fréquentes et donc un RPO potentiellement bien plus court.

Le coût d'un incident de ce type ne se limite pas au temps perdu. Le rapport 2025 d'IBM sur le coût des violations de données chiffre le coût moyen mondial d'une violation à 4,44 millions de dollars, en baisse de 9 % par rapport à l'année précédente. Au-delà du coût direct, la perte de données touche aussi le chiffre d'affaires par les interruptions de service, les transactions clients perdues et l'atteinte à la réputation.

Comment calculer son RPO ?

Chaque organisation a des RPO différents. S'appuyer sur les standards de son secteur aide à poser un premier repère, mais un RPO tenable se construit en trois temps, pas en recopiant une valeur de marché.

Le point de départ, c'est le BIA. Il identifie les activités critiques de l'organisation et les applications qui les soutiennent. C'est exactement le travail que je mène dans ma mission BIA : des entretiens terrain avec les opérationnels, pas un questionnaire diffusé par mail.

Vient ensuite l'expression du besoin. Pour chaque application critique, le métier indique la quantité de données qu'il ne peut pas se permettre de perdre. C'est le BRPO. La fréquence de mise à jour des données pèse beaucoup ici : plus elle est élevée, plus le besoin sera exigeant. Pour les systèmes les plus opérationnels, le métier exprimera un besoin proche de zéro.

La DSI répond enfin avec le RPO, c'est-à-dire ce que l'infrastructure en place permet réellement de garantir. L'écart entre les deux chiffres est l'information la plus utile de tout l'exercice. Tant qu'il n'est pas nommé, il n'est pas traité.

Hiérarchiser les niveaux de priorité des données est essentiel dans cette démarche. Toutes les données d'une organisation, et même toutes les données d'une seule application, n'ont pas la même valeur.

Exemple terrain. Une boutique en ligne classe ses données par niveaux. Pour la passerelle de paiement et la base d'expédition, qui traitent les transactions clients, le métier exprime un besoin proche de zéro. La direction retient la protection continue des données (CDP, Continuous Data Protection) pour ces flux. Les données marketing, elles, tolèrent quatre heures de perte, car elles sont peu critiques. Appliquer le même niveau de protection partout reviendrait soit à surinvestir sur des données secondaires, soit à sous-protéger des données vitales.

Cette démarche permet aussi de vérifier si l'organisation respecte ses engagements de service (SLA, Service Level Agreement) envers ses clients. Si les RPO et RTO constatés sont régulièrement dépassés pendant ou après un incident, c'est le signe qu'il faut revoir la stratégie de reprise après sinistre.

Quels facteurs influencent le RPO ?

Des facteurs internes et externes déterminent le RPO réellement atteignable par une organisation.

La fréquence de mise à jour des données

Évaluer régulièrement ses sauvegardes et les instantanés de données critiques permet de mettre en place les mesures nécessaires si un sinistre survient. Une sauvegarde n'est utile que si elle est alignée sur le rythme réel des données. Une sauvegarde programmée toutes les vingt-quatre heures expose à perdre jusqu'à vingt-quatre heures de données. Les organisations qui manipulent des données critiques en continu mettent en place une protection continue des données pour atteindre un RPO proche de zéro.

Le mode de stockage des données

La façon dont les données sont stockées et les sauvegardes configurées influence la vitesse à laquelle l'information peut être récupérée après un sinistre. Stockage sur site, cloud, stockage externalisé : chaque option a ses propres contraintes de délai et de coût.

Le secteur d'activité

Chaque secteur a ses standards. Une banque et une entreprise industrielle n'ont pas les mêmes exigences de protection des données. Connaître les références de son secteur aide à situer sa propre capacité et à identifier les écarts, tout en restant protégé contre les risques propres à ce secteur.

La conformité réglementaire

Certains cadres réglementaires imposent des exigences précises de protection et de récupération des données. Pour les entités financières, c'est notamment le cas avec DORA (Digital Operational Resilience Act). Je traite ce point en détail dans mon article sur DORA pour les mutuelles. Ne pas respecter ces exigences expose à des sanctions, des conséquences juridiques et une atteinte réputationnelle.

Quels sont les intervalles de RPO courants ?

Une même organisation gère des données de criticités très différentes. Raisonner par niveaux évite deux erreurs symétriques : surprotéger des données secondaires à grands frais, ou sous-protéger des données vitales. Les intervalles ci-dessous sont indicatifs.

Intervalle de RPO	Type de données et d'applications	Dispositif technique typique
Zéro à 1 heure	Transactions bancaires, données patient, opérations critiques en continu	Réplication continue, systèmes bancaires cœur avec RPO proche de zéro
1 à 4 heures	Gestion des stocks, bases clients, ERP, messagerie	Sauvegardes rapprochées dans la journée
4 à 24 heures	Marketing, analytique, administratif, contrôle qualité	Sauvegarde quotidienne

Plus le RPO visé est court, plus le coût est élevé, car il exige des sauvegardes fréquentes et une infrastructure de réplication conséquente.

Comment optimiser son RPO ?

Un RPO n'est pas une mesure figée. À mesure que l'organisation évolue, il faut le tester et l'ajuster.

Trois leviers permettent de le réduire. Augmenter la fréquence des sauvegardes, ce qui limite le volume de données exposées en cas d'incident. Répliquer les données, en créant des copies secondaires vers lesquelles basculer en cas de panne ou de cyberattaque, la fréquence de réplication déterminant alors le RPO final. Adopter des technologies avancées comme la protection continue des données, qui sauvegarde en temps réel et augmente fortement les chances de récupération.

Chacun de ces leviers a un coût. C'est le besoin exprimé par le métier qui indique où l'investissement se justifie, et où il serait disproportionné.

Point de vigilance. Un RPO ne se vérifie pas en regardant si la sauvegarde s'est lancée. Le tableau de bord peut afficher un statut vert alors que la sauvegarde est incomplète ou corrompue, comme l'a découvert GitLab à ses dépens. Le RPO se vérifie en restaurant réellement les données et en mesurant ce qui a pu être récupéré. Un exercice sur table permet déjà de confronter les chiffres affichés aux procédures réelles, étape par étape. Mais seul un test de restauration grandeur nature donne la valeur exacte.

Questions fréquentes sur le RPO

Quelle est la différence entre le BRPO et le RPO ?

Le BRPO (Business Recovery Point Objective) est le besoin exprimé par le métier : la quantité de données qu'une équipe opérationnelle estime ne pas pouvoir perdre pour une application donnée. Le RPO est la réponse technique de la DSI : ce que l'infrastructure permet réellement de garantir. L'objectif d'un dispositif de continuité est que le RPO soit inférieur ou égal au BRPO. Confondre les deux est l'erreur la plus fréquente, et celle qui produit des plans de continuité remplis de chiffres qui ne tiennent pas le jour du sinistre.

Le RPO est-il la même chose que la fréquence de sauvegarde ?

Non, mais les deux sont étroitement liés. La fréquence de sauvegarde est le levier technique qui détermine le RPO atteignable. Une sauvegarde toutes les vingt-quatre heures produit un RPO de vingt-quatre heures. Beaucoup d'organisations écrivent un RPO de quatre heures dans leur plan parce qu'elles aimeraient ne pas perdre plus de quatre heures de données. Puis on regarde l'infrastructure : la sauvegarde tourne une fois par nuit. L'écart ne se découvre que le jour du sinistre.

Un RPO peut-il être de zéro ?

Oui, pour certaines applications critiques, notamment les systèmes de transactions bancaires ou les données de santé. Un RPO proche de zéro suppose une réplication continue des données, souvent appelée protection continue des données (CDP). Le coût est significatif, donc on le réserve aux applications dont la criticité le justifie réellement, identifiées via le BIA.

Qui doit fixer le RPO dans une organisation ?

Personne ne le fixe seul. Le métier, via le BIA, identifie les activités critiques et exprime son besoin de fraîcheur des données pour chaque application support. La DSI y répond avec une capacité technique réelle. Écrire un chiffre sans ce dialogue conduit presque toujours à une valeur qui ne tient pas la route le jour du sinistre.

À quelle fréquence faut-il revoir son RPO ?

Dès qu'un changement significatif intervient : nouvelle application critique, évolution de l'infrastructure de stockage, nouvelle obligation réglementaire, changement dans les volumes de données traitées. À défaut, une revue annuelle accompagnée d'un test de restauration permet de vérifier que le RPO affiché reste tenable.

Passez à l'action

Le RPO n'est pas une fréquence de sauvegarde à recopier dans un tableau. C'est le dernier maillon d'une chaîne : une criticité d'activité issue du BIA, un besoin exprimé par le métier pour chaque application support, une capacité technique apportée en réponse, et un test de restauration pour confirmer que la seconde rejoint le premier.

Si vous voulez vérifier que les RPO de votre plan de continuité reposent sur cette logique et tiennent vraiment la route, envoyez-moi un message via le formulaire de contact ou réservez directement un créneau de 30 minutes via Calendly. On fait le point ensemble, sans engagement.

Sources et références

What Is a Recovery Point Objective (RPO)? (Continuity2)

GitLab.com database incident (GitLab, 2017)

How we decreased GitLab repo backup times from 48 hours to 41 minutes (GitLab)

Cost of a Data Breach Report 2025 (IBM)

À lire également

Besoin d'accompagnement ?

Découvrez nos offres dédiées à la mise en place d'un PCA, à l'accompagnement ISO 22301 ou aux exercices de crise immersifs. Pour en savoir plus sur ma démarche, consultez la page À propos.