PRA informatique : j'ai écrit et testé celui de ma société (7 étapes et modèle Excel)

Le 30 septembre 2026, j'ai reconstruit le site de Mill-Forma depuis un dossier vide, chronomètre en main. 28 secondes plus tard, ses 228 pages répondaient. Le site avait l'air de marcher. Il interdisait pourtant à Google d'explorer la moindre page, et son formulaire de rappel renvoyait une erreur 500.

C'est la différence entre un PRA informatique écrit et un PRA informatique testé. Je dirige un organisme de formation, je ne suis pas RSSI, et j'ai passé notre propre société à la méthode : inventaire, RTO et RPO, état des sauvegardes, puis deux tests de restauration chronométrés.

Cet article déroule cette méthode en 7 étapes, avec mes captures et mes erreurs. Chaque étape s'appuie sur un onglet du classeur Excel que vous pouvez télécharger. L'inventaire et les deux tests ont tenu dans un après-midi.

PRA informatique : de quoi on parle

Un PRA informatique (plan de reprise d'activité) est le document qui dit comment une entreprise redémarre son système d'information après un sinistre : qui fait quoi, dans quel ordre, à partir de quelles copies, et en combien de temps. Il s'adresse à celui qui devra l'exécuter un mauvais jour, pas à un auditeur. Un PRA qui n'a jamais été joué est une hypothèse.

On le confond avec le PCA, le plan de continuité d'activité. Le PCA organise le travail pendant la panne : mode dégradé, télétravail, procédures papier. Le PRA organise le retour à la normale. Dans une petite structure, les deux tiennent dans le même classeur, et c'est le PRA qu'on teste en premier parce qu'il se mesure.

Deux sigles portent tout le reste.

• Le RTO (recovery time objective) est la durée d'arrêt que vous tolérez pour une activité. L'ANSSI l'appelle DMIA, durée maximale d'interruption admissible.
• Le RPO (recovery point objective) est la quantité de données que vous acceptez de perdre, comptée en temps depuis la dernière copie exploitable. En français, PDMA, perte de données maximale admissible.

Un RTO de 4 heures et un RPO de 24 heures se lisent ainsi : l'activité doit repartir dans la demi-journée, et on accepte de ressaisir le travail de la veille.

Ce que la loi et vos clients vous demandent vraiment

Aucun texte n'écrit « toute entreprise doit avoir un PRA ». Trois sources l'exigent pourtant sans le nommer.

Le RGPD, pour tout le monde. L'article 32 demande à quiconque traite des données personnelles de prévoir « des moyens permettant de rétablir la disponibilité des données à caractère personnel et l'accès à celles-ci dans des délais appropriés en cas d'incident physique ou technique », et « une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité » de ces mesures. Rétablir dans un délai, et tester : c'est la définition d'un PRA. Un fichier clients ou une liste de stagiaires suffit à vous faire entrer dans le champ.

NIS2, pour les entités concernées. L'article 21 de la directive (UE) 2022/2555 range parmi les mesures obligatoires « la continuité des activités, par exemple la gestion des sauvegardes et la reprise des activités, et la gestion des crises ». Au 1er octobre 2026, la loi française de transposition n'est toujours pas promulguée : le Sénat l'a adoptée le 12 mars 2025, la commission spéciale de l'Assemblée nationale le 10 septembre 2025, et l'examen en séance publique est inscrit à l'ordre du jour à partir du 7 octobre 2026. La fiche de notre formation Gouvernance et PRA suit cet état réglementaire.

Vos clients, pour tous leurs fournisseurs. Une entreprise soumise à ces règles les reporte sur ses fournisseurs, par un questionnaire de sécurité. La question porte sur un PRA testé, et le second mot compte autant que le premier.

Côté méthode, la référence gratuite est le guide de l'ANSSI « Sauvegarde des systèmes d'information, les fondamentaux » (version du 27 novembre 2025). Sa recommandation R22 tient en deux phrases : « Les sauvegardes doivent être testées régulièrement. Une procédure de restauration du SI doit être rédigée et régulièrement mise en œuvre. » Les étapes 4 et 5 ci-dessous ne font rien d'autre.

Étape 1 : inventorier ce qui fait tourner la boîte

L'onglet Actifs reçoit une ligne par outil, par donnée et par accès dont l'entreprise a besoin pour travailler. Pour chacun : à quoi il sert, chez quel prestataire il vit, où se trouve sa copie, et combien de personnes en sont administratrices.

L'onglet tel qu'il est livré, avec l'exemple d'un cabinet de 25 salariés. Une ligne à un seul administrateur passe en rouge.

Pour le nôtre, je n'ai pas rempli cet onglet de mémoire. J'ai relevé ce que la machine disait : les dépôts de code et leur état, les enregistrements publics du domaine, l'état du poste de travail, la liste des variables du site chez l'hébergeur. Onze lignes en sont sorties. Je ne les publie pas, un inventaire est une carte, mais deux colonnes ont fait le travail.

« Où est la copie ». Le code du site est dans son dépôt et sur mon poste, deux exemplaires, et nos huit dépôts n'avaient aucun commit en attente d'envoi ce jour-là. C'est la ligne rassurante, et c'est elle qui trompe : on croit tout avoir en double parce que le code l'est. La colonne a fait remonter ce qui n'existait qu'une fois, à commencer par la configuration du site. J'y reviens à l'étape 4.

« Administrateurs ». C'est la colonne qu'on ne pense pas à remplir. Un outil dont une seule personne détient les accès est une panne en attente, même s'il ne tombe jamais : un congé, un accident, un départ suffisent. Dans une petite société, le chiffre de cette colonne est souvent 1, et c'est la première chose que l'inventaire donne à corriger.

La comptabilité et la paie ne sont pas dans mon relevé. Je ne les ai pas passées au test ce jour-là.

Étape 2 : fixer un RTO et un RPO par activité

L'onglet Impact ne liste pas des serveurs, il liste des activités : ce que l'entreprise fait pour ses clients, et ce qui se passe quand ça s'arrête. Pour chaque activité, un RTO et un RPO en heures, et les actifs dont elle dépend.

Nos lignes au soir du 30 septembre. Les trois colonnes bleutées se remplissent seules à partir du journal des tests. Avant l'étape 5, elles disaient toutes « Jamais testé ».

Voici ce que j'ai retenu pour nous.

Ce sont les cibles d'une société de services qui ne vend pas en ligne. Ce qui touche un client ou un stagiaire le jour même est à 4 heures. L'administratif peut attendre deux jours, la compta une semaine. J'avais sous les yeux une version plus stricte, à 1 heure pour tout ce qui touche au client, et je l'ai écartée. Un RTO d'une heure oblige à payer de la redondance et à tester plus souvent.

L'erreur classique est de fixer un RTO par outil (« le serveur doit revenir en 2 heures »). Un RTO par activité oblige à regarder toute la chaîne. « Formulaires du site » dépend du site, de sa configuration et de deux services tiers, et c'est exactement là que le test a cassé.

Étape 3 : choisir les scénarios de sinistre

Un PRA ne couvre pas tout. L'onglet Scénarios liste les sinistres plausibles et les cote de 1 à 4, en vraisemblance et en impact. Le produit des deux donne un score, et le score donne l'ordre dans lequel on écrit les fiches réflexe.

L'exemple livré : le rançongiciel arrive en tête avec 12 sur 16, et sa seule parade est un disque branché en permanence.

J'ai coté sept scénarios pour Mill-Forma. Celui qui est sorti en tête n'est ni une cyberattaque ni une panne de prestataire : c'est l'indisponibilité de la personne qui administre les outils. La panne de l'hébergeur du site, celle à laquelle tout le monde pense, est arrivée dans les dernières.

La colonne « Parade en place » est la plus instructive. Écrivez ce qui existe aujourd'hui, pas ce qui est prévu. Une case « Aucune » en face d'un score élevé est la prochaine chose à faire.

Ce classement est un tri à la main, pas une analyse de risques. La méthode complète s'appelle EBIOS Risk Manager, elle est publiée par l'ANSSI et elle part des sources de menace plutôt que des pannes. Pour une petite structure qui démarre, sept lignes cotées honnêtement valent mieux qu'une étude jamais finie.

Étape 4 : vérifier les sauvegardes, une par une

L'onglet Sauvegardes reprend chaque donnée de l'inventaire et pose quatre questions : où est la première copie, où est la seconde, l'une des deux est-elle hors ligne, et de quand date le dernier test de restauration.

L'ANSSI résume la cible dans sa recommandation R11, la règle « 3-2-1 » : « 3 copies distinctes des données, c'est-à-dire les données en production et 2 sauvegardes stockées sur des supports différents, dont 1 hors ligne ». La R12 ajoute qu'une sauvegarde hors ligne est « indispensable », même moins fréquente que les autres.

Dans l'exemple, une seule donnée sur sept est à jour. Un test vieux de 202 jours passe en « À retester ».

Ce que cet onglet m'a appris sur notre site tient en une phrase : le code était copié deux fois, sa configuration zéro.

Le site a besoin de huit variables d'environnement pour fonctionner en production : son adresse officielle, la clé du service d'envoi de mails, les accès à l'anti-spam des formulaires, le secret qui signe les liens de téléchargement. J'ai demandé la liste à l'hébergeur, puis compté ce que mon poste en conservait. Huit d'un côté, une de l'autre. Les sept autres n'existaient qu'à un endroit.

C'est exactement ce que vise la recommandation R25 de l'ANSSI : « Il est important de sauvegarder les médias d'installation et les configurations des applications métier. » On pense aux données, rarement aux réglages qui permettent de les servir. Et en relisant notre propre documentation de reprise, j'ai vu qu'elle ne listait que sept variables : la huitième, ajoutée treize jours plus tôt, n'y figurait pas. Celle-là, je l'ai corrigée dans la foulée.

Étape 5 : tester la restauration, chronomètre en main

Deux tests, choisis parmi les activités à 4 heures et à 2 jours. La règle que je me suis fixée : partir d'un dossier vide, n'utiliser que ce qui est censé être sauvegardé, et noter le temps de chaque commande.

Test 1 : reconstruire le site sans l'hébergeur

Depuis que nous avons quitté WordPress, le site entier est un dépôt de code : les pages, les fiches de formation, les articles, les redirections. En théorie, un git clone suffit à tout récupérer.

time git clone $DEPOT_SITE site

6 secondes pour récupérer 557 commits. Le dernier avait été poussé à 18 h 30, cinq minutes avant le test : le RPO de 0 est tenu pour le code.

Le dépôt revient en 6,2 secondes, avec le dernier commit, poussé cinq minutes plus tôt. Dernière ligne de la capture : le seul fichier d'environnement présent est .env.example, le modèle vide. Je continue sans rien ajouter.

time npm ci
time npm run build

Le build passe sans aucune variable d'environnement : 228 pages en 11,5 secondes.

L'installation des dépendances prend 5,1 secondes (le cache de npm était déjà sur ce poste, une machine neuve mettra plus longtemps), le build 11,5 secondes. 228 pages générées, aucun message d'erreur. Entre la première commande et la dernière vérification, il s'est écoulé 28 secondes. J'avais déjà fait deux passes dans le quart d'heure précédent : le build y avait pris 15,6 puis 16,6 secondes. L'ordre de grandeur est stable, une demi-minute.

À ce stade, j'aurais pu m'arrêter et écrire « RTO tenu ». J'ai démarré le site reconstruit et j'ai vérifié trois choses.

Les pages répondent. Le robots.txt interdit tout le site aux moteurs, et le formulaire de rappel tombe en erreur 500.

Les pages répondent 200. Les deux lignes suivantes sont les erreurs du test.

Le robots.txt renvoie Disallow: /. Notre site se protège contre l'indexation d'une préproduction : tant que la variable qui porte son adresse officielle n'est pas posée, il interdit tout aux moteurs. Remis en ligne tel quel après un sinistre, il aurait demandé à Google de ne plus explorer aucune page. Le site aurait eu l'air de marcher.

Le formulaire de rappel répond une erreur 500. Le message affiché au visiteur est « Envoi impossible pour le moment. Réessayez plus tard. », et le journal du serveur donne la cause : la clé du service d'envoi de mails est absente. Sans elle, aucune demande de devis ni de rappel ne nous parvient.

La cause est la même dans les deux cas, et c'est le constat de l'étape précédente : la configuration n'existait que chez l'hébergeur. Le verdict du test tient donc en deux lignes. « Site en ligne » : partiel, parce que les pages reviennent vite mais que je n'ai testé ni la bascule du domaine ni le déploiement chez un autre hébergeur. « Formulaires du site » : échec.

Un dernier point que le chronomètre ne montre pas. Le clone a marché sans rien demander parce que mon poste était déjà connecté au dépôt. Sur une machine de secours, il faut le compte et son second facteur. Cela s'écrit dans la fiche réflexe, pas le jour du sinistre.

Test 2 : sortir les données du logiciel de gestion

Nos clients, nos sessions, nos conventions et nos factures vivent dans un logiciel de gestion de la formation en SaaS. L'éditeur s'occupe de sa disponibilité. Ma question était autre : s'il ne répond pas un matin de session, est-ce que j'ai de quoi retrouver qui forme qui, où, et à quelle heure ?

J'ai lancé un export complet des données, en lecture seule. Il a rendu 29,1 Mo en 8 secondes, et les sessions à venir y étaient.

La limite est apparue en ouvrant les fichiers. L'export ramène les données et des liens vers les pièces, pas les pièces elles-mêmes. Conventions signées, feuilles d'émargement et factures en PDF restent chez l'éditeur, et un lien vers un service en panne ne sert à rien. Je n'ai pas testé plus loin, ni la récupération des pièces une par une, ni le réimport.

Verdict : partiel. Cet export n'était programmé nulle part, et je l'ai supprimé à la fin du test : ce sont des données personnelles de clients, et une copie sans règle de conservation est un problème de plus.

Étape 6 : écrire les fiches réflexe et l'annuaire de crise

Une fiche réflexe tient sur une page : un scénario, les gestes dans l'ordre, qui les fait, combien de temps ils prennent. Elle s'écrit après le test, avec les durées mesurées. Celle du site reprend ce que j'ai fait à l'étape 5, plus les trois gestes que je n'ai pas testés.

Deux gestes seulement ont une durée mesurée. Les autres portent la mention « Non mesuré » : c'est le programme du prochain test.

Deux choses que le test m'a apprises sur ces fiches. Le dernier geste est un contrôle, pas une action : vérifier le robots.txt et envoyer un formulaire, parce que ce sont les deux pannes qui ne se voient pas en ouvrant la page d'accueil. Et la mention « Non mesuré » a sa place dans une fiche. Elle dit à celui qui l'exécutera que la durée annoncée s'arrête là.

L'onglet Annuaire de crise liste qui appeler : le décideur, le second administrateur, le support de chaque prestataire, avec un numéro et une adresse qui ne dépendent pas du système en panne. Une adresse de secours sur le domaine de l'entreprise ne sert à rien si c'est le domaine qui est tombé. L'annuaire s'imprime : le jour où on en a besoin, le classeur n'est peut-être plus ouvrable.

Étape 7 : planifier les tests et tenir le journal des écarts

Le journal des tests est l'onglet qui transforme un document en PRA. Une ligne par test : la date, ce qui a été fait, la durée mesurée, le périmètre (complet, partiel, échec), ce qui a cassé, la correction, et la date à laquelle elle a été faite.

Trois lignes, aucun « Tenu ». La colonne « Corrigé le » est encore vide.

Le classeur calcule le verdict. Un test complet dont la durée mesurée passe sous le RTO donne « Tenu ». Un test complet au-dessus donne « Dépassé ». Un test partiel reste « Partiel » quelle que soit sa durée, et c'est voulu : 28 secondes pour reconstruire des pages ne disent rien du temps qu'il faudra pour basculer un domaine. Le verdict remonte ensuite dans l'onglet Impact, en face de chaque activité.

Côté sauvegardes, le classeur passe en alerte toute donnée dont la restauration n'a pas été testée depuis 90 jours. Ce seuil est un choix de notre modèle, aucun texte ne le fixe : l'ANSSI dit « régulièrement ». Changez-le si votre rythme est autre, mais gardez-en un.

Au soir du 30 septembre, notre journal compte trois lignes, et chacune porte sa correction :

1. Copier la configuration du site hors de l'hébergeur, puis tester la bascule du domaine.
2. Compléter la documentation de reprise.
3. Programmer l'export des données de gestion et tester la récupération des pièces.

La deuxième est faite depuis le soir même, c'est la variable manquante de l'étape 4. Les deux autres restent ouvertes, et une ligne ne reçoit sa date que lorsque le test repasse. Aucune des trois ne demande d'achat.

Le classeur à télécharger est livré rempli avec l'exemple du cabinet de 25 salariés, en lignes à effacer. Nos propres lignes n'y sont pas.

Ce que ce PRA ne couvre pas

Je préfère le dire avant qu'un RSSI ne le fasse remarquer.

Ce que j'ai testé est étroit : un site et un export. Je n'ai pas testé la messagerie, le domaine, la comptabilité, ni la reprise du poste lui-même. Trois activités sur six portent encore « Jamais testé ».

Ce classeur n'est pas un PCA. Il ne dit pas comment on tient une session de formation pendant que le logiciel de gestion est en panne, il dit comment on retrouve les données. La fiche F2 est un début.

Il ne détecte rien. Un PRA suppose qu'on sait qu'il y a un sinistre. Savoir qu'un compte est compromis ou qu'une sauvegarde échoue en silence depuis trois mois relève de la supervision, et c'est un autre chantier.

Il ne remplace pas une analyse de risques ni une politique de sécurité. Pour une structure soumise à NIS2, ou pour un DSI qui doit défendre un budget devant sa direction, il faut la méthode entière : EBIOS Risk Manager, une politique de sécurité écrite, un plan de réponse à incident, des exercices de crise. C'est le programme de notre formation Cybersécurité : Gouvernance et PRA, qui s'adresse aux DSI, aux RSSI et aux responsables de la continuité, et où le module PRA se travaille sur les actifs et les scénarios de l'entreprise. Durée recommandée ≈ 5 jours, à ajuster au besoin.

Et il ne règle pas le facteur humain. Le scénario le mieux coté de notre tableau est une personne, pas une machine. Pour les équipes, le premier réflexe reste la sensibilisation des collaborateurs, et pour ceux qui administrent l'infrastructure, la sécurité des réseaux.

Pour aller plus loin

• Stratégie digitale : ce qu'on a fait sur mill-forma.fr en trois mois. Le chantier qui a transformé notre site en dépôt de code, sans lequel le test 1 aurait demandé une sauvegarde de base de données.
• Plan de formation : la méthode en 7 étapes et le modèle Excel. Le même format, un classeur et une étape par onglet, pour inscrire la montée en compétences de l'équipe informatique au plan de l'année.
• Fin de la subrogation OPCO au 1er octobre 2026. Ce qui change dans le circuit de paiement si vous financez une formation par votre OPCO.

Questions fréquentes