Nous arrivons à la moitié de notre série !
Si vous avez bien suivi les précédents articles, vous devriez désormais avoir une bonne cartographie de votre infrastructure IT, de votre activité et des risques que votre ieprise encoure. Pour rappel, vous pouvez retrouver des fiches de récapitulatif d’avancement dans notre livre blanc 15 fiches méthodologiques pour mettre en place son PCA/PRA.
Maintenant que vous avez la vue d’ensemble, il est temps de définir les objectifs des vos plans.
⏱️ Les notions de RTO et RPO : différences et applications
Le RTO (Recovery Time Objective)
RTO est l’acronyme de Recovery Time Objective. On entend par RTO l’objectif de temps maximal acceptable pour rétablir un service, une application ou un processus métier après un incident. Plus concrètement, il s’agit de répondre à la question : « pendant combien de temps peut-on tolérer l’absence ou le fonctionnement dégradé de cet équipement ? ».
Le RTO ne correspond pas à la durée maximale : ça, c’est le Maximum Tolerable Downtime (MTD). Le MTD est le maximum, le RTO est l’objectif que vous vous fixez (forcément inférieur au MTD).
Imaginons que votre entreprise puisse fonctionner pendant 1 mois avec un processus de prise de commande défaillant avant que cela n’impacte gravement l’activité. Si vous décidez que cette durée ne peut pas excéder 2 semaines par sécurité, alors votre MTD est d’1 mois, et votre RTO est de 2 semaines.
Attention ! Le RTO est un objectif de reprise technique. Le « retour à la normale », aussi appelé Work Recovery Time (WRT), peut être plus long. En effet, redémarrer un serveur ou restaurer une application ne signifie pas forcément que l’activité est immédiatement opérationnelle. Certaines opérations de vérification et de remise en route peuvent prendre plusieurs heures, pendant lesquelles l’activité sera en service dégradé. La durée totale de l’interruption sera donc RTO + WRT (qui peut varier selon les conséquences du sinistre). Idéalement, ce total doit rester inférieur au MTD, avec une marge de sécurité.
Le RPO (Recovery Point Objective)
RPO est l’acronyme de Recovery Point Objective. Il s’agit de la quantité maximale de données que l’entreprise accepte de perdre en cas de sinistre. Dans un environnement basé sur des sauvegardes périodiques, le RPO correspond généralement à l’intervalle entre deux sauvegardes. Plus concrètement, il s’agit de répondre à la question : « Combien de temps en arrière accepte-t-on de revenir en cas de sinistre ? ». Encore une fois, le RPO n’est pas la quantité maximale de données que vous pouvez perdre sans conséquences critiques, mais celle que vous acceptez de perdre.
Imaginons que, techniquement, votre entreprise puisse survivre même en ayant perdu 15 jours de données de travail suite à un sinistre. Si vous décidez toutefois qu’il n’est pas acceptable de perdre plus d’une journée, alors votre RPO est de +/- 24h.
Exemple concret
Prenons pour exemple une société recevant 6 commandes par heure. Pour ce processus, le RTO a été fixé à 8 heures et le RPO à 4 heures. C’est-à-dire que l’entreprise a mis en place des solutions pour assurer qu’en cas de sinistre, le processus de prise de commande serait rétabli en 8h ou moins, et que sauvegardes des commandes sont effectuées toutes les 4h (à minuit, 4h, 8h, 12h, 16h et 20h). Un incident survient, entraînant la perte de toutes les commandes et l’arrêt du processus de prise de commandes.
| Heure de l’incident | Commandes perdues | Heure de retour à la normale |
| 14h00 | Remontée de la sauvegarde de 12h : 2h perdues, soit environ 12 commandes | 22h00 |
| 15h40 | Remontée de la sauvegarde de 12h : 3h40 perdues, soit environ 22 commandes | 23h40 |
| 16h10 | Remontée de la sauvegarde de 16h : 10min perdues, soit environ 1 commande | 00h10 |
Avec un RPO de 4h, l’entreprise s’assure de ne pas perdre plus de 24 commandes déjà passées. Avec un RTO de 8h, et dans le cas où aucune commande ne peut être enregistrée pendant l’interruption, l’entreprise limite son manque à gagner à 48 commandes.
⚠️ Les erreurs fréquentes sur le RPO et le RTO
Avant de voir comment calculer nos RTO et RPO, faisons un tour rapide de quelques idées reçues.
« On a une sauvegarde toutes les 2h, c’est bon »
Oui… et non ! Les sauvegardes permettent principalement de répondre au RPO. Et avoir des sauvegardes ne garantit pas qu’elles pourront être restaurées, et surtout restaurées rapidement ! Il est possible selon la quantité de données perdues, que la restauration prenne plusieurs jours voire plusieurs semaines. Et si le sinistre a également impacté vos serveurs, il faudra peut-être les remplacer avant même d’envisager restaurer vos données.
On peut ainsi se retrouver avec un très bon RPO, et un RTO terrible. Et au final, n’avoir perdu que 2h de travail, mais ne pouvoir les récupérer que dans 15 jours, ça n’est très efficace non plus… Il sera donc crucial d’intégrer le temps de restauration dans vos objectifs de reprise lorsque nous passerons au choix des solutions (cf. article 8).
« Objectifs RTO RPO à zéro »
Sur le papier, personne ne souhaite perdre de données ou subir une interruption de service. Mais atteindre un RTO ou un RPO proche de zéro nécessite généralement :
- une infrastructure redondée ;
- de la réplication en temps réel ;
- plusieurs sites d’hébergement ;
- des procédures de bascule automatisées ;
- des tests réguliers.
Le coût peut rapidement devenir disproportionné par rapport aux enjeux métier. D’autant plus si vous fixez les mêmes objectifs à l’ensemble de votre SI. Tous les services n’ont pas la même criticité, et peu d’entre eux nécessitent réellement des RTO et RPO aussi faibles. Définissez des objectifs réalistes, en fonction des impacts financiers et opérationnels de leur interruption.
« Concernant les services Cloud, le prestataire est responsable des RTO et RPO, pas moi »
Les RTO et RPO sont avant tout des exigences métier. Le fournisseur Cloud peut proposer certains niveaux de service, mais il ne connaît pas les conséquences d’une interruption sur votre activité.
Prenons par exemple un ERP SaaS hébergé chez un fournisseur garantissant une reprise en 24 heures. Si votre activité nécessite une reprise en moins de 4 heures, même si le prestataire respecte ses engagements contractuels, votre besoin métier n’est pas couvert. De la même manière, un fournisseur peut assurer la disponibilité de sa plateforme, mais pas la restauration de données supprimées par erreur, ou ne conserver les données que pendant une durée limitée.
Le Cloud transfère certaines responsabilités techniques, mais pas la responsabilité de la continuité d’activité. C’est donc à chaque entreprise de déterminer ses RTO et RPO métier, puis de vérifier que les engagements du prestataire permettent réellement de les atteindre.
💡 Pour avoir une meilleure visibilité sur vos données dans le Cloud, vous pouvez distribuer aux différents services de votre entreprise ce Guide des bonnes questions à poser à son prestataire Cloud.
⚙️ Mise en pratique : Comment définir des objectifs cohérents ?
Calcul des RTO
Un bon RTO ou un bon RPO n’est pas le plus faible possible : c’est celui qui permet de protéger efficacement l’activité tout en restant cohérent avec les moyens de l’entreprise. La tentation est souvent de fixer arbitrairement des objectifs de reprise. Pourtant, dans une démarche PCA/PRA, les RTO et RPO doivent découler directement des besoins métiers identifiés lors des étapes précédentes.
Avec les articles 3 (besoins de continuité) et 6 (mesure des conséquences), vous avez déterminé quels processus seraient impactés par la défaillance de chaque élément de votre infrastructure, et la durée maximale pendant laquelle votre entreprise pouvait tolérer le fonctionnement dégradé ou l’arrêt total de ces processus.
En croisant ces données, vous pourrez ainsi déterminer pour chaque équipement la tolérance maximale acceptable par votre entreprise en arrêt total et en fonctionnement dégradé. A vous ensuite de déterminer le RTO avec une marge de sécurité suffisante (la somme RTO + WRT doit être inférieure au MTD).
Définition des RPO
Là, c’est un peu plus délicat. On pourrait se dire qu’une fréquence de sauvegarde très élevée suffit à résoudre le problème. Mais cela en soulève un autre : le prix. Il peut varier drastiquement selon les supports et les types de sauvegarde (miroir, totale, complète, incrémentielle, différentielle, synthétique full…), ainsi que les options (copie hors-ligne, immutabilité).
💡 Si vous voulez en savoir plus sur la sauvegarde, découvrez notre livre blanc dédié La sauvegarde : coeur du Plan de Reprise d’Activité.
Pour déterminer le RPO d’un type de données, appuyez vous sur 4 éléments :
- Sa criticité
- Les obligations de conservation réglementaires
- La fréquence à laquelle il est modifié
- La difficulté à reconstituer l’information en cas de perte
En pratique, plus une donnée est critique, fréquemment modifiée et difficile à reconstituer, plus son RPO devra être faible. À l’inverse, certaines données peu évolutives ou facilement reconstituables peuvent supporter un RPO plus important sans impact significatif sur l’activité.
Prenons pour exemple le stockage des feuilles de paie. Ces données sont critiques (données personnelles) et l’entreprise a l’obligation légale de les conserver. Pour autant, ce stockage n’est mis à jour qu’une seule fois par mois en période de paie. Une sauvegarde immédiatement après la génération et le dépôt des nouvelles fiches de paie permet généralement de couvrir le principal risque de perte de données lié à ce processus. Entre deux cycles de paie, les modifications étant rares, un RPO très faible n’apporte pas forcément de bénéfice supplémentaire. En revanche, un RPO adapté ne dispense pas de mettre en place des mesures de protection appropriées. Il faudra notamment s’assurer que la solution de stockage est correctement sécurisée et protégée contre la suppression accidentelle, les erreurs humaines ou les cyberattaques
À l’inverse, une base de commandes e-commerce recevant plusieurs centaines de transactions par heure nécessitera généralement un RPO beaucoup plus faible. Perdre plusieurs heures de données pourrait représenter une perte financière importante et entraîner des difficultés de facturation ou de suivi des commandes.
En conclusion
Comme pour le RTO, il n’existe pas de « bon » RPO universel. Définir ses RTO et RPO ne consiste pas à choisir des chiffres au hasard ou à viser systématiquement le zéro interruption. Le bon RPO est celui qui permet de protéger efficacement les données critiques sans mettre en place une infrastructure disproportionnée par rapport aux besoins réels de l’entreprise. Dans le prochain article, nous verrons comment traduire ces objectifs en solutions techniques concrètes afin de construire un PRA capable de répondre efficacement aux différents scénarios de sinistre.
⏮️ Retournez au 1er article de la série.
◀️ Retrouvez ici le 6ème article de cette série sur la mesure des risques et leurs conséquences.
Retrouvez ici le 8ème article de cette série sur le choix des solutions techniques pour atteindre vos objectifs. ▶️