PRA et PCA

Comment tester un PRA ?

On teste un PRA en essayant de travailler sur le secours, pas en relisant le document. Le test le plus faible est une réunion, le plus fort une bascule réelle avec des utilisateurs, puis un retour arrière ; entre les deux, des paliers permettent de progresser sans arrêter l’entreprise à chaque fois.

Mis à jour en octobre 20264 min de lecture6 sources citées

L’essentiel

Palier A, test sur table : le document est-il encore vrai ? Deux à trois heures, sans toucher à la technique.
Palier B, restauration isolée : le secours démarre-t-il et l’application s’ouvre-t-elle, sans couper la production ?
Palier C, bascule réelle : le seul qui mesure le RTO et teste le retour arrière.
Un contrôle automatique de démarrage est utile, mais ne prouve pas que le métier peut travailler.
Chaque test produit un compte rendu daté : heures, écarts, décisions.

Ce que disent les référentiels

Le SGDSN recommande trois approches complémentaires : faire vérifier les documents, idéalement par un tiers de confiance ; tester la mise en œuvre des dispositifs, par exemple le basculement de certaines fonctions sur un site de secours ; vérifier enfin, par des exercices, que les procédures sont connues, comprises et peuvent être appliquées dans les délais prévus. L’ANSSI, dans son guide sur la sauvegarde, demande qu’une procédure de restauration du système d’information soit rédigée et régulièrement mise en œuvre.

Le NIST distingue deux formes d’exercice. L’exercice sur table est une discussion où chacun décrit son rôle face à un scénario. L’exercice fonctionnel fait exécuter les gestes réels dans un environnement simulé. Les trois paliers ci-dessous suivent cette progression.

Palier A. Test sur table

Les personnes nommées dans le plan parcourent les étapes à voix haute, téléphones devant elles. On vérifie que les numéros répondent, que la clé est trouvable, que l’ordre des serveurs est encore juste. Durée : pour un exercice de crise cyber sur table, l’ANSSI compte deux à trois heures, briefing et débriefing compris, et environ six semaines de préparation ; le NIST évoque de deux à huit heures selon les objectifs. Fréquence minimale : après chaque départ d’une personne clé. Ce palier ne prouve rien sur la technique. Il prouve que le document est encore vrai.

Palier B. Restauration technique isolée

On restaure ou on démarre le secours sans couper la production. On se connecte. On ouvre l’application. On note le temps depuis la décision jusqu’à l’écran métier. Les utilisateurs réels ne sont pas basculés. C’est le test qui révèle un disque manquant, une licence, un mot de passe, un réseau fermé.

Limite : la production n’ayant pas été coupée, on n’a pas prouvé le geste de bascule (DNS, IP, agent) ni le retour.

Palier C. Bascule réelle, sur un créneau annoncé

Un soir ou un dimanche, la production est arrêtée ou le trafic est envoyé au secours. Quelques utilisateurs font un geste métier vrai : éditer une pièce, pointer une commande, lire un dossier. Puis on revient en arrière et on vérifie que les saisies faites sur le secours ne sont pas perdues.

C’est le seul palier qui mesure le RTO et qui teste le retour. Il se planifie, il se communique, il a un critère d’arrêt (« si à 23 h le secours n’est pas là, on annule »).

Palier	Ce qu’il prouve	Ce qu’il ne prouve pas	Impact sur la production
A. Sur table	Le document, les contacts, les rôles	Que la technique fonctionne	Aucun
B. Restauration isolée	Que le secours démarre et que l’application s’ouvre	La bascule réseau et le retour	Aucun
C. Bascule réelle	Le RTO réel, le travail métier, le retour	—	Créneau annoncé

Checklist avant le palier C

Date et créneau validés par la direction, utilisateurs prévenus.
Dernière sauvegarde réussie vérifiée, clé de chiffrement en main.
Critère d’arrêt écrit, avec l’heure limite et la personne qui décide.
Un utilisateur métier par application testée, avec un geste précis à réaliser.
Procédure de retour relue, et sauvegarde de la production juste avant.
Une personne chargée de noter les heures et les écarts au fil de l’eau.

Ce que le compte rendu doit contenir

Date, palier, personnes, heure de début, heure où le geste métier a réussi, écarts, décisions. Une phrase du type « test OK » ne sert à rien six mois plus tard. Le NIST appelle ce document un rapport post-exercice : il consigne les observations et les recommandations pour améliorer le plan. L’ANSSI fait du retour d’expérience une étape à part entière de tout exercice.

Ce qu’un test de démarrage automatique prouve, et ne prouve pas

Certains services démarrent les copies chaque mois et vérifient qu’elles démarrent. C’est utile : une image qui ne démarre plus est détectée sans déranger la production. Ce n’est pas un palier C. L’application peut être cassée, la base incohérente, le réseau de bascule non testé, le retour arrière inconnu. Présenter ce contrôle comme « le PRA est testé » est inexact. Il faut dire : « le démarrage des images est contrôlé ; la bascule métier ne l’est pas encore ».

Chez WeDoBack

Le test mensuel inclus du PRA est de cette dernière catégorie : une procédure automatique démarre les instances stockées et lit leur écran de démarrage, sans toucher à la production. Le test en conditions réelles, qui correspond au palier C ou à un palier B poussé, est proposé jusqu’à dix heures et fait l’objet d’un devis. Les deux ont un rôle. Ils ne se remplacent pas. L’assistance humaine est joignable de 9 h à 13 h et de 14 h à 17 h 30 (heure de Paris), au 09 72 50 78 28 : un essai réel se cale dans ces horaires, ou se prévoit explicitement en dehors.

Découvrir l’offre PRA Demander un devis

Questions fréquentes

Peut-on tester un PRA sans arrêter la production ?

Oui, pour les paliers A et B : le test sur table et la restauration dans un environnement isolé ne touchent pas à la production. Seule la bascule réelle (palier C) demande un créneau annoncé, un soir ou un week-end, avec un critère d’arrêt défini à l’avance.

Qui doit participer au test ?

Les personnes nommées dans le plan : celle qui décide de basculer, celle qui administre, celle qui détient la clé de chiffrement, et au moins un utilisateur métier capable de vérifier qu’il peut réellement travailler. Sans utilisateur métier, on teste l’informatique, pas la reprise d’activité.

Que faire si le test échoue ?

C’est le but d’un test : trouver ce qui ne marche pas avant le sinistre. Notez l’écart, corrigez-le, et planifiez un nouvel essai sur ce point. Le NIST comme l’ANSSI insistent sur le retour d’expérience, qui transforme l’échec en amélioration du plan.

Pour aller plus loin

Sources

Documents consultés en octobre 2026.

Un projet de sauvegarde, de PRA ou de PCA ?

Plus de 20 ans d’expérience dans la protection des données des entreprises.

Demander un devis 09 72 50 78 28

Protégez vos données avec WeDoBack

Sauvegarde chiffrée hors site, stockage immuable, PRA et PCA : décrivez-nous vos serveurs, nous vous proposons la bonne combinaison.

Demander un devis Voir les offres et tarifs