PRA : pourquoi la plupart des plans de reprise échouent le jour J

Le plan existe. Il est signé, classé, mentionné dans les réponses aux appels d’offres, et il annonce une reprise en quatre heures. Le jour où il faut l’appliquer, la reprise prend trois jours. Dans la quasi-totalité des cas, la technologie a tenu. Le plan décrivait un objectif, alors que la reprise est une séquence d’opérations dépendantes les unes des autres, dont personne n’avait jamais mesuré la durée réelle bout à bout.

RTO et RPO sont des objectifs, pas des constats

Le RTO est la durée d’interruption maximale acceptable pour un service ; le RPO, la quantité de données que l’on accepte de perdre, exprimée en temps. Ces deux valeurs ont deux contreparties que l’on trouve rarement dans les documents : le délai et la perte effectivement constatés lors d’un exercice. Tant que ces constats n’existent pas, le RTO reste une intention. Le vocabulaire de la norme ISO 22301 y ajoute deux notions utiles, la durée maximale d’interruption tolérable et le niveau de service minimal acceptable en crise, qui obligent à répondre à une question souvent esquivée : avec quoi l’activité peut-elle fonctionner en mode dégradé, et pendant combien de temps ?

Le délai réel est une somme de durées en série : détecter l’événement, décider qu’il s’agit d’un sinistre, mobiliser les personnes, reconstruire le socle, restaurer l’annuaire, restaurer les données, valider les applications avec les métiers, rouvrir le service aux utilisateurs. Le maillon le plus sous-estimé de cette chaîne est la décision elle-même. Qui déclare le sinistre, à partir de quel seuil, avec quelle autorité, et sur la base de quelle information ? Si la déclaration prend quatre heures parce qu’elle remonte trois niveaux hiérarchiques un dimanche, aucune technologie ne tiendra un RTO de deux heures.

Vient ensuite une arithmétique que l’on omet presque systématiquement. Restaurer 20 To à un débit utile soutenu de 400 Mo/s demande environ quatorze heures de transfert pur, avant toute validation. Et ce débit utile est rarement celui de la fiche technique : la réhydratation des données dédupliquées, la lecture du catalogue, les accès aléatoires sur la cible et le nombre de tâches parallèles autorisées le réduisent souvent de moitié. Dimensionner un RTO sur un débit théorique conduit mécaniquement à se tromper d’un facteur deux à cinq. Le seul chiffre défendable est celui que vous avez mesuré sur votre propre infrastructure, avec votre propre volume.

Sauvegardes immuables et règle 3-2-1-1-0

Le modèle de menace a changé. Le sinistre de référence n’est plus l’incendie de la salle serveurs mais le chiffrement simultané de la production et de la sauvegarde, parce que le serveur de sauvegarde appartenait au même domaine que le reste du parc et qu’un compte de service disposait de privilèges élevés. Les attaquants cherchent la console de sauvegarde avant de chiffrer : c’est elle qui détermine si la victime paiera. Toute architecture de reprise conçue avant cette évolution est à réexaminer, même si elle fonctionne parfaitement en exercice technique.

• Trois copies des données, la production comprise.
• Deux supports de nature différente, pour ne pas dépendre d’un seul mode de défaillance.
• Une copie hors site, hors de portée d’un sinistre local.
• Une copie hors ligne, déconnectée ou rendue immuable, inaccessible depuis le domaine de production.
• Zéro erreur : la restaurabilité est vérifiée automatiquement, et l’échec de vérification ouvre un incident au lieu d’ajouter un avertissement dans la console.

Une immuabilité réelle résiste à un administrateur légitime, ce qu’aucune option cochée dans une console ne garantit à elle seule. Verrouillage d’objet dans le stockage, dépôt durci, support à écriture unique : le mécanisme importe moins que la garantie, à savoir qu’aucun compte, quel que soit son niveau de privilège, ne puisse raccourcir la rétention ni supprimer un point de restauration pendant la période verrouillée. Le plan d’identité doit lui aussi être séparé, avec des comptes locaux dédiés, une authentification multifacteur distincte de celle de la production et aucune jonction au domaine.

