Plan de reprise d’activité (PRA) : définition, étapes et obligations

Un incendie de salle serveur, une panne de baie de stockage ou un rançongiciel qui chiffre les serveurs un samedi matin : le jour où le système d’information s’arrête, la question n’est plus de savoir si l’entreprise a des sauvegardes, mais en combien de temps elle peut retravailler, et avec quelles données. Le plan de reprise d’activité (PRA) est le document et le dispositif qui répondent à cette question à l’avance.

Ce guide reprend la définition du PRA informatique, sa différence avec le plan de continuité d’activité (PCA), les deux indicateurs qui le dimensionnent (RTO et RPO, ou DMIA et PDMA), les étapes de mise en place, la façon de le tester et ce que disent réellement les textes (RGPD, NIS 2, DORA) sur son caractère obligatoire, en distinguant ce qui est en vigueur de ce qui est seulement adopté. Les recommandations citées viennent de l’ANSSI, de la CNIL et du SGDSN.

Qu’est-ce qu’un plan de reprise d’activité (PRA) ? Définition

Un plan de reprise d’activité est l’ensemble des procédures documentées, des moyens techniques et de l’organisation humaine qui permettent de redémarrer le système d’information après un sinistre majeur, puis de revenir au fonctionnement normal. En anglais, on parle de Disaster Recovery Plan, d’où l’acronyme DRP informatique utilisé dans de nombreux contrats et outils.

La CNIL, dans sa fiche « Prévoir la continuité et la reprise d’activité », pose la distinction ainsi : assurer la continuité d’activité « consiste à prévoir des moyens de continuer de fonctionner, en général de manière dégradée, malgré des dysfonctionnements », tandis que la reprise d’activité « englobe toutes les actions nécessaires pour relancer un système arrêté ».

Un PRA ne se limite donc pas à la sauvegarde. Il couvre tout ce qu’il faut pour que les utilisateurs retravaillent : les données, mais aussi les serveurs ou machines virtuelles pour les restaurer, les applications, le réseau, les accès des collaborateurs, l’ordre de redémarrage, les personnes qui décident et celles qui exécutent. On parle parfois de PRI (plan de reprise informatique) pour désigner le seul volet technique ; dans la pratique des PME, « PRA informatique » et « PRI » désignent souvent le même document.

Pourquoi un PRA : les enjeux pour une PME

Le premier enjeu est la menace cyber. Dans son Panorama de la cybermenace 2025, publié le 11 mars 2026, l’ANSSI indique que 128 compromissions par rançongiciel ont été portées à sa connaissance sur l’année 2025, un nombre « légèrement en baisse » par rapport à 2024. Les PME, TPE et ETI « restent la catégorie d’entités la plus affectée par des rançongiciels » : elles représentent 48 % des victimes recensées sur l’année 2025, devant les collectivités territoriales (11 %) et les établissements de santé (8 %). L’ANSSI rappelle aussi que ces attaques peuvent entraîner « l’interruption des chaînes de production et des services fournis par la victime ». Autrement dit, la cible la plus fréquente est précisément l’entreprise qui pense être trop petite pour intéresser un attaquant.

Le deuxième enjeu est économique. Sans plan, la reprise s’improvise : on cherche le contrat du prestataire, on découvre que la dernière sauvegarde complète est ancienne, que personne ne connaît l’ordre de redémarrage des applications. Chaque heure d’arrêt pèse sur le chiffre d’affaires, les pénalités clients et la masse salariale inoccupée. Le PRA transforme cette improvisation en procédure.

Le troisième enjeu est la conformité : la protection des données personnelles impose déjà de savoir rétablir l’accès aux données (voir la partie sur les obligations), et les secteurs régulés ont des exigences explicites de tests.

PRA et PCA : quelle différence ?

Les deux plans sont complémentaires mais ne répondent pas à la même question.

• Le plan de continuité d’activité (PCA) vise à ce que l’activité ne s’arrête pas, ou continue en mode dégradé : redondance des équipements, haute disponibilité, procédures manuelles de secours, télétravail, site de repli. Il couvre l’ensemble de l’organisation, pas seulement l’informatique. Le site Entreprendre Service-Public le présente comme une stratégie dont l’objectif est de « réduire l’impact d’un sinistre sur le fonctionnement de l’entreprise et de retrouver au plus vite un niveau d’activité comparable à l’état précédent la crise ».
• Le plan de reprise d’activité (PRA) intervient quand l’arrêt a eu lieu : il accepte une interruption, et organise la remise en route dans un délai et avec une perte de données fixés à l’avance.

