Une sauvegarde ne se dimensionne pas d’abord avec une capacité de support ou un nom de logiciel. Elle se dimensionne à partir d’une question métier : après un incident, quelles données l’entreprise peut-elle perdre et combien de temps un processus peut-il rester indisponible ? Le RPO et le RTO servent à rendre ces réponses concrètes, puis à vérifier que l’organisation peut les tenir.
Ils ne sont ni des objectifs marketing ni des chiffres que l’on copie d’un concurrent. Une PME peut accepter plusieurs heures d’indisponibilité pour une archive consultée rarement et exiger une reprise bien plus rapide pour la prise de commandes. Le bon modèle distingue ces situations sans créer une complexité que l’équipe ne saura pas exploiter.
RPO et RTO en langage simple
Le RPO (*Recovery Point Objective*) désigne le point dans le temps auquel les données doivent pouvoir être récupérées après un incident. En pratique, il traduit l’ancienneté maximale acceptable de la donnée restaurée. Si l’entreprise ne peut pas recréer plus d’une heure de saisie, un objectif de sauvegarde quotidien ne suffit probablement pas pour ce processus ; la solution exacte dépendra ensuite du fonctionnement réel.
Le RTO (*Recovery Time Objective*) est le délai maximal acceptable avant que le service redevienne utilisable. Il ne se résume pas à la vitesse de copie. Il comprend la détection de l’incident, la décision de lancer la reprise, la recherche de la bonne sauvegarde, la disponibilité du matériel et des accès, la restauration, les contrôles, puis la validation par le métier.
Un RPO faible et un RTO court demandent souvent davantage de fréquence, de disponibilité, de préparation et de tests. Ils peuvent aussi accroître le coût et la complexité. Le rôle du cadrage est de trouver un niveau proportionné à l’impact réel, non de viser des chiffres très ambitieux que personne ne pourra prouver.
Partir des processus qui s’arrêtent réellement
Une liste de serveurs ou de dossiers ne suffit pas. Réunissez les personnes qui connaissent l’activité et identifiez les processus dont l’arrêt bloque le chiffre d’affaires, la production, le service client, une obligation interne ou une décision importante. Pour chacun, demandez :
- quelle est la conséquence après une heure, une demi-journée ou une journée d’arrêt ;
- quelles données créées depuis le dernier point de reprise devraient être ressaisies ou seraient perdues ;
- quelles applications, configurations, identités ou équipements sont nécessaires au retour du service ;
- qui peut confirmer que le processus est redevenu utilisable.
Cette discussion révèle des dépendances que l’inventaire technique masque parfois : une application peut dépendre d’un partage, d’une base, d’une configuration, d’un accès réseau ou d’une personne habilitée. Le RTO doit couvrir cette chaîne, pas uniquement le temps d’extraction de données.
Limiter les classes de criticité
Une PME n’a pas besoin de vingt objectifs différents. Commencez par deux ou trois catégories compréhensibles, par exemple « critique », « important » et « différable ». Chaque catégorie reçoit une cible de RPO, une cible de RTO, un responsable métier et un scénario de reprise à tester.
Cette simplification permet d’expliquer les arbitrages. Un processus critique peut justifier une copie plus fréquente et un parcours de restauration préparé. Un processus différable peut accepter une fréquence moindre et une récupération planifiée. La même règle ne doit pas être imposée à toutes les données parce qu’elle est facile à administrer.
Traduire les objectifs en exigences de sauvegarde
Le RPO influence la fréquence à laquelle un état utilisable doit être capturé. Il impose aussi de vérifier ce qui se passe entre deux sauvegardes : saisies manuelles, exports, journaux applicatifs ou éléments hors du périmètre principal. Le RTO influence l’ensemble du parcours de reprise : volume à récupérer, disponibilité du média, lieu où se trouve la copie, matériel de remplacement, accès au logiciel et ordre de redémarrage des dépendances.
Ces objectifs permettent ensuite de poser des questions techniques pertinentes, sans présumer de la réponse : combien de jeux doivent rester disponibles au même moment ? Une copie doit-elle être séparée du site ? Qui détient le média ou les accès ? Quel support peut contenir le jeu avec une marge réaliste ? Quelle réserve est nécessaire lorsqu’un média est manquant ou qu’un test est en cours ?
Le produit, la capacité et l’architecture sont sélectionnés après ce travail et validés dans le contexte réel. Un support amovible peut contribuer à une rotation ou à une copie séparée ; il ne crée pas lui-même un RPO ou un RTO garanti.
Exemple fictif : raisonner sans inventer une promesse
Imaginons une PME dont la prise de commandes dépend d’une application et d’une base associée. Les responsables estiment qu’ils peuvent ressaisir au plus deux heures de commandes, et que le service doit être à nouveau utilisable dans les quatre heures suivant la décision de reprise. Ils définissent donc, pour ce processus, un RPO de deux heures et un RTO de quatre heures.
L’équipe ne conclut pas pour autant qu’un équipement précis répond à ces objectifs. Elle mesure la taille et le contenu du jeu, recense les prérequis de restauration, vérifie la fréquence réellement réalisable et réalise un test. Si la recherche du média, la préparation de l’environnement et la restauration dépassent quatre heures, le RTO n’est pas tenu ; il faut corriger le processus, les moyens ou l’objectif validé avec le métier.
À côté, l’archive documentaire de la PME peut accepter une donnée restaurée datant de la veille et une indisponibilité plus longue. La solution peut être différente, mais les deux décisions sont tracées et justifiées.
Un tableau de décision à reproduire dans Gutenberg
Le tableau ci-dessous transforme une discussion en hypothèses testables. Il peut être utilisé comme bloc Tableau dans Gutenberg ou dans un atelier interne.
| Processus | Impact d’arrêt | RPO visé | RTO visé | Dépendances à restaurer | Responsable métier | Dernier test et résultat |
|---|---|---|---|---|---|---|
| Prise de commandes | Exemple : service client bloqué | À définir | À définir | Application, données, accès | À définir | À renseigner après test |
| Archivage documentaire | Exemple : consultation différable | À définir | À définir | Données, recherche, droits | À définir | À renseigner après test |
Les valeurs finales doivent venir des responsables de processus et être revues quand l’activité, les données, les outils ou les équipes changent. Le tableau n’est pas un SLA ; c’est le point de départ d’une décision et d’un contrôle.
Le test transforme une cible en preuve
Un RPO supposé se vérifie en restaurant un point représentatif et en comparant sa date au besoin défini. Un RTO supposé se vérifie en chronométrant l’ensemble de la reprise, du déclenchement jusqu’à l’acceptation métier. Testez notamment un scénario où la personne habituelle n’est pas disponible ou une copie doit être récupérée hors site.
Si l’objectif n’est pas atteint, ne modifiez pas simplement la valeur sur le tableau. Identifiez la contrainte : fréquence insuffisante, jeu trop grand, média indisponible, dépendance oubliée, droits manquants ou procédure trop longue. Décidez ensuite, avec le métier, s’il faut améliorer la capacité de reprise ou réviser l’objectif acceptable.
La checklist de test de restauration et la règle 3-2-1-1-0 complètent ce cadrage. Les guides de calcul des supports et de choix RDX/LTO seront ajoutés au maillage lorsqu’ils seront publiés. Lorsqu’un objectif nécessite une architecture ou un dimensionnement spécifique, le lecteur peut demander un cadrage de projet auprès de Tandberg Data.
Partager ce guide
