Comment définir le RTO et le RPO de mon Plan de Reprise d’Activité ? par Anthony GALLO

Pourquoi le RTO et le RPO sont-ils réservés au PRA ?

Comme vous avez pu le comprendre dans le titre, dans cet avis, je mentionne uniquement le RTO et le RPO du Plan de Reprise d’Activité (PRA). Pourquoi ? Eh bien parce que pour le PCA (Plan de Continuité d’Activités), le RTO et le RPO sont proches de zéro. Si pour vous, l’ensemble de vos activités sont critiques et les enjeux trop importants pour absorber un arrêt, un Plan de Continuité d’Activité sera le plus adapté.

Le RTO et le RPO interviennent dans le PRA lors de la définition du périmètre de criticité de votre système d’information. Une fois les applications et activités critiques référencées, il convient de définir le RTO et le RPO pour définir les objectifs de la reprise du service.

De manière générale, ces deux notions sont un engagement avec la direction de l’entreprise. Un engagement qui prend en compte les moyens humains, financiers et techniques.

Qu’est-ce que le RTO ?

Le RTO ou Recovery Time Objective est la durée d’interruption maximale admissible. C’est le temps entre l’incident et la remise en route opérationnelle du système (serveur, réseau, applications…). Par exemple, pour un RTO de deux heures, si l’incident se produit à 9h, le système sera de nouveau opérationnel à 11h maximum.

Qu’est-ce que le RPO ?

Le RPO ou Recovery Point Objective est la perte de données maximale admissible. C’est le volume de données que vous êtes prêt à perdre entre la dernière sauvegarde et l’interruption de service. Les données comprises entre la dernière sauvegarde et l’interruption seront donc perdues.

Pour réduire au maximum le RPO, il est courant d’automatiser et de régulariser les sauvegardes. Mais des sauvegardes plus fréquentes entraînent des moyens techniques plus importants notamment sur le volume de stockage à disposition sur l’infrastructure et le réseau nécessaire.

Quelle est la différence entre les deux ?

Ce sont les notions et sollicitations qui différent entre les deux. Le RPO est généralement technique et matériel.

Le RTO, lui, implique beaucoup plus de ressources et est un plan plus large. Il sollicite toute la chaîne de l’entreprise :

• Côté technique, l’équipe réseau vérifiera que l’accès au réseau est disponible. Ensuite, l’équipe système remettra en place les serveurs et les données. Et enfin, l’équipe développement/applicatif garantira le bon fonctionnement des applications. Cette chaîne technique doit être automatisée et/ou pilotée afin d’éviter des allers-retours entre les équipes.
• Côté marketing, l’équipe communication devra prévenir les clients de l’incident et du plan d’actions prévu.
• Suivant votre entreprise, d’autres services peuvent impactés et donc sollicités.

L’organisation doit être bien définie et testée. Le RTO est ainsi beaucoup plus contrôlé.

Il est possible de créer un RTO et un RPO propre à chaque service/applicatif de l’entreprise. Chacun ayant ses propres enjeux et criticités, cette pratique peut être adaptée.

Il faut également savoir que ce n’est pas parce qu’il y a des sauvegardes régulières qu’on peut s’engager sur un RTO court. Et inversement, ce n’est pas parce que vous avez un excellent RPO que le RTO sera respecté en un claquement de doigts. Pour respecter le RTO, il faut des moyens et du temps.

Comment les calculer ?

Pour calculer le RTO et le RPO, il faut prendre en compte les potentiels impacts d’une indisponibilité. Une coupure aura deux impacts sur l’entreprise :

• Impact direct comprenant la perte du chiffre d’affaires depuis l’incident, les salaires des employés, l’infrastructure à mettre en place pour restaurer le service et les interventions des prestataires externes.
• Impact indirect comprenant l’image de marque, la réputation de l’entreprise qui pourra entraîner la perte de chiffre d’affaires sur le moyen et long terme.

Outre la notion de temps, les coûts sont très importants dans le calcul du RTO et du RPO. Plus le temps est court, plus le PRA sera onéreux. Ce calcul est un savant mélange entre vos moyens et la criticité de vos activités.

La définition du RTO RPO, s’accompagne de la définition des :

• Moyens techniques, humains, organisationnels et financiers disponibles
• Technologies et méthodologies à utiliser

Mon dernier conseil

Il est important de se poser les bonnes questions pour ne rien négliger. On se dit souvent, ce n’est pas grave si cette application ne fonctionne pas une journée. Oui, mais si vos données n’ont pas été sauvegardées depuis une semaine ? Eh bien, acceptez-vous de tout perdre ? Comment réagiront vos clients et vos collaborateurs ?

Voici une liste de questions que j’estime importantes à se poser :

• Quels sont les impacts sur la vie de mon entreprise si j’ai une interruption de service ?
• Acceptez-vous de perdre vos données ?
• Aujourd’hui, qu’avez-vous en place ?
• Avez-vous la garantie que l’existant est efficace ?
• Qu’est-ce qui se passe en cas de sinistre ?
• Quels sont mes objectifs pour pallier un sinistre ?

Autre point, n’hésitez pas à vous faire accompagner par un prestataire dont c’est le métier. Sur l’ensemble du projet ou uniquement pour une partie, il est toujours intéressant d’avoir un regard extérieur à son organisation.