Les notions de RPO et RTO interviennent dans un certain contexte. Pour éviter de subir des pertes de données et des pertes financières, les entreprises prévoyantes réfléchissent à ce qui pourrait se passer en cas de sinistre informatique. La mise en place d’un DRP (Disaster Recovery Plan), désigné en français plan de reprise d’activité (PRA), contribue à formaliser des processus qui permettent de reprendre rapidement les activités. Ce dispositif détermine quoi faire en termes de logistique, informatique et humain. Celles-ci favorisent l’élaboration d’une stratégie d’investissement de mesures de sécurité informatique, et aident à déterminer les actions à mettre en place dans un ordre précis lors d’une catastrophe.
Le Recovery Point Objective (RPO), ou objectif de temps de reprise, définit ce qu’il est considéré acceptable de perdre lorsqu’une entreprise subit un sinistre. C’est la durée maximale d’enregistrement des données. Cet indicateur détermine quels sont les objectifs de sauvegarde.
Par exemple, quand une entreprise fixe le RPO à 24 heures, en considérant que la volumétrie est faible, une sauvegarde complète de la base de données peut s’avérer suffisante en fin de journée pour rencontrer l’objectif de ce RPO.
Toutefois, avec un RPO très faible (de quelques minutes maximum), comme cela est généralement de mise dans des secteurs tels que les télécommunications ou les banques, d’innombrables sauvegardes devront avoir lieu au cours d’une même journée. Dépendamment de la volumétrie, diverses techniques de sauvegarde seront mises en œuvre pour rencontrer l’objectif de RPO.
Le Recovery Time Objective (RTO) ou objectif de délai de restauration est un indicateur qui concerne la durée maximale d’interruption qu’une entreprise considère acceptable. Cela correspond au laps de temps maximal, au cours duquel une ressource informatique – qu’il s’agisse d’une application, d’un ordinateur, d’un réseau ou d’un serveur – ne fonctionne plus suite à l’avènement d’une catastrophe ou d’un incident malencontreux.
L’entreprise définit à l’avance ce laps de temps admissible. Cette décision est prise en fonction de plusieurs paramètres d’analyse de risques, entre autres les besoins de production spécifiques d’une entreprise.
Par exemple, lorsque la production d’une entreprise est orchestrée dans le cadre d’un dispositif ERP (Enterprise Ressource Planning), en cas d’une défaillance conduisant des parties de l’ERP à ne plus fonctionner, cela bloque la production. Une telle entreprise aura intérêt à définir un RTO considérablement court.
Dans le cas d’une application de messagerie instantanée, le RTO peut consister en un laps de temps plus long, étant donné qu’il ne s’agit pas d’un outil critique pour la pérennité de l’entreprise.
Ces deux indicateurs permettent à l’entreprise de déterminer précisément en quoi devrait consister le temps total d’interruption d’un réseau, machine, serveur ou application après un sinistre majeur.
Une analyse doit être déployée pour parvenir à se faire une idée de ce temps total d’interruption. Plusieurs éléments doivent être pris en compte, comme le temps de détection de l’incident, le laps de temps nécessaire pour permettre la prise de décision qui conduit à un basculement en mode secours, le temps requis pour suivre et déployer des procédures précises de secours, et en dernier lieu, le délai exigé pour effectuer des contrôles et relancer l’infrastructure informatique ou application tombée en panne assurant une reprise d’activité.
D’autres facteurs influent sur les indicateurs RPO et RTO. Selon le domaine d’activité dans lequel œuvre une entreprise, il arrive qu’il ne soit pas nécessaire de mettre en relation le RTO et le RPO dans un plan de reprise d’activité.