PRA ou PCA : Ce qu’une PME doit vraiment mettre en place pour protéger son activité

Un sinistre informatique peut paralyser une PME en quelques heures : Cyberattaque, incendie, dégâts des eaux, panne serveur, perte de données… Face à ces risques, deux approches existent : Le PRA (Plan de Reprise d’Activité) et le PCA (Plan de Continuité d’Activité). Souvent confondus, ces deux dispositifs ne répondent pas aux mêmes besoins ni aux mêmes budgets. Pour une PME, la vraie question n’est pas “Faut-il un PCA ?” mais plutôt “Comment mettre en place un PRA efficace et réaliste ?”

1. PRA / PCA : Les chiffres parlent d’eux-mêmes

Avant même de comparer les approches, un constat effrayant et inquiétant s’impose : La majorité des PME n’ont ni PRA ni PCA formalisé.

• D’après plusieurs études internationales, près d’une PME sur deux ne dispose d’aucun plan de continuité ou de reprise formel.
• En France, un sondage auprès de collectivités a montré que 76 % n’avaient ni PCA ni PRA : On peut sans peine extrapoler que la situation est au moins aussi marquée dans les PME.
• Selon Travelers, 48 % des petites entreprises reconnaissent ne pas avoir de plan de continuité — autrement dit, elles improviseraient en cas de crise.
• Le PCA, avec ses infrastructures redondantes et son coût élevé, reste quasi inexistant dans le tissu des PME. Avec plus de 25 ans d'expérience terrain, je n'ai croisé qu'une seule PME qui disposait d'un vrai PCA complet et c'est moi qui l'ai mis en place et testé.
• Le PRA, quant à lui, est plus fréquent sous une forme simplifiée : Sauvegardes dans le cloud, plan de restauration d’un serveur ou procédures internes. Mais il est encore trop souvent incomplet, non documenté ou jamais testé.

En clair :

• Le PCA est un luxe réservé à quelques secteurs critiques (finance, santé, e-commerce massif).
• Le PRA est une nécessité pour toutes les PME… Mais encore loin d’être systématiquement en place.

2. PCA vs. PRA : Bien comprendre la différence

Ces deux sigles — PCA (Plan de Continuité d’Activité) et PRA (Plan de Reprise d’Activité) — sont souvent employés indifféremment et mis cote à cote par les prestataires. Pourtant, ils n’ont pas le même objectif, ne mobilisent pas les mêmes ressources et ne se construisent pas de la même manière. Et surtout pas les mêmes coûts. Pour un dirigeant de PME, comprendre la nuance est essentiel pour faire un choix réaliste et pertinent.

2.1 Le PCA, la Rolls-Royce de la résilience

Le PCA vise un objectif ambitieux : Ne jamais interrompre l’activité, même en cas de sinistre majeur.
Concrètement, cela signifie que l’entreprise doit pouvoir basculer immédiatement d’un système à un autre sans que les clients, les fournisseurs ou les collaborateurs ne ressentent de coupure.

Quelques exemples de contextes où le PCA est justifié :

• Un hôpital où la moindre indisponibilité peut mettre en danger des vies ;
• Une salle de marché financière où chaque seconde d’arrêt peut coûter des millions ;
• Un site e-commerce à très fort volume (plusieurs dizaines de milliers de transactions par jour) ;
• Une plateforme de paiements numériques qui doit répondre en quelques millisecondes et 24/7.

Mais pour atteindre cette continuité “temps réel”, il faut mettre en place :

• Des infrastructures redondantes (souvent en double, voire triple site) ;
• Une synchronisation permanente et temps réel des données ;
• Des équipes capables de superviser et de maintenir ce dispositif 24/7.

Résultat : Le PCA est extrêmement coûteux. Il mobilise des budgets que seules de grandes organisations ou des secteurs critiques peuvent absorber. Pour une PME de 30 ou 100 salariés, un PCA complet est rarement réaliste… et encore moins nécessaire.

2.2 Le PRA, la solution pragmatique

Le PRA, à l’inverse, part du principe qu’une interruption est possible. Mais il définit des moyens et des délais de reprise adaptés à l’entreprise selon ses enjeux, ses risques et ses impacts acceptés.
L’objectif n’est pas l’absence totale d’arrêt mais une reprise suffisamment rapide pour limiter l’impact économique et opérationnel.

