PRA informatique PME : guide pour un plan testé et chiffré

Frédéric Allain, Fondateur de CTO Externe
20 ans d’expertise en infrastructure, sécurité IT et pilotage de projets numériques · Basé à Damigny (61)
Voir le profil complet

82 % des PME non préparées ne survivent pas à un crash informatique majeur. Pourtant, la plupart des dirigeants que j’audite croient avoir un plan, jusqu’à ce qu’on teste. Ce guide vous donne la méthode pour construire un PRA informatique pour PME qui tient debout en conditions réelles, sans noyer votre budget dans du DRaaS surdimensionné.

Vous dirigez une PME et vous voulez vérifier si votre plan tiendrait vraiment ?
Diagnostic gratuit en 30 minutes, sans engagement.
Réserver un diagnostic gratuit

PRA vs PCA : la distinction qui change tout

Les termes PRA (Plan de Reprise d’Activité) et PCA (Plan de Continuité d’Activité) sont souvent confondus. La différence n’est pas une coquetterie de jargon, elle conditionne votre budget et vos priorités.

CritèrePRA (Plan de Reprise)PCA (Plan de Continuité)
PérimètreSystème d’information uniquementToute l’entreprise (locaux, équipes, IT, fournisseurs)
ObjectifRedémarrer le SI après un sinistreMaintenir l’activité métier même en mode dégradé
Coût pour PME 80 salariés5 à 30 k€ initial + maintenance30 à 100 k€ + équipe dédiée
Pertinent pour95 % des PMEETI, secteurs réglementés (santé, banque)

Pour la quasi-totalité des PME de 10 à 250 salariés, ce qu’il faut construire est un PRA, pas un PCA. Si quelqu’un vous propose un PCA à 80 k€ pour une PME de 50 personnes sans contrainte réglementaire, fuyez : c’est de la vente.

Les 4 ingrédients d’un PRA opérationnel

Un PRA digne de ce nom repose sur quatre éléments précis. Si l’un manque, votre plan est de la fiction.

Le RTO (Recovery Time Objective)

C’est la durée maximale acceptable d’interruption d’un service avant qu’il soit remis en route. Le RTO se définit par service, pas globalement. Votre fileshare peut peut-être tomber 4 heures sans drame ; votre ERP de production, peut-être 30 minutes au-delà desquelles vous perdez des commandes irrécupérables.

Le RPO (Recovery Point Objective)

C’est la perte de données maximale acceptable. Concrètement : à quelle heure remontent vos dernières sauvegardes utilisables ? Si vous sauvegardez tous les soirs à minuit, votre RPO est de 24 heures. Si vous répliquez en continu, votre RPO est de quelques minutes. Plus le RPO est court, plus le coût grimpe.

Les scénarios couverts

Un PRA n’est pas « un plan pour un sinistre ». C’est plusieurs plans pour des scénarios distincts : ransomware, panne matérielle critique, sinistre du site (incendie, dégât des eaux), erreur humaine destructive. Les réponses techniques sont totalement différentes.

Les tests documentés

C’est l’ingrédient que 80 % des PRA n’ont jamais. Sans test, vous ne savez pas si votre plan fonctionne. On y reviendra : c’est le sujet le plus critique de cet article.

Comment construire votre PRA en 6 étapes

Voici la méthode que j’applique chez les PME que j’accompagne, étalée sur 4 à 8 semaines selon la complexité du SI.

Étape 1 : Inventaire des actifs critiques (1 semaine)

Listez tous les services métier qui tournent dans votre SI : ERP, CRM, fileshare, messagerie, outils métier, applications développées en interne, sites web, environnements de développement…

Pour chaque service, notez :

  • À qui il sert (commerce, production, RH, direction)
  • L’impact si indisponible (commande perdue, salaire pas payé, contrat annulé)
  • Les données qu’il contient et leur sensibilité (RGPD)

L’erreur classique : vouloir tout protéger au même niveau. Vous finissez avec un budget infini ou un PRA bâclé partout. La triage trois catégories suffit : critique (RTO < 4h), important (RTO < 24h), secondaire (RTO < 1 semaine).

Étape 2 : Calibrer RTO et RPO par service (3 à 5 jours)

