PRA informatique : plan de reprise d’activité pour une PME

Un PRA informatique (plan de reprise d’activité informatique) est le document qui décrit comment vous remettez vos systèmes en marche après un sinistre : attaque par rançongiciel, incendie du local serveur, dégât des eaux, panne matérielle ou erreur humaine grave. Ce n’est pas une sauvegarde, ni une simple checklist griffonnée un vendredi soir : c’est une procédure écrite, testée, qui dit qui fait quoi, dans quel ordre, et en combien de temps.

Cette page couvre ce qu’un PRA informatique contient concrètement pour une PME de 10 à 50 postes, comment le construire en partant des RTO et RPO de chaque application, ce qu’il coûte en 2026, et à quelle fréquence le tester. Si vous cherchez la différence avec un plan de continuité d’activité, elle est détaillée sur PRA ou PCA : quelle différence pour votre PME.

Qu’est-ce qu’un PRA informatique, concrètement ?

Le PRA répond à une seule question, posée pour chaque application critique : si ce système tombe aujourd’hui, comment est-il relancé, par qui, et en combien de temps ? Il couvre l’infrastructure technique — serveurs, postes, réseau, messagerie, logiciel métier, téléphonie — et non l’organisation globale de l’entreprise pendant la crise, qui relève plutôt du plan de continuité (PCA).

Concrètement, un PRA informatique repose sur trois éléments qui doivent exister avant qu’un incident ne survienne : des sauvegardes fiables et testées, une infrastructure de secours (même minimale) où restaurer ces données, et une procédure écrite que quelqu’un peut suivre sans improviser. Sans sauvegarde exploitable, il n’y a pas de PRA possible : voir la règle 3-2-1-1-0 et les budgets de sauvegarde pour ce socle.

Dans une PME de 10 à 50 postes, le PRA n’est presque jamais l’affaire d’un seul service. Le dirigeant ou le responsable administratif fixe les priorités métier (quelle application fait perdre le plus d’argent à l’arrêt), le prestataire informatique traduit ces priorités en solutions techniques, et un tiers, souvent l’assureur ou un partenaire cybersécurité, vérifie que le tout tient la route. C’est cette combinaison qui distingue un vrai PRA d’un simple contrat d’infogérance.

Que contient un PRA pour une PME de 10 à 50 postes ?

Pour une structure de cette taille, le PRA n’a pas besoin de faire cent pages. Un document de 15 à 25 pages, tenu à jour, suffit largement s’il couvre les points suivants :

• Inventaire des applications critiques : messagerie, logiciel métier, ERP/CRM, site marchand, téléphonie, partage de fichiers, avec pour chacune un RTO et un RPO chiffrés.
• Cartographie de l’infrastructure : serveurs physiques et virtuels, postes, liens réseau, contrats d’hébergement et de maintenance, avec leurs points de contact.
• Scénarios de sinistre couverts : ransomware, panne matérielle, sinistre physique (incendie, dégât des eaux), indisponibilité du prestataire d’hébergement.
• Procédures de restauration : étape par étape, pour chaque application, avec les identifiants d’accès (stockés de façon sécurisée, hors du système compromis).
• Infrastructure de secours : où et comment les systèmes sont relancés — datacenter de secours, cloud, ou matériel de remplacement identifié.
• Annuaire de crise : qui déclenche le PRA, qui contacte le prestataire, qui informe les équipes et les clients.
• Journal de test : dates des exercices passés, incidents rencontrés, actions correctives.

C’est cette trame, complétée avec vos propres systèmes, qui constitue votre document PRA. Elle se rapproche de celle d’un plan de reprise d’activité au sens large, mais centrée ici sur l’informatique plutôt que sur l’organisation métier complète.

