Comment créer un plan de reprise après sinistre informatique

Pourquoi un PRA n’est pas un luxe pour les PME sénégalaises ?

60 % des PME qui perdent leurs données ferment dans les 6 mois, selon les études FEMA et Cisco. Au Sénégal, où les coupures électriques, ransomwares et erreurs de stagiaires sont plus fréquents qu’ailleurs, un PRA même minimal (3-2-1 + procédure 1 page + 2 tests/an) divise par 5 le risque de fermeture après un incident majeur. Et bonne nouvelle : 90 % des sinistres informatiques (panne disque, ransomware, suppression accidentelle) se résolvent en 2-4 heures avec un PRA basique.

Plan de reprise après sinistre : préparez-vous au pire

Un PRA (Plan de Reprise d’Activité) définit comment votre entreprise reprend ses opérations après un incident majeur : cyberattaque, panne matérielle, catastrophe naturelle ou erreur humaine.

Les composantes d’un PRA

Étape 1 : Identifier les actifs critiques

• Serveurs : site web, email, applications métier
• Données : base clients, comptabilité, contrats
• Services : internet, téléphonie, paiements
• Équipements : ordinateurs, imprimantes, réseau

Étape 2 : La stratégie de sauvegarde 3-2-1

Étape 3 : Procédures de reprise

Pour un site WordPress

1. Restaurer la dernière sauvegarde de la base de données
2. Restaurer les fichiers WordPress (wp-content)
3. Vérifier que le site fonctionne
4. Changer tous les mots de passe
5. Scanner avec Wordfence ou Sucuri

Pour un réseau d’entreprise

1. Isoler les systèmes compromis
2. Restaurer le serveur depuis la dernière sauvegarde saine
3. Vérifier l’intégrité des données
4. Reconnecter progressivement les postes
5. Documenter l’incident

Étape 4 : Tester le PRA

Erreurs fréquentes

1. Sauvegardes jamais testées

Cause : on configure UpdraftPlus, on voit « backup OK » chaque jour. Le jour de l’incident, la restauration échoue (fichier corrompu, mot de passe oublié, format incompatible).

Solution : test de restauration complète tous les 3 mois, sur un environnement de staging. Documentez le RTO réel mesuré. Une sauvegarde non testée n’est pas une sauvegarde.

2. PRA dans la tête du DSI uniquement

Cause : tout le savoir est concentré chez une seule personne. Si elle est en congé/malade/partie le jour de l’incident, l’entreprise est paralysée.

Solution : documentation écrite (1-2 pages) accessible à 2-3 personnes minimum. Procédures pas-à-pas avec captures d’écran, mots de passe stockés dans Bitwarden Teams partagé.

3. RPO/RTO non quantifiés

Cause : « on veut récupérer rapidement » — mais combien de temps précisément ? 30 min ou 24h ? Le coût et la complexité varient d’un facteur 100 entre les deux.

Solution : chiffrez le coût d’arrêt (FCFA/heure) pour chaque système critique, et alignez le budget PRA dessus. RTO 1h pour la facturation, RTO 24h pour le wiki interne : tout n’a pas le même poids.

4. Sauvegardes sur le même réseau que la production

Cause : NAS de backup branché sur le même VLAN que les serveurs prod. Le ransomware chiffre tout en même temps.

Solution : 1 copie hors site obligatoire (Backblaze B2, Wasabi, autre VPS). Et idéalement une copie immutable (object lock) que même un admin ne peut pas effacer pendant N jours.

5. Pas de plan de communication crise

Cause : on restaure les serveurs en silence pendant 4h. Pendant ce temps, les clients voient « site indisponible », appellent en panique, partagent sur Facebook et la confiance s’effondre.

Solution : dans le PRA, intégrez un plan de comm : page status (statuspage.io, gratuit), template tweet/WhatsApp, message d’attente des appels, briefing direction. Communication = 50 % de la gestion de crise.

Modèle de PRA simplifié

Pour explorer plus loin

