Continuité du service
Objectifs de reprise : interruption, perte de données et preuves
La durée visée pour reprendre une tâche et la perte de données tolérée sont deux objectifs distincts. Ils doivent être rattachés aux dossiers et aux preuves de reprise, pas à la seule fréquence d’une sauvegarde.
Source et portée du repère
Microsoft distingue objectifs de temps de reprise et de point de reprise, et demande de qualifier les objectifs avec les parties prenantes et les preuves d’essai.
Microsoft Learn : définir des objectifs de fiabilité — consultée le . Repères d’architecture adaptés éditorialement ; aucun délai de service garanti ni exercice de restauration effectué dans ce lot.
Les contrôles qui suivent constituent une méthode éditoriale de Performance Voyage. Ils ne rapportent aucune opération exécutée sur un compte fournisseur.
Relier l’objectif à une tâche métier
Nommez les tâches qui doivent reprendre : consulter un dossier, préparer une confirmation ou suivre un paiement. Le temps d’ouverture d’un serveur ne représente pas forcément leur disponibilité utile. Gardez données et rôles nécessaires à chaque tâche. L’objectif proposé doit rester discuté et attribué avant de devenir un engagement de service.
Séparer interruption et perte de données
Le registre garde l’objectif de temps de reprise et celui de point de reprise dans des lignes distinctes. La fréquence de copie ne prouve pas, à elle seule, la perte réelle après un incident. Retrouvez aussi les écritures, messages et références qui doivent rester cohérents. Un système relancé avec des dossiers incomplets n’a pas forcément atteint le résultat métier attendu.
Comparer l’objectif aux observations du scénario
Un scénario fictif ou une revue documentaire prépare les dépendances et les preuves à collecter. Si un exercice autorisé est réellement réalisé ultérieurement, son résultat doit rester distinct de la cible initiale. Le bilan attribue les limites et les tâches encore indisponibles. Une fiche préparatoire ne constitue pas une mesure de restauration ni une garantie de délai pour la production.
Deux cas fictifs à faire rapprocher
La fréquence de sauvegarde devient le résultat prouvé
Scénario fictif : une copie horaire suffit à déclarer un point de reprise tenu. Faites retrouver ce que le scénario montrerait sur les écritures et références. La préparation distingue configuration et preuve de données récupérées.
Le serveur ouvert ferme la reprise métier
Scénario fictif : la page fonctionne mais les confirmations récentes restent absentes. Comparez tâche prioritaire et données nécessaires. Le suivi conserve la partie encore indisponible plutôt qu’un résultat global de reprise.
Conserver les preuves et la prochaine décision
| Point | Preuve à retrouver | Contrôle proposé |
|---|---|---|
| Tâche | Parcours prioritaire | Définir l’usage à reprendre. |
| Données | Objets et écritures nécessaires | Limiter le périmètre. |
| RTO | Temps cible et décision | Garder l’objectif attribué. |
| RPO | Point cible et données tolérées | Séparer la perte visée. |
| Dépendances | Services et références utiles | Préparer la cohérence. |
| Scénario | Cas et preuves attendues | Rendre l’objectif vérifiable. |
| Observation | Résultat réellement obtenu | Écarter une garantie supposée. |
| Écart | Limite et prochaine revue | Attribuer la suite. |
Les objectifs sont rattachés à des tâches et données précises. Cible, configuration et résultat d’essai restent distincts ; aucune garantie de production n’est tirée d’un registre préparatoire.
Erreurs à éviter
- Confondre fréquence de copie et perte prouvée.
- Clore sur un serveur accessible.
- Transformer un objectif proposé en SLA garanti.
La fiche de contrôle permet de suivre les huit points. Le registre associé peut être préparé dans l’atelier avec des références fictives ou anonymisées.
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- Microsoft Learn : définir des objectifs de fiabilité — Repères d’architecture adaptés éditorialement ; aucun délai de service garanti ni exercice de restauration effectué dans ce lot. (consultée le )
Questions fréquentes
Questions utiles avant de décider
RTO et RPO répondent-ils au même besoin ?
Ils distinguent délai de reprise et point de données visé.
Une sauvegarde suffit-elle à prouver l’objectif ?
Le résultat utile demande des observations sur les tâches et données.
Le modèle mesure-t-il une restauration ?
Il prépare le scénario ; la mesure doit provenir d’un exercice réellement autorisé.