Asseyez-vous avec les responsables métier (pas seulement la DSI ou l’IT). Pour chaque service de votre inventaire :

  • Combien de temps pouvez-vous tenir sans ? (RTO)
  • Combien de données pouvez-vous perdre ? (RPO)

Exemple pour une PME industrielle de 80 salariés :

ServiceRTO acceptableRPO acceptable
ERP / commandes1 heure15 minutes
CRM / contacts4 heures24 heures
Fileshare4 heures24 heures
Messagerie8 heures4 heures
Outils de dev1 semaine1 jour

Ces chiffres conditionnent le budget. Un RPO de 15 minutes sur l’ERP exige une réplication active vers un site secondaire ; un RPO de 24 heures se contente d’une sauvegarde nocturne classique.

Étape 3 : Concevoir les scénarios (1 semaine)

Construisez trois scénarios distincts au minimum :

Scénario 1 : Ransomware : un chiffrement étend ses tentacules sur les serveurs et les sauvegardes connectées. La réponse : isoler, restaurer depuis une sauvegarde immuable (off-site ou air-gap), notifier la CNIL si données personnelles, déposer plainte. Délai typique de reprise : 2 à 5 jours.

Scénario 2 : Panne matérielle critique : un serveur principal lâche, un baie de stockage est corrompue. La réponse : bascule sur du matériel de spare ou réinstallation, restauration des données depuis sauvegarde. Délai : quelques heures à 1 jour selon les contrats matériel.

Scénario 3 : Sinistre du site : incendie, dégât des eaux, inondation. La réponse : redémarrage complet sur infrastructure cloud ou site secondaire. Délai : 1 jour à 1 semaine si rien n’a été préparé hors-site.

Pour chaque scénario, vous documentez : qui décide quoi, dans quel ordre, avec quels outils.

Étape 4 : Documenter et industrialiser (2-3 semaines)

Un PRA non documenté n’existe pas. Vous devez produire :

  • Un runbook étape par étape (en français, lisible par quelqu’un qui découvre votre SI, pas par votre admin sys habituel qui est peut-être en arrêt maladie ce jour-là)
  • Un schéma d’infrastructure à jour (réseau, serveurs, dépendances)
  • Une liste de contacts critiques : hébergeur, fournisseur matériel, éditeurs logiciels critiques, assureur cyber, prestataire cyber d’urgence
  • Les identifiants d’urgence stockés dans un gestionnaire de mots de passe d’urgence (pas dans Excel)

Règle d’or : tous ces documents doivent être stockés en dehors du système qui peut tomber. Pas sur le SharePoint d’entreprise. Pas sur le NAS local. Un cloud externe ou une copie papier dans le coffre. Sinon le jour J, vous ne pouvez pas accéder à votre propre plan.

Étape 5 : Tester (le sujet le plus critique)

C’est ici que se joue 80 % de la valeur de votre PRA, et c’est la partie que les concurrents traitent en deux lignes.

Sans test régulier, votre PRA est de la fiction. J’ai vu sur le terrain :

  • Des sauvegardes qui tournent depuis 2 ans mais n’ont jamais été restaurées une seule fois
  • Des sauvegardes vérifiées par un script qui valide la taille du fichier, pas son contenu
  • Des sauvegardes qui se font… sur le même disque que les données sources

Le test minimal recommandé :

TestFréquenceDuréeObjectif
Restauration partielle (1 fichier, 1 dossier)Mensuel30 minVérifier que la sauvegarde est lisible
Restauration complète d’un service non-critiqueTrimestriel2-4 hVérifier que la chaîne complète fonctionne
DR drill (bascule complète sur infrastructure de secours)Annuel1-2 joursValider le RTO réel en conditions réalistes
Test après changement majeur du SIÉvénementielVariableGarantir que le PRA est toujours valable

L’audit révèle souvent qu’un PRA « en place » depuis 3 ans n’a jamais été testé une seule fois en conditions réelles. Un audit numérique pour PME inclut systématiquement ce test : c’est souvent la première restauration jamais réalisée.

Étape 6 : Maintenir (continu)

Un PRA vit. Chaque évolution du SI peut l’invalider :

  • Migration vers un nouveau cloud → nouveau runbook
  • Changement d’ERP → nouveaux RTO/RPO à calibrer
  • Arrivée de nouvelles équipes → onboarding sur le runbook
  • Modification réglementaire (NIS2, RGPD) → revue des engagements