Pour une PME, viser la continuité totale sur tout le périmètre est rarement tenable. L’approche la plus courante combine un dispositif de continuité pour les quelques fonctions qui ne supportent aucun arrêt (site de vente en ligne, logiciel de production) et un PRA solide pour le reste (messagerie, comptabilité, fichiers). Le SGDSN, dans son « Guide pour réaliser un plan de continuité d’activité », traite d’ailleurs la reprise comme une composante du dispositif global de continuité.

Les sinistres et menaces à couvrir : cyberattaque, incendie, panne

Un PRA se construit à partir de scénarios. Les plus courants :

• Cyberattaque : rançongiciel, sabotage, compromission d’un compte administrateur. C’est aujourd’hui le scénario dimensionnant, car l’attaquant vise aussi les sauvegardes. L’ANSSI note dans son guide sur la sauvegarde qu’il « est fréquent qu’un attaquant tente de chiffrer, d’effacer ou de rendre indisponible l’infrastructure » de sauvegarde.
• Sinistre physique : incendie, dégât des eaux, inondation, coupure électrique prolongée sur le site qui héberge les serveurs.
• Panne technique : défaillance d’une baie de stockage, d’un hyperviseur, d’un lien réseau, mise à jour qui corrompt une base.
• Défaillance d’un prestataire : hébergeur, éditeur SaaS ou infogéreur indisponible, ou fin de contrat mal préparée.
• Erreur humaine : suppression massive de données, mauvaise manipulation d’un administrateur.

Chaque scénario ne demande pas la même réponse : un incendie impose un site de secours distant, un rançongiciel impose des sauvegardes hors d’atteinte et une restauration dans un environnement assaini.

RTO et RPO (DMIA et PDMA) : les deux indicateurs du PRA

Deux chiffres, fixés application par application, déterminent toute l’architecture du PRA. Les guides français emploient les sigles DMIA et PDMA, équivalents des sigles anglais RTO et RPO.

RTO ou DMIA : la durée maximale d’interruption admissible

Le RTO (Recovery Time Objective) est le temps maximal toléré entre l’incident et la reprise du service. L’ANSSI le rend par « durée maximale d’interruption admissible (DMIA) » ; le guide du SGDSN parle de « Durée Maximale d’Interruption Acceptable ». Si le RTO du logiciel de gestion est de quelques heures, l’équipe ou le prestataire doit pouvoir diagnostiquer, décider la bascule, restaurer et rouvrir les accès dans ce délai. Plus il est court, plus la solution est coûteuse : un RTO de quelques minutes suppose une réplication et une bascule automatisée, un RTO de plusieurs jours peut reposer sur des sauvegardes classiques.

RPO ou PDMA : la perte de données maximale admissible

Le RPO (Recovery Point Objective) est la quantité de données, exprimée en temps, que l’on accepte de perdre : c’est l’âge de la dernière copie restaurable. Avec une seule sauvegarde par nuit, une panne en fin d’après-midi fait perdre la journée de saisie. L’ANSSI, qui parle de « perte de données maximale admissible (PDMA) », précise que la sauvegarde ne couvre pas tous les besoins : pour une PDMA de moins de 24 h, elle recommande de privilégier d’autres solutions « telle que la réplication (synchrone ou asynchrone) ».

Ces deux valeurs ne se décident pas au service informatique seul : elles résultent de l’analyse d’impact menée avec les métiers.

L’analyse d’impact (BIA) : identifier les activités critiques

L’analyse d’impact sur l’activité (Business Impact Analysis, BIA) est la première étape d’un PRA sérieux, et celle que l’on saute le plus souvent. Elle consiste à lister les processus métier, les applications et données dont ils dépendent, puis à évaluer pour chacun ce que coûte une interruption : chiffre d’affaires non réalisé, salariés inoccupés, pénalités contractuelles, données à ressaisir, atteinte à l’image, obligations légales non tenues.

Elle se mène avec les responsables métier (direction financière, commerciale, production, RH), pas seulement avec la DSI. C’est souvent à ce moment qu’apparaissent des dépendances oubliées : un tableur critique sur un poste, un outil SaaS souscrit par un service, un serveur de licences dont dépend toute la production. Le résultat est un tableau qui classe les actifs par priorité de reprise, avec un RTO et un RPO pour chacun : c’est la base du budget du PRA, puisque le coût d’une heure d’arrêt se compare directement au coût du dispositif.

