Plan de reprise d'activité : ce qu'une PME doit vraiment préparer

Un plan de reprise d’activité n’est pas un document de cinquante pages. C’est la réponse écrite à une question simple : si notre informatique s’arrête maintenant, que fait-on, dans quel ordre, et en combien de temps sommes-nous de retour ? Dans beaucoup de PME marocaines, cette réponse n’existe que dans la tête d’une ou deux personnes : le responsable informatique, le prestataire, parfois le gérant. Le jour où le serveur ne redémarre pas, où un ransomware chiffre les fichiers ou où un dégât des eaux touche la salle technique, l’entreprise découvre qu’elle improvise. Ce guide explique les décisions à prendre, les scénarios à couvrir, le contenu du plan et la manière de le tester sans arrêter l’activité.

PRA, PCA : de quoi parle-t-on ?

Les deux sigles sont souvent confondus :

• Le plan de reprise d’activité (PRA) organise le redémarrage après un arrêt : restaurer les systèmes, les données et les accès, dans un ordre défini.
• Le plan de continuité d’activité (PCA) vise à éviter l’arrêt : équipements redondants, bascule automatique, procédures de fonctionnement en mode dégradé.

Un PCA complet coûte cher et n’est justifié que pour les activités qui ne tolèrent presque aucune interruption. Pour la plupart des PME, la priorité est un PRA réaliste et testé, complété par quelques éléments de continuité ciblés sur les points les plus critiques.

Deux chiffres à décider avant tout

• RTO (temps de reprise) : combien d’heures d’arrêt acceptez-vous ? Une clinique répond « deux heures », un cabinet comptable « une journée », sauf en période fiscale.
• RPO (perte de données acceptable) : combien de minutes ou d’heures de travail pouvez-vous perdre ? C’est ce chiffre qui fixe la fréquence des sauvegardes.

Ces deux valeurs dictent le budget. Un RTO de deux heures exige des serveurs de secours prêts à démarrer ; un RTO de 48 heures se contente de bonnes sauvegardes et d’un matériel de remplacement disponible.

Ce sont des décisions de direction, pas des décisions techniques. Le rôle de l’informaticien est de chiffrer ce que coûte chaque niveau ; celui du dirigeant est de choisir, application par application. La messagerie, l’ERP, le logiciel de caisse ou le dossier patient n’ont pas forcément le même RTO.

RTO visé	Ce qu’il faut en place	Profil typique
Quelques heures (par exemple deux heures)	Serveurs de secours prêts à démarrer, réplication des machines virtuelles, procédure de bascule répétée	Activité qui s’arrête net sans informatique : soins, production, accueil client
Une journée	Sauvegardes locales rapides à restaurer, matériel de remplacement identifié, restauration déjà chronométrée	Cabinets, bureaux, services où l’on peut travailler quelques heures en mode dégradé
48 heures	Bonnes sauvegardes, dont une copie hors site et immuable, et matériel de remplacement disponible	Activités où un arrêt court est gênant mais pas critique

Les scénarios à couvrir

Panne matérielle, ransomware, incendie ou dégât des eaux, coupure électrique prolongée, erreur humaine, départ d’un administrateur. Chaque scénario a une réponse différente. Le ransomware, par exemple, exige des sauvegardes immuables et un réseau que l’on peut isoler en quelques minutes.

Scénario	Ce qui est perdu	Réponse principale
Panne matérielle	Un serveur, un stockage, un équipement réseau	Redondance ou matériel de remplacement, restauration depuis la sauvegarde locale
Ransomware	Données chiffrées, sauvegardes accessibles, parfois comptes d’administration	Isolement du réseau, sauvegarde immuable hors site, reconstruction de l’identité avant tout
Incendie ou dégât des eaux	Salle technique entière	Copie hors site, matériel de remplacement, lieu de redémarrage prévu
Coupure électrique prolongée	Accès aux serveurs locaux	Onduleurs pour un arrêt propre, services essentiels accessibles hors site
Erreur humaine	Fichiers ou base supprimés, configuration cassée	Restauration granulaire, rétention suffisante pour remonter avant l’erreur
Départ d’un administrateur	Mots de passe, connaissance du système	Coffre de mots de passe partagé, documentation à jour, comptes nominatifs

Le scénario ransomware est le plus exigeant, car il touche aussi les sauvegardes. Notre article sur la règle 3-2-1-1-0 et les sauvegardes immuables détaille comment garder une copie hors d’atteinte, et celui sur les sept mesures contre les ransomwares couvre la prévention.

Le plan lui-même, en une page

