Un lundi matin, une PME industrielle de 85 personnes découvre que tous ses fichiers sont chiffrés. Message de rançon sur chaque poste. L’ERP est inaccessible. Les plans de fabrication sont bloqués. La direction appelle le prestataire informatique, qui découvre que les sauvegardes réseau ont aussi été chiffrées trois semaines plus tôt par l’attaquant. La seule sauvegarde disponible remonte à six mois. L’entreprise mettra 19 jours à reprendre une activité partielle et perdra deux clients majeurs qui ne peuvent pas attendre.

Ce scénario n’est pas une fiction catastrophiste. C’est la situation réelle de PME françaises plusieurs fois par semaine. La différence entre cette entreprise et une autre qui aurait traversé la même attaque en trois jours ? Un PRA testé, des sauvegardes immutables hors site, et une procédure de reprise documentée et connue de tous les acteurs.

Ce guide couvre la construction complète d’un PRA (Plan de Reprise d’Activité) et d’un PCA (Plan de Continuité d’Activité) adaptés à une PME : de la distinction des deux plans jusqu’aux exercices de test, en passant par la stratégie de sauvegarde et le modèle de document.

PRA et PCA : la différence expliquée simplement

Les deux acronymes sont souvent confondus ou utilisés indistinctement. Ils désignent pourtant deux réponses distinctes à des phases différentes d’une crise.

Le PCA : maintenir l’activité pendant la crise

Le Plan de Continuité d’Activité répond à la question : que fait l’entreprise pour continuer à fonctionner pendant que les systèmes sont indisponibles ? Il s’active dès le début de l’incident et couvre la période de crise.

Le PCA décrit les modes dégradés : comment la comptabilité gère les factures si l’ERP est inaccessible, comment la production suit les commandes si le système de gestion des stocks est hors ligne, comment les commerciaux communiquent avec les clients si la messagerie est compromise. Il peut mobiliser des processus manuels, des outils alternatifs, des ressources de substitution.

Un PCA efficace repose sur une idée simple : certains processus peuvent s’arrêter sans danger immédiat pour l’entreprise, d’autres ne peuvent pas. L’objectif du PCA est de maintenir les seconds en vie le temps que le PRA restaure les systèmes.

Le PRA : restaurer les systèmes après la crise

Le Plan de Reprise d’Activité (ou Plan de Reprise d’Activité Informatique dans sa déclinaison technique) répond à la question : comment les systèmes informatiques sont-ils restaurés, dans quel ordre, et selon quels critères de validation ?

Le PRA s’active dès que l’équipe technique commence la remédiation. Il documente les procédures de restauration pour chaque système critique, définit les priorités de reconstruction, et précise les vérifications à réaliser avant de remettre un système en production.

Les deux indicateurs fondamentaux : RTO et RPO

Tout PRA repose sur deux métriques qui doivent être définies avant d’écrire la moindre procédure.

Le RTO (Recovery Time Objective) est le délai maximum acceptable pour restaurer un système. Si votre ERP a un RTO de 4 heures, vos procédures de restauration doivent permettre d’atteindre cet objectif en conditions réelles — pas théoriques.

Le RPO (Recovery Point Objective) est la quantité maximale de données que vous acceptez de perdre, exprimée en durée. Un RPO de 24 heures signifie que vous tolérez de perdre les données de la dernière journée. Ce paramètre conditionne directement la fréquence de vos sauvegardes.

Ces deux indicateurs ne sont pas des décisions techniques. Ce sont des arbitrages métier : le coût d’une protection plus serrée (sauvegardes horaires, infrastructure de reprise rapide) versus le coût d’une perte de données ou d’une indisponibilité prolongée. La direction doit les valider, pas seulement le responsable IT.

Pourquoi chaque PME a besoin d’un PRA/PCA

Ce que disent les chiffres sur le ransomware