Le PRA s’appuie généralement sur :

• Une documentation claire et accessible en toute circonstance ;
• Un recueil des éléments de contacts et un annuaire d'urgence ;
• Des sauvegardes externalisées (dans le cloud, sur un autre site) suivies et testées ;
• Des procédures de redéploiement (serveur virtuel, machines de secours, accès distant) ;
• Un rôle attribué à chaque collaborateur en cas de crise.

Son avantage majeur : Il est accessible financièrement et peut être adapté à toutes les tailles de PME. On peut définir des priorités claires (par exemple : Remettre l’ERP et la messagerie sous 24h, les fichiers partagés sous 48h).
Un PRA bien pensé permet de reprendre après un sinistre en quelques heures ou jours, là où sans PRA il faudrait parfois plusieurs semaines.

2.3 Un exemple concret : L’industrie vs. le commerce

Prenons deux cas réels :

• Une PME industrielle de 60 salariés : Son serveur tombe en panne un lundi matin.
  • Sans PRA : Arrêt de la production, salariés au ralenti, commandes bloquées. La reprise prend une semaine.
  • Avec PRA : Restauration des sauvegardes sur un serveur cloud, ERP remis en service en 6h, la production redémarre le lendemain.
• Un commerce de détail avec e-commerce : Son site est indisponible suite à une cyberattaque.
  • Avec PCA : Bascule immédiate sur un site miroir, aucune perte de vente, mais coût du dispositif insoutenable pour une petite structure.
  • Avec PRA : Site rétabli en 24h, quelques ventes perdues mais activité rapidement relancée, à un coût proportionné.

2.4 La question clé pour les dirigeants

Au-delà des définitions techniques, la question que chaque dirigeant devrait se poser est très simple :

Combien de temps mon entreprise peut tenir sans informatique ?

• Moins de 5 minutes : Il vous faut un PCA, sans hésiter (banque, santé, secteur critique).
• Moins d’une heure : Une continuité très forte est nécessaire, proche du PCA ou du PRA “premium”.
• 24 heures : C’est la cible la plus courante pour une PME avec un PRA bien conçu.
• Plus de 48 heures : Rare, car dans la plupart des secteurs, les conséquences d’un arrêt dépassent vite le supportable (pertes de CA, image, stress clients).

Cette question permet de définir vos objectifs de reprise :

• Le RTO (Recovery Time Objective) : C'est le délai maximum toléré avant reprise. Ce RTO peut aussi être définit selon les principales fonctions d'entreprise (Exemple : 24h pour la production mais 48h pour la comptabilité).
• Le RPO (Recovery Point Objective) : C'est la quantité de données que vous acceptez de perdre. Pour illustrer : Les sauvegardes du serveur comptabilité se déclenchent à 22h et durent en moyenne 1h30 (fin à 23h30). Le service comptable commence à saisir à 8h30 le matin. Le serveur crashe à 15h. Vous avez définitivement perdu 6h30 de saisie, données qu'il faudra donc ressaisir. Tenable ?

En pratique, 99 % des PME se situent dans la tranche “quelques heures à 24h”. C’est exactement le terrain du PRA.

3. Pourquoi un PRA est vital pour toutes les PME ?

Un PRA n’est pas une option "de confort" : C’est un filet de sécurité indispensable pour toute PME quel que soit son secteur. Là où le PCA reste réservé à quelques métiers critiques, le PRA répond à une réalité universelle : Aucune PME ne peut se permettre de rester paralysée plusieurs jours sans impact majeur.

3.1 Les risques sont universels

On pense souvent que les sinistres informatiques ne concernent "que les autres". Pourtant, les causes d’interruption sont multiples et peuvent frapper n’importe quelle PME :

• Cyberattaques (ransomware, phishing, vols de données) : Un scénario malheureusement courant dans les PME.
• Pannes techniques : Disque dur HS, serveur qui lâche, panne réseau, mises à jour système ou applicative vérolées.
• Incidents physiques : Incendie, dégât des eaux, vol de matériel, coup de pelleteuse malheureux...
• Erreur humaine : Suppression accidentelle d’un fichier, mauvaise configuration réseau.

