RTO et RPO : comprendre et fixer vos objectifs de reprise

Combien de temps votre organisation peut-elle rester à l’arrêt ? Et combien d’heures de travail peut-elle accepter de perdre ? Tant que ces deux questions n’ont pas de réponse chiffrée, votre plan de reprise repose sur de l’improvisation.

Le RTO et le RPO sont les deux chiffres qui transforment une intention de continuité en engagement mesurable. Ils conditionnent l’architecture de votre sauvegarde, son coût, et ce que vous pouvez réellement promettre à votre direction, vos usagers ou vos clients.

Définitions, différences, méthode : voici comment fixer des objectifs tenables.

RPO : la perte de données maximale acceptable

Le RPO (Recovery Point Objective) désigne l’ancienneté maximale des données que vous acceptez de perdre entre la dernière sauvegarde exploitable et l’incident. On le traduit en français par « point de reprise » ou « perte de données maximale admissible ».

Concrètement : avec un RPO de 24 heures, une sauvegarde quotidienne suffit, et vous acceptez de perdre jusqu’à une journée de travail. Avec un RPO de 15 minutes, il vous faut des sauvegardes incrémentales très fréquentes, voire une réplication quasi continue. Chaque réduction du RPO augmente les exigences techniques, donc, parfois, le coût.

RTO : le délai maximal de reprise

Le RTO (Recovery Time Objective) désigne la durée maximale acceptable entre l’incident et la remise en service effective. Il ne couvre pas seulement la restauration technique : il inclut la détection, la décision, la restauration, puis la vérification que les services fonctionnent.

Un RTO de 4 heures sur la messagerie signifie que vos équipes doivent être capables de détecter l’incident, de décider de la bascule, de restaurer et de vérifier le service en moins de 4 heures. Si la seule restauration des données en prend 6, l’objectif est intenable, quel que soit le document qui l’affiche.

RTO vs RPO : la différence en une phrase

Le RPO regarde en arrière : ce que vous acceptez de perdre. Le RTO regarde en avant : le temps que vous vous donnez pour redémarrer.

Exemple : un service avec un RPO de 4 heures et un RTO de 8 heures signifie qu’après un incident survenu à 16 h, vous repartez au plus tard à minuit, sur des données datant au plus tôt de midi. Si ce scénario est inacceptable pour la paie, la facturation ou l’état civil, vos objectifs sont mal calibrés.

Comment fixer vos RTO et RPO : la méthode

Par application, jamais globalement. Un RTO unique pour tout le système d’information est soit hors de prix, soit faux. Classez vos services par criticité : ceux dont l’arrêt bloque l’activité ou crée une obligation légale (paie, facturation, état civil pour une collectivité), ceux qui tolèrent quelques heures, ceux qui peuvent attendre plusieurs jours.

Par le coût d’indisponibilité. Pour chaque service critique, estimez ce que coûte une heure ou une journée d’arrêt : production perdue, pénalités, service public interrompu, image. Le bon RTO est celui où le coût de l’arrêt devient supérieur au coût de la protection. Cet arbitrage appartient à la direction, pas à l’équipe informatique seule.

Par scénario. Panne matérielle, erreur humaine, sinistre sur un site, cyberattaque. Le scénario dimensionnant est presque toujours le rançongiciel : les sauvegardes sont attaquées en premier, précisément pour rendre vos RTO et RPO impossibles à tenir. Des objectifs qui ne survivent pas à la compromission du système d’information ne sont pas des objectifs, ce sont des hypothèses optimistes.

Par le test. Un RTO jamais mesuré en conditions réelles n’engage personne. Chronométrez une restauration complète : c’est la seule façon de savoir si vos chiffres sont des engagements ou des slogans.

Ce que vos objectifs exigent de votre sauvegarde

Un RPO court exige des sauvegardes fréquentes, donc une architecture qui absorbe des incréments rapprochés sans saturer. Un RTO court exige une restauration granulaire ou complète, testée, sans dépendre de la disponibilité d’un tiers. Et les deux exigent une condition préalable : que vos sauvegardes existent encore le jour de l’incident. C’est le rôle d’une sauvegarde immuable, isolée du système d’information de production, avec une sauvegarde externalisée.

Le coffre de sauvegarde distribué DATIS ne fixe pas vos objectifs à votre place. Il se raccorde comme cible de stockage sous votre logiciel de sauvegarde (Veeam, Commvault, NetBackup, solutions compatibles S3/SMB/NFS) et rend vos engagements tenables : incrément perpétuel pour réduire la perte de données, immuabilité ZFS, chiffrement avant distribution, redondance géodistribuée sans datacenter. Vous définissez vos objectifs. DATIS crée les conditions pour les honorer.

Pour la place de la sauvegarde dans l’ensemble du dispositif de reprise, voir notre article PRA et PCA : le socle technique sans lequel rien ne tient.

RTO, RPO et réglementation

La directive NIS2 impose aux entités de son périmètre de documenter et de tester leur continuité d’activité : des objectifs de reprise explicites en sont le préalable. Le règlement DORA fait de même pour le secteur financier. Et le RGPD (article 32) exige la capacité à rétablir la disponibilité des données à caractère personnel et l’accès à celles-ci « dans des délais appropriés » après un incident. Dans les trois cas, des RTO et RPO documentés et testés sont la preuve attendue.