Le règlement européen DORA, applicable au secteur financier, a d’ailleurs rendu cette analyse obligatoire pour les entités qu’il vise : elles doivent procéder « à une analyse des incidences sur les activités de leurs expositions à de graves perturbations de leurs activités ».

Les étapes pour mettre en place un plan de reprise d’activité

Une fois les activités critiques et leurs objectifs connus, la mise en place suit en général cet ordre.

Obtenir l’engagement de la direction et nommer un responsable

Le PRA engage un budget et des arbitrages (quelles applications d’abord, quel niveau de perte accepté). Il doit être porté par la direction, avec un responsable identifié et un suppléant.

Cartographier le système d’information et les risques

Inventaire des serveurs, applications, flux, comptes d’administration, prestataires et contrats ; puis analyse des scénarios de sinistre pertinents pour l’entreprise.

Définir la stratégie de sauvegarde : règle 3-2-1 et copie hors ligne

L’ANSSI, dans son guide « Sauvegarde des systèmes d’information – Les fondamentaux » (version du 27/11/2025), recommande d’appliquer 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 ». Elle juge « indispensable » de mettre en place une sauvegarde hors ligne, « même si celle-ci est moins fréquente que les sauvegardes locales régulières en ligne ». Une sauvegarde hors ligne est, selon l’agence, une sauvegarde « sur un support déconnecté de tout SI ».

Le même guide demande de définir les durées de rétention (avec en exemple « 15 jours de sauvegardes journalières, 1 an de sauvegardes mensuelles, 5 ans de sauvegardes annuelles »), de dédier des comptes d’administration nominatifs à la sauvegarde et de chiffrer les flux de sauvegarde. Ces mesures visent un risque précis : un attaquant qui a pris la main sur le réseau cherchera d’abord à détruire les copies.

Choisir le site de secours : second site, cloud ou DRaaS

Il faut savoir où redémarrer si le site principal est inutilisable. Trois grandes options existent : un second site équipé (salle ou datacenter distant), un environnement de secours chez un hébergeur ou un fournisseur cloud, ou une offre de reprise « as a service » (DRaaS) dans laquelle le prestataire réplique les machines et fournit la capacité de calcul au moment de la bascule. Le cloud réduit le coût de l’infrastructure dormante, mais pose des questions de bande passante (combien de temps pour rapatrier les données ?), de compatibilité avec les applications anciennes et de localisation des données. Si vous comparez des hébergeurs, notre comparatif des solutions d’hébergement cloud recense les offres du marché.

Prévoir le réseau et les accès des utilisateurs

Restaurer les serveurs ne sert à rien si personne ne peut s’y connecter. Le PRA doit prévoir les accès distants (VPN, bureaux virtuels), la redirection des noms de domaine et des adresses publiques pour que les clients retrouvent les services en ligne, et la téléphonie de secours.

Rédiger le plan : contenu et documentation

Le document opérationnel, souvent appelé runbook, décrit pas à pas le déclenchement et la reprise. Il contient au minimum :

• les critères de déclenchement et la personne habilitée à déclarer le sinistre ;
• la liste des intervenants internes et externes avec leurs coordonnées (la CNIL recommande un plan « même sommaire, incluant la liste des intervenants ») ;
• l’inventaire des actifs critiques avec leur RTO, leur RPO et leur ordre de reprise ;
• les procédures de restauration et de bascule, application par application ;
• les procédures de vérification de l’intégrité des données restaurées ;
• le plan de communication de crise (salariés, clients, fournisseurs, assureur, autorités) ;
• la procédure de retour au site nominal.

Ce document doit rester accessible quand le système d’information est hors service : version papier, stockage externe sécurisé. L’ANSSI ajoute qu’il faut sauvegarder l’infrastructure de sauvegarde elle-même, avec notamment « les procédures d’import des sauvegardes, le catalogue de sauvegarde, la liste du matériel pour un déploiement sur un site de secours ».

Organiser la cellule de crise et la communication

Un sinistre informatique majeur est une crise d’entreprise : décisions juridiques (dépôt de plainte, notification d’une violation de données à la CNIL), relations avec l’assureur, communication aux clients. La CNIL recommande de « définir une organisation de gestion de crise » et de s’assurer que « les utilisateurs, prestataires et sous-traitants savent qui alerter en cas d’incident ». Le plan doit pouvoir être déclenché par plusieurs personnes, pas par un seul administrateur.

Tester le plan de reprise d’activité : méthodes et fréquence

