RTO / RPO : définition et intérêt
En cas de situation catastrophique, les systèmes d'information doivent être protégés en amont par des indicateurs d'objectifs...de pertes. De quoi se donner des délais en cas de panne.
Le RTO c'est quoi ?
Le RTO ou Recovery Time Objective, peut se traduire par la durée maximale d'interruption admissible d'une ressources informatiques. Il s'agit du temps maximal acceptable pendant lequel une brique IT (serveur, réseau, ordinateur, application) peut ne pas être fonctionnelle suite à une interruption majeure de service. Cette durée est définie à l'avance, et ce en fonction des besoins de production d'une entreprise vis-à-vis de la ressource informatique.
Dans une entreprise qui utilise un ERP pour sa production, si l'ERP vient à ne plus fonctionner, la production est bloquée, mettant en danger la pérennité de l'entreprise. Le RTO de cet ERP devra donc être extrêmement court. De même pour le CRM. En revanche, le RTO d'une application de messagerie instantanée pourra lui être beaucoup plus long, puisque ce n'est pas une application critique.
Le RPO, c'est quoi ?
RPO ou Recovery Point Objective, désigne la durée maximum d'enregistrement des données qu'il est acceptable de perdre lors d'une panne. Le fait de quantifier le RPO définit en fait les objectifs de sauvegarde, ce qui demande de connaître la volumétrie et les fenêtres de sauvegarde.
Le RTO est considéré en lien avec le RPO
Par exemple, si le RPO est défini à 24 heures et que la volumétrie est faible, alors on peut considérer que une sauvegarde complète en fin de journée suffit. En revanche, si le RPO est très faible comme c'est le cas dans les secteurs de la banque ou des télécommunications, alors plusieurs sauvegardes seront nécessaires par jour, et en fonction de la volumétrie, différentes techniques de sauvegarde seront utilisées.
Comment RTO et RPO interviennent dans un Plan de Reprise d'Activité ?
En cas d'accident, de sinistre, de panne, les entreprises prévoyantes mettent en place un PRA (Plan de Reprise d'Activité) qui permet de formaliser des processus pour assurer la reprise des activités que ce soit d'un point de vue logistique, humain, ou encore informatique. C'est dans ce contexte informatique que la définition du RTO et du RPO permet de planifier les actions à mener en cas de sinistre, mais aussi et surtout d'adopter une stratégie d'investissement informatique en vue d'une situation catastrophique.
RPO et RTO, quel lien ?
Le RTO est considéré en lien avec le RPO. Si l'on analyse les deux indicateurs ensemble, on peut déterminer le temps total d'interruption d'une ressource après un incident majeur. Ce délai va alors comprendre le temps de détection de l'incident, le temps de prise de décision du passage en mode secours, le temps de mise en oeuvre des procédures de secours et enfin le délai de contrôle et de relance de l'application ou de l'infrastructure en panne. Tous ces temps cumulés doivent être inférieurs au RTO défini au préalable.
Mais il est important de noter qu'en fonction du domaine d'activité de l'entreprise, le RTO et le RPO ne seront pas mis systématiquement en relation. Ainsi, un site internet de vente aura avant tout besoin de faire repartir son application web, et n'aura qu'un besoin relatif de faire face aux commandes perdues au moment de la panne. A l'inverse, une application SaaS de gestion de la relation client devra tendre vers un RTO faible qui devra être en ligne avec ses engagements de disponibilité de service. Des SLA visant évidemment à minimiser le RPO de ses clients.