Que sont le RTO et le RPO ?
Le RTO (Recovery Time Objective) et le RPO (Recovery Point Objective) sont deux objectifs chiffrés qui structurent la reprise après un incident. Ils traduisent en valeurs concrètes une question stratégique : combien de temps d'arrêt et combien de perte de données une activité peut-elle supporter ?
Le RTO est une durée : le délai visé entre l'interruption d'un service et son rétablissement. Le RPO est aussi une durée, mais mesurée dans l'autre sens : l'écart maximal entre la dernière sauvegarde exploitable et le moment de l'incident, c'est-à-dire les données que l'on accepte de perdre.
Pourquoi c'est important pour votre organisation
Le RTO et le RPO transforment une intention floue (« reprendre vite ») en exigences mesurables qui dimensionnent l'architecture technique et le budget. Sans eux, on investit à l'aveugle, soit trop, soit pas assez.
Ils servent aussi de contrat implicite entre l'informatique et les métiers : chacun sait ce qui est garanti pour chaque activité, et peut arbitrer en connaissance de cause entre niveau de service et coût.
Comment les utiliser
- Différencier par criticité : des cibles courtes pour les activités vitales, plus larges ailleurs.
- Aligner les sauvegardes sur le RPO : la fréquence des copies découle de la perte tolérée.
- Aligner l'infrastructure sur le RTO : redondance et bascule selon le temps d'arrêt accepté.
- Tester : vérifier que les valeurs annoncées sont réellement atteignables.
Où les organisations pèchent le plus souvent
L'erreur la plus fréquente est de définir des RTO et RPO très ambitieux sur le papier, sans jamais vérifier qu'ils sont tenables. Le jour de l'incident, l'écart entre la cible théorique et la capacité réelle de reprise se paie cher. L'autre écueil est d'appliquer les mêmes valeurs à toutes les activités, sans les différencier selon leur criticité.