recovery-point-objective
Lexique IT

RPO : choisir la perte de données acceptable pour votre PME

Mis à jour le · Rédaction Pixel’IT

Le Recovery Point Objective, ou RPO, définit le point de données auquel l’entreprise doit pouvoir revenir après un incident. On l’exprime souvent par une durée de perte de données acceptable. Ce choix guide les sauvegardes et la réplication, mais doit être vérifié sur des points réellement récupérables.

Lire le RPO sur une chronologie

Supposons, à titre d’exemple, qu’un incident survienne à 15 h et que le dernier état exploitable soit celui de 14 h. Il existe une heure de données potentiellement à reconstituer. L’entreprise doit savoir si cette perte est acceptable et comment traiter les opérations concernées.

Le RPO est l’objectif convenu ; le point effectivement récupérable est un résultat à constater. Un échec de sauvegarde, une copie incomplète ou une corruption peut éloigner le résultat de l’objectif.

Ne pas confondre RPO, RTO et conservation

NotionQuestion posée
RPOÀ quel état de données doit-on pouvoir revenir ?
RTODans quel délai doit-on remettre le service à disposition ?
ConservationCombien de temps garde-t-on les états ou documents prévus ?

Une durée de conservation longue ne garantit pas un état récent. Une restauration rapide ne prouve pas que les données récupérées sont assez fraîches. Consultez le guide du RTO et du délai de reprise pour compléter l’analyse.

Définir les besoins par application et par donnée

Évaluez la fréquence des modifications et les moyens de reconstitution. Une commande peut parfois être ressaisie depuis une confirmation ; un ensemble de modifications non tracées peut être beaucoup plus difficile à reconstruire. Incluez le temps des utilisateurs et le risque d’erreurs.

  • Quelles données changent pendant une journée ?
  • Quelles opérations disposent d’une autre trace fiable ?
  • Quels systèmes doivent retrouver un état cohérent ?
  • Qui valide la reprise des données et les écarts ?

Les objectifs peuvent varier entre une base de production, des fichiers de travail et des archives. Ils doivent rester compréhensibles pour les responsables métier.

Vérifier la chaîne de protection

La fréquence de lancement des tâches n’est qu’un paramètre. Contrôlez la réussite, la durée, le retard de transfert et la disponibilité de la destination. Une copie doit être exploitable avec les configurations, accès et clés nécessaires.

La réplication peut réduire le décalage, mais aussi propager une suppression ou une corruption. Prévoyez des états historiques et une protection adaptés aux scénarios retenus. Les mécanismes de synchronisation de fichiers ne remplacent pas à eux seuls une stratégie de récupération.

Le guide sauvegarde des données en entreprise permet de replacer ces contrôles dans un dispositif complet.

Tester un état cohérent et utilisable

Restaurez un échantillon représentatif dans un cadre maîtrisé. Vérifiez la date des données, l’ouverture de l’application et la cohérence entre éléments liés. Si une base et des documents sont restaurés à des états différents, certains dossiers peuvent rester incomplets.

  1. Identifier le point choisi et son horodatage.
  2. Restaurer les éléments nécessaires.
  3. Faire contrôler les résultats par un utilisateur métier.
  4. Mesurer l’écart avec l’objectif.
  5. Corriger la protection ou réviser l’objectif avec le responsable.

Un incident découvert tardivement peut exiger de revenir plus loin que le dernier état disponible. La profondeur de conservation et la recherche d’un état sain doivent être étudiées en complément du RPO.

Cas illustratif : une PME commerciale à Genève

Une PME pense disposer d’une copie horaire. L’examen révèle que les transferts vers la destination ont échoué depuis la veille. L’horaire prévu ne correspond donc pas au dernier point récupérable.

La société met en place le suivi des erreurs, une personne responsable et un exercice de restauration. Elle vérifie désormais un résultat de protection, en plus du planning des tâches.

Questions fréquentes

Un RPO nul est-il possible ?

Certaines architectures visent l’absence de perte pour des scénarios définis. Il faut préciser les limites, la cohérence et les événements couverts ; cela ne protège pas automatiquement de toute corruption.

Une sauvegarde quotidienne respecte-t-elle un RPO de 24 heures ?

Seulement si les points sont suffisamment récents, réussis et exploitables dans le scénario prévu. Les retards et échecs doivent être pris en compte.

Qui choisit le RPO ?

Les responsables métier expriment le besoin. L’équipe technique et les prestataires évaluent les moyens, les coûts et les résultats des tests.

Accompagner votre PME à Genève

Pixel’IT aide à définir le périmètre de sauvegarde et de récupération et à suivre son fonctionnement dans une prestation d’infogérance à Genève.

Préparer un échange avec Pixel’IT · 022 562 42 99

Sources et documentation

Documentation consultée le 28 octobre 2026. Les fonctions et conditions des services peuvent évoluer.