Aucun de ces risques n’est "théorique". Ils arrivent chaque semaine à des entreprises de toutes tailles.

3.2 Les impacts sont immédiats et sévères

Un arrêt informatique entraîne bien plus que la perte d’accès aux données :

• Perte de chiffre d’affaires : Commandes bloquées, production arrêtée, facturation suspendue.
• Atteinte à l’image : Clients et partenaires inquiets, réputation fragilisée.
• Risque légal : Perte de données personnelles (RGPD), impossibilité de respecter les obligations de facturation électronique.
• Tension interne : Salariés inactifs, managers sous pression, direction débordée.

Même 24 heures d’arrêt peuvent suffire à générer un stress important et des pertes significatives.

3.3 L’étude des risques : La base d’un PRA efficace

La première étape pour bâtir un PRA n’est pas technique : C’est une étude des risques.
Concrètement, il s’agit de répondre à trois questions clés :

1. Quels sont les scénarios de crise les plus probables ?
   (cyberattaque, panne serveur, coupure électrique, incendie, etc.)
2. Quels systèmes et données sont critiques pour mon activité ?
   (ERP, messagerie, fichiers clients, logiciels de production, comptabilité).
3. Quels sont mes seuils de tolérance ?
   • RTO : Combien de temps maximum puis-je rester à l’arrêt avant que la situation ne devienne insupportable ?
   • RPO : Combien de données maximum suis-je prêt à perdre (1h, 4h, 24h) ?

Cette analyse permet de calibrer un PRA réaliste, ni surdimensionné (inutilement coûteux), ni sous-dimensionné (dangereux).

3.4 Exemple concret

Un prestataire événementiel de 40 salariés a été victime d’un ransomware.

• Sans PRA : Il aurait fallu plusieurs semaines pour reconstruire les serveurs, avec une perte totale de l’activité et des contrats annulés.
• Avec un PRA basé sur une étude de risques : Sauvegardes toutes les heures dans le cloud, procédures de restauration documentées, tests réguliers. Résultat : Ses systèmes critiques (ERP, paie, devis) ont été restaurés en 8 heures. Les pertes ont été limitées à une demi-journée de travail.

4. Comment concevoir un PRA efficace et réaliste

Un PRA efficace n’est pas forcément un document de 200 pages ni une infrastructure coûteuse. C’est avant tout un plan clair, adapté à la réalité de l’entreprise et testé régulièrement. L’enjeu n’est pas de viser la perfection mais d’avoir un dispositif robuste, proportionné et opérationnel.

4.1 Identifier les systèmes critiques

Toutes les applications ne se valent pas. Certaines peuvent attendre, d’autres pas.

• Systèmes vitaux : ERP, messagerie, fichiers de production, outils de facturation.
• Systèmes importants : GED, outils collaboratifs, intranet.
• Systèmes secondaires : Applications de confort ou à usage ponctuel.

Classez vos applications en trois catégories : Indispensable, important, secondaire. Cela permet de prioriser ce qui doit absolument être remis en service en premier.

4.2 Définir les objectifs de reprise

Un PRA n’a de sens que s’il est calibré. C’est le rôle des deux indicateurs clés :

• RTO (Recovery Time Objective) : Combien de temps maximum votre entreprise peut supporter sans ce système (1h, 4h, 24h) ?
• RPO (Recovery Point Objective) : Quelle quantité de données pouvez-vous perdre au maximum (aucune, 1h, 1 journée) ?

Ces deux chiffres, définis pour chaque application critique, guident toutes les décisions techniques du PRA.

4.3 Identifier les risques et les scénarios

Un PRA doit être conçu en fonction des menaces réelles qui pèsent sur l’entreprise. L’étape clé consiste à imaginer des scénarios de crise :

• Cyberattaque : Ransomware qui chiffre tous les fichiers, phishing qui compromet un compte.
• Panne matérielle : Serveur HS, disque dur qui lâche, alimentation électrique grillée.
• Erreur humaine : Suppression accidentelle de dossiers, mauvaise configuration réseau.
• Incidents physiques : Incendie, inondation, vol de matériel, coupure électrique prolongée.
• Indisponibilité d’un prestataire : Hébergeur en panne, fournisseur cloud défaillant.