Un PRA qui n’a jamais été testé reste une hypothèse. La CNIL classe parmi les erreurs à éviter le fait de « ne pas tester les mesures de continuité ou de reprise d’activité en amont », et l’ANSSI pose que « les sauvegardes doivent être testées régulièrement » et qu’une « procédure de restauration du SI doit être rédigée et régulièrement mise en œuvre ».

Les tests vont du plus léger au plus complet :

• Restauration unitaire : restaurer un fichier, une base, une machine virtuelle et vérifier qu’ils sont exploitables.
• Exercice sur table : dérouler le scénario avec les décideurs et l’équipe technique, sans toucher à la production, pour vérifier que chacun connaît son rôle.
• Test de bascule partiel : redémarrer une application critique sur l’environnement de secours et faire travailler quelques utilisateurs dessus.
• Test complet : bascule de l’ensemble du périmètre, mesure du RTO et du RPO réellement obtenus, puis retour au site principal.

La CNIL admet que des tests ciblés limitent l’impact sur la production, mais précise que « la continuité et la reprise des éléments les plus critiques doivent être testées de temps en temps » et qu’« un test de l’arrêt complet du système d’information doit également être envisagé ». Pour le secteur financier, DORA fixe un rythme : les plans de continuité et de rétablissement des TIC sont testés « au moins une fois par an », ainsi qu’en cas de modification substantielle des systèmes critiques. Hors secteur régulé, un test complet par an et des restaurations unitaires plus fréquentes constituent un repère raisonnable. Chaque test se consigne dans un registre : date, périmètre, RTO et RPO mesurés, écarts, actions correctives.

Retour à la normale et mise à jour du PRA

On prépare souvent la bascule vers le secours, plus rarement le retour. Or la CNIL cite explicitement comme erreur le fait de « ne pas prévoir de retour à la normale ». Après la crise, il faut rapatrier vers le site principal reconstruit les données modifiées pendant la période de secours, sans en perdre ni réintroduire de code malveillant. L’ANSSI rappelle qu’après un incident de sécurité, « les sauvegardes peuvent contenir des implants de l’attaquant » et recommande de réinstaller les systèmes « à partir d’images officielles de confiance ».

Le PRA vit ensuite avec le système d’information : nouvelle application, changement d’hébergeur, départ d’un administrateur, nouveau contrat de prestation. Chaque changement significatif doit déclencher une mise à jour du plan, et le plan doit être relu après chaque test et chaque incident réel.

Le PRA est-il obligatoire ? Ce que disent le RGPD, NIS 2 et DORA

Aucun texte n’impose à toutes les entreprises de rédiger un document intitulé « PRA ». En revanche, plusieurs textes imposent la capacité de reprise elle-même. Il faut distinguer ce qui s’applique déjà de ce qui est seulement adopté.

RGPD : pouvoir rétablir l’accès aux données

L’article 32 du RGPD demande au responsable du traitement et au sous-traitant de mettre en œuvre, « selon les besoins », « 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 », ainsi qu’« une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures ». Le texte ne prononce pas le mot « PRA », mais une entreprise incapable de restaurer son fichier clients après un rançongiciel aura du mal à démontrer qu’elle a respecté cette exigence. La CNIL, dans sa fiche sur la continuité et la reprise d’activité, recommande de « rédiger un plan de continuité (PCA) et de reprise (PRA) d’activité informatique ».

DORA : déjà applicable au secteur financier

Le règlement DORA s’applique « à partir du 17 janvier 2025 » et, comme tout règlement européen, il est directement applicable sans loi française. Son article 11 impose aux entités financières une « politique de continuité des activités de TIC », des « plans de réponse et de rétablissement des TIC » et des tests « au moins une fois par an ». Certaines petites entités (petites entreprises d’investissement non interconnectées, établissements de paiement exemptés…) relèvent à la place du « cadre simplifié de gestion du risque lié aux TIC » de l’article 16, qui écarte les articles 5 à 15. Son article 12 encadre les sauvegardes et précise que, lorsqu’elles restaurent des données avec leurs propres systèmes, les entités utilisent des systèmes « séparés physiquement et logiquement du système de TIC source ».

NIS 2 : adoptée au niveau européen, pas encore transposée en France

La directive NIS 2 a été publiée au Journal officiel de l’Union européenne le 27 décembre 2022. Les États membres devaient adopter les dispositions nationales « au plus tard le 17 octobre 2024 » et les appliquer à partir du 18 octobre 2024. Son article 21 range « la continuité des activités, par exemple la gestion des sauvegardes et la reprise des activités, et la gestion des crises » parmi les mesures minimales.