Le ransomware est aujourd’hui la menace principale qui justifie l’existence d’un PRA dans une PME. Selon le rapport annuel de l’ANSSI publié sur cyber.gouv.fr, les PME et ETI représentent la majorité des victimes de ransomware en France. Les raisons sont connues : elles disposent de données de valeur, de systèmes souvent peu segmentés, et de capacités de réponse limitées.

Le délai moyen de reprise d’activité après un ransomware sans plan de reprise documenté est de 21 jours, contre 3 à 5 jours pour les organisations disposant d’un PRA testé et de sauvegardes immutables. Cette différence n’est pas anecdotique : une interruption de 21 jours est fatale pour de nombreuses PME.

Autre donnée structurante : dans un ransomware sur deux, les sauvegardes réseau ont été compromises avant le déclenchement du chiffrement. L’attaquant accède au réseau, attend, et atteint les sauvegardes avant d’agir. Une architecture de sauvegarde non isolée n’offre qu’une fausse sécurité.

L’obligation NIS2 article 21.2.c

La directive NIS2, transposée en droit français en 2025, impose à toutes les entités dans son périmètre d’assurer la continuité de leurs activités, y compris « la gestion des sauvegardes, la reprise après sinistre et la gestion de crise » (article 21.2.c). L’absence d’un PRA/PCA documenté constitue un écart formellement sanctionnable lors des contrôles de l’ANSSI.

Pour les entreprises hors périmètre NIS2, les assureurs cyber ont durci leurs exigences depuis 2022. La plupart conditionnent leur couverture à l’existence de sauvegardes testées et, pour les contrats les plus récents, d’un PRA documenté. Une entreprise victime d’un ransomware sans sauvegarde testée peut se voir refuser l’indemnisation.

Notre guide conformité NIS2 détaille les critères d’entrée dans le périmètre de la directive. Notre page ISO 27001 couvre les exigences équivalentes du contrôle A.5.30 pour les organisations engagées dans une démarche de certification.

Construire votre PCA : maintenir l’activité en mode dégradé

Identifier les processus critiques

La première étape du PCA est un recensement des processus métier par criticité. Posez la question métier : si ce processus est indisponible pendant 48 heures, quel est l’impact sur le chiffre d’affaires, sur les obligations contractuelles, sur la sécurité des personnes ?

Classez chaque processus en trois niveaux :

Critique (arrêt intolérable au-delà de quelques heures) : facturation, gestion des commandes clients actives, chaîne de production si applicable, accès aux données réglementaires.

Important (arrêt tolérable quelques jours) : comptabilité courante, RH opérationnel, CRM.

Non critique (arrêt tolérable plusieurs semaines) : reporting, outils de communication interne secondaires, sites web institutionnels.

Pour chaque processus critique, identifiez le ou les systèmes dont il dépend, les données nécessaires, les personnes clés, et les prestataires impliqués. Cette cartographie est la base du PCA et du PRA.

Définir les modes dégradés

Pour chaque processus critique, répondez à cette question : si le système principal est indisponible, quelle solution de substitution permet de maintenir une activité minimale ?

Les réponses possibles : basculement sur un système alternatif préconfiguré, retour aux processus manuels avec des formulaires papier préparés à l’avance, délégation temporaire à un prestataire externe, utilisation d’un outil SaaS de secours. Ces modes dégradés doivent être documentés, testés avant l’incident, et connus des équipes qui devront les activer sous pression.

La notion d’activité minimale viable

Le PCA doit définir le niveau d’activité minimal que l’entreprise doit maintenir pour honorer ses obligations critiques. Ce niveau dépend du secteur : une entreprise industrielle peut maintenir la production avec des plannings papier pendant 48 heures, une société de services financiers ne peut pas accepter l’indisponibilité de ses outils de transaction.

Cette définition de l’activité minimale viable conditionne l’ensemble des choix d’investissement dans la résilience. Elle doit être validée par la direction générale, pas décidée unilatéralement par le responsable IT.