Pour chaque scénario, demandez-vous :

• Quelle probabilité que cela arrive dans votre entreprise ?
• Quel impact sur vos systèmes critiques ?
• Quelles mesures de prévention ou de reprise mettre en place ?

C’est ce travail d’étude des risques qui permet d’éviter les plans théoriques trop coûteux ou, au contraire, insuffisants.

Pour ne pas se limiter à une simple “liste au hasard” de menaces, il est utile de s’appuyer sur des méthodologies éprouvées de gestion des risques.

• EBIOS Risk Manager (méthode de l’ANSSI en France) : Permet d’identifier les événements redoutés, les scénarios de menace et les mesures de sécurité associées.
• ISO 27005 (norme internationale) : Cadre méthodologique pour l’analyse et la gestion des risques liés à la sécurité de l’information.
• MEHARI (Méthodologie Harmonisée d’Analyse des Risques) : Propose une approche systématique pour quantifier les risques et prioriser les actions.
• NIST Risk Management Framework (États-Unis) : Modèle largement utilisé à l’international, plus technique mais très complet.

Ces référentiels peuvent sembler lourds pour une PME mais ils offrent un cadre solide. Dans la pratique, un DSI externalisé ou un consultant peut les adapter de façon pragmatique pour :

• Identifier les risques majeurs,
• Hiérarchiser les scénarios à couvrir,
• Calibrer le PRA en conséquence.

4.4 Choisir les moyens adaptés

Une fois les systèmes critiques, les objectifs de reprise (RTO/RPO) et les scénarios de risques définis, il est temps de passer aux solutions concrètes. Ici, l’idée n’est pas de “tout acheter” mais de sélectionner les moyens proportionnés aux besoins réels de l’entreprise.

a) Les sauvegardes externalisées

• Pourquoi ? C’est la base de tout PRA. Sans sauvegardes fiables, aucun plan ne tient.
• Bonnes pratiques :
  • Sauvegardes locales ET externalisées (principe du 3-2-1 : 3 copies, sur 2 supports, dont 1 hors site).
  • Automatisation et monitoring (vérifier que la sauvegarde s’exécute vraiment).
  • Test de restauration régulier.

b) Les environnements de secours

• Serveurs virtuels dans le cloud : Permettent de relancer l’ERP ou les fichiers en quelques heures.
• Serveurs physiques de secours : Utiles pour les PME industrielles avec logiciels métiers locaux.
• PC portables préconfigurés : Pour que les équipes clés puissent redémarrer rapidement.

c) Les procédures organisationnelles

• Plan d’appel et de communication interne/externe en cas de crise.
• Rôles clairement attribués : Qui décide, qui restaure, qui informe.
• Documentation centralisée (mais aussi disponible hors ligne).

Ici, la clé est d’aligner les moyens sur les objectifs : Inutile de payer une redondance temps réel si votre RTO est de 24h. À l’inverse, inutile de prévoir un PRA qui prend 5 jours à activer si votre entreprise ne peut tenir qu’une journée.

4.5 Documenter et tester le PRA

Un PRA n’a de valeur que s’il est documenté et éprouvé. Beaucoup d’entreprises croient être protégées parce qu’elles ont “des sauvegardes quelque part”… mais découvrent trop tard qu’elles ne savent pas comment les restaurer.

a) Documenter clairement

• Procédures pas à pas : Restauration d’un serveur, accès à la messagerie, remise en service d’un VPN.
• Fiches contacts d’urgence : Prestataires IT, hébergeur, fournisseurs logiciels, référents internes.
• Supports hors ligne : Conserver une version papier ou PDF du plan, accessible même sans réseau.

b) Organiser des tests réguliers

• Simulation partielle : Restauration d’un fichier, test de bascule sur un serveur cloud.
• Simulation complète : Scénario fictif (ex. panne serveur) avec activation du plan par l’équipe.
• Fréquence minimale : Au moins une fois par an, ou après tout changement majeur du SI.

👉 L’expérience montre que les tests révèlent toujours des surprises : Sauvegarde corrompue, dépendance oubliée, mot de passe perdu… Mieux vaut le découvrir en exercice qu’en pleine crise.