L’exercice est la seule preuve

Les exercices se hiérarchisent : relecture documentaire, exercice sur table avec les décideurs, restauration d’un composant isolé, restauration complète dans un environnement cloisonné, bascule réelle d’un service avec ses utilisateurs. Chaque niveau répond à une question différente et aucun ne remplace le suivant. La norme ISO 22301 exige un programme d’exercices et une évaluation périodique de la documentation et des capacités, parce qu’un plan non éprouvé vieillit plus vite que l’infrastructure qu’il décrit.

Un exercice doit produire un relevé : une chronologie horodatée des opérations, le délai et la perte de données réellement constatés face aux objectifs annoncés, la liste des points de blocage, les décisions prises et les actions correctives assorties d’un responsable et d’une date. Un exercice qui se déroule sans aucune difficulté tient de la démonstration plus que du test. Les organisations qui progressent sont celles qui acceptent de jouer des scénarios inconfortables : la personne clé est injoignable, le site principal est inaccessible, la sauvegarde la plus récente est corrompue.

Les erreurs qui reviennent

1. 1Les dépendances oubliées. L’annuaire et le fournisseur d’identité se restaurent avant tout le reste, et leur procédure de reprise est spécifique. Viennent ensuite le DNS, la distribution d’adresses, l’autorité de certification, les serveurs de licences, les coffres à secrets, le service d’authentification multifacteur, la synchronisation horaire et la supervision elle-même.
2. 2La dépendance circulaire. Le gestionnaire de mots de passe hébergé sur l’infrastructure à restaurer, le plan de reprise stocké sur le partage chiffré, la procédure accessible uniquement via l’intranet : prévoyez une copie hors bande et un accès de secours testé.
3. 3Tout est critique. Lorsque chaque application est classée en priorité maximale, aucune ne l’est réellement et l’ordre de reprise se décide dans l’urgence. La hiérarchisation doit être arbitrée et validée par les métiers, la DSI ne pouvant la fixer seule.
4. 4Des runbooks périmés. Noms de machines, adresses, versions et contacts dérivent en quelques mois. Un runbook se révise à chaque changement d’architecture et se vérifie à chaque exercice.
5. 5Surveiller la sauvegarde au lieu de la restauration. Un indicateur de tâche réussie ne dit rien de la restaurabilité. Et l’on ne teste jamais que le point d’hier, presque jamais le point le plus ancien encore sous rétention.
6. 6Aucun moyen de communication hors bande. Si la messagerie et la téléphonie reposent sur le système sinistré, la cellule de crise ne peut même pas se réunir. Prévoyez une liste de contacts imprimée et un canal indépendant.
7. 7Les obligations de notification absentes du plan. Les délais réglementaires courent pendant la reprise : 72 heures pour une violation de données personnelles, 24 heures pour une alerte précoce au titre de NIS2 lorsque l’entité y est soumise. La cellule de crise doit les avoir en tête dès les premières heures.
8. 8Les instantanés pris pour des sauvegardes. Un instantané conservé dans le même compte, le même abonnement ou la même région que la production disparaît avec elle, et un administrateur compromis le supprime en quelques minutes.

Ce que le cloud déplace

Le modèle de responsabilité partagée est souvent lu à l’envers : l’engagement du fournisseur porte sur la disponibilité de son infrastructure, et s’arrête là où commence la récupérabilité de vos données après une suppression ou un chiffrement. La rétention d’une plateforme en mode service protège contre l’erreur de manipulation pendant quelques semaines, rarement contre une compromission administrative ; elle ne tient donc pas le rôle d’une sauvegarde. Une copie dans un compte distinct, avec des identifiants séparés, reste la règle. Enfin, dans une infrastructure décrite par le code, le dépôt et la chaîne d’intégration sont eux aussi des dépendances critiques : restaurer une plateforme cloud consiste à rejouer du code puis à réinjecter des données, autrement dit à conduire un projet logiciel sous contrainte de temps.