RTO et RPO sont deux acronymes omniprésents dans les discussions sur les plans de reprise d'activité et pourtant souvent mal compris, confondus,
ou définis de manière approximative. Un RTO mal calibré conduit à des objectifs inatteignables lors d'un incident réel. Un RPO défini sans lien
avec la fréquence de sauvegarde crée des pertes de données que personne n'avait anticipées.
Ce guide clarifie les deux notions, explique comment les définir selon la criticité réelle des systèmes, et détaille comment les mesurer et les documenter pour satisfaire aux exigences NIS2 et aux audits ANSSI.
Pour comprendre le cadre réglementaire dans lequel s'inscrivent ces objectifs, consultez notre Guide complet PCA et PRA 2026.
Pour une méthodologie de test complète, consultez notre guide : Comment tester son PRA selon l'ANSSI en 2026 ?
Le RTO est la durée maximale acceptable entre le moment où un incident survient et le moment où les systèmes sont à nouveau opérationnels.
Il répond à la question : combien de temps mon organisation peut-elle fonctionner sans ce système avant que l'impact devienne inacceptable ?
Un RTO de 4 heures sur un ERP de production signifie que l'entreprise doit être en mesure de restaurer ce système et de relancer les processus métiers associés dans ce délai, pas seulement de démarrer la restauration, mais de finaliser l'ensemble de la reprise.
Le RTO s'exprime en unité de temps : minutes, heures, jours. Il varie selon les systèmes. Un système de messagerie peut tolérer un RTO de 24 heures,
un système de supervision industrielle peut en nécessiter un inférieur à 15 minutes.
Le RPO est la quantité maximale de données qu'une organisation accepte de perdre en cas d'incident. Il répond à la question :
jusqu'à quand en arrière peut-on restaurer les données sans que la perte soit inacceptable ?
Un RPO de 1 heure signifie que les sauvegardes doivent être suffisamment fréquentes pour qu'en cas d'incident, la perte de données ne dépasse pas
1 heure de production. Si la dernière sauvegarde date de 6 heures avant l'incident, le RPO réel est de 6 heures, indépendamment de l'objectif défini
sur le papier.
Le RPO conditionne directement la fréquence des sauvegardes et l'architecture technique retenue.
RTO et RPO sont deux dimensions indépendantes d'un même problème et confondre les deux conduit à des architectures de reprise incohérentes.
C'est l'erreur de conception la plus fréquente. Une infrastructure capable de restaurer un système en 30 minutes (RTO excellent)
mais dont les sauvegardes sont effectuées toutes les 24 heures expose à une perte de données d'une journée entière (RPO de 24 heures).
Les deux objectifs doivent être définis et atteints simultanément, ils répondent à des contraintes techniques différentes.
Le RTO dépend principalement de l'architecture de restauration : vitesse du stockage, capacité réseau, processus de redémarrage des applications.
Le RPO dépend principalement de la fréquence et de la granularité des sauvegardes.
Un RPO de 15 minutes impose des sauvegardes incrémentales très fréquentes, ce qui n'est pas compatible avec une solution de sauvegarde traditionnelle en mode batch nocturne.
Un RTO de 1 heure sur un environnement virtualisé impose une capacité de restauration bare-metal ou une réplication en temps quasi-réel vers
un environnement de reprise prêt à démarrer.
Ces exigences déterminent directement le choix entre une architecture on-premise, hybride ou cloud et le niveau d'investissement nécessaire.
C'est pourquoi les RTO/RPO doivent être définis avant de choisir une solution de backup, pas après.
Les objectifs 14 et 15 du ReCyF imposent des RTO/RPO définis, vérifiés et documentés. Lors d'un contrôle ANSSI, c'est la cohérence entre les objectifs définis, l'architecture en place et les résultats de tests qui sera évaluée. Un RTO de 4 heures affiché dans le PRA avec une architecture incapable
de l'atteindre constitue un écart de conformité direct.
La définition des RTO/RPO n'est pas un exercice uniforme. Appliquer les mêmes objectifs à tous les systèmes d'une organisation conduit
soit à des investissements disproportionnés sur des systèmes non critiques, soit à des lacunes sur les systèmes réellement essentiels à l'activité.
Le point de départ est l'analyse d'impact (BIA : Business Impact Analysis) : pour chaque système, quelle est la conséquence d'une indisponibilité
sur l'activité ? À partir de quelle durée l'impact devient-il critique ? Quelle quantité de données perdues est acceptable ?
Cette analyse produit une classification des systèmes en trois niveaux typiques :
Systèmes critiques : leur indisponibilité bloque immédiatement l'activité principale.
RTO cible : inférieur à 4 heures. RPO cible : inférieur à 15 minutes.
Systèmes importants : leur indisponibilité dégrade l'activité sans la bloquer complètement. Messagerie, outils collaboratifs, CRM. RTO cible : 4 à 24 heures. RPO cible : 1 à 4 heures.
Systèmes secondaires : leur indisponibilité est gênante mais sans impact direct sur l'activité principale. Outils internes, archives, reporting. RTO cible : 24 à 72 heures. RPO cible : 24 heures.
Pour les entreprises industrielles avec des environnements OT (SCADA, automates, systèmes de supervision), les RTO/RPO sont structurellement
plus contraignants que dans les environnements IT classiques. Une ligne de production arrêtée génère des pertes financières immédiates
et mesurables à l'heure. Les RTO sur ces systèmes sont souvent inférieurs à 1 heure, avec des RPO quasi-nuls sur les paramètres de configuration critiques.
Les objectifs RTO/RPO doivent être définis en cohérence avec ce que l'architecture technique est capable d'atteindre.
Sur une infrastructure avec restauration locale depuis un stockage on-premise, des RTO de quelques minutes sont atteignables sur des environnements virtualisés, à titre d'exemple, des environnements Hyper-V et VMware peuvent atteindre des RTO inférieurs à 10 minutes avec une architecture
de réplication adaptée. Sur une restauration depuis un cloud avec une connexion standard, le même système peut nécessiter plusieurs heures.
C'est pourquoi l'architecture de backup doit être choisie en fonction des RTO/RPO cibles, pas l'inverse.
Définir des objectifs RTO/RPO est une première étape. Les mesurer en conditions réelles et en constituer une preuve exploitable lors d'un audit NIS2
en est une autre, c'est celle que la majorité des entreprises n'ont pas encore franchie.
Le RTO réel se mesure lors d'un test de restauration complet, en chronométrant chaque étape : déclenchement de la restauration, transfert des données depuis le stockage, redémarrage des services, validation fonctionnelle des applications, reprise des processus métiers.
Ces temps varient considérablement selon l'architecture retenue. Sur une infrastructure avec stockage local on-premise et restauration bare-metal,
des environnements virtualisés Hyper-V ou VMware peuvent atteindre des RTO de quelques minutes. Sur une restauration depuis un cloud via
une connexion standard, le même périmètre peut nécessiter plusieurs heures selon les volumes.
L'écart entre le RTO théorique et le RTO mesuré lors d'un premier test est souvent significatif, les dépendances applicatives, les configurations
non documentées et les étapes manuelles non anticipées allongent systématiquement les délais réels.
Le RPO réel se mesure en identifiant la date et l'heure de la dernière sauvegarde saine disponible au moment de l'incident simulé, puis en calculant l'écart avec le moment de déclenchement du test.
Ce calcul doit inclure les données de tous les systèmes du périmètre y compris ceux dont la sauvegarde est moins fréquente ou moins bien surveillée.
Un RPO global ne vaut que ce que vaut le système le moins bien sauvegardé du périmètre critique.
Chaque test de restauration doit produire un rapport structuré contenant : la date et le périmètre du test, la méthode utilisée (test partiel, test complet, dissimilar hardware), les RTO et RPO mesurés système par système, les écarts constatés par rapport aux objectifs définis, et les actions correctives engagées.
Ce rapport constitue la pièce centrale du dossier de conformité NIS2 sur la partie backup et reprise. Sans lui, les objectifs RTO/RPO inscrits dans le PRA n'ont aucune valeur probante lors d'un contrôle.
Pour la méthodologie détaillée des tests et la structure des rapports, consultez notre guide : Comment tester son PRA selon l'ANSSI en 2026 ?
Des RTO/RPO définis arbitrairement, souvent en copiant des valeurs standard trouvées dans des modèles de PRA, ne reflètent pas la réalité des systèmes et des processus de l'organisation. Un RTO de 4 heures sur un système dont l'arrêt génère des pertes de 50 000€ par heure est sous-dimensionné.
Un RTO de 4 heures sur un système de reporting mensuel est sur-dimensionné et inutilement coûteux à atteindre.
Restaurer un serveur et reprendre l'activité métier sont deux étapes distinctes. La restauration technique peut être rapide, quelques minutes
sur un environnement virtualisé avec une architecture adaptée, mais la reprise effective de l'activité dépend aussi du rechargement des données,
de la reconnexion des utilisateurs, de la validation fonctionnelle des applications et du redémarrage des processus dans le bon ordre.
Le RTO doit englober l'ensemble de cette chaîne, pas seulement la restauration technique.
C'est l'erreur la plus répandue et la plus coûteuse. Des RTO/RPO non testés restent des hypothèses. Un premier test révèle systématiquement des écarts (dépendances applicatives non cartographiées, étapes manuelles non documentées, performances de restauration inférieures aux estimations…).
Ces écarts doivent être identifiés lors des tests, pas lors d'un incident réel.
Un RTO de 4 heures sur l'ensemble du SI est un objectif uniforme qui ne correspond à la réalité d'aucun système. Certains systèmes critiques nécessitent un RTO inférieur à 30 minutes : un système de supervision industrielle, un système de paiement, une plateforme de production en continu.
D'autres peuvent tolérer 48 heures. Allouer les mêmes ressources à tous crée des sur-investissements sur les systèmes non critiques
et des sous-investissements sur les systèmes qui en auraient besoin.
Un RPO de 1 heure avec des sauvegardes nocturnes est une contradiction technique. La fréquence de sauvegarde doit être strictement cohérente avec
le RPO défini : une sauvegarde toutes les heures pour un RPO d'1 heure, une réplication quasi-continue pour un RPO de quelques minutes.
Cet alignement doit être vérifié lors de l'audit de l'architecture backup, pas seulement lors d'un incident.
RTO et RPO sont les deux indicateurs qui transforment un PRA en outil opérationnel ou qui révèlent qu'il reste un document théorique.
Les définir avec précision selon la criticité réelle des systèmes, les vérifier lors de tests documentés et les aligner avec l'architecture backup en place constituent les trois conditions pour qu'ils aient une valeur réelle, tant pour la reprise effective en cas d'incident que pour la conformité NIS2.
VYTALX accompagne les ETI des secteurs régulés dans la définition et la vérification de leurs RTO/RPO, avec des tests de restauration assistés et les rapports auditables nécessaires à leur dossier de conformité.