Qui décide de déclencher le plan. Qui appelle qui, avec les numéros. Où sont les sauvegardes et comment y accéder sans le réseau de l’entreprise. Dans quel ordre restaurer : identité, réseau, messagerie, ERP, fichiers. Comment prévenir clients et fournisseurs.

Cet ordre n’est pas arbitraire. Sans l’identité (annuaire, comptes, MFA), personne ne peut se connecter à rien. Sans le réseau (pare-feu, commutateurs, accès internet), les systèmes restaurés restent injoignables. La messagerie permet ensuite de communiquer avec les clients et les équipes, avant de remettre en route l’ERP et enfin les fichiers, souvent volumineux et moins urgents.

Le document doit être disponible hors du système qu’il sert à reconstruire : une version imprimée dans un lieu connu, une copie accessible sans le réseau de l’entreprise. Un PRA stocké uniquement sur le serveur de fichiers disparaît avec lui.

Méthode pas à pas

1. Inventorier les applications, les serveurs et les données, avec leur propriétaire métier.
2. Fixer le RTO et le RPO de chaque application avec la direction.
3. Comparer ces objectifs avec la réalité : fréquence des sauvegardes, lieu de stockage, temps de restauration déjà mesuré.
4. Combler les écarts : sauvegarde immuable, matériel de remplacement, réplication, ou, lorsque le RTO est court, une infrastructure virtualisée en haute disponibilité.
5. Rédiger la page : déclenchement, contacts, accès aux sauvegardes, ordre de restauration, communication.
6. Tester, mesurer, corriger, puis recommencer au trimestre suivant.

Ce qui fait varier l’effort et le budget

Deux PME de même taille peuvent avoir des PRA très différents. Les principaux facteurs sont :

• Le RTO et le RPO retenus : ce sont eux qui pèsent le plus, car un arrêt court et une perte de données minime imposent de la redondance et des sauvegardes fréquentes.
• Le nombre d’applications critiques et leurs dépendances : un ERP relié à une base de données, à un annuaire et à des postes clients demande plus de préparation qu’un simple partage de fichiers.
• La part de l’informatique hébergée sur site par rapport au cloud, qui change les scénarios à couvrir et les moyens de restauration.
• Le nombre de sites à remettre en route et la qualité des liens qui les relient.
• La documentation existante : partir d’un inventaire à jour réduit fortement le travail initial.
• Le niveau d’exigence des tests, d’une restauration par application jusqu’à la reconstruction complète dans un environnement isolé.

Les erreurs les plus fréquentes

Dans les PME, les mêmes écarts reviennent souvent :

• Un RTO décidé par défaut. Personne ne l’a fixé, et l’on découvre pendant l’incident que la restauration prend bien plus longtemps que ce que l’activité supporte.
• Des sauvegardes inaccessibles sans le réseau. Les identifiants sont dans l’annuaire à reconstruire, ou la console n’est joignable que depuis un poste interne.
• Des numéros de téléphone obsolètes ou un seul contact d’urgence, en congé le jour J.
• Un plan jamais relu après un changement de serveur, de prestataire ou d’application.
• La communication oubliée : clients, fournisseurs et équipes apprennent la panne par eux-mêmes.

Le test, sinon rien

Un PRA jamais testé est une hypothèse. Nous réalisons avec nos clients une restauration complète chronométrée au moins une fois par trimestre, sur un environnement isolé, et nous mettons à jour le document à chaque écart constaté.

Le test se fait sans arrêter la production : les systèmes sont restaurés dans un réseau isolé, où l’on vérifie que les applications démarrent, que les données sont cohérentes et que les utilisateurs clés peuvent travailler. Le chronomètre donne le RTO réel ; la date du dernier point restauré donne le RPO réel. Si l’un des deux dépasse l’objectif fixé, le plan ou l’infrastructure doit évoluer.

Checklist : votre PRA en l’état

• Le RTO et le RPO de chaque application critique sont écrits et validés par la direction.
• Une copie des sauvegardes est hors site et immuable.
• Les sauvegardes sont accessibles sans le réseau ni l’annuaire de l’entreprise.
• L’ordre de restauration est défini : identité, réseau, messagerie, ERP, fichiers.
• Les contacts d’urgence sont à jour, avec au moins un suppléant.
• Le plan existe en version imprimée et hors du serveur de fichiers.
• Une restauration complète est testée chaque trimestre, et chaque écart est corrigé.

Le PRA fait partie de notre offre cybersécurité et de nos architectures de virtualisation haute disponibilité. Pour définir vos objectifs de reprise et vérifier qu’ils sont atteignables, contactez-nous.