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
| Notion | Question posée |
|---|---|
| RPO | À quel état de données doit-on pouvoir revenir ? |
| RTO | Dans quel délai doit-on remettre le service à disposition ? |
| Conservation | Combien 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.
- Identifier le point choisi et son horodatage.
- Restaurer les éléments nécessaires.
- Faire contrôler les résultats par un utilisateur métier.
- Mesurer l’écart avec l’objectif.
- 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.
Sources et documentation
- NIST — Définition du Recovery Point Objective
- AWS — Sauvegarde, réplication et points de récupération
Documentation consultée le 28 octobre 2026. Les fonctions et conditions des services peuvent évoluer.