• Protéger votre entreprise contre les ransomwares — l’incident n°1 qui déclenche un PRA.
• Créer une politique de sécurité informatique — la PSI doit inclure le PRA.
• Sécuriser votre site WordPress — application directe pour les sites WP/WooCommerce.
• Gérer les droits d’accès — qui peut déclencher la restauration ?
• Référence officielle : CISA — Cyber Resilience et NIST Cybersecurity Framework 2.0.
• Outils : Veeam Backup Free, restic, UpdraftPlus (WP).

Etape 1 : cartographier les actifs critiques avant de parler de reprise

Avant de choisir une solution de sauvegarde ou un site de repli, on liste froidement ce qui ferait couler l’activite si on le perdait demain matin. Pour un cabinet a Dakar, une PME a Abidjan ou une fintech a Lome, c’est generalement la base clients, la comptabilite, les contrats signes, les boites mail professionnelles et l’application metier. On ouvre un tableur et on cree quatre colonnes : actif, ou il est stocke, qui en depend, combien d’heures sans cet actif avant arret total.

Actif                | Stockage         | Depend       | Tolerance
---------------------|------------------|--------------|----------
Base clients CRM     | Serveur local    | Commercial   | 4 h
Compta Sage          | PC comptable     | Direction    | 24 h
Mails Microsoft 365  | Cloud Microsoft  | Tous         | 2 h
Contrats PDF         | Disque partage   | Juridique    | 48 h

La colonne tolerance devient votre RTO (Recovery Time Objective). Si la base CRM doit revivre en 4 h, aucune sauvegarde sur disque externe rapportee le lendemain matin ne fera l’affaire. Cette grille evite de surinvestir sur des actifs secondaires et de sous-proteger ceux qui paient les salaires.

Etape 2 : definir RTO et RPO chiffres, pas des voeux pieux

Le RTO repond a la question « en combien de temps je redemarre ». Le RPO (Recovery Point Objective) repond a « combien de donnees je peux me permettre de perdre ». Une sauvegarde quotidienne a 23h donne un RPO de 24 h : si le serveur tombe a 22h, vous perdez la journee entiere de saisie. Pour un commerce qui encaisse 200 transactions par jour a 5 000 FCFA en moyenne, ca represente 1 000 000 FCFA (environ 1 525 EUR) de ressaisie ou de perte seche.

On etablit donc un tableau RTO/RPO valide par la direction, signe, range dans le classeur qualite. C’est ce document qui justifiera plus tard l’achat d’un NAS replique ou d’un abonnement cloud. Sans ce chiffrage, n’importe quel devis paraitra trop cher.

Etape 3 : appliquer la regle 3-2-1 sans triche

La regle 3-2-1 reste la base : 3 copies des donnees, sur 2 supports differents, dont 1 hors site. Concretement pour une PME a Yaounde, ca donne : copie de production sur le serveur, copie locale sur un NAS Synology ou QNAP, copie distante sur un service cloud type Backblaze B2, Wasabi ou OVH Object Storage.

# Sauvegarde quotidienne vers Backblaze B2 avec rclone
rclone sync /srv/data b2:pme-backup-2026   --backup-dir b2:pme-backup-2026/archive/$(date +%Y-%m-%d)   --transfers 4 --checksum --log-file /var/log/rclone-b2.log

L’option –backup-dir conserve les versions ecrasees pendant la duree de retention configuree cote Backblaze. Le –checksum verifie que chaque fichier transfere est identique a la source, ce qui detecte une corruption silencieuse. On planifie via cron a 2h du matin et on s’abonne aux notifications de fin de job par email.

Etape 4 : tester la restauration, pas juste la sauvegarde

Une sauvegarde non testee est une sauvegarde qui n’existe pas. On planifie un test trimestriel ou on prend un fichier au hasard d’il y a 30 jours et on le restaure sur un PC vierge. Chronometre en main. Si la restauration prend 6 h alors que le RTO est de 4 h, le plan est non conforme.