4.6 Exemple concret : Un PRA réaliste en PME

Prenons le cas d’une PME de négoce de 80 personnes. Après analyse des risques et définition des priorités, elle a établi :

• ERP (application cœur de métier)
  • RTO : 24h / RPO : 1h
  • Solution : Sauvegardes horaires dans le cloud + possibilité de relancer l’ERP sur un serveur virtuel hébergé.
• Messagerie (Microsoft 365)
  • RTO : 4h / RPO : 15 minutes
  • Solution : Service SaaS avec redondance native + procédures de restauration d’urgence de boîtes mails.
• Fichiers partagés (documents clients et fournisseurs)
  • RTO : 48h / RPO : 1 jour
  • Solution : Synchronisation quotidienne avec un espace cloud sécurisé.
• Équipe de crise
  • Dirigeant : Arbitre les décisions.
  • Responsable administratif : Communication interne/externe.
  • Prestataire IT : Restauration technique.

Le plan est documenté et testé deux fois par an (simulation de panne serveur + simulation de coupure réseau). Résultat : Lors d’un incident réel (panne de stockage) l’ERP a été redémarré dans le cloud en 6 heures, sans perte significative.

Cet exemple montre qu’un PRA n’a pas besoin d’être hors de prix. Avec une analyse rigoureuse, un choix adapté de solutions et des tests réguliers, une PME peut atteindre un excellent niveau de résilience.

5. Le rôle des dirigeants et du DSI externalisé

Un PRA ne se limite pas à une question technique confiée aux informaticiens. C’est avant tout une décision de gouvernance : Définir ce que l’entreprise peut accepter comme interruption, ce qu’elle ne peut pas tolérer et quels moyens elle est prête à y consacrer.

5.1 Le dirigeant : L’arbitre des priorités

Le dirigeant d’une PME est le seul à pouvoir répondre à la question clé :
“Combien de temps mon entreprise peut-elle fonctionner sans informatique ?”

• Si la réponse est “pas plus de quelques heures”, alors le budget et les moyens doivent être dimensionnés en conséquence.
• Si l’entreprise peut encaisser 24h ou 48h d’arrêt, alors le PRA peut être plus léger, mais il doit être clair et documenté.

Le rôle du dirigeant est donc de fixer le curseur entre le risque acceptable et l’investissement nécessaire. C’est une décision stratégique, pas seulement technique.

5.2 Le DSI externalisé : Le traducteur et le chef d’orchestre

La difficulté des dirigeants de PME c’est de transformer ces choix stratégiques en solutions concrètes. C’est là qu’intervient le DSI externalisé, dont la mission est de :

• Traduire les besoins métiers en objectifs IT (Ex. : “nous ne pouvons pas perdre plus d’une demi-journée de commandes” → RPO = 4h).
• Concevoir le plan adapté : Solutions de sauvegarde, infrastructures de secours, procédures de reprise.
• Coordonner les prestataires (hébergeurs, intégrateurs, éditeurs de logiciels) pour qu’ils travaillent dans le même sens.
• Formaliser et tester le PRA pour qu’il soit utilisable le jour J.

Le DSI externalisé joue un rôle clé : Il parle à la fois le langage du dirigeant (chiffre d’affaires, continuité, clients) et celui des prestataires (sauvegardes, serveurs, RTO/RPO).

5.3 Ne pas céder aux discours commerciaux

Beaucoup de prestataires ont tendance à “vendre du PCA” comme solution universelle en mettant en avant la peur de la panne. Mais un PCA complet est rarement justifié en PME.

Le DSI externalisé apporte un regard neutre et pragmatique :

• Il dimensionne le plan en fonction de la réalité métier,
• Il évite de payer pour de la redondance inutile,
• Il sécurise l’entreprise avec un plan opérationnel et réaliste.

5.4 Exemple concret

Un dirigeant de PME industrielle de 50 salariés était convaincu par son prestataire qu’il lui fallait un PCA. Après analyse :

• Coût estimé du PCA : 95k€ d'investissement et 20k€ / an de fonctionnement.
• Après arbitrage avec le DSI externalisé : PRA basé sur des sauvegardes cloud + redémarrage en 24h, coût : 12 000 € / an.
• Résultat : Plan adapté, testé, validé par le dirigeant avec un budget soutenable.