Revue minimale annuelle. Tout PRA non revu depuis plus de 12 mois doit être considéré comme suspect.

Combien ça coûte vraiment

Voici des ordres de grandeur que j’observe pour les PME françaises, hors secteurs réglementés.

ComposantPME 25 salariésPME 80 salariésPME 150 salariés
Solution sauvegarde + restauration testée100 à 300 €/mois300 à 800 €/mois800 à 2 000 €/mois
DRaaS cloud (réplication SI)300 à 800 €/mois800 à 3 000 €/mois3 000 à 8 000 €/mois
Audit + conception PRA initiale2 à 4 k€4 à 8 k€8 à 15 k€
Tests annuels (drill + partiels)1 à 2 k€/an2 à 5 k€/an5 à 12 k€/an

À comparer au coût d’une interruption non maîtrisée : 5 000 € à 100 000 € par heure selon le secteur d’activité (source : étude Naitways, ordres de grandeur cohérents avec les chiffres ANSSI sur les coûts de cyberattaque PME).

Arbitrage simple : si le coût d’une heure d’interruption dépasse 5 000 €, investir dans du DRaaS se justifie. En-deçà, une stratégie sauvegarde + restauration testée + runbook documenté suffit largement.

Les 5 erreurs récurrentes qui rendent un PRA inutile

  1. Les sauvegardes ne sont jamais testées. Numéro 1 absolu. Une sauvegarde non testée n’est pas une sauvegarde, c’est un fichier sur un disque.
  2. Le PRA est documenté mais jamais ouvert. Il a été écrit en 2022 par un prestataire, classé dans un dossier réseau, et personne ne l’a relu depuis. Le SI a évolué, le PRA non.
  3. Les sauvegardes sont stockées sur le même réseau que la production. Un ransomware moderne chiffre tout ce qu’il atteint, y compris les sauvegardes connectées. Sans copie immuable ou air-gap, pas de protection ransomware.
  4. Pas de RTO/RPO formalisé par service. En situation d’incident, personne ne sait quoi prioriser, et chacun improvise selon sa peur du moment.
  5. Le PRA prévoit « un sinistre générique », pas les vrais scénarios. Or la réponse à un ransomware n’a rien à voir avec la réponse à une panne hardware. Un seul runbook fourre-tout = des décisions trop lentes le jour J.

Un audit numérique pour PME commence systématiquement par identifier ces cinq erreurs. Dans 80 % des cas, au moins trois sont présentes.

PRA MVP : par où commencer en 2 semaines sans budget initial

Si vous lisez cet article et que votre PME n’a rien d’un PRA aujourd’hui, ne vous lancez pas dans un projet à 30 k€. Démarrez par un PRA Minimum Viable Product qui couvre déjà 70 % du risque réel :

Semaine 1

  • Inventaire des 3 services métier les plus critiques (max)
  • Audit des sauvegardes existantes (que sauvegarde-t-on, où, à quelle fréquence)
  • Test de restauration d’un fichier choisi au hasard dans la sauvegarde de la veille, si ça échoue ici, vous avez déjà identifié un problème majeur

Semaine 2

  • Rédaction d’un runbook simple d’une page par scénario (3 scénarios max)
  • Identification des contacts d’urgence (hébergeur, prestataire matériel, assureur)
  • Stockage de la documentation hors du SI (cloud externe, papier)

Coût : zéro si fait en interne, 2 à 4 jours de prestataire externe sinon. Et déjà, vous avez davantage qu’une majorité de PME françaises.

Quand un PRA simple suffit, quand investir lourdement

L’honnêteté impose de le dire : toutes les PME n’ont pas besoin du même niveau de PRA.

Un PRA simple suffit quand :

  • Vous pouvez tenir 24 h sans système sans perdre de clients
  • Vos données changent peu en cours de journée (RPO 24 h acceptable)
  • Vous n’avez pas de contrainte réglementaire forte (santé, finance)

Cible : sauvegarde quotidienne testée + runbook documenté. Budget annuel typique : 3 à 8 k€.

Un PRA avancé se justifie quand :

  • Une heure d’interruption coûte plus de 5 000 € (e-commerce, production industrielle)
  • Vous avez une obligation réglementaire (santé, banque, opérateur d’importance vitale)
  • Votre activité repose entièrement sur un service numérique disponible 24/7

