SLO, PRA, sauvegardes : remettre les priorités dans le bon ordre

Un paquebot embarque trois promesses de sécurité. La première est affichée à l'accueil : « nous garantissons votre traversée ». La deuxième est le plan d'évacuation punaisé dans chaque cabine. La troisième, ce sont les canots de sauvetage arrimés sur le pont. Sur le papier, tout y est. Mais si les canots ne sont jamais descendus lors d'un exercice, si le plan d'évacuation ne dit pas qui rassemble les enfants, et si la promesse de l'accueil ignore combien de places offrent réellement les canots, alors la nuit du naufrage, ces trois dispositifs ne s'emboîtent pas. Chacun était vrai isolément ; ensemble, ils ne tenaient pas.

En informatique, ces trois promesses ont des noms : les SLO (les objectifs de disponibilité, la promesse affichée), le PRA (le plan de reprise, l'évacuation) et les sauvegardes (les canots). Beaucoup d'organisations les gèrent séparément, si bien qu'ils ne parlent pas le même langage. Le résultat est toujours le même : des efforts dispersés, des budgets mal placés, et un risque qui reste élevé malgré des investissements importants. Remettre les priorités dans le bon ordre, c'est faire en sorte que les trois s'emboîtent avant la tempête.

Quand les priorités se mélangent

Les SLO (Service Level Objectives) servent à mesurer l’expérience utilisateur ou métier. Les PRA (Plans de reprise d’activité) traitent de la remise en service après incident. Les sauvegardes protègent les données. Si ces trois axes ne sont pas coordonnés, on obtient une sécurité factice : on a des sauvegardes qui ne permettent pas une reprise rapide, ou une disponibilité garantie sur des services qui n’ont pas de vrai plan de remise en route.

Erreur n°1 : définir des SLO sans analyse métier

Un SLO de 99,9 % peut sembler top, mais il n’a de sens que si les services concernés supportent des usages critiques. Sans priorisation métier, des ressources non essentielles peuvent absorber des budgets et des efforts qui devraient aller vers des services plus critiques.

• Ne pas confondre disponibilité et importance métier.
• Éviter les SLO copié-collés sans examen des impacts réels.
• Faire valider les objectifs par les métiers avant de les fixer.

Erreur n°2 : des PRA trop généraux

Un PRA qui dit simplement « reprendre l’activité » n’est pas suffisant. Il faut définir des objectifs de reprise concrets, des rôles clairement assignés et des scénarios réalistes. Sans cela, le plan devient un document théorique qui ne sert à rien en situation de crise.

• Vérifier que les priorités de reprise correspondent aux SLO critiques.
• Identifier les dépendances entre services, données et équipes.
• Tester régulièrement les processus de reprise.

Erreur n°3 : des sauvegardes déconnectées

Si les sauvegardes existent mais qu’elles ne sont jamais testées, elles n’ont aucune valeur le jour du sinistre : ce sont des canots qu'on découvre percés une fois à l'eau. Un dispositif efficace doit répondre à des objectifs de point de restauration (RPO) et de temps de restauration (RTO), et rester aligné avec les besoins métier. La règle du 3-2-1 et les restaurations testées, que nous détaillons dans notre guide dédié aux sauvegardes, en sont le socle.

• Ne pas garder des sauvegardes non restaurées depuis des mois.
• S’assurer que les périodicités correspondent aux besoins réels.
• Vérifier la cohérence entre sauvegarde, PRA et capacité réelle de l’infrastructure à absorber une reprise.

Comment rétablir l’ordre

Pour rendre l’ensemble cohérent, commencez par poser les questions suivantes :

• Quels services sont vraiment critiques pour le business ?
• quelles données doivent être restaurées en priorité ?
• combien de temps d’interruption est acceptable pour chaque famille de services ?

Ensuite, structurez le dispositif :

• des SLO basés sur les usages métier ;
• des PRA définis par type de dégâts et niveau de criticité ;
• des sauvegardes validées par des tests réguliers et des restaurations réelles.

Un exemple d’alignement efficace

Une société de services cloud a défini trois niveaux de criticité :

• Niveau 1, services client et passerelles de paiement : RTO 1h, RPO 15 min. On ne perd presque rien, et on redémarre en une heure.
• Niveau 2, reporting interne et outils de pilotage : RTO 4h, RPO 1h. Une interruption d'une demi-journée reste tolérable.
• Niveau 3, archives et services non critiques : RTO 24h, RPO 24h. On peut attendre le lendemain sans conséquence grave.

Cette classification a permis de concentrer les sauvegardes, les PRA et les ressources de récupération sur ce qui comptait réellement, plutôt que de chercher à tout couvrir au même niveau.

Ce que Kenawek recommande

Nous proposons de :

• valoriser les données et services selon leur impact métier ;
• définir des SLO cohérents avec les PRA ;
• tester les restaurations de sauvegarde dans des scénarios concrets ;
• mettre en place une gouvernance de la résilience partagée entre sécurité, infra et métiers.

Cette approche transforme SLO, PRA et sauvegardes en leviers de résilience opérationnelle, plutôt qu’en coûts isolés.