Un plan de reprise d’activité (PRA) est le dispositif documenté qui permet à une entreprise de redémarrer ses systèmes critiques après un sinistre (panne, incendie, cyberattaque, coupure) dans un délai défini. Il repose sur trois piliers : des sauvegardes testées, une infrastructure de secours, et une procédure écrite avec des responsables nommés.
Concrètement : deux indicateurs pilotent tout — le RTO (temps d’interruption acceptable) et le RPO (quantité de données qu’on accepte de perdre).
Comment fonctionne un plan de reprise d’activité (PRA) ? Réponse courte
Le PRA fonctionne en quatre temps : on identifie les systèmes critiques, on réplique leurs données vers un site ou un cloud de secours, on documente la procédure de bascule avec les responsables, puis on teste régulièrement le redémarrage. Sans test, un PRA n’existe pas — c’est un document, pas une capacité.
RTO et RPO : les deux chiffres qui définissent votre PRA
| Indicateur | Signification | Exemple PME |
|---|---|---|
| RTO | Durée maximale d’interruption acceptée | 4 heures pour l’ERP, 1 jour pour la messagerie |
| RPO | Perte de données maximale acceptée | 15 minutes pour la facturation, 24 h pour les fichiers |
| MTTR | Temps moyen réel de restauration | Mesuré lors des tests, doit rester sous le RTO |
Les 5 étapes de construction d’un PRA
Étape 1 — Cartographier les systèmes critiques. Listez applications, serveurs, bases de données et identifiez ce qui arrête l’entreprise en cas d’indisponibilité.
Étape 2 — Définir RTO et RPO par application. Toutes les applications n’ont pas la même criticité : la paie tolère 24 h, la facturation non.
Étape 3 — Mettre en place la réplication. Sauvegardes selon la règle 3-2-1 (trois copies, deux supports, une hors site) et réplication continue vers un site de secours ou un cloud.
Étape 4 — Rédiger la procédure. Qui fait quoi, dans quel ordre, avec quels accès de secours. Les identifiants de secours doivent être accessibles hors du système en panne.
Étape 5 — Tester et corriger. Un test de restauration complet au moins deux fois par an, avec un compte rendu et des actions correctives.
PRA, PCA, sauvegarde : ne pas confondre
| Dispositif | Objet | Cible typique |
|---|---|---|
| Sauvegarde | Copier les données pour pouvoir les restaurer | Toutes les entreprises |
| PRA | Redémarrer les systèmes informatiques après sinistre | PME avec ERP / production |
| PCA | Maintenir l’activité métier pendant la panne (sites, personnes, procédures) | Industrie, santé, logistique |
Les erreurs qui rendent un PRA inutile
1. Sauvegarder sans tester la restauration. La première cause d’échec : on découvre au moment du sinistre que l’archive est illisible.
2. Conserver la sauvegarde dans le même bâtiment. Un incendie ou un ransomware chiffre les deux copies.
3. Ne pas documenter les accès de secours. Si le mot de passe du serveur est dans le serveur, vous n’avez rien.
4. Ignorer la dépendance cloud. Vérifiez les engagements de l’hébergeur et votre capacité à sortir vos données.
5. Ne nommer aucun responsable. Un PRA sans pilote désigné est déclenché trop tard.
Ce que nous déployons
NETREGIA réalise l’audit de criticité, dimensionne RTO/RPO, met en place les sauvegardes 3-2-1 et la réplication, rédige le PRA et forme vos équipes, puis assure les tests périodiques. Voir nos pages sauvegarde et récupération de données et cloud computing.
En résumé : un PRA, c’est des sauvegardes testées + une infra de secours + une procédure écrite avec des responsables. RTO = temps d’arrêt toléré, RPO = données perdues tolérées. Sans test de restauration deux fois par an, vous n’avez pas de PRA.
Êtes-vous réellement protégé ?
Devis gratuit sous 24 h. Casablanca et tout le Maroc.