# Test restauration depuis B2 vers un dossier temporaire
mkdir -p /tmp/restore-test
rclone copy b2:pme-backup-2026/srv/data/clients.db /tmp/restore-test
sha256sum /tmp/restore-test/clients.db
# Comparer avec un hash connu de reference

La sortie sha256sum doit correspondre au hash archive lors de la sauvegarde. Toute divergence revele une corruption qu’il faut investiguer immediatement, en general en relancant une copie complete depuis la source.

Etape 5 : preparer un site de repli realiste

Pour une PME, le site de repli n’est pas forcement un datacenter en miroir. C’est souvent une seconde agence equipee, le domicile du DSI, ou un serveur cloud type Scaleway ou OVH chez Roubaix qui peut etre allume en 2 h. On documente l’adresse IP, les identifiants de console, le contact technique, le mode de bascule DNS.

On y stocke en permanence une image systeme du serveur principal, mise a jour chaque semaine. Le jour J, on n’improvise pas : on sort le runbook, on suit les etapes numerotees. C’est la difference entre une bascule en 4 h et une cellule de crise qui dure 3 jours.

Etape 6 : rediger un runbook clair et numerote

Le runbook est le document que le stagiaire de garde doit pouvoir suivre seul a 3h du matin. Il commence par la liste des contacts (DSI, hebergeur, fournisseur Internet, direction), puis enchaine les etapes : couper l’acces, lever la sauvegarde la plus recente, monter le serveur de repli, basculer le DNS, communiquer aux equipes.

Runbook bascule serveur principal
1. Confirmer la panne avec hebergeur (tel : +221 33 ...)
2. Bloquer ecritures sur l'ancien serveur
3. Sur cloud OVH, demarrer instance backup-prod-01
4. Modifier enregistrement A : data.entreprise.com -> 51.x.x.x
5. Vider cache DNS interne (TTL 300 s)
6. Verifier connexion via VPN test
7. Annoncer aux equipes par WhatsApp Business

Chaque etape doit etre verifiable. Si l’etape 4 echoue, on ne passe pas a la 5. Le runbook vit : apres chaque incident reel ou exercice, on annote ce qui a coince et on met a jour la procedure.

Etape 7 : organiser un exercice annuel grandeur nature

Une fois par an, on simule une perte totale du serveur principal un samedi matin. On chronometre, on observe, on note. Cet exercice revele les angles morts : mot de passe perdu, contact hebergeur qui a change, VPN expire, batterie de l’onduleur HS. Mieux vaut decouvrir ces problemes en exercice qu’en pleine crise.

On invite la direction a observer. Elle comprend mieux les budgets demandes l’annee suivante quand elle a vu de ses yeux ce qui se passe quand le serveur tombe. C’est aussi l’occasion de former un second technicien, pour eviter le facteur bus.

Etape 8 : tracer, ameliorer, recommencer

Apres chaque exercice ou incident reel, on remplit un rapport court : duree de la bascule, RTO atteint, ecarts au runbook, actions correctives. Ce rapport alimente le tableau de bord PRA suivi par la direction. En 2 a 3 cycles, le RTO mesure converge vers le RTO cible.

Pour approfondir sur la securisation des donnees clients pendant un incident, lisez notre guide sur les fondamentaux de la cybersecurite et la fiche dediee aux malwares et leurs protections. Un PRA solide protege votre activite, vos clients et votre reputation.

Etape 9 : integrer les fournisseurs cles dans votre PRA

Votre PRA ne s’arrete pas aux serveurs internes. L’hebergeur, l’operateur Internet, le fournisseur de telephonie professionnelle, l’editeur du logiciel metier sont autant de maillons qui peuvent tomber. On documente pour chacun le contact technique direct, le SLA contractuel, le numero d’astreinte 24/7. On verifie tous les 6 mois que ces contacts sont toujours valides et que les SLA correspondent toujours aux RTO definis a l’etape 2. Un fournisseur qui repond sous 48 h alors que votre RTO est de 4 h est un point de defaillance majeur a renegocier ou remplacer immediatement avant qu’un incident ne le revele dans la douleur.