Le plan de continuité d’activité (PCA) organise le maintien des activités prioritaires pendant une perturbation, si nécessaire en mode dégradé. Le plan de reprise d’activité (PRA) organise le retour des systèmes, des applications et des données à un fonctionnement normal après l’incident. Les deux plans se complètent : le premier limite l’impact pendant la crise, le second encadre la reprise.
Une sauvegarde est un prérequis de la reprise, pas un plan à elle seule. Elle permet de restaurer des données, mais ne remplace ni l’analyse d’impact sur l’activité, ni la gouvernance, ni les procédures métier, ni les exercices qui vérifient que l’ensemble fonctionne.
Ce guide s’adresse aux DSI et RSSI qui doivent cadrer ou revoir une démarche PCA/PRA. Il passe en revue les décisions à prendre : le périmètre, les services prioritaires, les dépendances, les objectifs RTO et RPO, la stratégie de reprise, les rôles et les preuves à conserver.
Le plan de continuité d’activité et le plan de reprise d’activité répondent à deux questions différentes. Le PCA répond à « comment continuer à servir nos clients et à fonctionner pendant la perturbation ? ». Le PRA répond à « comment remettre en service les systèmes et les données, dans quel ordre et avec quelle perte acceptable ? ».
Le PCA couvre l’ensemble de l’organisation : processus métier, personnes, locaux, fournisseurs et systèmes d’information. Il décrit les modes dégradés (procédures manuelles, postes ou sites de repli, priorisation des commandes ou des clients), l’organisation de crise et la communication. Il est porté par la direction et les métiers, avec l’appui de la DSI et du RSSI. La norme ISO 22301 fournit un cadre de référence pour structurer un système de management de la continuité d’activité.
Le PRA décrit comment rétablir les ressources nécessaires aux activités après une perturbation. Dans un contexte DSI, il porte principalement sur le système d’information : restauration des données, remise en service des infrastructures et des applications, ordre de reprise et validation avant retour en production. On parle alors de PRA informatique.
Le tableau ci-dessous résume les différences entre PCA et PRA dans une organisation B2B.
Le PRA informatique traduit les besoins des métiers en dispositions techniques. Il couvre en général :
Un PRA informatique contribue au PCA, mais ne le remplace pas. Il ne couvre ni les procédures métier en mode dégradé, ni la gestion de crise, ni la communication interne et externe, ni les solutions de contournement organisationnelles. Une DSI peut restaurer un ERP dans les délais prévus : si la comptabilité ne sait pas comment traiter les factures reçues pendant l’arrêt, l’activité reste perturbée.
Deux objectifs structurent la reprise de chaque service :
Exemple : pour un ERP qui porte la prise de commandes, les métiers peuvent estimer qu’au-delà d’une journée d’arrêt les retards de livraison deviennent critiques, et qu’ils savent ressaisir une demi-journée de commandes à partir des e-mails clients. Le RTO cible est alors d’une journée et le RPO d’une demi-journée. Pour un intranet documentaire, plusieurs jours d’indisponibilité peuvent rester acceptables.
Il n’existe pas de valeur standard. Les objectifs dépendent de l’impact d’un arrêt sur chaque activité, mesuré pendant l’analyse d’impact sur l’activité (BIA). Ils doivent être validés par les responsables métier, puis confrontés à ce que l’infrastructure et les sauvegardes permettent réellement. Un objectif ambitieux qui n’a jamais été atteint en exercice donne une fausse assurance.
Pour la méthode de calcul et des exemples détaillés, consultez notre guide RTO et RPO : définitions, différences et méthode pour les définir dans votre PRA.
La démarche ci-dessous reprend les pratiques usuelles du management de la continuité d’activité, notamment celles décrites par la norme ISO 22301. Son niveau de détail se dimensionne selon la taille de l’organisation et son exposition aux risques.
Désigner un sponsor à la direction, un responsable du PCA et un responsable du PRA informatique. Fixer le périmètre (entités, sites, activités) et les scénarios de référence : cyberattaque, indisponibilité d’un datacenter ou d’un fournisseur, perte d’un site, erreur humaine majeure.
L’analyse d’impact sur l’activité (BIA) évalue, pour chaque activité, les conséquences d’un arrêt qui se prolonge : financières, opérationnelles, juridiques et d’image. La cartographie des dépendances relie ensuite chaque activité aux applications, données, infrastructures, prestataires et personnes clés dont elle a besoin.
Classer les services par niveau de criticité et fixer leurs RTO et RPO. La validation par les métiers rend ces objectifs opposables : elle engage les choix techniques et budgétaires qui suivent.
Pour chaque niveau de criticité, choisir les solutions. Côté métiers : modes dégradés et solutions de contournement. Côté système d’information : sauvegarde et restauration, réplication, environnement de reprise, engagements de secours des fournisseurs. Le choix se fait en comparant le coût de chaque option à l’impact qu’elle permet d’éviter.
Rédiger des procédures utilisables en situation de crise : qui décide le déclenchement, qui fait quoi, dans quel ordre, avec quels accès. Tenir à jour un annuaire de crise (équipes internes, prestataires, éditeurs, assureur) consultable même si le système d’information est indisponible. Définir les critères de retour en production : données contrôlées, sécurité vérifiée, validation par les utilisateurs clés.
Les exercices vérifient que les procédures fonctionnent et que les objectifs sont atteignables. Chaque exercice donne lieu à un retour d’expérience et à un plan d’action. Le PCA et le PRA sont mis à jour après chaque changement significatif : nouvelle application, migration, changement de prestataire, réorganisation.
Pour préparer et conduire ces exercices, consultez Comment tester son PRA selon l’ANSSI : guide pratique et checklist. Les écarts les plus fréquents, comme des objectifs jamais validés ou des plans non mis à jour, sont détaillés dans notre article sur les erreurs critiques dans un PRA/PCA et comment les corriger.
Disposer de sauvegardes et savoir restaurer sont deux choses différentes. Une sauvegarde qui s’exécute sans erreur peut être incomplète, chiffrée par un attaquant, trop longue à restaurer ou dépendante d’un composant lui-même indisponible. Le PRA doit donc s’appuyer sur une capacité de restauration vérifiée, pas seulement sur l’existence de copies.
Les points à traiter :
La règle 3-2-1-1-0, l’immuabilité des copies ou l’isolement physique (air gap) sont des mesures possibles. Leur pertinence dépend des scénarios de risque, des objectifs de reprise et des contraintes d’exploitation. Aucune ne rend à elle seule une organisation conforme ni ne suffit à assurer la reprise : elles s’inscrivent dans le PRA et se vérifient par des restaurations. Le guide de l’ANSSI Fondamentaux de la sauvegarde des systèmes d’information détaille des recommandations sur ces sujets.
Pour choisir une architecture adaptée à vos objectifs, consultez notre comparatif Backup on-premise, hybride ou cloud : quel choix pour un PRA efficace ?
Les textes et documents cités autour du PCA et du PRA n’ont pas la même portée. Les confondre conduit soit à surinvestir, soit à sous-estimer une exigence réelle.
Certaines organisations sont soumises à des textes qui traitent de la continuité et de la reprise :
L’applicabilité d’une obligation, son calendrier et ses modalités doivent être vérifiés avec les fonctions juridique et conformité de l’organisation.
La norme ISO 22301, les guides de l’ANSSI, les publications de l’ENISA ou le référentiel ReCyF de l’ANSSI sont des référentiels et des guides. Ils aident à structurer et à justifier une démarche, mais ne créent pas d’obligation par eux-mêmes, sauf si un texte, un contrat ou une autorité les rend applicables. Il en va de même pour des règles de bonne pratique comme 3-2-1-1-0.
Les pratiques décrites dans ce guide (exercices réguliers, copie de sauvegarde protégée, revue après changement, preuves de restauration) sont des recommandations opérationnelles. Leur fréquence et leur niveau d’exigence se fixent selon le risque, la criticité des services et les obligations effectivement applicables.