Construire votre PRA : restaurer les systèmes critiques

La stratégie de sauvegarde 3-2-1

La règle 3-2-1 est le standard de l’industrie pour une architecture de sauvegarde résistante :

3 copies des données : la production plus deux copies de sauvegarde
2 supports différents : par exemple, un NAS local et un stockage cloud
1 copie hors site : déconnectée du réseau de production, inaccessible depuis l’Active Directory de l’entreprise

Cette règle n’est pas théorique : elle répond directement au scénario ransomware décrit plus haut. Si l’attaquant compromet votre réseau et chiffre la copie locale, la copie hors site déconnectée reste intacte. C’est votre dernier recours.

Pour les PME avec un budget limité, la copie hors site peut être un disque physique déposé dans un coffre hors site et échangé hebdomadairement, ou un stockage objet cloud avec la politique d’immutabilité activée (AWS S3 Object Lock, Azure Blob Storage immutable, etc.).

Les sauvegardes immutables : le bouclier contre le ransomware

Une sauvegarde immutable est une sauvegarde qui ne peut pas être modifiée ou supprimée pendant une durée définie (la période de rétention), même par un compte administrateur compromis. Cette technologie est disponible dans la plupart des solutions de backup professionnelles et dans les principaux services cloud.

L’immutabilité est la protection la plus efficace contre le scénario où l’attaquant cible les sauvegardes avant de déclencher le ransomware. Même avec les identifiants admin, il ne peut pas effacer les sauvegardes couvertes par la période d’immutabilité.

M365 et Google Workspace : une idée reçue coûteuse

Microsoft et Google offrent des fonctionnalités de rétention et de corbeille dans leurs suites collaboratives. Ces fonctionnalités ne constituent pas une sauvegarde au sens opérationnel du terme.

Les limites concrètes : la rétention Exchange Online protège contre la suppression accidentelle d’emails, mais pas contre le chiffrement massif des fichiers OneDrive synchronisés via le client de bureau — scénario courant dans un ransomware. Les politiques de rétention SharePoint ont une durée maximale et des exceptions qui créent des angles morts. Microsoft indique explicitement dans ses conditions de service que la sauvegarde des données est la responsabilité du client.

Une solution de backup tierce dédiée à M365 ou Google Workspace (Veeam Backup for Microsoft 365, Druva, AvePoint, Backupify) est nécessaire pour garantir une restauration fiable en toutes circonstances.

Les procédures de restauration

Chaque système critique doit disposer d’une procédure de restauration documentée. Cette procédure doit être suffisamment précise pour être exécutée par quelqu’un qui n’a pas participé à sa rédaction — votre prestataire habituel peut être indisponible le jour J.

Contenu minimal de chaque procédure :

Référence de la sauvegarde à utiliser (emplacement, accès, identifiants séparés)
Séquence d’opérations pas à pas avec les commandes ou clics si nécessaire
Dépendances : quels systèmes doivent être restaurés avant celui-ci
Vérifications de validation : comment s’assurer que le système restauré fonctionne correctement avant remise en production
Durée estimée de la restauration (RTO de référence)
Contact de l’éditeur ou du prestataire en cas de blocage

Le plan de communication de crise

Un PRA sans plan de communication est incomplet. Pendant la crise, quatre audiences nécessitent une communication distincte :

En interne : les collaborateurs ont besoin de savoir ce qui se passe, ce qu’ils peuvent ou ne peuvent pas faire, et quand ils auront des nouvelles. L’absence de communication interne génère des rumeurs et des comportements contre-productifs.

Les clients : selon l’impact sur les délais ou la disponibilité des services, une communication client doit être préparée. Mieux vaut une communication proactive honnête qu’un silence suivi de questions anxieuses.

Les partenaires et fournisseurs : si la crise affecte des données partagées ou des flux EDI, les partenaires doivent être alertés rapidement.