Le PRA ne dispense pas de protéger physiquement les locaux, qui conditionnent plusieurs de ces scénarios : un cambriolage emporte aussi les serveurs et les postes. Pour une agence ou un commerce en rez-de-chaussée, la fermeture de la vitrine par un rideau métallique reste la première barrière avant toute considération informatique ; le prix d’un rideau métallique de commerce dépend de la largeur, du type de tablier et de la motorisation.

Comment construire son PRA en partant des RTO et RPO ?

C’est le point de départ technique, et c’est souvent celui que les PME sautent. Deux indicateurs, à définir pour chaque application, pas pour l’entreprise entière :

• RTO (Recovery Time Objective) : le délai maximal toléré avant que l’application ne soit de nouveau utilisable. Une messagerie peut tolérer 4 heures d’arrêt, un logiciel de facturation 24 heures, un site e-commerce quelques minutes.
• RPO (Recovery Point Objective) : la quantité de données que vous acceptez de perdre, exprimée en temps. Un RPO de 4 heures signifie que vous acceptez de reperdre jusqu’à 4 heures de saisie en cas d’incident, ce qui fixe la fréquence de sauvegarde nécessaire.

La méthode concrète : listez vos 5 à 10 applications les plus critiques, demandez à chaque responsable métier combien de temps d’arrêt et combien de données perdues seraient réellement tolérables (pas confortables, tolérables), puis choisissez l’architecture de secours et la fréquence de sauvegarde qui permettent de tenir ces chiffres. Plus le RTO et le RPO visés sont courts, plus le budget grimpe : c’est le compromis central de tout PRA.

Un piège classique : fixer le même RTO pour toutes les applications, par facilité. Dans une PME de 10 à 50 postes, la messagerie et le logiciel de facturation n’ont presque jamais le même niveau de criticité qu’un outil de gestion des stocks ou un serveur de fichiers partagés. Hiérarchiser permet de concentrer le budget de reprise là où l’arrêt coûte réellement cher, plutôt que de tout traiter au même niveau, ce qui fait exploser la facture sans gain réel.

Quel budget prévoir pour un PRA informatique en 2026 ?

Le coût dépend directement du niveau de reprise visé, c’est-à-dire du RTO cible. Voici des ordres de grandeur constatés pour une PME de 10 à 50 postes, hors coût des sauvegardes elles-mêmes (déjà budgétées dans le socle 3-2-1-1-0) :

Pour la majorité des PME de 10 à 50 postes, sans activité e-commerce ni production continue, la reprise tiède offre le meilleur compromis coût/délai. La reprise à chaud se justifie surtout pour une activité qui perd du chiffre d’affaires à chaque minute d’arrêt, ou pour répondre à une exigence contractuelle ou réglementaire précise.

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

Un PRA non testé est une hypothèse, pas un plan. Le rythme raisonnable pour une PME de 10 à 50 postes :

PRA, PCA, sauvegarde : trois documents, trois rôles

Ces trois notions sont souvent confondues. La sauvegarde protège la donnée elle-même. Le PRA organise la remise en service technique après sinistre. Le plan de continuité d’activité (PCA) va plus loin : il organise le fonctionnement de l’entreprise entière pendant la crise, y compris les activités non informatiques (accueil client, logistique, paie). Pour la comparaison détaillée et savoir lequel prioriser selon votre activité, consultez PRA ou PCA : quelle différence pour votre PME.

Que se passe-t-il si vous n’avez pas de PRA le jour d’une attaque ?

Sans PRA, la reprise se fait dans l’urgence, sans procédure, avec un risque réel de décisions contradictoires : qui restaure quoi, dans quel ordre, avec quelles données. C’est souvent à ce moment que des PME découvrent que leurs sauvegardes n’étaient pas complètes, ou que personne ne connaît la procédure de restauration du logiciel métier. Le guide attaque par ransomware : que faire détaille la marche à suivre dans l’urgence, mais un PRA écrit à l’avance change tout : il transforme une improvisation de plusieurs jours en une procédure de quelques heures.

Questions fréquentes sur le PRA informatique