PCA et PRA : définition, différences et mise en œuvre en PME

Le PCA (plan de continuité d'activité) permet à une entreprise de maintenir ses activités essentielles pendant une crise, si besoin en mode dégradé. Le PRA (plan de reprise d'activité) organise le redémarrage du système d'information après un sinistre, dans un délai et avec une perte de données fixés à l'avance. Le premier évite l'arrêt, le second en limite la durée. En PME, les deux reposent sur les mêmes fondations : savoir quelles applications sont critiques, disposer de sauvegardes réellement restaurables et avoir testé la procédure avant d'en avoir besoin.

PCA et PRA : quelles différences ?

Les deux plans sont souvent cités ensemble (« PCA/PRA », « PRA et PCA ») parce qu'ils répondent au même risque : l'interruption de l'activité. Ils n'interviennent pas au même moment et ne mobilisent pas les mêmes moyens.

‍

‍

On rencontre aussi les sigles PCI et PRI (plan de continuité informatique, plan de reprise informatique), qui désignent le volet strictement informatique de ces plans. Dans une PME, la distinction est rarement utile : le PCA/PRA est d'abord un sujet informatique, complété par les procédures métiers qui permettent de travailler pendant la crise.

RTO et RPO : les deux chiffres qui dimensionnent tout

Un PRA se construit autour de deux objectifs, à fixer application par application :