En France, la transposition passe par le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, qui transpose aussi la directive REC et le volet DORA. Selon l’ANSSI, il a été adopté par le Sénat les 11 et 12 mars 2025 et voté en commission spéciale de l’Assemblée nationale le 10 septembre 2025. Au 8 octobre 2026, la loi n’est pas promulguée et son examen à l’Assemblée nationale n’est pas achevé. L’ANSSI précise que NIS 2 entrera en vigueur en France « dès lors que l’ensemble des textes de transposition (loi, décrets, arrêtés) auront été promulgués », et que cette date « ne correspond pas à la date d’application de l’ensemble des exigences ». Concrètement, une PME qui serait qualifiée d’entité importante n’a pas encore d’obligation française au titre de NIS 2, mais les mesures attendues sont connues et un PRA testé en fait partie.

Normes et certifications

Deux normes servent de référence sans être obligatoires : l’ISO 22301:2019 (« Sécurité et résilience — Systèmes de management de la continuité d’activité — Exigences ») et l’ISO/IEC 27001:2022 pour la sécurité de l’information. Elles sont utiles pour structurer la démarche ou pour évaluer un prestataire certifié.

Les erreurs fréquentes

Confondre sauvegarde et PRA

Disposer de sauvegardes ne suffit pas si l’on n’a ni machines pour restaurer, ni procédure, ni bande passante suffisante pour rapatrier les données depuis le cloud dans le délai fixé. Le PRA inclut la capacité de calcul, le réseau et l’organisation.

Garder toutes les copies à portée de l’attaquant

Des sauvegardes sur un NAS joint au même domaine que la production seront chiffrées avec elle. D’où l’insistance de l’ANSSI sur la copie hors ligne et, en cas d’incident, sur l’isolement immédiat de l’infrastructure de sauvegarde, avec un mode « bouton rouge » d’urgence.

Ne jamais tester

Le système change en permanence ; un plan figé devient faux. Un test révèle des scripts obsolètes, des mots de passe perdus, des dépendances oubliées.

Oublier le retour à la normale et le facteur humain

Un plan qui ne peut être déclenché que par une seule personne, injoignable le jour du sinistre, échoue. Le retour au site principal doit être écrit aussi précisément que la bascule.

Baisser la sécurité en mode dégradé

La CNIL met en garde contre le fait de « réduire le niveau de sécurité des données lors de la mise en place d’une procédure dégradée ». Un accès de secours ouvert sans authentification forte devient une nouvelle porte d’entrée.

Choisir un prestataire pour son PRA

Beaucoup de PME confient la conception ou l’exploitation de leur PRA à une ESN, un infogéreur ou une agence spécialisée en cybersécurité. La qualité du travail ne se voit que le jour où tout va mal, d’où l’importance des critères de sélection. Chez La Fabrique du Net, nous recommandons de vérifier en priorité les points suivants.

• La méthode : demandez comment le prestataire mène l’analyse d’impact et qui il interroge côté métiers. Une offre qui commence par un produit de sauvegarde sans BIA est un mauvais signe.
• Les engagements contractuels : RTO et RPO écrits dans le contrat, application par application, avec les pénalités en cas de dépassement et la disponibilité réelle du support (astreinte la nuit et le week-end, ou simple ticket).
• Les tests inclus : un test de restauration ou de bascule par an au minimum doit figurer dans l’offre, avec un compte rendu.
• L’hébergement : localisation des données et des machines de secours, chaîne de sous-traitance, conformité RGPD.
• La réversibilité : le plan de réversibilité décrit comment vous récupérez vos données, vos configurations et votre documentation si vous changez de prestataire. Sans lui, le PRA dépend entièrement d’un contrat.
• Les références et certifications : ISO 27001 ou ISO 22301, références dans votre secteur et à votre taille.

Pour comparer des prestataires, consultez notre sélection d’agences de cybersécurité ; pour l’outillage, notre comparatif des logiciels de sauvegarde.

Modèle de PRA et grille d’auto-évaluation

📥 Télécharger notre modèle de PRA au format Excel (gratuit, sans inscription). Le classeur contient un guide, un inventaire des actifs critiques à compléter (avec RTO/RPO cibles par application), un plan de bascule pas à pas avec responsables et contacts d’astreinte, et un registre de tests : les trois documents de base d’un PRA exploitable le jour J. Les valeurs déjà saisies sont des exemples à remplacer par les vôtres.

