PRA et PCA
Comment déterminer son RPO ?
On détermine un RPO en demandant, pour chaque activité : « si nous perdions les saisies depuis X heures, que faudrait-il refaire, et combien cela coûte-t-il ? » La plus grande valeur de X encore acceptable est le RPO. On règle ensuite la sauvegarde pour que l’intervalle entre deux copies réussies soit inférieur à ce X.
Mis à jour en octobre 20263 min de lecture4 sources citées
L’essentiel
- Posez la question aux utilisateurs de chaque outil, pas seulement à l’informaticien.
- Trois critères : vitesse de changement des données, possibilité de les reconstruire, coût de la perte.
- Un RPO de 24 heures suppose une alerte le matin : deux échecs de suite, et le RPO réel passe à 48 heures.
- Sous une heure, prévoyez réplication ou journaux de base de données, et un historique contre le ransomware.
- La profondeur d’historique (30 jours, un an) est un réglage distinct du RPO.
La méthode en une réunion
Le NIST appelle cet exercice l’analyse d’impact sur l’activité (BIA) : identifier les processus, mesurer les conséquences d’une interruption, puis fixer les priorités de reprise. Pour une PME, une réunion suffit. Pour chaque outil vital, posez trois questions aux gens qui s’en servent, pas seulement à l’informaticien.
- À quelle vitesse les données changent-elles ? Une écriture par minute, par heure, par semaine ?
- Peut-on les reconstruire ? Un mail reçu de l’extérieur, non. Une facture dont le double est encore sur le bureau du client, en partie. Une saisie de production d’atelier, non.
- Au bout de combien de temps perdu le coût devient-il inacceptable ? Coût de resaisie, commandes à repasser, dossiers à rouvrir de mémoire.
Notez la réponse en heures. Exemples fréquents en PME :
| Activité | RPO souvent raisonnable | Pourquoi |
|---|---|---|
| Fichiers bureautiques peu modifiés | 24 h | La perte d’une journée se voit et se refait |
| ERP ou logiciel de devis saisi toute la journée | 1 à 4 h | Une journée de devis perdue ne se reconstitue pas |
| Messagerie | 1 à 8 h | Les messages entrants ne sont pas ressaisissables |
| Comptabilité | 24 h, plus un archivage long à part | La journée se refait ; l’exercice, lui, s’archive |
| Base de caisse | Minutes à 1 h | L’argent encaissé doit rester tracé |
Ce tableau n’est pas une norme. C’est un point de départ pour contredire ou confirmer avec les opérationnels.
Traduire le RPO en fréquence
- RPO 24 h : une sauvegarde réussie par jour, et une alerte le matin si elle a échoué. Si elle échoue deux nuits de suite, le RPO réel devient 48 h. La surveillance fait partie du RPO.
- RPO 4 h : au moins une copie toutes les quatre heures pendant les heures ouvrées.
- RPO inférieur à une heure : réplication ou copies très fréquentes, et une discussion séparée sur le ransomware, parce que la copie la plus fraîche sera peut-être déjà mauvaise. L’ANSSI recommande d’ailleurs, quand la perte admissible est inférieure à 24 heures, d’envisager la réplication en plus de la sauvegarde.
Pour une base de données, la fréquence ne se règle pas seulement par des sauvegardes complètes. Microsoft indique qu’en mode de récupération complet, des sauvegardes fréquentes du journal de transactions permettent de restaurer à un instant précis. C’est souvent le moyen le plus économique d’obtenir un RPO de quelques minutes sur un logiciel métier.
Prévoyez aussi la profondeur : pouvoir revenir 30 jours en arrière ne change pas le RPO (qui parle de fraîcheur), mais elle sauve le cas où les dernières copies sont corrompues. L’ANSSI cite par exemple 15 jours de sauvegardes journalières, un an de mensuelles et cinq ans d’annuelles. Les deux réglages coexistent.
Vérifier que le RPO tient
Un RPO se vérifie dans la console, pas dans le contrat :
- l’heure de la dernière copie réussie de chaque serveur, chaque matin ;
- la durée des tâches : une sauvegarde qui dure cinq heures ne peut pas tourner toutes les quatre heures ;
- le volume de changements envoyé par rapport au débit montant du site ;
- un essai de restauration, au moins sur un fichier, pour prouver que la copie est lisible. Voir Comment tester qu’une sauvegarde fonctionne ?.
Erreurs
- Laisser l’éditeur du logiciel annoncer le RPO (« sauvegarde en temps réel ») sans regarder l’intervalle réel des jobs.
- Un seul RPO pour toute l’entreprise, calé sur l’application la plus bavarde, ce qui fait payer le niveau maximum pour des fichiers statiques.
- Oublier que le RPO de la messagerie cloud est celui de votre copie, pas celui de la corbeille de l’éditeur.
Chez WeDoBack
La fréquence se règle dans la console : le RPO dépend de ce choix du client. Le volume souscrit doit absorber cette fréquence, car des copies plus rapprochées retiennent plus de changements. L’ordre de grandeur publié pour démarrer est le volume actuel multiplié par trois, à ajuster après une semaine d’usage. WeDoBack n’impose pas un RPO. Si le lien du client ne peut pas envoyer les changements dans l’intervalle choisi, le RPO réel sera plus long que le RPO affiché : c’est une contrainte physique, à mesurer au premier mois, pas un détail. La surveillance des sauvegardes fonctionne 24 h/24 ; l’assistance humaine est joignable de 9 h à 13 h et de 14 h à 17 h 30 (heure de Paris). Les tarifs des offres SMART et INTEGRAL sont détaillés sur la page offres et tarifs.
Questions fréquentes
Qui doit fixer le RPO, la direction ou l’informatique ?
La direction et les responsables métier, parce que le RPO est un choix économique : combien de travail perdu l’entreprise accepte. L’informatique traduit ensuite ce choix en fréquence de sauvegarde, et signale ce qui est techniquement impossible avec le débit ou le budget disponible.
Faut-il le même RPO pour tous les serveurs ?
Non. Un RPO unique, calé sur l’application la plus active, fait payer le niveau maximal pour des fichiers qui changent peu. Une ligne par activité, avec sa fréquence, est plus juste et souvent moins chère.
Le RPO de Microsoft 365 ou de Google Workspace est-il celui de l’éditeur ?
Non. Les corbeilles et la rétention de l’éditeur ne sont pas une copie que vous maîtrisez. Le RPO de votre messagerie est celui de votre propre sauvegarde : sa fréquence et sa dernière réussite.
Sources
Documents consultés en octobre 2026.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Sauvegarde des systèmes d’information – Les fondamentaux (ANSSI-BP-100, v1.1, 27 novembre 2025) — ANSSI
- Back up and Restore of SQL Server Databases — Microsoft Learn
- Offres et tarifs de sauvegarde externalisée — WeDoBack
Un projet de sauvegarde, de PRA ou de PCA ?
Plus de 20 ans d’expérience dans la protection des données des entreprises.
Demander un devis09 72 50 78 28Protégez vos données avec WeDoBack
Sauvegarde chiffrée hors site, stockage immuable, PRA et PCA : décrivez-nous vos serveurs, nous vous proposons la bonne combinaison.