Les autorités : notification CNIL sous 72h si des données personnelles sont exposées, notification ANSSI sous 24h pour les entités NIS2. Ces délais courent dès la prise de connaissance de l’incident, pas depuis sa résolution.

Le plan de réponse à incident détaille la structure complète de la cellule de crise et les procédures de notification légale.

Le chapitre sauvegardes : les points non négociables

La sauvegarde est le cœur du PRA. Sans sauvegarde exploitable, le PRA est un document vide. Voici les points non négociables à vérifier dans votre stratégie actuelle.

Fréquence et rétention

La fréquence des sauvegardes doit être alignée sur vos RPO. Si votre RPO est de 4 heures, vous avez besoin de sauvegardes toutes les 4 heures. Si votre RPO est de 24 heures, une sauvegarde quotidienne suffit — à condition qu’elle soit fiable.

La rétention doit être suffisamment longue pour couvrir le délai de détection d’un ransomware. Les attaquants modernes restent en moyenne plusieurs semaines sur un réseau avant de déclencher le chiffrement. Une rétention de 30 jours est un minimum. Si vos sauvegardes les plus récentes sont corrompues, vous devez pouvoir remonter à une version saine d’il y a trois semaines.

Isolation et séparation des accès

Les identifiants d’accès aux sauvegardes doivent être distincts des identifiants de production. Un compte de service dédié aux sauvegardes, avec des droits limités à l’écriture sur le stockage de sauvegarde, ne doit pas être accessible via les comptes utilisateurs ou administrateurs du domaine. Cette séparation est la mesure la plus simple et la plus efficace pour protéger les sauvegardes d’un attaquant qui a compromis l’Active Directory.

Copie hors ligne

Au moins une copie de sauvegarde doit être physiquement ou logiquement déconnectée du réseau de production. Les options pratiques pour une PME : disque externe déposé hors site et échangé selon un planning défini, stockage objet cloud avec immutabilité activée et accès via des identifiants distincts non exposés au réseau interne.

Test de restauration trimestriel

Une sauvegarde non testée est une hypothèse, pas une garantie. Le test de restauration consiste à restaurer un système depuis la sauvegarde dans un environnement isolé et à vérifier que le résultat est exploitable. Ce test doit être planifié, documenté, et ses résultats archivés.

Le test révèle deux catégories de problèmes que la simple vérification des jobs de sauvegarde ne détecte pas : les corruptions silencieuses de données dans les fichiers de sauvegarde, et les écarts entre le RTO théorique et le temps réel de restauration. Un système prévu pour se restaurer en 2 heures qui en prend en réalité 8 est un problème de planification, pas une fatalité — à condition de le découvrir avant la crise.

Tester votre PRA/PCA : deux niveaux d’exercice

Un plan non testé est un plan dont on ignore s’il fonctionne. Les tests doivent être réguliers, progressifs, et leurs résultats doivent alimenter les mises à jour du plan.

Le test de restauration réelle

C’est le test technique fondamental du PRA. Trimestriellement, l’équipe IT restaure un ou plusieurs systèmes depuis les sauvegardes dans un environnement de test isolé. Les métriques à mesurer : temps de restauration réel comparé au RTO théorique, état des données restaurées comparé au RPO théorique, obstacles rencontrés (accès introuvables, documentation incomplète, dépendances manquantes).

Documentez chaque test avec les résultats et les actions correctives identifiées. Cette documentation est une preuve de conformité utile pour les assureurs et les auditeurs NIS2.

L’exercice tabletop

L’exercice tabletop est un exercice de simulation de crise sans mise en jeu des systèmes réels. Les membres de la cellule de crise se réunissent deux heures autour d’un scénario fictif : ransomware, incendie du datacenter, panne de l’hébergeur principal.

