RTO / RPO Objectifs de délai de reprise et de point de reprise.

Deux horloges qui mesurent des choses différentes

Le RTO et le RPO sont les deux objectifs de reprise qui transforment une vague promesse de résilience en chiffres vérifiables. Ils sont faciles à confondre parce qu'ils s'expriment tous deux en unités de temps, mais ils mesurent des choses différentes et orientent vers des solutions différentes. Le recovery time objective concerne la durée pendant laquelle vous pouvez rester à l'arrêt. Le recovery point objective concerne le volume de données que vous pouvez vous permettre de perdre. Confondez-les et vous achèterez la mauvaise architecture de reprise.

Imaginez la perturbation comme un instant unique sur une ligne de temps. Le RTO regarde vers l'avant à partir de cet instant : c'est la fenêtre maximale entre la panne et le moment où le processus redevient utilisable, avant que le préjudice ne devienne inacceptable. Le RPO regarde vers l'arrière à partir de cet instant : c'est l'âge maximal de la dernière copie valide des données à laquelle vous pouvez revenir, ce qui équivaut au volume de données le plus récent que vous acceptez de perdre. Un RTO de quatre heures avec un RPO de quinze minutes signifie que le service doit être rétabli en moins de quatre heures et ne peut pas perdre plus de quinze minutes de transactions.

D'où viennent les chiffres, et pourquoi la responsabilité compte

Les deux objectifs sont des résultats de l'analyse d'impact sur l'activité, et non des estimations faites dans la salle des serveurs. Le BIA étudie chaque activité critique, mesure comment le préjudice d'une panne croît dans le temps, et produit des objectifs de reprise que le propriétaire du processus valide. Cette responsabilité est précisément l'enjeu. Un RTO et un RPO qu'une équipe technique fixe de façon isolée décrivent ce que l'infrastructure peut faire, et non ce dont l'activité a besoin ; l'écart entre les deux ne se révèle que lors d'un incident réel, qui est le pire moment pour le découvrir.

Les objectifs doivent aussi être conciliés avec le coût. Faire tendre un RPO vers zéro implique une réplication continue ou synchrone. Faire tendre un RTO vers quelques minutes implique une capacité de secours à chaud qui reste inactive. Les deux sont coûteux, donc le BIA impose une conversation honnête sur les processus qui justifient réellement cette dépense et ceux qui peuvent tolérer une fenêtre plus longue. Hiérarchiser les activités est normal : le moteur de paiement et le site marketing méritent rarement les mêmes objectifs.

Comment le RTO et le RPO s'inscrivent dans les normes

Ces objectifs constituent un vocabulaire central des cadres de continuité et de résilience. ISO 22301, la norme internationale pour les systèmes de management de la continuité d'activité, traite les recovery time et recovery point objectives comme des résultats de l'analyse d'impact qui orientent la stratégie et les solutions de continuité. Ils alimentent directement la conception de la reprise après sinistre, les calendriers de sauvegarde et le choix des sites de reprise. Dans les secteurs réglementés, ils sont de plus en plus examinés plutôt que présumés : le règlement européen DORA fixe des attentes de continuité et de test pour les entités financières, et la directive NIS 2 exige des mesures de continuité d'activité et de sauvegarde de la part des entités essentielles et importantes.

Les praticiens font trois choses avec ces chiffres. Ils les dérivent du BIA avec les propriétaires métier. Ils conçoivent la sauvegarde, la réplication et la bascule pour que l'architecture puisse réellement les respecter. Puis ils le prouvent par des tests, car un RTO non testé n'est qu'une aspiration. L'objectif ne gagne la confiance qu'une fois qu'un exercice de reprise a montré que l'équipe peut l'atteindre dans des conditions réalistes.