Points clés
- Comprendre les indicateurs essentiels : le RTO (recovery time objective) définit le délai maximal acceptable pour rétablir les systèmes après une interruption, tandis que le RPO (recovery point objective) définit la perte de données maximale acceptable, mesurée en remontant depuis l’instant de la panne.
- Assumer sa propre reprise : les fournisseurs SaaS garantissent la disponibilité de la plateforme, pas la protection des données. Dans le modèle de responsabilité partagée, définir et respecter les objectifs de RTO et de RPO incombe au client, pas au fournisseur.
- Adapter les objectifs aux réalités du SaaS : en sauvegarde SaaS, le respect du RTO et du RPO dépend de la vitesse de restauration, du volume de données, du throttling des API du fournisseur et de la fréquence des sauvegardes, et non de la disponibilité d’une infrastructure sur site.
- Se protéger contre les ransomwares : les attaquants visant de plus en plus directement les copies de sauvegarde, respecter son RPO et son RTO pendant une attaque exige au moins une sauvegarde immuable, hors ligne ou isolée (air gap), conformément à la règle 3-2-1-1-0.
- Appliquer les bonnes pratiques : alignez vos objectifs sur l’impact métier, automatisez les sauvegardes, testez régulièrement la restauration, surveillez les performances et tenez compte des nouveaux périmètres comme les agents IA et Copilot, qui modifient la vitesse de circulation des données.
La planification d’un PRA (plan de reprise d’activité) repose sur des objectifs qui aident les entreprises à formaliser leurs attentes en matière de reprise. Parmi ces objectifs figurent le RTO et le RPO, qui déterminent à quelle vitesse les systèmes doivent être rétablis et quel volume de perte de données reste acceptable après un incident.
Ces notions sont largement adoptées dans les environnements informatiques traditionnels, mais les facteurs qui influencent le RTO et le RPO ne sont pas les mêmes dans les environnements SaaS. Cet article examine de plus près le rôle du RTO et du RPO dans les plateformes SaaS et les systèmes de sauvegarde. L’objectif : définir des attentes réalistes pour la sauvegarde SaaS en comprenant précisément comment ces deux indicateurs se comportent dans ce type d’environnement.
Avec la sauvegarde SaaS, le RTO et le RPO relèvent de votre responsabilité
Les fournisseurs SaaS fonctionnent selon un modèle de responsabilité partagée : le fournisseur garantit la disponibilité de la plateforme et de l’infrastructure, mais la protection des données elles-mêmes (contre une suppression accidentelle, un ransomware, une menace interne ou une migration ratée) revient au client.
Microsoft 365, Google Workspace et Salesforce déclinent tous toute responsabilité en cas de perte de données dans leurs conditions d’utilisation. C’est précisément pour cette raison que le RTO et le RPO doivent être définis et pris en charge en interne, plutôt que considérés comme couverts par le SLA (contrat de niveau de service) du fournisseur.
Ce que signifient le RTO et le RPO en sauvegarde SaaS
Le RTO et le RPO fixent tous deux des limites acceptables pour certains facteurs, avant qu’un sinistre ne survienne. Voici ce que chacun établit :
Le RPO (recovery point objective) correspond au volume maximal de données qu’une entreprise peut se permettre de perdre après un incident. Il se mesure en remontant depuis le moment de l’interruption et détermine la fréquence à laquelle les sauvegardes doivent être réalisées pour respecter la tolérance à la perte de données.
Le RTO (recovery time objective) correspond à la durée maximale pendant laquelle le système d’une entreprise peut rester indisponible avant que l’impact sur l’activité ne devienne inacceptable. Il se mesure à partir du moment de la panne et définit la rapidité avec laquelle les services doivent être remis en ligne.
Ces deux objectifs se fixent avant un sinistre : ce ne sont pas des mesures de ce qui s’est réellement produit.
| RTO | RPO | |
| Ce qu’il mesure | L’interruption de service | La perte de données |
| Sens de la mesure | À partir de la panne | En remontant avant la panne |
| Facteurs déterminants | Vitesse de restauration, volume de données, limites des API | Fréquence des sauvegardes, automatisation |
| Responsabilité | IT/exploitation | IT/exploitation + gouvernance des données |
RTO et RPO dans les environnements SaaS
Le RTO et le RPO mesurent la même chose, quel que soit l’environnement. Ce qui change avec la sauvegarde SaaS, ce sont les variables qui déterminent si ces objectifs peuvent réellement être tenus au moment d’une restauration.
- Ce qui influence le RTO en sauvegarde SaaS :
- la vitesse à laquelle les données peuvent être restaurées via le processus de restauration de la solution de sauvegarde ;
- le volume de données à récupérer, sachant que des jeux de données volumineux allongent la restauration ;
- le throttling des API imposé par le fournisseur (par exemple les limites de débit de l’API Microsoft Graph et de l’API Google Workspace), qui plafonne la vitesse de réécriture des données, quelle que soit la bande passante ou le budget dont vous disposez.
- Ce qui influence le RPO en sauvegarde SaaS :
- la fréquence des sauvegardes, qui détermine directement l’ampleur de la fenêtre de perte de données potentielle ;
- le fait que les sauvegardes soient automatisées et s’exécutent de façon régulière, sans interruption ;
- la vitesse à laquelle les données évoluent entre deux sauvegardes, pour l’ensemble des utilisateurs et des systèmes.
En quoi le SaaS modifie les attentes en matière de RTO
Dans un contexte de sauvegarde SaaS, le RTO se résume à la capacité de restaurer les données efficacement. Il dépend donc fortement des performances de restauration et du volume de données, plutôt que de la disponibilité de l’infrastructure. Les principaux facteurs qui influencent le RTO sont :
- le volume de données à restaurer ;
- la vitesse des opérations de restauration via les API ;
- les limites imposées par le fournisseur SaaS pendant la restauration des données.
En quoi le SaaS modifie les attentes en matière de RPO
De son côté, le RPO en sauvegarde SaaS dépend de la fréquence des sauvegardes et de la capture des données. Les points à prendre en compte sont notamment :
- les modifications fréquentes des données SaaS par les utilisateurs et les systèmes ;
- les intervalles de sauvegarde, qui déterminent le volume de données susceptible d’être perdu ;
- les écarts entre deux sauvegardes, qui représentent une perte de données potentielle ;
- la rétention native (une corbeille, par exemple), qui n’est pas une sauvegarde et peut être purgée par un attaquant, supprimant totalement ce point de restauration.
Améliorer son RPO revient à réduire les écarts entre les sauvegardes. Cela suppose :
- une fréquence de sauvegarde plus élevée ;
- une automatisation fiable ;
- un suivi régulier de la réussite des sauvegardes.
Influence du RTO et du RPO sur les stratégies de reprise SaaS
Le RTO et le RPO déterminent la façon dont une entreprise construit et fait évoluer sa stratégie de sauvegarde SaaS. Pour définir ces indicateurs, il faut tenir compte des éléments suivants :
- Un RPO plus serré : il exige des sauvegardes plus fréquentes, ce qui influe sur la configuration et la surveillance de la solution de sauvegarde.
- Un RTO plus serré : il suppose des capacités de restauration plus rapides, ce qui peut orienter le choix de la solution de sauvegarde et la structuration des workflows de restauration.
- Des tests réguliers : ils permettent de confirmer que les objectifs annoncés sont réellement atteignables. Tester une stratégie de sauvegarde, en conditions réelles ou simulées, aide à valider sa fiabilité.
- La hiérarchisation des systèmes : en classant les systèmes par criticité, une entreprise peut appliquer des objectifs de RTO et de RPO plus stricts aux applications prioritaires, tout en acceptant des seuils plus souples pour les moins critiques.
Les scénarios de reprise les plus courants en SaaS
Voici les situations les plus fréquentes où la récupération des données est critique, et le rôle déterminant qu’y jouent le RTO et le RPO.
Suppression accidentelle
RTO : il détermine la rapidité avec laquelle la solution de sauvegarde peut mener la restauration à son terme une fois le bon point de restauration identifié.
RPO : il détermine l’ancienneté du point de restauration disponible, ce qui fixe la limite des données récupérables.
Attaques par ransomware
RTO : il détermine la durée pendant laquelle l’activité reste perturbée pendant la restauration (une situation compliquée par le fait que les souches de ransomware actuelles recherchent activement les copies de sauvegarde accessibles pour les chiffrer ou les supprimer avant de chiffrer les données de production).
RPO : il détermine jusqu’où il faut remonter pour atteindre une sauvegarde antérieure à la compromission (ce qui n’est possible que si cette sauvegarde était immuable ou hors ligne, et donc épargnée par l’attaque).
Erreur de configuration
RTO : il détermine la rapidité avec laquelle l’activité normale peut reprendre une fois la sauvegarde appropriée sélectionnée et appliquée.
RPO : il définit le volume de données susceptible d’être perdu lors d’une restauration à un point antérieur à la modification à l’origine du problème.
Bonnes pratiques pour le RTO et le RPO en sauvegarde SaaS
Voici quelques bonnes pratiques de sauvegarde SaaS pour aider les entreprises à tenir leurs objectifs de RTO et de RPO.
- Définir le RTO et le RPO en fonction des besoins métier : évaluez les exigences de l’activité à partir de ce que la perte ou l’indisponibilité des données coûterait réellement à l’entreprise.
- Automatiser les sauvegardes pour soutenir les objectifs de RPO : l’automatisation des sauvegardes réduit les écarts et limite les risques d’exposition passés inaperçus.
- Tester régulièrement les procédures de restauration : assurez-vous que les points de restauration respectent les exigences de RPO et que les procédures permettent d’atteindre les objectifs de RTO définis.
- Surveiller les performances des sauvegardes : les échecs de sauvegarde doivent déclencher des alertes automatiques auprès des équipes IT, afin de détecter les problèmes avant qu’ils ne prennent de l’ampleur.
- Ajuster à mesure que les données augmentent : la fréquence des sauvegardes et la vitesse de restauration peuvent évoluer, notamment à mesure que le volume de données SaaS croît.
- Intégrer les agents IA et Copilot au périmètre de sauvegarde : recensez les agents Copilot, les flux Power Automate et les intégrations IA tierces actifs.
- Conserver au moins une copie de sauvegarde immuable, hors ligne ou isolée (air gap) : appliquez la règle 3-2-1-1-0, car une sauvegarde qu’un attaquant peut supprimer n’est pas un véritable point de restauration.
Idées fausses répandues sur le RTO et le RPO en SaaS
Les solutions de sauvegarde SaaS et leurs capacités font l’objet de plusieurs idées fausses. En voici quelques-unes :
« Les systèmes cloud garantissent une reprise instantanée. »
Ce n’est pas parce qu’une plateforme SaaS repose sur le cloud que la restauration des données est instantanée. Restaurer des données depuis une sauvegarde prend toujours du temps, et ce délai varie selon le volume de données à récupérer.
« Le RTO est toujours court dans les environnements SaaS. »
Plusieurs facteurs, comme un jeu de données volumineux ou des limites de débit pendant la restauration, peuvent allonger le temps de reprise. La disponibilité de la plateforme n’est pas synonyme de reprise rapide.
« Le RPO est automatiquement minimal. »
C’est l’entreprise qui configure la fréquence des sauvegardes, et cette fréquence détermine le RPO. Sans planification délibérée, le RPO peut donc être bien plus élevé que prévu, même avec une solution de sauvegarde cloud-native.
« La fréquence des sauvegardes n’a pas d’incidence sur la perte de données. »
La fréquence et l’exposition à la perte de données sont directement liées. L’intervalle entre deux sauvegardes définit exactement le volume de données en jeu si un incident survient juste avant l’exécution de la suivante.
« Les performances de restauration sont illimitées. »
Les processus de sauvegarde et de restauration ont des limites de débit. Ces limites ne disparaissent pas en situation d’urgence et doivent être intégrées dès le départ à la définition du RTO.
Bien comprendre le RTO et le RPO en sauvegarde SaaS
Le RTO et le RPO doivent être considérés comme des engagements concrets : ils déterminent la conception d’une stratégie de sauvegarde SaaS, la façon de tester les processus de restauration et le réalisme des attentes de reprise en cas d’événement imprévu affectant les données de l’entreprise. Au final, chaque entreprise doit définir son RTO et son RPO en fonction de l’impact métier réel, puis les valider par des tests réguliers.
Sujets connexes :