• le RTO (Recovery Time Objective), ou DMIA (durée maximale d'interruption admissible) : combien de temps l'activité peut-elle se passer de cette application ?
• le RPO (Recovery Point Objective), ou PDMA (perte de données maximale admissible) : combien d'heures de données l'entreprise peut-elle accepter de perdre ?

Ces deux valeurs déterminent la technique et le budget. Un RPO de 24 heures se satisfait d'une sauvegarde quotidienne. Un RPO de quelques minutes impose une réplication continue vers un second site. Plus les objectifs sont courts, plus le dispositif coûte cher : c'est pourquoi ils doivent être fixés par la direction avec les métiers, et pas seulement par l'équipe informatique.

En pratique, une PME n'a pas besoin des mêmes objectifs partout. La messagerie, l'ERP ou la production peuvent justifier un RTO de quelques heures, quand un intranet ou un outil d'archivage peut attendre plusieurs jours.

Construire un PCA/PRA en PME : les étapes

1. Mener le bilan d'impact sur l'activité (BIA). Lister les processus métiers, les applications dont ils dépendent, et l'impact d'une interruption dans le temps (financier, contractuel, réglementaire, image). C'est ce bilan qui fixe les RTO et RPO.
2. Analyser les risques. Identifier les scénarios les plus probables : rançongiciel, panne matérielle, erreur humaine, sinistre sur les locaux, défaillance d'un prestataire ou d'un service cloud. Cette analyse s'inscrit dans une démarche de gouvernance, risques et conformité (GRC).
3. Choisir les solutions techniques. Sauvegarde, réplication, infrastructure de secours, redondance des accès réseau : chaque choix doit répondre à un RTO et un RPO précis.
4. Rédiger les procédures. Qui déclare la crise, qui fait quoi, dans quel ordre les services redémarrent, comment joindre les équipes, les prestataires et les clients. Ces procédures et l'annuaire de crise doivent rester accessibles même si le système d'information est hors service.
5. Tester. Un plan jamais testé est une hypothèse. Les tests révèlent les dépendances oubliées et les délais réels de restauration.
6. Maintenir le plan à jour. Chaque nouvelle application, migration ou changement de prestataire modifie le plan. Une revue au moins annuelle, et après chaque changement majeur, évite qu'il devienne obsolète.

Sauvegarde et PRA : pourquoi la sauvegarde ne suffit pas

La sauvegarde est la base de tout PRA, mais elle n'en est qu'une partie. Une entreprise peut sauvegarder chaque nuit et être incapable de redémarrer en moins d'une semaine si elle n'a jamais mesuré le temps de restauration, ni prévu sur quelle infrastructure restaurer.

La règle de référence reste le 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site. Face aux rançongiciels, elle s'est enrichie en 3-2-1-1-0 : une copie immuable ou déconnectée, que l'attaquant ne peut ni chiffrer ni supprimer, et zéro erreur constatée lors des vérifications de restauration.

Trois points font la différence en cas d'attaque :

• Isoler la sauvegarde. Les attaquants cherchent en priorité à détruire les sauvegardes avant de chiffrer. La console de sauvegarde ne doit pas dépendre des mêmes comptes d'administration que le reste du système d'information, et doit être protégée par une authentification multifacteur.
• Vérifier la restauration, pas seulement la sauvegarde. Un journal « sauvegarde réussie » ne prouve pas que les données sont restaurables.
• Couvrir aussi le cloud. Microsoft 365 assure la disponibilité du service, mais la corbeille et les durées de rétention ne remplacent pas une sauvegarde indépendante de vos données, notamment face à une suppression massive ou à un chiffrement malveillant.

Tester son PRA : types de tests et fréquence

Il existe plusieurs niveaux de test, du plus simple au plus complet :

• le test de restauration : restaurer un fichier, une base ou un serveur et mesurer le temps nécessaire ;
• l'exercice sur table : dérouler un scénario de crise en réunion, avec les responsables, pour vérifier que chacun connaît son rôle ;
• le test de bascule partiel : faire redémarrer une application critique sur l'infrastructure de secours ;
• l'exercice complet : simuler la perte du site principal et reprendre l'activité sur le dispositif de secours.

Il n'existe pas de fréquence réglementaire unique. Une pratique courante consiste à tester régulièrement la restauration des applications critiques, à organiser au moins un exercice par an, et à retester après chaque changement majeur de l'infrastructure. Chaque test doit être documenté : date, périmètre, temps mesuré comparé au RTO, écarts constatés et actions correctives. Ces comptes rendus sont aussi les preuves demandées lors d'un audit de conformité.

‍

‍

PCA, PRA et obligations réglementaires

Le PCA/PRA n'est plus seulement une bonne pratique. Plusieurs textes l'exigent directement ou indirectement :

• NIS2 : l'article 21 de la directive range la continuité des activités, dont la gestion des sauvegardes, la reprise après sinistre et la gestion de crise, parmi les mesures de gestion des risques imposées aux entités concernées. Pour savoir si votre entreprise l'est, voir NIS2 : mon entreprise est-elle concernée ?
• DORA : applicable depuis le 17 janvier 2025 aux entités financières, le règlement impose une politique de continuité des activités informatiques, des plans de réponse et de reprise, et des politiques de sauvegarde et de restauration. Leurs prestataires informatiques voient ces exigences répercutées dans leurs contrats.
• RGPD : l'article 32 demande des moyens permettant de rétablir la disponibilité des données personnelles et l'accès à celles-ci dans des délais appropriés en cas d'incident.

Pour structurer la démarche, le SGDSN publie un guide méthodologique pour réaliser un plan de continuité d'activité, et la norme ISO 22301 définit les exigences d'un système de management de la continuité d'activité pour les entreprises qui visent une certification.

Les erreurs les plus fréquentes

• Un PRA stocké uniquement sur le système qu'il doit restaurer. Si le serveur de fichiers est chiffré, la procédure l'est aussi.
• Des sauvegardes accessibles avec les mêmes identifiants que la production. Un attaquant qui obtient les droits d'administration peut les supprimer.
• Des RTO fixés sans budget. Promettre une reprise en une heure sans infrastructure de secours crée une fausse sécurité.
• Oublier les applications SaaS et les prestataires. Messagerie, CRM, logiciel de paie : leur indisponibilité doit aussi être prévue.
• Ne jamais tester. C'est l'erreur la plus répandue, et celle qui transforme un incident en crise.

Ce que prend en charge IT Systèmes

IT Systèmes conçoit et met en place les plans de continuité et de reprise d'activité de ses clients, avec des tests réguliers pour vérifier leur efficacité. L'accompagnement couvre le bilan d'impact, la définition des objectifs de reprise, la mise en œuvre des sauvegardes et du dispositif de secours avec nos partenaires technologiques, dont Veeam, et la documentation des tests.

Le PCA/PRA s'intègre dans notre offre de gouvernance, risques et conformité du SI et dans l'approche cybersécurité d'IT Systèmes : les équipes qui supervisent et exploitent votre infrastructure au quotidien sont aussi celles qui préparent sa reprise.

FAQ

PCA ou PRA : par lequel commencer ?
Pour la plupart des PME, par le PRA : des sauvegardes isolées, restaurables et testées, et une procédure de redémarrage. Le PCA vient ensuite pour les activités qui ne peuvent pas s'arrêter, là où une bascule ou un mode dégradé est justifié.

Une PME est-elle obligée d'avoir un PCA/PRA ?
Oui si elle entre dans le périmètre de NIS2 ou de DORA. Le RGPD impose par ailleurs de pouvoir rétablir la disponibilité des données personnelles. En dehors de ces cas, l'exigence vient souvent des clients, des appels d'offres ou des assureurs.

Quelle différence entre une sauvegarde et un PRA ?
La sauvegarde est une copie des données. Le PRA est l'organisation complète du redémarrage : priorités, infrastructure de restauration, procédures, responsabilités et délais cibles.

Que signifient RTO et RPO ?
Le RTO est la durée maximale d'interruption acceptable pour une application, le RPO la quantité maximale de données que l'on accepte de perdre, exprimée en temps. Ce sont les deux objectifs qui dimensionnent le PRA.

À quelle fréquence tester un PRA ?
Aucun texte ne fixe une fréquence unique. Une pratique courante combine des tests de restauration réguliers sur les applications critiques, au moins un exercice annuel et un nouveau test après chaque changement majeur.

‍

‍