PRA informatique : passer du plan déclaré à la reprise prouvée

Un plan de reprise est souvent évalué à partir de documents : politique de sauvegarde, rapports de jobs, schéma d’architecture et procédure. Ces éléments sont nécessaires. Ils ne prouvent pas qu’un service redémarrera après une compromission, une panne majeure ou la perte d’un site.

La question utile n’est donc pas : les sauvegardes sont-elles vertes ? C’est : quand un service métier complet a-t-il été restauré pour la dernière fois, avec ses données, ses dépendances, son authentification et une validation métier ?

Si un service complet n’a jamais été restauré, le PRA reste une hypothèse de reprise.

Le premier niveau de preuve d’un plan de continuité

La sauvegarde n’est qu’un maillon

Une sauvegarde réussie atteste qu’une copie a été produite. Elle ne dit pas si cette copie est encore lisible, si elle est protégée contre l’effacement, si l’infrastructure cible est disponible, si les secrets et les certificats sont accessibles, ni si l’application peut fonctionner après la restauration. La reprise est une chaîne. Elle échoue au maillon que personne n’a testé.

Commencer par les services, pas par les serveurs

Un PRA construit à partir des machines finit par leur attribuer une importance qu’elles n’ont pas forcément. La priorité doit partir des services à maintenir, puis remonter vers leurs composants.

• Le service concerné et son propriétaire métier.
• L’impact concret d’une interruption : activité arrêtée, activité ralentie ou simple inconfort.
• La perte de données acceptable, c’est-à-dire le RPO réellement défendable.
• Le délai maximal avant retour à un service utilisable, c’est-à-dire le RTO réellement attendu.
• L’ordre de reprise et les prérequis : identité, réseau, base de données, stockage, certificats ou flux externes.
• Le critère de validation qui permet au métier de dire que le service est revenu, et pas seulement que les serveurs ont redémarré.

Cette qualification évite de sous-estimer un service critique ou de mobiliser des moyens disproportionnés pour un service secondaire. Tous peuvent être sauvegardés. Ils ne peuvent pas tous être rétablis en même temps.

Les dépendances qui font échouer une reprise

Les échecs viennent souvent d’un élément périphérique absent du dossier de sauvegarde. La machine est restaurée, mais le service reste inutilisable parce que son environnement ne l’est pas.

Identité, DNS et temps

Un applicatif peut démarrer sans que les utilisateurs puissent s’authentifier. Annuaire, DNS, synchronisation horaire et comptes de service doivent donc être inclus dans le scénario.

Données et traitements associés

Une base restaurée n’est pas forcément une application restaurée. Il faut aussi retrouver les tâches planifiées, les échanges de fichiers et les contrôles de cohérence attendus par le métier.

Réseau, sécurité et accès

La zone de reprise doit permettre les flux nécessaires sans reproduire aveuglément la production. Pare-feu, VPN, certificats, bastion et comptes d’administration doivent être vérifiés pendant l’exercice.

Licences, secrets et support

Une licence, une clé de chiffrement inaccessible ou un support impossible à mobiliser peut bloquer la reprise. Ce sont des conditions de remise en service, pas des détails documentaires.

Compétences et responsabilités

Une procédure que seul son auteur sait exécuter n’est pas une capacité de reprise. Une autre personne doit pouvoir suivre la séquence et savoir quand escalader.

Protéger les copies, puis vérifier qu’elles restent utilisables

La règle 3-2-1 reste un bon point de départ : plusieurs copies, sur plusieurs supports, dont une séparée du site principal. Elle ne suffit pas contre une compromission. Il faut aussi contrôler les droits de suppression, la rétention et la restauration en environnement isolé.

• Un compte d’administration de la sauvegarde séparé des comptes utilisés pour administrer les systèmes sauvegardés.
• Une copie immuable, hors ligne ou hors domaine d’administration selon le niveau de menace retenu.
• Une durée de rétention cohérente avec le délai de détection d’une compromission.
• Un environnement de restauration disponible, dimensionné et suffisamment documenté pour accueillir le service.
• Des journaux qui permettent de vérifier les opérations réalisées et les comptes qui les ont autorisées.
• Un test de restauration qui vérifie aussi la confidentialité et l’intégrité des données remises en service.

Produire une copie et savoir l’utiliser sont deux capacités différentes. Le contrôle doit porter sur les deux.

Un test utile ressemble à un incident, pas à une démonstration

Un exercice n’a pas besoin de simuler toute la catastrophe. Il doit choisir un service représentatif, isoler la restauration et conserver les contraintes qui font perdre du temps : absence, dépendance inconnue, accès à demander ou étape manuelle oubliée.

Choisir un périmètre représentatif

Le bon candidat n’est ni le plus simple, ni le plus impossible à restaurer. Il doit exposer des dépendances courantes et avoir un propriétaire métier disponible pour valider le résultat.

Mesurer ce qui prend réellement du temps

Il faut horodater le début, la première infrastructure disponible, l’accès applicatif, la validation métier et la fin. Il faut aussi compter les interventions manuelles, les personnes sollicitées et les demandes de droits.

Fermer la boucle

Chaque écart doit avoir un responsable, une action, une échéance et une condition de retest. Sinon le compte rendu devient une archive sans effet sur la capacité réelle de reprise.

Qui doit décider quand la reprise est suffisante ?

La réussite ne se résume pas à un nombre de minutes. Elle dépend d’un accord préalable sur ce qui doit être démontré et sur la dégradation acceptable.

• Le métier confirme la priorité du service, le parcours à valider et la perte de données acceptable.
• L’infrastructure décrit la séquence technique, les dépendances, les ressources nécessaires et les limites du scénario.
• La sécurité vérifie l’isolement des copies, les accès, la traçabilité et les conditions de confiance au redémarrage.
• La direction arbitre les écarts qui exigent du budget, de la capacité ou une réduction explicite du niveau de service.

Obtenir une première preuve de reprise

État des lieux — choisir le service et fixer les objectifs

Nommer le service, son propriétaire, son RTO, son RPO, ses dépendances et le parcours de validation. Un objectif non validé reste une hypothèse.

Vérifier les copies et les conditions de reprise

Contrôler la rétention, l’isolement, les droits, la capacité de restauration et les éléments périphériques. Les blocages doivent sortir avant le test.

Dérouler une restauration technique

Restaurer dans un environnement contrôlé, mesurer chaque étape et corriger la procédure. Le but est d’obtenir une séquence reproductible.

Faire valider et décider

Faire exécuter le parcours métier, attribuer les actions et décider si le niveau de preuve permet d’étendre la méthode.

Un PRA qui n’a jamais été éprouvé doit être présenté comme une hypothèse, pas comme une garantie. La première décision utile n’est pas d’acheter un nouvel outil. C’est de choisir un service, de définir ce que signifie son retour et de réserver le temps nécessaire pour le restaurer réellement.