Pour situer votre niveau de préparation avant de solliciter un prestataire, nous avons conçu cette grille simplifiée : chaque domaine rapporte de zéro à deux points.

Lecture : moins de cinq points, l’entreprise n’est pas en mesure de redémarrer de façon maîtrisée ; de cinq à huit points, les bases existent mais la fiabilité n’est pas démontrée ; au-delà de huit points, le dispositif est solide, à condition de continuer à le tester.

FAQ sur le plan de reprise d’activité

Quelle est la différence entre PCA et PRA ?

Le PCA (plan de continuité d’activité) vise à continuer de fonctionner malgré l’incident, souvent en mode dégradé, et couvre toute l’organisation. Le PRA (plan de reprise d’activité) organise le redémarrage après un arrêt, dans un délai (RTO) et avec une perte de données (RPO) fixés à l’avance. La CNIL résume : la continuité consiste à « continuer de fonctionner », la reprise « englobe toutes les actions nécessaires pour relancer un système arrêté ».

C’est quoi un PRA en informatique ?

Le PRA informatique est le volet du plan de reprise consacré au système d’information : sauvegardes, site de secours, procédures de restauration, ordre de redémarrage des applications, accès des utilisateurs. On l’appelle aussi PRI (plan de reprise informatique) ou, en anglais, DRP informatique (Disaster Recovery Plan).

Que signifient DMIA et PDMA ?

La DMIA est la durée maximale d’interruption admissible, équivalent du RTO anglais : le temps d’arrêt toléré avant la reprise. La PDMA est la perte de données maximale admissible, équivalent du RPO : l’âge maximal des données que l’on accepte de retrouver après restauration. L’ANSSI et le SGDSN emploient ces sigles dans leurs guides.

Le plan de continuité ou de reprise d’activité est-il obligatoire ?

Pas sous ce nom pour toutes les entreprises. Le RGPD, en vigueur, impose déjà de pouvoir rétablir l’accès aux données personnelles dans des délais appropriés et de tester régulièrement les mesures de sécurité. DORA, applicable depuis le 17 janvier 2025, impose des plans testés chaque année aux entités financières. NIS 2 en fera une mesure attendue des entités essentielles et importantes, mais sa loi de transposition n’était pas promulguée en France au 8 octobre 2026.

Que doit contenir un PRA ?

Au minimum : les critères et responsables de déclenchement, la liste des intervenants et leurs coordonnées, l’inventaire des actifs critiques avec RTO, RPO et priorité, les procédures de restauration et de bascule, la vérification des données restaurées, le plan de communication de crise, la procédure de retour à la normale et le registre des tests.

Comment tester un plan de reprise d’activité, et à quelle fréquence ?

Du plus simple au plus complet : restaurations unitaires, exercice sur table avec les décideurs, bascule partielle d’une application, puis test complet de bascule et de retour. DORA impose aux entités financières un test au moins une fois par an ; pour les autres entreprises, un test complet annuel et des restaurations plus fréquentes sont un repère courant. La CNIL recommande de tester régulièrement la restauration des sauvegardes et d’envisager un test d’arrêt complet du système d’information.

Comment rédiger un plan de reprise d’activité numérique pour une PME ?

Pour préparer la reprise informatique après un sinistre, partez de l’analyse d’impact avec les responsables métier, fixez un RTO et un RPO par application, mettez en place une sauvegarde 3-2-1 avec une copie hors ligne, choisissez un site de secours (cloud, DRaaS ou second site), rédigez le runbook avec la liste des intervenants, puis testez. Le modèle Excel proposé plus haut fournit la trame des trois documents de base.

Qu’est-ce qu’un plan de réversibilité ?

C’est la partie du contrat avec un hébergeur ou un infogéreur qui décrit comment l’entreprise récupère ses données, configurations et documentation en fin de contrat ou en cas de changement de prestataire : formats, délais, coûts, assistance. Il complète le PRA en évitant que la capacité de reprise dépende d’un seul fournisseur.

Combien coûte un PRA ?

Le budget dépend surtout des objectifs fixés : plus le RTO et le RPO sont courts, plus il faut de réplication et de ressources de secours réservées. Il comprend un coût de mise en place (analyse d’impact, architecture, rédaction, premier test) et un coût récurrent (stockage, licences, ressources de secours, tests, infogérance). Le bon repère est le coût d’une heure ou d’une journée d’arrêt, établi pendant l’analyse d’impact.