Un facilitateur présente la situation initiale, fait des questions sur les décisions de l’équipe, et injecte des événements supplémentaires au fil de l’exercice : « les sauvegardes réseau sont aussi chiffrées », « votre prestataire IT est en vacances », « un journaliste vous appelle ». L’objectif est de faire émerger les décisions non documentées dans le plan — et il y en a toujours.

Le debriefing produit une liste d’actions correctives concrètes à intégrer au plan avant le prochain exercice. Consultez notre guide dédié aux exercices de crise cyber pour les scénarios et la méthode détaillée.

Compléter les exercices par des simulations de phishing

Le PCA et le PRA couvrent la réponse organisationnelle à une crise déclenchée. Les simulations de phishing couvrent la prévention en aval : en testant régulièrement la capacité des collaborateurs à détecter et signaler un email malveillant, elles réduisent la probabilité que la crise se déclenche. Une attaque stoppée au stade du phishing initial n’active ni le PCA ni le PRA.

Notre outil de test de sécurité email permet de vérifier en quelques minutes la robustesse de votre configuration email (SPF, DKIM, DMARC) contre les attaques par usurpation d’identité.

Modèle de plan PRA/PCA pour une PME

Ce squelette couvre les sections essentielles d’un document PRA/PCA opérationnel pour une PME de 20 à 250 personnes.

1. Objet, périmètre et gouvernance

Système d’information couvert (sites, environnements cloud, applications SaaS critiques), périmètre exclu, version du document, date de dernière révision, nom du responsable du plan et de son suppléant.

2. Analyse d’impact métier

Tableau des processus critiques avec leur niveau de criticité, le RTO et le RPO associés, et les systèmes dont ils dépendent. C’est la partie la plus structurante du document — elle conditionne toutes les décisions de priorité dans la restauration.

3. Cellule de crise et contacts d’urgence

Membres de la cellule de crise, rôles, coordonnées personnelles directes (hors messagerie professionnelle). Arbre d’appel. Contacts externes : prestataire IT, hébergeur, assureur cyber, ANSSI (3018), numéro d’urgence de l’éditeur ERP. Ce chapitre doit tenir sur une page imprimable.

4. Plan de Continuité d’Activité (PCA)

Pour chaque processus critique : mode dégradé activé en cas d’indisponibilité, ressources alternatives, procédure d’activation, critères de bascule vers le mode normal.

5. Architecture de sauvegarde

Description de l’architecture 3-2-1 en place : emplacement de chaque copie, fréquence, rétention, outil utilisé, politique d’immutabilité, accès. Couverture M365/Google Workspace. Planification des tests trimestriels.

6. Procédures de restauration

Fiche par système critique : référence sauvegarde, séquence de restauration, dépendances, validations avant remise en production, durée estimée.

7. Plan de communication de crise

Modèles de messages pour chaque audience (interne, clients, partenaires), processus de validation avant envoi, personne autorisée à s’exprimer publiquement, délais légaux de notification.

8. Tests et exercices

Calendrier des tests de restauration et des exercices tabletop, résultats des tests précédents, actions correctives en cours.

9. Gestion documentaire

Version, auteur, approbateurs, date de prochaine révision. Le plan est révisé après chaque incident réel, chaque exercice, et chaque changement d’infrastructure ou d’organisation significatif.

Questions fréquentes sur le PRA/PCA pour les PME

Thomas Ferreira, CISSP, GCFA — Consultant en cybersécurité et continuité d’activité. Thomas accompagne des PME et ETI françaises dans la construction de plans de reprise et de continuité, l’architecture de sauvegarde et les exercices de simulation de crise. Ce guide s’appuie sur les guides ANSSI publiés sur cyber.gouv.fr, le guide EBIOS RM, les contrôles ISO 27001 Annexe A.5.29 et A.5.30, et les exigences de l’article 21.2.c de la directive NIS2.

Pour compléter votre démarche de résilience, consultez notre plan de réponse à incident pour la gestion de la crise active, et notre guide des exercices de crise cyber pour la méthode tabletop détaillée.