Le dirigeant a pris la décision stratégique ; le DSI a construit la solution concrète.

En résumé :

• Le dirigeant fixe le niveau de tolérance au risque.
• Le DSI externalisé transforme cette décision en PRA opérationnel, proportionné et testé.

C’est ce tandem qui garantit la résilience réelle de la PME, sans dépenses inutiles ni angles morts dangereux.

6. Passer à l’action : Les premières étapes pour une PME

Mettre en place un PRA peut sembler complexe au premier abord. Mais en réalité, la démarche peut être découpée en étapes simples et progressives. L’objectif n’est pas d’avoir un plan parfait du jour au lendemain mais de sécuriser progressivement son entreprise.

6.1 Faire un état des lieux

Avant de parler sauvegardes ou scénarios de crise, la première étape consiste à dresser une photographie claire du système d’information.
Cet état des lieux est le socle du PRA. Il ne s’agit pas seulement d’un constat technique mais d’une cartographie des dépendances de l’entreprise à l’informatique.

Questions clés à se poser :

• Quels sont mes systèmes et applications critiques (ERP, messagerie, fichiers partagés, outils métier) ?
• Où sont stockées mes données ? (serveur interne, cloud, postes locaux)
• Quels sont les flux vitaux ? (commandes clients, facturation, production, paie)
• Quelles sont les pratiques actuelles de sauvegarde ? Fonctionnent-elles réellement ?
• Ai-je déjà vécu une panne ou une perte de données ? Comment cela a-t-il été géré ?

Le livrable attendu : La cartographie des systèmes et dépendances

Un document simple et visuel doit sortir de cette étape, par exemple sous forme de tableau ou de schéma.
Il doit contenir au minimum :

• La liste des applications et données clés (ERP, CRM, messagerie, GED, fichiers partagés, etc.).
• Leur criticité : indispensable, important, secondaire.
• Les dépendances : ex. l’ERP dépend du serveur X et de la base de données Y.
• Le mode d’hébergement : local, cloud, SaaS.
• Les sauvegardes existantes : fréquence, lieu de stockage, responsable.
• Les vulnérabilités identifiées : absence de sauvegarde testée, dépendance à un seul fournisseur, etc.

Ce livrable devient la base de dialogue entre le dirigeant et le DSI : il rend visible, noir sur blanc, les forces et les faiblesses du SI.

Application / Donnée	Criticité	Dépendances	Hébergement	Sauvegarde actuelle	Risque identifié
ERP (gestion commandes)	Indispensable	Serveur interne + SQL	Local (serveur physique)	Sauvegarde nocturne sur NAS	Pas de test de restauration, dépendance au serveur unique
Messagerie	Indispensable	Microsoft 365	SaaS	Redondance Microsoft	OK
Fichiers partagés	Important	NAS interne	Local	Copie hebdomadaire externe	Fréquence insuffisante
Comptabilité	Important	Poste dédié + appli SaaS	Mixte	Sauvegarde locale manuelle	Risque d’oubli

Pourquoi ce livrable est stratégique ?

• Il met en lumière les points de fragilité immédiats.
• Il permet au dirigeant de comprendre concrètement ce qui est en jeu.
• Il donne une base chiffrée et priorisée pour décider où investir (sauvegarde, cloud, redondance).

Sans cet état des lieux et son livrable, le PRA reste flou et théorique. Avec lui, on sait exactement quoi protéger, comment et avec quelle priorité.

6.2 Définir ses priorités

Une fois l’état des lieux dressé, l’étape suivante est de classer les priorités : Tout ne peut pas être remis en service en même temps lors d’une crise. C’est une étape stratégique où le dirigeant doit arbitrer, car elle touche directement au modèle économique de l’entreprise.

a) Identifier les activités vitales

Quelles sont les fonctions sans lesquelles l’entreprise est paralysée ?

• Pour une PME industrielle : l’ERP (gestion des commandes et production).
• Pour une société de services : la messagerie et le CRM.
• Pour un cabinet comptable : les outils de paie et de comptabilité.

