Un plan de reprise d’activité, ou PRA, répond à une seule question : dans quel ordre et en combien de temps l’entreprise redémarre après un sinistre informatique. La plupart des modèles disponibles en ligne s’arrêtent à la définition. Celui-ci est rempli, avec des valeurs que vous pouvez reprendre et corriger.
En bref — Un PRA tient en quatre décisions : ce que vous acceptez de perdre (le RPO), le délai avant de retravailler (le RTO), l’ordre de redémarrage des applications, et qui décide de déclencher le plan. Tout le reste en découle. Un plan jamais testé ne vaut rien : les délais qu’il annonce ne sont vérifiés que par un test de restauration.
Ce qu'un plan de reprise d'activité doit contenir
Huit rubriques suffisent, et aucune ne peut manquer sans rendre le plan inapplicable le jour J.
1. Le périmètre. La liste nominative des serveurs, applications et données couverts. Ce qui n’y figure pas ne sera pas restauré.
2. Les deux objectifs chiffrés. Le RPO et le RTO, par application et non globalement.
3. L’ordre de redémarrage. Numéroté. L’annuaire et le réseau avant la messagerie, la messagerie avant l’ERP, l’ERP avant les postes.
4. Le déclenchement. Qui a le pouvoir de déclarer le sinistre, et son suppléant.
5. Les accès de secours. Où sont les mots de passe d’administration si l’annuaire est inaccessible, et qui peut les lire.
6. Le mode dégradé. Comment l’activité continue pendant la reprise : commandes sur papier, téléphone renvoyé sur mobile, caisse hors ligne.
7. Les contacts. Prestataire, opérateur, assureur, et les numéros qui fonctionnent quand la messagerie est tombée.
8. La date du dernier test. Un plan sans cette ligne est une intention.
Exemple de plan de reprise d'activité pour une PME de 30 personnes
Voici un plan rempli pour un cas courant : une PME de 30 salariés, deux serveurs physiques, un ERP métier, la messagerie sur Microsoft 365 et un partage de fichiers.
Périmètre — Serveur ERP (base SQL), serveur de fichiers, annuaire Active Directory, messagerie Microsoft 365, postes de travail. Hors périmètre : téléphonie mobile personnelle, archives papier.
Objectifs par application — ERP : RPO 4 heures, RTO 24 heures. Fichiers : RPO 24 heures, RTO 24 heures. Annuaire : RPO 24 heures, RTO 4 heures. Messagerie : assurée par l’éditeur.
Ordre de redémarrage — 1. réseau et pare-feu ; 2. annuaire ; 3. serveur de fichiers ; 4. ERP ; 5. postes de travail ; 6. impressions et périphériques.
Déclenchement — Le dirigeant, ou à défaut le responsable administratif, déclare le sinistre et prévient le prestataire. Aucune restauration ne démarre sans cette déclaration.
Accès de secours — Coffre de mots de passe exporté chaque mois, copie chiffrée conservée hors site, deux personnes détiennent le code.
Mode dégradé — Prise de commandes sur formulaire papier pendant 24 heures, standard renvoyé sur deux mobiles, facturation reportée.
Dernier test — Restauration complète de la base ERP, réalisée le trimestre dernier, redémarrage constaté en 6 heures contre 24 visées.
Les deux chiffres qui déterminent tout le reste
Le RPO est le volume de travail que vous acceptez de perdre. Un RPO de 4 heures signifie que la dernière sauvegarde exploitable peut avoir 4 heures : vous ressaisissez au pire une demi-journée.
Le RTO est le délai avant de retravailler. Il dépend de la sauvegarde, mais aussi du matériel disponible pour redémarrer : restaurer 2 To sur un serveur qu’il faut d’abord commander, c’est une semaine, quelle que soit la qualité des sauvegardes.
Nos trois niveaux de service engagent un RPO de 24 heures, 4 heures ou 1 heure, et un RTO de 72 heures, 24 heures ou 4 heures. Ces valeurs figurent au contrat. Plus elles sont courtes, plus le dispositif coûte cher, parce qu’il faut répliquer plus souvent et garder du matériel prêt.
Le point que les plans escamotent : le test
Un plan de reprise qui n’a jamais été exécuté annonce des délais théoriques. Le test révèle toujours la même chose : une dépendance oubliée, une licence liée au matériel remplacé, un mot de passe que personne ne retrouve, ou un volume de données qui met trois fois plus longtemps à revenir que prévu.
Nous réalisons au minimum deux tests de restauration par an et nous en remettons le compte rendu écrit, avec le délai réellement atteint. C’est ce document, et non le plan, qui prouve que la reprise fonctionne. Pour les environnements Microsoft, Azure Site Recovery permet de basculer vers une région secondaire ; encore faut-il avoir essayé au moins une fois.
PRA, PCA et sauvegarde : trois choses différentes
La confusion est fréquente et elle coûte cher au moment de comparer des devis.
La sauvegarde copie les données pour pouvoir les restaurer. Elle ne dit rien du délai.
Le PRA organise le redémarrage après un arrêt : dans quel ordre, en combien de temps, par qui. Il suppose une interruption assumée.
Le PCA, plan de continuité, vise à ne pas s’arrêter du tout : infrastructure doublée, bascule automatique. Il coûte plusieurs fois le prix d’un PRA.
Une PME a besoin d’une sauvegarde et d’un PRA. Le PCA se justifie quand une heure d’arrêt coûte plus que le doublement de l’infrastructure.
La matière première du plan reste la copie hors site : voyez notre solution de sauvegarde externalisée.
Les erreurs qui rendent un plan inutilisable
Le plan n’existe que sur le serveur qui est tombé. Il doit être imprimé et accessible hors ligne.
Les objectifs sont globaux. « RTO 24 heures » pour toute l’entreprise ne dit pas quoi redémarrer en premier.
Personne n’est nommé. Un plan sans nom de personne ne se déclenche pas.
Aucune date de test. C’est le signe le plus fiable d’un plan qui ne fonctionnera pas.
Le mode dégradé est absent. Vingt-quatre heures d’arrêt se traversent, à condition d’avoir prévu comment.
Questions fréquentes
Qu'est-ce qu'un plan de reprise d'activité ?
C’est un document qui décrit comment redémarrer le système d’information après un sinistre : le périmètre couvert, le délai visé par application, l’ordre de redémarrage, qui déclenche et qui exécute. Il se distingue d’une sauvegarde, qui copie les données sans rien promettre sur le délai.
Que doit contenir un plan de reprise d'activité ?
Huit rubriques : le périmètre, les objectifs RPO et RTO par application, l’ordre de redémarrage, la personne qui déclenche, les accès de secours, le mode dégradé, les contacts utiles, et la date du dernier test. Un modèle rempli pour une PME de 30 personnes figure plus haut dans cette page.
Que signifient RPO et RTO ?
Le RPO est la perte de données acceptée, le RTO le délai avant de retravailler. Nos niveaux de service engagent un RPO de 24 heures, 4 heures ou 1 heure, et un RTO de 72 heures, 24 heures ou 4 heures, inscrits au contrat.
Quelle différence entre un PRA et un PCA ?
Le PRA organise le redémarrage après une interruption assumée. Le PCA, plan de continuité, vise à ne pas s’interrompre : infrastructure doublée et bascule automatique, pour un coût plusieurs fois supérieur. Une PME commence par la sauvegarde et le PRA.
À quelle fréquence tester son plan de reprise ?
Au minimum deux fois par an, et à chaque changement important d’infrastructure. Chaque test doit produire un compte rendu écrit indiquant le délai réellement atteint : c’est la seule preuve que les objectifs du plan sont tenables.
Une sauvegarde suffit-elle à tenir lieu de PRA ?
Non. La sauvegarde est la matière première du plan, pas le plan. Sans ordre de redémarrage, sans délai visé et sans personne nommée, vous avez des données restaurables mais aucune idée du temps que prendra la reprise.
Comment obtenir un plan adapté à mon parc ?
Nous établissons le plan à partir d’un audit gratuit du parc, qui relève le périmètre réel, les dépendances entre applications et les délais atteignables avec l’infrastructure en place. Le devis suit sous 48 heures.
Faire écrire votre plan de reprise
Un plan utile se construit sur le parc réel, pas sur un modèle. L’audit relève les dépendances entre applications et les délais réellement atteignables avec l’infrastructure en place. Il est gratuit, et le devis suit sous 48 heures.
Les valeurs de l’exemple sont celles d’un cas courant et n’ont pas valeur d’engagement : les objectifs d’un plan se fixent par application, sur le parc réel.
