| En bref Le PCA (plan de continuité d’activité) vise à maintenir les activités critiques pendant une crise ; le PRA (plan de reprise d’activité) organise le redémarrage après une interruption effective. Les deux se construisent à partir de deux indicateurs : le RTO, durée d’indisponibilité tolérable, et le RPO, volume de données que l’entreprise accepte de perdre. Ces deux chiffres, fixés activité par activité, déterminent l’ensemble des choix techniques et budgétaires. Un plan non testé ne vaut rien. |
La plupart des PME possèdent des sauvegardes. Beaucoup moins savent combien de temps il leur faudrait pour redevenir opérationnelles, ni quelle quantité de travail serait perdue. C’est pourtant la seule question qui compte le jour de l’incident, et c’est exactement ce que formalisent le PRA et le PCA. Ces documents ne relèvent pas de la grande entreprise : ils relèvent de toute organisation qui ne peut pas se permettre trois semaines d’arrêt.
Quelle différence entre PRA et PCA ?
| Critère | PCA – continuité | PRA – reprise |
|---|---|---|
| Objectif | Éviter l’interruption des activités critiques | Redémarrer après une interruption avérée |
| Moment d’activation | Pendant l’événement | Après l’événement |
| Périmètre | Organisationnel et technique : locaux, personnel, fournisseurs, SI | Principalement technique : données, serveurs, applications, réseau |
| Exemple de mesure | Second lien internet, télétravail généralisé, procédure papier de secours | Restauration des sauvegardes, serveur de secours, réinstallation maîtrisée |
| Question à laquelle il répond | « Comment continuer à travailler ? » | « Comment revenir à la normale, et en combien de temps ? » |
Les deux plans sont complémentaires et se recoupent partiellement. Une PME qui démarre gagne à construire d’abord son PRA, plus concret et directement adossé à la sauvegarde, puis à l’étendre progressivement vers un PCA à mesure que les activités critiques sont formalisées.
RTO et RPO : les deux chiffres qui structurent tout
Ce sont les deux indicateurs fondateurs, et leur absence explique la plupart des plans inutilisables.
- RTO – Recovery Time Objective : la durée maximale d’indisponibilité acceptable pour une activité donnée. Réponse à la question « combien de temps pouvons-nous rester à l’arrêt ? »
- RPO – Recovery Point Objective : le volume maximal de données que l’entreprise accepte de perdre, exprimé en temps. Réponse à la question « combien d’heures de travail pouvons-nous refaire ? »
Exemple concret. Une sauvegarde s’exécute chaque nuit à 22 h. Une panne survient à 17 h. Les données créées entre 22 h et 17 h, soit dix-neuf heures de travail, sont perdues : le RPO effectif est de 24 heures. Si la restauration complète du serveur prend six heures, le RTO effectif est de six heures. Ces deux valeurs constatées doivent être comparées à ce que l’entreprise juge tolérable. L’écart entre les deux définit exactement le budget à engager.
Le principe économique est simple : plus le RTO et le RPO visés sont courts, plus le coût augmente, de façon non linéaire. Passer de 24 heures à 4 heures coûte modérément ; passer de 4 heures à 15 minutes suppose de la réplication continue et un site de secours, ce qui change d’ordre de grandeur budgétaire.
| Type d’activité | RTO typique | RPO typique | Dispositif correspondant |
|---|---|---|---|
| Site e-commerce, production continue | < 1 h | < 15 min | Réplication temps réel, bascule automatique, site de secours |
| ERP, facturation, gestion commerciale | 4 à 8 h | 1 à 4 h | Sauvegardes multiples par jour, serveur de secours virtualisé |
| Messagerie et bureautique | 4 à 24 h | 1 à 24 h | Sauvegarde du cloud collaboratif, restauration granulaire |
| Archives, historiques, documentation | 3 à 7 jours | 24 h | Sauvegarde quotidienne classique, restauration à la demande |
| Postes de travail individuels | 1 à 3 jours | 24 h | Image de référence, données centralisées sur serveur ou cloud |
Comment construire un PRA/PCA en sept étapes ?
- Cartographier les activités et leurs dépendances : lister les processus métier, puis pour chacun les applications, données, serveurs, accès réseau et prestataires nécessaires. C’est l’étape la plus longue et la plus utile.
- Réaliser une analyse d’impact : pour chaque activité, estimer ce que coûte une heure, une journée, une semaine d’arrêt. Le chiffrage, même approximatif, permet d’arbitrer sans discussion idéologique.
- Fixer un RTO et un RPO par activité : c’est une décision de direction, pas une décision technique. Toutes les activités ne méritent pas le même niveau de protection.
- Identifier les scénarios de sinistre : panne de serveur, ransomware, perte des locaux, indisponibilité d’un prestataire cloud, départ ou absence de la personne clé. Quatre à six scénarios suffisent.
- Choisir les mesures techniques : c’est ici qu’intervient une sauvegarde selon la règle 3-2-1, éventuellement complétée par de la virtualisation, un second site ou des services en ligne de secours.
- Écrire les procédures et désigner les rôles : qui décide de déclencher le plan, qui exécute, qui communique aux clients, qui contacte l’assureur. Avec des coordonnées accessibles hors du système d’information.
- Tester, puis corriger : un plan jamais éprouvé contient toujours au moins une erreur bloquante. Le test la révèle avant l’incident, pas pendant.
Que doit contenir un plan opérationnel ?
Un guide du PRA et du PCA pour PME de MIAP détaille la démarche complète, mais le document final doit au minimum comporter les éléments suivants, sous une forme utilisable par quelqu’un qui n’a pas participé à sa rédaction.
- Les critères de déclenchement : à partir de quel seuil active-t-on le plan, et qui prend la décision.
- L’annuaire de crise : dirigeants, prestataire informatique, assureur, hébergeur, fournisseurs critiques, avec numéros directs.
- L’inventaire technique : serveurs, applications, licences, contrats, emplacement et modalités d’accès aux sauvegardes.
- Les procédures de restauration pas à pas : dans l’ordre exact des dépendances, annuaire avant applications métier, par exemple.
- L’ordre de priorité de redémarrage : tout ne peut pas repartir en même temps, l’arbitrage doit être décidé à froid.
- Le mode dégradé : comment continuer à facturer, livrer ou répondre aux clients sans le système d’information.
- Le plan de communication : messages types pour les clients, les salariés et, le cas échéant, les autorités.
Un point souvent négligé : le plan doit être accessible hors du système d’information qu’il est censé restaurer. Un PRA stocké uniquement sur le serveur chiffré par un ransomware ne sert à rien. Une copie papier en coffre et une copie sur support externe hors ligne restent la règle.
Comment tester un PRA sans perturber la production ?
Le test n’est pas nécessairement une bascule complète. Quatre niveaux existent, de complexité et de coût croissants, et il est cohérent de les combiner sur une année.
| Type de test | Fréquence | Durée | Ce qu’il vérifie |
|---|---|---|---|
| Revue documentaire | Semestrielle | 1 à 2 h | Le plan est à jour : contacts, inventaire, procédures |
| Restauration ponctuelle | Mensuelle | 30 min | Les sauvegardes sont lisibles et les données intègres |
| Exercice sur table | Annuelle | Une demi-journée | Les rôles et les décisions sont clairs pour chacun |
| Bascule réelle ou en bac à sable | Annuelle | 1 journée | Le RTO annoncé est atteignable dans la réalité |
L’indicateur à consigner après chaque test est le RTO constaté, à comparer au RTO visé. C’est le seul chiffre qui démontre qu’un plan fonctionne, et le seul que demandera un client, un assureur ou un auditeur.
Les erreurs les plus fréquentes
| Erreur | Pourquoi elle coûte cher |
|---|---|
| Confondre sauvegarde et PRA | La sauvegarde est un moyen ; le PRA décrit qui restaure quoi, dans quel ordre et en combien de temps |
| Ne pas fixer de RTO ni de RPO | Sans objectif chiffré, aucun arbitrage budgétaire n’est possible et le plan reste théorique |
| Oublier les dépendances externes | Un opérateur télécom, un éditeur SaaS ou un prestataire indisponible bloque la reprise malgré des sauvegardes saines |
| Stocker le plan uniquement sur le SI | Il devient inaccessible exactement au moment où il est nécessaire |
| Reposer sur une seule personne | Si elle est en congés, malade ou partie, le plan n’est pas exécutable |
| Ne jamais tester | Les incompatibilités de version, licences expirées et mots de passe obsolètes se découvrent pendant la crise |
| Ne pas mettre à jour après changement | Un nouvel ERP ou une migration cloud rend le plan caduc en quelques mois |
Questions fréquentes
Un PRA est-il obligatoire pour une PME ?
Il n’existe pas d’obligation générale. Plusieurs cadres l’imposent indirectement : le RGPD exige de pouvoir rétablir la disponibilité des données personnelles en cas d’incident, certains secteurs réglementés ont des exigences propres, et la continuité d’activité figure parmi les domaines couverts par NIS2 pour les entités concernées. Dans les faits, ce sont surtout les donneurs d’ordre et les assureurs qui le demandent.
Combien coûte la mise en place d’un PRA pour une PME ?
Le coût dépend entièrement des RTO et RPO retenus. La phase d’analyse et de rédaction représente généralement quelques jours de travail. Les investissements techniques vont d’un renforcement de la sauvegarde existante à la mise en place d’un site de secours répliqué, avec un rapport de un à dix entre ces deux extrêmes. C’est pourquoi la définition des objectifs précède toujours le chiffrage.
Le cloud dispense-t-il d’un PRA ?
Non. Un hébergeur garantit la disponibilité de son infrastructure, pas celle de vos données ni de votre configuration. Une suppression accidentelle, un compte compromis ou un chiffrement par ransomware se propagent au cloud comme ailleurs. Le PRA reste nécessaire, son contenu change simplement de nature.
À quelle fréquence mettre à jour son PRA ?
Au minimum une fois par an, et systématiquement après tout changement structurant : migration, nouvel outil métier, changement de prestataire, déménagement, ou évolution significative de l’effectif. Un plan de plus de dix-huit mois sans revue est généralement inexploitable.
Peut-on commencer petit ?
Oui, et c’est même recommandé. Un premier document de cinq pages couvrant les trois activités les plus critiques, avec des RTO et RPO assumés et un test de restauration documenté, vaut infiniment mieux qu’un plan exhaustif jamais terminé.
Ce qu’il faut retenir
- Le PCA maintient l’activité pendant la crise, le PRA organise le redémarrage après.
- Tout part du RTO et du RPO, fixés activité par activité par la direction.
- Le coût croît de façon non linéaire à mesure que ces objectifs se resserrent.
- Le plan doit rester accessible en dehors du système d’information qu’il restaure.
- Le RTO constaté lors d’un test est le seul indicateur qui prouve que le plan fonctionne.