L’idée est de déterminer ce qui doit absolument redémarrer en premier, même si le reste attend.

b) Fixer les seuils de tolérance : RTO et RPO

C’est ici que la réflexion métier devient opérationnelle.

• RTO (Recovery Time Objective) : Combien de temps maximum une application peut-elle rester indisponible ?
• RPO (Recovery Point Objective) : Combien de données maximum peut-on se permettre de perdre (depuis la dernière sauvegarde) ?

Exemple :

• ERP : RTO 24h / RPO 1h.
• Messagerie : RTO 4h / RPO 15 min.
• GED (archives clients) : RTO 48h / RPO 1 jour.

c) Hiérarchiser les systèmes

Une fois les seuils fixés, on établit un ordre de reprise clair.
Exemple pour une PME de 50 salariés :

1. Messagerie et outils collaboratifs → indispensables pour garder le lien avec clients et partenaires.
2. ERP → cœur de métier, nécessaire pour traiter commandes et production.
3. Fichiers partagés → utiles mais peuvent attendre quelques heures.
4. Applications secondaires (intranet, outils de reporting) → remis en service plus tard.

d) Exemple concret de priorisation

Une PME de transport a défini ses priorités comme suit :

• Système de planification des tournées : RTO 2h / RPO 15 min → serveur miroir prêt dans le cloud.
• Messagerie : RTO 4h / RPO 1h → service Microsoft 365 redondant.
• Comptabilité : RTO 48h / RPO 1 jour → sauvegarde quotidienne, reprise différée.

Lors d’une panne de serveur, l’entreprise a pu reprendre ses activités critiques (planification + messagerie) dans la journée, et n’a subi qu’un retard mineur sur la comptabilité.

Définir les priorités, c’est transformer une réflexion parfois floue (“on ne peut pas s’arrêter”) en un plan réaliste et chiffré. Cela permet au dirigeant d’investir intelligemment, sans surpayer des solutions inutiles, et de s’assurer que l’entreprise redémarrera là où ça compte vraiment.

6.3 Mettre en place un plan de sauvegarde fiable

• Sauvegardes externalisées automatiques.
• Tests réguliers de restauration.
• Respect de la règle du 3-2-1 (3 copies, 2 supports, 1 hors site).

La sauvegarde est la brique de base d’un PRA. Sans elle, aucun plan n’est possible.

6.3 Mettre en place un plan de sauvegarde fiable

On entend souvent “oui, oui, on a des sauvegardes”... mais lorsqu’un incident survient, la réalité est parfois brutale : sauvegardes incomplètes, stockées sur le même serveur que les données originales, ou tout simplement impossibles à restaurer.
Un plan de sauvegarde structuré et testé est donc la colonne vertébrale du PRA.

a) La règle du 3-2-1

Une bonne stratégie de sauvegarde repose sur une règle simple :

• 3 copies des données : l’original + 2 copies.
• 2 supports différents : disque interne, NAS, cloud, bande, etc.
• 1 copie hors site : dans le cloud ou dans un autre lieu physique.

Cela évite le scénario trop fréquent de la PME qui sauvegarde sur un NAS… et perd tout lorsque l’incendie ou le ransomware touche à la fois les données et les sauvegardes.

b) Fréquence et automatisation

• Sauvegardes quotidiennes minimum pour les applications critiques.
• Sauvegardes horaires pour les systèmes sensibles (ERP, messagerie).
• Automatisation : bannir les sauvegardes manuelles (souvent oubliées).
• Surveillance : vérifier que la sauvegarde s’est bien exécutée (alerte en cas d’échec).

c) Le test de restauration : la clé

Une sauvegarde qui n’a jamais été testée n’existe pas.

• Faire des tests de restauration partielle (un fichier, une base).
• Organiser des tests de restauration complète (serveur, ERP, VM).
• Vérifier les temps réels de restauration : ils servent à confronter la pratique aux objectifs RTO/RPO.

d) Diversifier les solutions

• Sauvegarde locale : rapide et peu coûteuse, mais vulnérable aux sinistres.
• Sauvegarde cloud : flexible et accessible en mobilité, mais dépendante d’Internet.
• Sauvegarde hybride : combinaison des deux, souvent la meilleure option pour une PME.

