Plan de reprise d'activité (PRA) pour PME : par où commencer

Si vos systèmes tombent demain — rançongiciel, panne, erreur humaine — combien de temps votre entreprise peut-elle tenir ?

La plupart des PME n'ont pas de réponse claire à cette question. Un plan de reprise d'activité (PRA) donne cette réponse et structure la remise en marche.

Ce qu'est un PRA (et ce que ce n'est pas)

Définition simple

Un PRA est un document qui décrit comment votre entreprise va remettre ses systèmes informatiques en marche après un incident majeur. Il répond à cinq questions : quels systèmes sont prioritaires ? Dans quel ordre les rétablir ? Qui fait quoi ? Quels sont les délais acceptables ? Où sont les sauvegardes et les ressources nécessaires ?

Ce n'est pas un document de 200 pages. Pour une PME, un PRA efficace peut tenir en quelques pages — à condition qu'il soit concret, testé et accessible aux bonnes personnes.

Différence entre PRA et PCA

Le PRA (Plan de reprise d'activité) se concentre sur la remise en marche après un incident. Il entre en jeu quand les systèmes sont arrêtés.

Le PCA (Plan de continuité des activités) est plus large : il couvre aussi comment maintenir un minimum d'activité pendant l'incident. Par exemple : si votre serveur de fichiers est hors service, le PCA prévoit que les équipes peuvent travailler temporairement à partir de copies locales ou d'un environnement de secours.

En pratique, pour une PME, les deux sont souvent combinés dans un seul document. L'important n'est pas la distinction théorique — c'est d'avoir un plan qui fonctionne.

Pourquoi un PRA n'est pas réservé aux grandes entreprises

Une PME de services professionnels qui perd ses courriels pendant 3 jours perd des contrats. Une PME manufacturière dont l'ERP est hors service pendant 48 heures arrête sa production. Une entreprise de construction dont les plans numériques sont inaccessibles bloque ses chantiers.

L'impact d'un arrêt est souvent proportionnellement plus lourd pour une PME que pour une grande organisation, parce que la PME a moins de marge de manœuvre, moins de redondance et moins de ressources d'urgence.

Les éléments essentiels d'un PRA pour PME

Inventaire des systèmes critiques

Quels sont les systèmes sans lesquels votre entreprise ne peut pas fonctionner ? Pour une PME manufacturière, c'est peut-être l'ERP et le serveur de fichiers. Pour un cabinet de services professionnels, c'est peut-être le courriel et le système de gestion de projets. Cet inventaire est le fondement du PRA — tout le reste en découle.

Définition du RTO et du RPO

Le RTO (Recovery Time Objective) est le délai maximal acceptable pour remettre un système en marche. Si votre ERP tombe et que vous ne pouvez pas produire sans lui, votre RTO est peut-être de 4 heures.

Le RPO (Recovery Point Objective) est la quantité maximale de données que vous pouvez vous permettre de perdre, mesurée en temps. Un RPO de 24 heures signifie que vous acceptez de perdre au maximum les données de la dernière journée — votre sauvegarde doit donc être quotidienne au minimum.

Ces deux indicateurs guident vos choix techniques : type de sauvegarde, fréquence, infrastructure de secours.

Procédures de restauration documentées

Comment restaurer chaque système critique ? Quels sont les étapes, les identifiants nécessaires, les contacts des fournisseurs ? La procédure doit être suffisamment claire pour qu'une personne qui n'a pas participé à la construction du plan puisse l'exécuter en situation d'urgence.

Rôles et responsabilités

Qui déclenche le plan ? Qui contacte le fournisseur TI ? Qui communique avec les clients ? Qui valide la reprise ? Dans une PME, ces rôles peuvent être tenus par 2 ou 3 personnes — mais ils doivent être définis à l'avance, pas improvisés en pleine crise.

Liste de contacts d'urgence

Numéro du fournisseur TI (ligne d'urgence, pas le numéro général), contact de l'assureur, contact du consultant en cybersécurité si applicable, contact de l'hébergeur cloud. Cette liste doit être accessible même si vos systèmes sont hors service — pas uniquement dans un fichier sur le serveur qui vient de tomber.

Comment construire un PRA en 5 étapes

Étape 1 : identifier vos systèmes critiques

Listez tous vos systèmes informatiques et classez-les par ordre d'importance pour vos opérations. Soyez précis : « le serveur de fichiers » ne suffit pas. Précisez quels dossiers sont critiques, quels services dépendent de quel serveur, quelles applications sont indispensables.

Étape 2 : définir vos délais acceptables (RTO/RPO)

Pour chaque système critique, posez la question : combien de temps peut-on s'en passer ? Et combien de données peut-on se permettre de perdre ? Les réponses ne sont pas techniques — elles sont opérationnelles. C'est la direction qui les définit, pas l'équipe TI.

Étape 3 : documenter les procédures de restauration

Pour chaque système critique, documentez la marche à suivre pour le remettre en service. Incluez les prérequis (alimentation, réseau, identifiants), les étapes de restauration, les vérifications à faire après la remise en service. Si votre fournisseur TI gère la restauration, documentez au minimum comment le joindre en urgence et quoi lui demander.

Étape 4 : assigner les responsabilités

Nommez un responsable pour chaque action du plan. Dans une PME de 30 employés, le dirigeant coordonne probablement la crise, un responsable TI ou le fournisseur gère la restauration technique, et une personne gère la communication interne et externe. Le but : que personne ne se demande « c'est à qui de faire ça ? » en pleine urgence.

Étape 5 : tester le plan au moins une fois

Un plan qui n'a jamais été testé est un plan qui ne fonctionne probablement pas. Le test ne doit pas être complexe : simulez la perte d'un système critique et suivez la procédure. Vous découvrirez les oublis, les étapes manquantes, les identifiants périmés. Mieux vaut les découvrir lors d'un test que lors d'un vrai incident.

Les sauvegardes : nécessaires mais pas suffisantes

Pourquoi une sauvegarde non testée ne vaut rien

Beaucoup de PME ont des sauvegardes automatisées qui tournent en arrière-plan depuis des mois ou des années. Mais personne n'a jamais vérifié si elles fonctionnent. Des sauvegardes corrompues, incomplètes, ou impossibles à restaurer sont plus courantes qu'on le pense. La seule façon de le savoir : tester une restauration.

La règle 3-2-1

C'est un principe simple et largement reconnu dans l'industrie : 3 copies de vos données, sur 2 types de supports différents, dont 1 copie hors site (ou hors réseau). L'objectif est de s'assurer qu'un seul incident (rançongiciel, incendie, panne) ne puisse pas détruire toutes vos copies simultanément.

Les erreurs qui rendent un plan de reprise inutile

Des sauvegardes stockées uniquement sur le même réseau que les systèmes de production — un rançongiciel les chiffre en même temps. Des sauvegardes quotidiennes mais une restauration jamais testée — on découvre le jour J que les fichiers sont corrompus depuis 6 mois. Des identifiants de restauration stockés uniquement dans le gestionnaire de mots de passe qui est sur le serveur hors service.

Erreurs fréquentes

Confondre sauvegarde et PRA. Avoir des sauvegardes, c'est un composant du PRA. Mais un PRA couvre aussi les procédures, les responsabilités, les délais, les contacts, la communication. La sauvegarde sans le plan, c'est un extincteur sans connaître la sortie de secours.

Ne jamais tester la restauration. C'est l'erreur la plus dangereuse et la plus courante. Si vous n'avez jamais restauré un système à partir de vos sauvegardes, vous ne savez pas si ça fonctionne. Testez au moins une fois par an.

Documenter un plan et ne jamais le relire. Un PRA écrit en 2023 avec des numéros de téléphone périmés, des procédures obsolètes et des systèmes qui ont changé depuis n'a aucune valeur. Le plan doit être revu au minimum une fois par an.

Oublier les accès et identifiants de restauration. En situation de crise, l'accès aux mots de passe administrateur, aux clés de chiffrement des sauvegardes et aux identifiants des fournisseurs cloud est critique. Si ces informations sont uniquement dans la tête d'une seule personne ou sur un système hors service, le plan est bloqué.

Ce qu'il faut faire maintenant

Listez vos 5 systèmes les plus critiques. Ceux sans lesquels vous ne pouvez pas opérer. Ne réfléchissez pas en termes techniques — réfléchissez en termes d'opérations : sans quoi ne pouvez-vous pas livrer, facturer, produire, communiquer ?

Vérifiez la date de votre dernière sauvegarde. Et demandez-vous : est-ce qu'on a déjà testé une restauration ? Si la réponse est non, planifiez un test cette semaine.

Estimez combien de temps vous pouvez tenir. Si votre courriel tombe : 2 heures ? 2 jours ? Si votre ERP tombe : combien de temps avant que la production s'arrête ? Ces chiffres sont la base de votre PRA.

Questions fréquentes

C'est quoi le RTO et le RPO ? RTO : le délai maximal pour remettre un système en marche. RPO : la quantité maximale de données qu'on accepte de perdre. Les deux guident les choix techniques de votre PRA.

Est-ce que Microsoft 365 sauvegarde mes données automatiquement ? Microsoft garantit la disponibilité de la plateforme, pas la récupération de vos données. La corbeille a une durée limitée. Une solution de sauvegarde tierce pour Microsoft 365 est recommandée.

Combien de temps prend la construction d'un PRA ? Pour une PME, un PRA de base peut être construit en quelques jours à quelques semaines, selon la complexité de l'environnement. Le plus long n'est pas la rédaction — c'est l'inventaire des systèmes et la définition des priorités.