Lorsqu’une panne, un sinistre ou une cyberattaque interrompt les systèmes, deux questions deviennent urgentes : combien de temps l’entreprise peut-elle rester sans service, et quelle quantité de travail peut-elle perdre ? Les réponses prennent la forme du RTO et du RPO.
Ces indicateurs orientent la sauvegarde des données, le choix des outils et la préparation d’un plan de reprise. Pour les fixer utilement, une entreprise doit partir de ses activités réelles plutôt que d’une promesse de restauration rapide.
À retenir : deux objectifs pour la reprise après sinistre
- RTO : durée maximale tolérée avant le rétablissement d’un service essentiel
- RPO : quantité de travail que l’organisation accepte de perdre
- Objectifs définis selon la criticité des activités, des applications et des données
- Résultats vérifiés par des exercices de restauration et des mesures réelles
RTO et RPO : comprendre les deux indicateurs
Le RPO mesure la perte de données acceptable
Le RPO, ou objectif de point de reprise, désigne la période de données que l’organisation accepte de ne pas pouvoir récupérer après un incident. Il se rapporte donc à l’intervalle entre le dernier point de sauvegarde exploitable et l’interruption.
Imaginons une boutique en ligne qui sauvegarde sa base de commandes chaque nuit. Si son serveur tombe en panne en fin de journée, les commandes enregistrées depuis la dernière copie risquent de manquer ; une sauvegarde plus fréquente réduit cette fenêtre.
Les besoins ne sont pas identiques partout. Un site vitrine rarement actualisé peut tolérer une perte plus importante qu’un système de facturation ou qu’une base de production alimentée en continu.
Le RTO inclut toute la durée d’interruption
Le RTO, ou objectif de temps de reprise, fixe la durée maximale acceptable avant le retour du service. Il ne correspond pas seulement au temps nécessaire pour copier des fichiers ou redémarrer un serveur.
Il faut aussi compter la détection de l’incident, la décision d’activer le plan de reprise, la restauration des systèmes et les contrôles avant remise en service. Une restauration technique rapide ne suffit donc pas si l’incident est découvert tardivement ou si les équipes ignorent la procédure.
Le RPO répond à la question « jusqu’où peut-on revenir ? », tandis que le RTO demande « quand faut-il fonctionner de nouveau ? ». Ces deux réponses cadrent les exigences de continuité d’activité et préparent le choix des solutions.
Définir des objectifs RTO et RPO réalistes
Relier les objectifs aux conséquences métier
Une fois les deux notions distinguées, l’entreprise peut déterminer ses seuils en évaluant les conséquences concrètes d’un arrêt ou d’une perte de données. Les équipes métier connaissent souvent mieux que les seules équipes informatiques les effets sur les ventes, la production et les clients.
Une méthode simple consiste à examiner chaque service et à estimer les impacts d’une indisponibilité, puis ceux d’un retour à une sauvegarde plus ancienne. Il faut également considérer la productivité des collaborateurs, les dépendances entre applications et les obligations de conservation applicables aux documents.
Dans une entreprise fictive de distribution, le portail de commande peut être prioritaire pendant les périodes de forte activité, tandis que des archives anciennes peuvent être restaurées dans un délai plus long. Cette hiérarchie évite d’imposer le même niveau de protection à tout le système.
Éléments à évaluer pour chaque service :
- Effet d’un arrêt sur les ventes, la production et les utilisateurs
- Coût de la reconstitution des données manquantes
- Dépendances avec les applications et services essentiels
- Contraintes de conservation et besoins de conformité
Comparer les exigences entre services
Le tableau ci-dessous propose une grille de réflexion, et non des seuils universels. Les objectifs doivent être validés par les responsables concernés, puis comparés aux capacités techniques et au budget disponibles.
| Service à examiner | Enjeu principal | Question RPO | Question RTO |
|---|---|---|---|
| Commerce en ligne | Commandes et paiements | Quel volume de transactions peut être ressaisi ? | Combien de temps le site peut-il rester indisponible ? |
| Facturation | Émission et suivi des factures | Quels documents ou changements doivent être récupérés ? | Quand la facturation doit-elle reprendre ? |
| Production | Continuité des opérations | Quelle perte de données bloque ou retarde la production ? | Quel arrêt désorganise les équipes ? |
| Archives bureautiques | Accès aux documents historiques | Quelle période de modifications peut être refaite ? | Quel délai de restauration reste acceptable ? |
Cette comparaison met en évidence les arbitrages nécessaires avant de choisir une architecture. Le niveau de protection retenu devra ensuite être traduit en fréquences de sauvegarde, emplacements de stockage et procédures testables.
Atteindre les objectifs grâce aux sauvegardes et aux tests
Adapter la sauvegarde au niveau de criticité
Les objectifs définis deviennent utiles lorsqu’ils guident les choix techniques. Une base de production qui évolue constamment peut nécessiter des copies plus rapprochées que des archives peu modifiées, tandis que la durée de rétention dépend des besoins opérationnels et réglementaires.
Le stockage local peut accélérer certaines restaurations, mais il reste exposé aux sinistres qui touchent les locaux ou l’infrastructure. Une copie distante ou dans le cloud apporte une autre option ; combiner plusieurs emplacements peut équilibrer rapidité de reprise et protection.
Le tableau compare des moyens courants sans supposer qu’une technologie garantit à elle seule un résultat. Chaque dispositif doit être évalué par rapport aux données concernées, aux accès disponibles et aux étapes nécessaires à la remise en service.
| Dispositif | Apport possible | Point de vigilance |
|---|---|---|
| Sauvegarde fréquente | Réduit l’intervalle de données potentiellement perdues | Vérifier la réussite et l’exploitabilité des copies |
| Copie locale | Peut accélérer l’accès aux données de restauration | Risque d’exposition au même sinistre que les systèmes principaux |
| Copie distante ou cloud | Éloigne une copie de l’infrastructure principale | Évaluer les délais de transfert et de récupération |
| Virtualisation et orchestration | Peuvent faciliter le redémarrage coordonné des services | Préparer et tester les configurations de reprise |
Tester la restauration et mesurer les délais réels
Une sauvegarde n’est utile que si les données peuvent être restaurées et si les équipes savent exécuter la procédure. Les tests révèlent les comptes manquants, les dépendances oubliées et les délais que les estimations initiales ne montrent pas.
Pour rendre ces contrôles réguliers, l’entreprise peut documenter les résultats et attribuer les actions correctives à des responsables :
- Restaurer des fichiers représentatifs et vérifier leur intégrité
- Chronométrer les étapes, de la détection au retour opérationnel
- Comparer l’âge de la dernière copie disponible au RPO visé
- Mettre à jour les procédures après chaque changement important
Une réplication ou une infrastructure redondante peut soutenir un RTO exigeant, mais elle ne remplace pas nécessairement une sauvegarde restaurable. C’est la répétition des essais qui transforme les objectifs théoriques en capacité de reprise mesurée.
Les résultats d’un exercice peuvent aussi faire apparaître un décalage entre le délai attendu et le temps réellement nécessaire. Ce constat permet de réviser les procédures ou les ressources avant qu’un incident ne mette l’activité à l’épreuve.
Transformer l’analyse en décision
Les meilleures décisions reposent sur un cadre compréhensible, quelques critères vérifiables et une étape suivante clairement définie. Testez la méthode à petite échelle, mesurez le résultat puis ajustez avant de généraliser.
Votre checklist
- Définir le résultat attendu
- Identifier trois critères prioritaires
- Prévoir une mesure de contrôle
- Fixer une date de réévaluation
