RTO et RPO : poser les bonnes questions métier avant l’architecture

Deux objectifs qui ne mesurent pas la même chose

Le RTO (Recovery Time Objective) exprime une durée cible de reprise après une interruption. Le RPO (Recovery Point Objective) exprime une perte de données maximale acceptable, mesurée en temps. On peut avoir un RTO court et un RPO long, ou l’inverse : ce sont deux curseurs indépendants.

Ce sont des objectifs à définir puis à tester. Les saisir dans un outil ne prouve pas que votre système sait les respecter : tant qu’un exercice n’a pas eu lieu, ce sont des intentions.

Raisonner service par service

La prise de commandes, un intranet documentaire et un outil de reporting n’ont pas la même criticité. Appliquer un RTO unique à tout le système revient à surpayer la moitié du périmètre et à sous-protéger l’autre.

Pour chaque service, interrogez les équipes sur trois points : la durée d’interruption réellement supportable, les conséquences opérationnelles au-delà, et les données qui devraient être ressaisies. La troisième question est celle qui révèle le vrai RPO — souvent bien plus court que ce que l’infrastructure prévoit.

Cartographier les dépendances avant de promettre

Une application dépend d’une base de données, d’un système d’identité, du réseau, parfois de services tiers. Le plan de reprise doit intégrer ces dépendances et un ordre de remise en service : redémarrer un serveur ne suffit pas à rétablir un parcours métier.

1. Lister les composants dont dépend le service, y compris les fournisseurs externes.
2. Identifier ceux que vous ne contrôlez pas : leur RTO devient un plancher pour le vôtre.
3. Définir l’ordre de redémarrage et les vérifications entre chaque étape.
4. Nommer les personnes nécessaires — et prévoir leur absence.

Tester la restauration, pas seulement la sauvegarde

Un exercice vérifie les accès, les sauvegardes, les procédures et le fonctionnement métier après restauration. Consignez le temps observé, les difficultés rencontrées et les écarts aux objectifs : c’est ce document qui rend la discussion budgétaire concrète.

Les surprises viennent rarement des données elles-mêmes. Elles viennent des accès expirés, d’une procédure écrite pour une version antérieure, d’un secret stocké uniquement sur la machine perdue, ou d’une personne indisponible.

Formaliser, puis réexaminer

Faites valider les objectifs par les responsables métier et techniques. Précisez le périmètre, les hypothèses retenues, les responsabilités et la fréquence de réévaluation. Un changement d’architecture, de volumétrie ou de prestataire peut invalider un RTO tenu l’an dernier.

Un objectif de reprise n’a de valeur que rapproché des moyens réellement financés : sans cela, c’est une ligne rassurante dans un document que personne ne relira.