Cible : DRaaS, réplication active, site secondaire. Budget annuel typique : 15 à 50 k€+.

Faire un BIA (Business Impact Analysis) avec votre équipe métier en début de projet permet de trancher proprement entre les deux.

Questions fréquentes

Quelle est la différence entre un PRA et une simple sauvegarde ?

Une sauvegarde est un composant du PRA, pas un PRA. Le PRA inclut la sauvegarde, mais aussi le matériel de remplacement, la procédure de restauration, les contacts d’urgence, les engagements de délai (RTO/RPO), les tests réguliers et la documentation à jour. Une PME peut avoir des sauvegardes excellentes et un PRA inexistant, c’est même le cas le plus fréquent.

Combien de temps faut-il pour mettre en place un PRA dans une PME ?

Un PRA MVP opérationnel peut être déployé en 2 semaines. Un PRA complet documenté, testé et industrialisé prend généralement 6 à 12 semaines pour une PME de 50 à 150 salariés. Comptez plus si votre SI est très hétérogène (mix on-premise, multi-cloud, environnements legacy).

Le RGPD impose-t-il un PRA ?

Le RGPD ne mentionne pas explicitement le terme « PRA », mais l’article 32 impose la capacité à rétablir la disponibilité des données et l’accès à celles-ci dans des délais appropriés en cas d’incident. En cas de contrôle ou d’incident notifié à la CNIL, l’absence de plan de continuité documenté est un facteur aggravant. Le guide d’hygiène informatique de l’ANSSI consacre plusieurs sections aux sauvegardes et à la résilience.

À quelle fréquence faut-il tester son PRA ?

Au minimum : restauration partielle mensuelle, restauration complète d’un service trimestrielle, DR drill annuel. Et impérativement, après chaque changement majeur du SI (migration cloud, nouveau serveur critique, changement d’ERP, refonte réseau). Un PRA non testé depuis plus de 12 mois doit être considéré comme suspect.

Un PRA cloud (DRaaS) est-il préférable à un PRA on-premise ?

Pas systématiquement. Le DRaaS (Disaster Recovery as a Service) est puissant : il offre un site secondaire activable rapidement, géré par un prestataire. Mais il coûte 300 à 8 000 €/mois selon le SI couvert. Pour une PME dont une heure d’interruption ne coûte pas 5 000 €, une stratégie sauvegarde hors-site + matériel de spare + runbook revient 5 à 10 fois moins cher pour une protection suffisante.

Que faire si je n’ai pas de DSI pour piloter le PRA ?

C’est précisément le cas de la majorité des PME que j’accompagne. Trois options : confier le projet à votre prestataire informatique habituel (qualité variable), recruter un consultant pour la mission ponctuelle (3 à 8 k€), ou prendre un DSI externe à temps partagé qui pilote le PRA et reste disponible pour la maintenance dans la durée. Cette dernière option est généralement la plus économique sur un cycle de 12 mois.

Quel rapport avec le NIST CSF 2.0 ?

Le PRA correspond directement à la fonction « Recover » du référentiel NIST CSF 2.0, l’une des six fonctions clés d’un programme de cybersécurité mature. Construire un PRA testé est donc aussi une étape vers une conformité progressive au NIST CSF, utile si vous travaillez avec des grands comptes qui l’exigent dans leurs appels d’offres.

En résumé

Un PRA informatique pour PME n’est pas un document, c’est une discipline : inventaire des actifs critiques, calibrage RTO/RPO par service, scénarios distincts, documentation hors-SI, tests réguliers en conditions réelles, et maintenance continue.

Un PRA simple bien fait coûte 3 à 8 k€ par an pour une PME standard, et vous protège contre 70 à 80 % des incidents que je vois sur le terrain. Un PRA non testé, quel que soit son budget, ne vous protège de rien.

Si vous voulez vérifier en 30 minutes si votre PRA actuel tiendrait vraiment, ou comment en construire un sans vous noyer dans le sujet, je suis joignable.

Mettre en place un PRA testé avec un DSI externe
Diagnostic gratuit 30 min, audit complet en 5 jours, mise en place 6 à 12 semaines.
Réserver un diagnostic gratuit

Vous avez un projet,
 des questions ?