À quoi ressemble un PRA informatique, et comment le tester
Un PRA informatique, ou plan de reprise d'activité, décrit ce que l'entreprise doit relancer après un sinistre, dans quel ordre, à partir de quelles sauvegardes et en combien de temps. Un PRA de PME tient en quelques pages : la liste des services critiques, les objectifs de reprise fixés avec la direction, les procédures de restauration et les personnes à prévenir. Ce document ne vaut que s'il a été éprouvé. C'est pourquoi on le teste régulièrement, en général une fois par an, et après chaque changement important du système d'information.
Les rubriques d'un PRA informatique
Un document écrit pour le jour de la panne
Un plan de reprise d'activité n'est pas un rapport technique que l'on valide puis que l'on oublie. Il sera lu un matin de crise, par un dirigeant qui découvre une demande de rançon sur l'écran du serveur et par des salariés qui attendent devant des postes inutilisables. Sa forme doit servir ce moment-là. On y trouve des étapes numérotées, des noms et des numéros de téléphone plutôt que des principes, et l'on en garde une copie imprimée hors des locaux. Le PRA n'est d'ailleurs qu'une pièce de la continuité de service, qui couvre aussi la prévention et le travail en mode dégradé.
Les rubriques, dans l'ordre
Le plan s'ouvre sur son périmètre et sur les scénarios qu'il couvre : panne de serveur, rançongiciel, incendie, coupure prolongée de la connexion internet. Il désigne ensuite la cellule de crise, c'est-à-dire la personne qui déclenche le plan, celle qui décide et celle qui prévient les salariés, les clients et l'assureur. Le cœur du document recense les services critiques et ce dont chacun dépend ; pour chaque service, il indique un objectif de reprise, l'emplacement des sauvegardes et la procédure de restauration pas à pas. Les dernières pages rassemblent les vérifications à faire avant de rouvrir le service, les contacts des fournisseurs et des éditeurs, puis l'historique des tests.
Un exemple de PRA pour une PME de vingt salariés
Le cadre : une entreprise de négoce
Prenons une PME de vingt personnes qui vend du matériel aux professionnels. Son logiciel de gestion commerciale, installé sur un serveur dans les locaux, contient les devis, les commandes, les stocks et la facturation ; les documents de l'entreprise sont rangés sur ce même serveur, tandis que la messagerie est hébergée dans Microsoft 365. Une sauvegarde part chaque nuit vers un stockage externe, et une copie reste sur un NAS dans le bureau. Le scénario retenu est celui d'un rançongiciel qui chiffre le serveur un mardi matin, en pleine prise de commandes.
Ce que le plan prévoit, service par service
Le dirigeant, ou son adjoint en son absence, déclenche le plan et appelle le prestataire informatique, dont le numéro figure en première page. Le serveur est aussitôt isolé du réseau, et la consigne est claire : personne ne redémarre les postes au hasard. La priorité va au logiciel de gestion, sans lequel aucune commande ne sort : la direction s'est fixé pour objectif de le rouvrir dans la journée, avec une perte limitée aux saisies faites depuis la veille au soir. Les dossiers partagés suivent le lendemain, les archives des années précédentes en fin de semaine.
La restauration part de la copie externe, parce que le NAS, branché au même réseau, a pu être touché lui aussi. Elle se fait sur un serveur de remplacement prévu dans le plan, jamais sur la machine compromise tant qu'on ignore par où l'attaque est passée. Avant de rouvrir l'accès, une commerciale vérifie que les commandes de la veille sont présentes et qu'une facture s'édite correctement. Pendant ce temps, l'équipe note les commandes téléphoniques dans un tableur partagé, qu'elle ressaisira ensuite. Ce mode dégradé relève du plan de continuité, mais le PRA le rappelle pour que chacun sache quoi faire.
Fixer le RPO et le RTO du plan
Deux questions posées à la direction
Le RPO, que l'on traduit par perte de données maximale admissible, répond à une question simple : combien de travail accepte-t-on de perdre ? Le RTO, ou durée maximale d'interruption admissible, en pose une autre : combien de temps peut-on se passer de ce service ? Ces valeurs relèvent de l'activité bien plus que de la technique, et c'est à la direction de les fixer, service par service. Dans notre entreprise de négoce, perdre une matinée de commandes oblige à rappeler des clients, alors qu'une semaine de modifications perdue sur les archives passerait presque inaperçue.
Le prix de chaque heure gagnée
Plus les objectifs sont courts, plus la reprise coûte cher à préparer. Avec une sauvegarde par nuit, on peut perdre jusqu'à une journée de travail ; viser quelques heures suppose des sauvegardes plus fréquentes, voire une réplication continue. Le temps de restauration dépend aussi de la construction des copies, et le choix entre sauvegarde complète, incrémentielle ou différentielle pèse directement sur le RTO. Un redémarrage très rapide exige parfois un serveur de secours, qu'il faut acheter et entretenir. Le bon objectif est celui dont le coût reste inférieur aux pertes qu'entraînerait l'arrêt.
Tester le PRA : méthode et fréquence
Du test sur table à la restauration réelle
Le test sur table réunit la direction et les personnes citées dans le plan autour d'un scénario. On déroule les étapes à voix haute, et l'on découvre vite qu'un numéro a changé ou qu'une décision n'a pas de responsable. La restauration partielle vérifie ensuite qu'un dossier ou une boîte aux lettres revient intact depuis la sauvegarde. L'essai complet, enfin, consiste à remonter un serveur entier sur une machine isolée, sans toucher à la production, en chronométrant chaque étape jusqu'à l'ouverture du logiciel métier. Lui seul dit si le RTO inscrit sur le papier est tenable. Les écarts constatés, comme une licence restée liée à l'ancien serveur, sont consignés et corrigés avant le test suivant.
Au moins une fois par an, et à chaque changement
Un rythme annuel convient à la plupart des PME, assez rapproché pour que le plan ne vieillisse pas. Un test supplémentaire s'impose après tout changement notable, qu'il s'agisse d'un nouveau serveur, d'un logiciel métier remplacé ou d'un déménagement. Les structures concernées par la directive NIS2 ont une raison de plus de s'y tenir : son article 21 range la gestion des sauvegardes et la reprise des activités parmi les mesures de gestion des risques qu'elles doivent prendre, et leur demande d'évaluer l'efficacité de ces mesures ; le guide consacré à l'audit NIS2 et à la mise en conformité détaille ces obligations.
Éviter les erreurs qui rendent un PRA inutile
Les pièges les plus fréquents
La première erreur consiste à ranger le plan et les mots de passe au seul endroit qui risque de disparaître : le serveur lui-même. La deuxième touche la sauvegarde. Une copie branchée en permanence au réseau sera chiffrée par le rançongiciel en même temps que les données qu'elle devait protéger, et c'est pourquoi le plan de sauvegarde informatique doit prévoir au moins un exemplaire hors des locaux et hors d'atteinte. Viennent ensuite les dépendances oubliées, comme ce logiciel métier qui refuse de démarrer tant que son serveur de licences n'a pas été restauré. Un plan jamais relu renvoie vite à un serveur remplacé depuis ou à un logiciel abandonné. Quant au plan qui repose sur une seule personne, il ne sert à rien le jour où elle est en congé.
Le PRA tel que nous le construisons
Chez KERIONIS, nous construisons le PRA avec vous, à partir de votre activité réelle et non d'un plan type. Nous recensons les services critiques et leurs dépendances, nous fixons ensemble les objectifs RPO et RTO, que nous inscrivons ensuite au contrat, et nous écrivons des procédures faites pour être suivies sans hésiter. Nous mettons le plan en œuvre, nous le testons chaque année et nous le revoyons à chaque évolution de votre informatique, qu'il s'agisse d'un nouveau serveur ou d'un logiciel métier qui change. Il s'appuie sur une sauvegarde quotidienne hébergée en France, dont les restaurations sont testées régulièrement.
Préparer la reprise de votre activité
Voyez comment nous assurons la continuité de service : sauvegarde vérifiée chaque jour, PRA testé chaque année, supervision continue.
Notre page détaille aussi la démarche du PRA, étape par étape.
Questions fréquentes sur ce guide
Que contient un plan de reprise d'activité informatique ?
Un PRA informatique recense les services critiques de l'entreprise et leurs dépendances, fixe pour chacun la perte de données (RPO) et la durée d'arrêt (RTO) jugées acceptables, puis décrit pas à pas les procédures de restauration. Il précise aussi qui déclenche le plan, qui prévenir et comment vérifier que tout fonctionne avant de rouvrir le service.
Comment tester un PRA ?
Un PRA se teste d'abord sur table : on déroule le scénario avec les personnes citées dans le plan, puis on vérifie la restauration de fichiers ou de boîtes aux lettres. L'essai le plus complet consiste à remonter un serveur entier sur une machine isolée et à mesurer le temps réel de reprise. Un test par an au moins, et après chaque changement important, garde le plan fidèle à la réalité.
Quelle différence entre PRA et PCA ?
Le PRA organise la reprise après l'incident : quel service relancer en premier, à partir de quelles sauvegardes et en combien de temps. Le PCA, plan de continuité d'activité, vise à faire tourner l'entreprise pendant l'incident, par exemple avec un accès de secours à la messagerie ou des procédures en mode dégradé. Les deux se complètent.