En cas d’incident majeur, une entreprise doit pouvoir reprendre rapidement ses activités et restaurer ses données avec un minimum de pertes. Deux indicateurs structurent cette capacité de résilience : le RTO (Recovery Time Objective), qui fixe le temps maximal d’interruption toléré, et le RPO (Recovery Point Objective), qui détermine la quantité de données qu’il est acceptable de perdre. Souvent confondus, ils répondent pourtant à des enjeux différents et complémentaires. Découvrez le rôle de ces deux indicateurs en cybersécurité, et la méthode pour les calculer, les optimiser et les maintenir dans le temps.
RTO et RPO : définitions et rôle en cybersécurité
RPO (Recovery Point Objective) : signification
Le Recovery Point Objective, ou RPO, exprime la quantité maximale de données qu’une entreprise peut se permettre de perdre entre deux sauvegardes. En France, l’ANSSI emploie le terme PDMA (Perte de Données Maximale Admissible). Cette valeur dépend directement de la fréquence des sauvegardes ou des mécanismes de réplication. Plus le RPO est bas, plus les sauvegardes doivent être rapprochées.
Par exemple, une sauvegarde planifiée toutes les quatre heures fixe un RPO de quatre heures ; si un incident survient, toutes les données créées dans cet intervalle sont potentiellement perdues.
RTO (Recovery Time Objective) : définition
Le Recovery Time Objective, ou RTO, correspond quant à lui à la durée maximale d’interruption admissible avant le rétablissement complet des services critiques. L’ANSSI parle de DMIA (Durée Maximale d’Interruption Admissible) dans son Guide de Sauvegarde des Systèmes d’Information1. Ce paramètre détermine le temps disponible pour restaurer l’activité après un sinistre.
Par exemple, un RTO de deux heures signifie que, même après une panne majeure, les services critiques doivent être rétablis dans ce délai.
RTP vs RPO : comprendre la différence
Deux objectifs complémentaires mais distincts
Le RTO et le RPO sont deux piliers de la continuité d’activité et de la cybersécurité en entreprise. Bien qu’étroitement liés, ils ne mesurent pas la même chose et doivent être définis séparément pour bâtir une stratégie de reprise fiable.
- Le RPO marque le point de restauration des données en amont de l’événement, c’est-à-dire l’instant le plus récent auquel il est possible de revenir sans perte inacceptable.
- Le RTO indique le délai maximal accordé pour remettre en service les applications critiques après l’événement.
Sur une chronologie, le RPO correspond donc au dernier point de sauvegarde exploitable avant l’incident, tandis que le RTO fixe la limite temporelle à laquelle l’ensemble des services doit être rétabli.
|
Critère de comparaison |
RPO |
RTO |
|---|---|---|
|
Objet mesuré |
Quantité maximale de données pouvant être perdue |
Durée maximale d’interruption admissible |
|
Objectif principal |
Préserver l’intégrité des informations |
Garantir la disponibilité des services |
|
Facteurs de calcul |
Volume et fréquence de création de données, criticité métier, exigences de sauvegarde |
Coût d’un arrêt, dépendances techniques, capacité de basculement (PRA/PCA) |
|
Moyens techniques pour l’atteindre |
Sauvegardes fréquentes, réplication synchrone ou asynchrone, stockage immuable |
Infrastructure redondante, automatisation du PRA, orchestration des services |
|
Impact financier direct |
Pertes de données monétisables (transactions, commandes, données sensibles) |
Pertes d’exploitation (chiffre d’affaires, pénalités contractuelles, atteinte à l’image) |
|
Exigences réglementaires |
RGPD, NIS2, obligations de conservation ou de protection des données |
NIS2, DORA, ISO 27001, engagements de continuité de service |
|
Exemple concret |
RPO de 15 min pour une base de commandes |
RTO de 2 h pour une plateforme e-commerce |
En associant ces deux indicateurs, une organisation détermine à la fois la quantité de données qu’elle accepte de perdre et le temps dont elle dispose pour revenir à un fonctionnement normal.
C’est ce couple, qui permet de dimensionner un PRA ou un PCA en fonction des risques réels.
L'importance des RTO et RPO pour la reprise après incident
Continuité d'activité et réduction du risque cyber
Lorsqu’un datacenter tombe en panne ou qu’une attaque par ransomware bloque les systèmes, le temps joue contre l’organisation.
Sans objectifs RTO et RPO clairement définis, les pertes financières s’accumulent, la production s’interrompt et la réputation se dégrade. Ces deux paramètres sont la colonne vertébrale des Plans de Reprise d’Activité (PRA) et Plans de Continuité d’Activité (PCA). Ils orientent la hiérarchisation des priorités et la mobilisation des ressources humaines et techniques nécessaires pour redémarrer les services dans les délais attendus.
Pour tout savoir sur les différents plans de résilience et la continuité d’activité, découvrez notre article : PRA, PRI, PCA, PCI : définition, différences et application.
Répondre aux obligations réglementaires et contractuelles
Au-delà de l’intérêt opérationnel, plusieurs textes imposent de documenter et de tester les objectifs de reprise.
La directive NIS2 exige que les opérateurs de services essentiels et les entités importantes garantissent la disponibilité et la résilience de leurs systèmes d’information. Cela implique de définir, chiffrer et mettre à jour les délais de reprise de leurs services critiques, ainsi que de prouver, par des tests réguliers, la capacité à atteindre ces objectifs.
Dans le secteur financier, le règlement DORA (Digital Operational Resilience Act) va plus loin : il impose non seulement de fixer des valeurs RTO et RPO adaptées au risque, mais aussi de démontrer régulièrement, via des exercices pratiques, que les plans de continuité et de reprise sont réellement capables de les tenir. Les institutions doivent conserver la trace de ces tests pour être en mesure de les présenter aux autorités de contrôle.
La norme ISO 27001, pour sa part, intègre le RTO et le RPO dans le Système de Management de la Sécurité de l’Information. Elle requiert que ces objectifs soient cohérents avec l’analyse d’impact métier (BIA), validés par la direction et revus après tout changement majeur de l’infrastructure ou du périmètre d’activité.
Enfin, les SLA (Service Level Agreements) conclus avec les clients, partenaires ou prestataires, incluent fréquemment des engagements chiffrés de disponibilité et de reprise. Ces clauses rendent l’entreprise juridiquement responsable en cas de non-respect, exposant à des pénalités financières ou à des litiges contractuels.
Méthode pour définir les valeurs de RTO et RPO en fonction du risque cyber
1. Cartographier les applications et évaluer leur criticité
La première étape pour définir les valeurs de RTO et RPO en fonction du risque cyber consiste à recenser l’ensemble des processus métiers critiques : ERP, CRM, plateformes de paiement, messagerie, bases de données, applications de production ou d’analyse.
Chaque service doit être évalué selon l’impact financier, juridique et opérationnel qu’entraînerait une interruption prolongée. Cette analyse identifie les applications qui supportent la continuité du chiffre d’affaires ou la protection de données sensibles.
Il est également indispensable de déterminer les dépendances techniques : infrastructures réseau, serveurs d’authentification, bases partagées ou systèmes de sauvegarde.
Cette cartographie permet de hiérarchiser les priorités de reprise : par exemple, un site e-commerce ou une chaîne de production automatisée seront placés dans les niveaux les plus critiques, devant des services internes moins sensibles.
2. Calculer le RPO (Recovery Point Objective)
Le RPO découle de la fréquence de modification des données et de leur importance pour l’activité. L’évaluation s’appuie sur des indicateurs comme le nombre de transactions par minute, les volumes d’écritures ou la valeur unitaire des données créées.
Pour chaque application critique, la perte de données maximale admissible (PDMA) doit être chiffrée. Cette PDMA se convertit ensuite en fréquence de sauvegarde ou de réplication.
Quelques exemples illustrent ces ordres de grandeur :
- Une plateforme de paiement nécessitera un RPO de l’ordre de cinq minutes, afin de ne pas perdre de transactions.
- Un intranet interne pourra se contenter d’une sauvegarde toutes les heures.
Cette étape permet d’arbitrer entre coûts techniques (sauvegardes continues, réplication synchrone) et tolérance métier.
3. Calculer le RTO (Recovery Time Objective)
Le calcul du RTO consiste à évaluer la durée d’interruption acceptable pour chaque service. L’analyse combine plusieurs paramètres : coût d’un arrêt en termes de chiffre d’affaires, éventuelles pénalités contractuelles, atteinte à la réputation et exigences réglementaires.
Il s’agit aussi d’identifier les ressources nécessaires à la reprise : infrastructures de secours, licences logicielles, équipes disponibles, prestataires externes. L’ensemble détermine la DMIA (Durée Maximale d’Interruption Admissible).
Par exemple :
- Un front e-commerce peut nécessiter un RTO de trente minutes pour éviter une perte importante de ventes.
- Une application RH supportera généralement un délai de reprise d’au moins quatre heures.
4. Valider les objectifs par des tests PRA
Une fois les objectifs fixés, ils doivent être confrontés à la réalité opérationnelle.
Les exercices PRA, planifiés ou inopinés, simulent des pannes ou des cyberattaques pour vérifier que les RTO et RPO peuvent effectivement être atteints.
Les écarts entre les valeurs théoriques et les résultats observés sont ensuite analysés pour ajuster les procédures, qu’il s’agisse de sauvegardes trop lentes, de dépendances non documentées ou d’une orchestration défaillante.
Les conclusions de ces tests alimentent le Système de Management de la Sécurité de l’Information (SMSI) et constituent ensuite une preuve de conformité en cas d’audit.
Comment optimiser et maintenir vos RTO et RPO dans la durée ?
Renforcer l'infrastructure et la stratégie de sauvegarde
La robustesse de l’architecture de sauvegarde joue un rôle clef dans l’optimisation des RTO et RPO.
Il convient de choisir une combinaison adaptée entre sauvegardes complètes, incrémentielles, différentielles et continues, en fonction du volume de données et des délais de restauration attendus.
La mise en place d’une réplication synchrone, qui écrit les données simultanément sur plusieurs sites, permet de viser un RPO proche de zéro.
La réplication asynchrone, moins coûteuse, reste appropriée lorsque quelques minutes de perte de données sont acceptables.
Des sites de secours viennent compléter le dispositif. En configuration cluster actif/actif, ils prennent automatiquement le relais sans interruption visible. En actif/passif, ils nécessitent un basculement manuel ou semi-automatisé mais réduisent tout de même considérablement le RTO.
Enfin, des tests réguliers de restauration sont indispensables pour vérifier l’intégrité des sauvegardes et la fiabilité de la stratégie.
Le saviez-vous ?
La mise en œuvre d’une solution de sauvegarde chiffrée externalisée comme LockFiles renforce encore cette résilience. Grâce au chiffrement, à l’immutabilité des données et à un hébergement hors site, LockFiles garantit la protection des informations critiques tout en facilitant leur intégration dans un PRA ou un PCA.
Automatiser et orchestrer les reprises
L’automatisation constitue un facteur déterminant pour abaisser le RTO.
Des playbooks PRA/PCA permettent de déclencher automatiquement les procédures de basculement dès la détection d’un incident.
Des outils d’orchestration comme Ansible ou Terraform coordonnent la reconstruction des serveurs, des bases de données et des applications, tout en centralisant le pilotage et les alertes dans une console unique.
Des simulations complètes planifiées à intervalles réguliers garantissent que cette automatisation reste performante et détectent d’éventuelles faiblesses avant qu’un incident réel ne survienne.
Contrôler et réviser régulièrement les objectifs
Les objectifs RTO et RPO ne sont jamais figés. Une revue périodique, au minimum annuelle, permet de vérifier leur pertinence.
Chaque changement majeur (migration vers le cloud, refonte du réseau, déploiement d’un nouvel ERP…) doit déclencher une réévaluation immédiate.
Les documents de référence (PRA, PCA, SLA internes) doivent être mis à jour pour refléter ces ajustements et maintenir la conformité réglementaire et contractuelle.
Renforcer la gouvernance et impliquer les métiers
La réussite d’une stratégie RTO/RPO repose sur une gouvernance claire. C’est pourquoi la direction des systèmes d’information, le RSSI et les responsables métiers doivent participer activement au suivi continu !
Un comité PRA/PCA peut être institué pour valider les ajustements et garantir que les budgets et responsabilités évoluent en cohérence avec les besoins.
Enfin, la formation régulière des équipes opérationnelles limite le risque d’erreurs humaines lors d’un sinistre et assure une réactivité optimale, pour un RTO et RPO conformes aux objectifs fixés.
Sources :
.png?width=700&name=Related%20content%20-%20Role%20Based%20Access%20Controle%20(RBAC).png)
