RTO et RPO : fixer les bons objectifs avec la direction

Deux nombres décident de la plupart de vos choix de continuité et de leur coût : le RTO et le RPO. Pourtant, ils sont souvent fixés par défaut, côté technique, sans que la direction ait jamais arbitré ce qu’elle est prête à perdre. C’est une erreur, parce que ce sont des décisions métier avant d’être des décisions d’infrastructure. Voici comment les poser correctement.

Ce que RTO et RPO veulent dire

Les deux répondent à des questions différentes après un incident :

• RTO (Recovery Time Objective) : en combien de temps le service doit-il être de nouveau opérationnel ? C’est la durée d’interruption acceptable.
• RPO (Recovery Point Objective) : combien de données pouvez-vous vous permettre de perdre ? C’est l’écart acceptable entre le dernier point de sauvegarde et l’incident.

Un exemple rend cela concret. Un RPO de 24 heures signifie que vous acceptez de perdre jusqu’à une journée de données. Un RTO de 4 heures signifie que le service doit être rétabli en moins de quatre heures. Ce ne sont pas des paramètres techniques, ce sont des promesses faites au métier.

Pourquoi cela se décide avec la direction

Le RTO et le RPO sont des arbitrages entre risque accepté et coût. Plus vous les serrez, plus l’infrastructure coûte cher : un RPO proche de zéro demande de la réplication permanente, un RTO court demande de la haute disponibilité et de la capacité de secours prête à démarrer. À l’inverse, des objectifs lâches coûtent moins, mais exposent à une perte plus lourde.

Seule la direction peut trancher cet arbitrage, parce qu’elle seule connaît le coût d’une interruption pour l’activité : chiffre d’affaires perdu, engagements clients, impact réputationnel, obligations réglementaires. Le rôle de l’IT est d’éclairer la décision avec les coûts associés à chaque niveau d’objectif, pas de la prendre seule dans son coin.

Un objectif par criticité, pas un seul pour tout

L’erreur suivante est d’appliquer un RTO et un RPO uniques à toute l’infrastructure. Toutes les charges n’ont pas la même valeur. Classez vos applications par criticité et attribuez à chaque palier ses propres objectifs : l’ERP qui arrête l’entreprise n’a pas le même RTO qu’un serveur de test. Cela évite de surpayer pour protéger ce qui n’en a pas besoin, et de sous-protéger ce qui compte vraiment.

De l’objectif à l’architecture

Une fois les nombres posés, ils dictent les choix techniques :

• Le RPO pilote la sauvegarde : sa fréquence, et le recours éventuel à de la réplication. Un RPO de 24h se satisfait d’une sauvegarde quotidienne ; un RPO de 15 minutes impose autre chose.
• Le RTO pilote la reprise : haute disponibilité, vitesse de restauration, capacité de secours, et surtout un plan de reprise écrit et répété. Restaurer vite ne s’improvise pas le jour de l’incident.

Là où ça devient difficile

Le piège classique n’est pas de mal choisir les nombres, c’est de ne jamais vérifier qu’on les tient. Annoncer un RTO de 4 heures sans avoir jamais chronométré une restauration réelle, c’est une fiction. Le seul moyen de savoir si vous respectez vos objectifs est de tester la restauration et de mesurer le temps réel.

C’est ce que garantissent une exploitation managée et une sauvegarde testée. Notre hébergement Proxmox managé dimensionne la haute disponibilité et la capacité de reprise sur vos objectifs de RTO, et Cloud-PBS fournit des sauvegardes externalisées dont la restauration est vérifiée, ce qui transforme votre RPO et votre RTO en promesses tenues plutôt qu’en chiffres sur une diapositive.