Exemple : Une PME industrielle sauvegarde ses fichiers critiques toutes les heures dans le cloud, conserve une copie quotidienne sur un NAS local, et garde une archive mensuelle externalisée sur bande.

e) Exemple concret

Un cabinet de 20 personnes pensait être protégé : ses données étaient copiées chaque nuit sur un NAS interne. Après un ransomware, le NAS a été chiffré en même temps que le serveur.
Depuis, la stratégie a évolué :

• Sauvegarde cloud chiffrée toutes les heures (RPO = 1h).
• Copie locale quotidienne (RTO = 4h).
• Test de restauration complet deux fois par an.

Résultat : Lors d’un incident de panne disque, l’entreprise a restauré ses données en 2 heures, sans perte.

Le plan de sauvegarde est la brique de base du PRA. Sans lui, même le meilleur plan de reprise reste théorique. Avec lui, une PME a déjà parcouru 50 % du chemin vers une vraie résilience.

6.4 Documenter, former et tester

Un PRA ne sert à rien s’il dort dans un tiroir ou s’il n’est compris que par une seule personne technique. Pour qu’il soit opérationnel le jour J, il doit être documenté clairement, approprié par l’équipe et surtout testé régulièrement.

a) Documenter clairement

• Procédures pas à pas : Comment restaurer un serveur, comment reconnecter les utilisateurs, comment accéder aux sauvegardes.
• Fiches contacts d’urgence : Prestataire IT, hébergeur, éditeurs de logiciels, équipe interne, opérateurs télécoms, contrat d'énergie...
• Supports hors ligne : Une version papier ou un PDF stocké hors du réseau, pour être consultable même si le SI est indisponible.
• Priorisation : Un tableau simple qui rappelle l’ordre de redémarrage (messagerie → ERP → fichiers → reste).

La documentation doit être claire, courte et utilisable par un non-informaticien.

b) Former les acteurs clés

Le PRA doit être compris par plus d’une personne :

• Dirigeant : Arbitre des décisions en cas de crise.
• Responsable administratif ou financier : Assure la communication interne et externe.
• Référent technique (ou prestataire IT) : Exécute les restaurations.
• Un suppléant identifié : Pour éviter le “single point of failure” (si la seule personne qui sait quoi faire est absente).

Un briefing annuel de 30 minutes suffit souvent à maintenir la vigilance.

c) Tester régulièrement

Un PRA jamais testé est un faux-semblant. Les tests doivent être proportionnés et progressifs :

• Tests partiels : Restauration d’un fichier ou d’une base de données.
• Tests complets : Simulation de panne serveur, bascule sur le cloud.
• Fréquence : Au moins une fois par an, et après tout changement majeur (migration ERP, nouvel hébergeur, changement de sauvegarde).

Chaque test révèle des surprises : Mot de passe perdu, dépendance oubliée, délai de restauration plus long que prévu. C’est normal et c’est justement l’intérêt des exercices.

Un exemple concret

Une PME de services de 35 salariés avait un PRA écrit, mais jamais testé. Lors d’une coupure électrique prolongée, le serveur n’a pas redémarré correctement, et personne ne savait comment restaurer les données. Résultat : 3 jours d’arrêt.
Depuis, l’entreprise organise chaque année un “test PRA” d’une demi-journée : coupure simulée, restauration ERP et messagerie. La dernière simulation a permis de redémarrer l’ERP en 4 heures, au lieu des 3 jours subis lors du premier incident.

En résumé : Un PRA efficace est documenté pour être utilisable, partagé avec les bonnes personnes, et testé pour être fiable. Sans ces trois étapes, il reste une belle intention sur le papier.

Pour conclure

Le PCA est une vitrine impressionnante mais qui ne concerne que quelques secteurs ultra-critiques. Pour toutes les autres PME, la vraie priorité est le PRA : Un plan concret, accessible et vital pour continuer à travailler après un incident.

Mieux vaut un PRA simple mais testé qu’un PCA rêvé mais inabordable.

Dirigeant de TPE/PME, vous n’avez pas encore de PRA ou vous doutez de son efficacité ? Réservez en ligne votre créneau pour un appel découverte de 30mn gratuit et sans engagement.