Différence PCA PRA : 5 points essentiels pour ne plus les confondre
Différence PCA PRA : 5 points essentiels pour ne plus les confondre
La différence PCA PRA est probablement la confusion la plus répandue en matière de résilience d’entreprise. Les deux sigles circulent dans les mêmes réunions, apparaissent dans les mêmes appels d’offres, et sont régulièrement employés l’un pour l’autre — y compris par des prestataires informatiques.
Cette confusion n’est pas anodine. Une organisation persuadée d’avoir couvert le sujet parce que sa DSI dispose d’un plan de reprise découvre souvent, le jour de la crise, qu’elle sait redémarrer ses serveurs mais pas faire tourner son activité.
Cet article clarifie ce qui distingue réellement ces deux dispositifs, pourquoi l’un ne remplace pas l’autre, et comment ils s’articulent dans une démarche cohérente.
Table des matières
Deux réponses à deux questions différentes
La façon la plus simple de saisir la différence PCA PRA consiste à écouter la question à laquelle chacun répond.
Le Plan de Continuité d’Activité répond à : comment continuons-nous à fonctionner pendant que le problème dure ? Il organise le maintien des activités essentielles en mode dégradé, avec des moyens réduits, éventuellement sans informatique du tout.
Le Plan de Reprise d’Activité répond à : comment remettons-nous les systèmes en état ? Il décrit les opérations techniques de restauration : bascule sur l’infrastructure de secours, restauration des sauvegardes, remise en service des applications.
À retenir
Le PCA est un plan métier qui intègre une dimension informatique. Le PRA est un plan informatique. L’un englobe l’autre — ils ne sont pas au même niveau.
En anglais, la distinction est plus lisible : Business Continuity Plan d’un côté, Disaster Recovery Plan de l’autre. Le premier parle de l’activité, le second du sinistre technique.
Les cinq différences fondamentales
1. L’objectif
Le PCA vise la continuité du service rendu. Peu importe le moyen : si vos commandes peuvent être saisies sur papier pendant deux jours, c’est une solution de continuité valable.
Le PRA vise le retour à la normale technique. Son succès se mesure au fait que les systèmes refonctionnent comme avant.
Cette différence d’objectif change tout. Un PCA accepte le mode dégradé comme un état de fonctionnement légitime. Un PRA le considère comme un état transitoire à supprimer au plus vite.
2. Le périmètre
C’est la différence la plus structurante. Le PRA couvre les systèmes d’information : serveurs, réseaux, données, applications.
Le PCA couvre tout ce dont dépend l’activité :
Un incendie dans vos bureaux ne relève pas du PRA si vos serveurs sont hébergés ailleurs. Il relève pleinement du PCA.
3. Le moment
Le PCA s’active dès le début de la perturbation et reste en vigueur tant qu’elle dure. Il peut couvrir des semaines.
Le PRA s’exécute sur une fenêtre plus courte, celle de la restauration technique. Une fois les systèmes rétablis, il s’arrête.
Les deux fonctionnent souvent en parallèle : pendant que la DSI restaure, les équipes métier travaillent en mode dégradé selon le PCA.
4. Le pilotage
Le PRA est piloté par la DSI ou le prestataire infogérance. Ses acteurs sont techniques.
Le PCA relève de la direction générale. Il engage des arbitrages qui dépassent largement l’informatique : faut-il arrêter la production, communiquer publiquement, déclencher les procédures d’assurance, notifier les autorités.
C’est pourquoi un PCA rédigé uniquement par la DSI produit rarement un document exploitable en crise réelle.
À retenir
Si votre plan a été écrit sans la direction générale, la communication et le juridique, vous avez probablement un PRA que vous appelez PCA.
5. Les indicateurs
Les deux dispositifs partagent deux métriques techniques :
Mais le PCA en ajoute une, souvent ignorée : la DMIA, ou Durée Maximale d’Interruption Admissible. Elle exprime le point au-delà duquel l’interruption devient irréversible pour l’organisation — perte de clients définitive, rupture de contrat, dépôt de bilan.
Le RTO est un objectif technique. La DMIA est une limite métier. Le premier doit impérativement rester inférieur à la seconde.
Pourquoi un PRA seul ne suffit pas
Beaucoup d’organisations disposent d’un PRA correct et se croient couvertes. Voici ce que le jour de la crise révèle.
Le PRA suppose que quelqu’un le déclenche. Qui a autorité pour décider d’une bascule ? À quel moment ? Sur quels critères ? Ces questions relèvent du PCA.
Le PRA ne dit rien de l’activité pendant la restauration. Si le RTO est de huit heures, que font vos équipes pendant ces huit heures ? Comment traitez-vous les commandes urgentes ? Que répondez-vous à un client qui appelle ?
Le PRA ignore les scénarios non informatiques. Inondation des locaux, indisponibilité massive du personnel, défaillance d’un fournisseur unique : aucun de ces cas ne se résout par une restauration de sauvegarde.
Le PRA ne couvre pas la communication. Or en cas de cyberattaque, la façon dont vous communiquez avec vos clients et vos partenaires pèse souvent plus lourd sur votre réputation que le délai technique de reprise.
Consultez nos services de continuité d’activité pour un accompagnement sur ces deux volets.
Comment les deux plans s’articulent
La bonne articulation suit une logique descendante.
1. On commence par l’analyse d’impact métier. Le BIA identifie les processus critiques, mesure ce que coûte leur interruption et fixe la DMIA de chacun. C’est le socle commun aux deux plans.
2. On en déduit les objectifs de reprise. Les RTO et RPO découlent de la DMIA, jamais l’inverse. Un RTO fixé par la DSI sans référence au métier est un chiffre arbitraire.
3. On construit le PCA. Stratégies de continuité par processus, organisation de crise, procédures dégradées, communication.
4. On décline le PRA. Il devient le volet informatique du PCA, dimensionné sur les objectifs fixés à l’étape 2.
5. On teste l’ensemble. Un exercice de crise éprouve le PCA ; un test de bascule éprouve le PRA. Les deux sont nécessaires et ne se substituent pas l’un à l’autre.
Cette séquence explique pourquoi commencer par le PRA — ce que font la plupart des organisations — conduit souvent à un dispositif mal calibré : on a optimisé la technique sans savoir ce que le métier pouvait réellement supporter.
Téléchargez notre checklist de résilience pour situer votre niveau actuel sur ces deux volets.
Ce qu’exigent NIS2 et DORA
La distinction entre les deux plans a cessé d’être théorique depuis que les textes européens s’en sont saisis.
L’article 21 de la directive NIS2 impose aux entités essentielles et importantes des mesures de continuité d’activité, incluant explicitement la gestion des sauvegardes, la reprise après sinistre et la gestion de crise. La formulation couvre les deux dimensions : le volet technique et le volet organisationnel.
Le règlement DORA, applicable au secteur financier depuis janvier 2025, va plus loin encore en exigeant une politique de continuité documentée, des plans de réponse et de rétablissement, et un programme de tests structuré.
Dans les deux textes, la logique est identique : disposer d’un plan de restauration technique ne suffit pas à démontrer la résilience d’une organisation. Il faut prouver que l’activité elle-même peut se poursuivre.
Côté normatif, la référence internationale du management de la continuité d’activité est la norme ISO 22301, tandis que la préparation des systèmes d’information à la continuité relève de l’ISO/IEC 27031. La séparation des deux normes reflète exactement la distinction entre PCA et PRA.
Questions fréquentes
Quelle est la différence PCA PRA en une phrase ?
Le PCA organise la poursuite de l’activité pendant une crise, tous moyens confondus. Le PRA décrit la restauration technique des systèmes d’information. Le second est une composante du premier.
Peut-on avoir un PRA sans PCA ?
Techniquement oui, et c’est le cas le plus fréquent. Mais cela laisse sans réponse les questions de décision, d’organisation, de communication et de fonctionnement en mode dégradé — c’est-à-dire l’essentiel de ce qui se joue en crise.
Faut-il deux documents séparés ?
Pas nécessairement. Le PRA peut constituer une annexe technique du PCA. Ce qui compte est que les deux périmètres soient couverts et que les objectifs de reprise du PRA découlent bien de l’analyse d’impact métier.
Le PRA est-il seulement l’affaire de la DSI ?
Sa mise en œuvre, oui. Son dimensionnement, non : les RTO et RPO qu’il doit tenir sont fixés par le métier, en fonction de ce que l’organisation peut réellement supporter comme interruption.
Par lequel commencer quand on n’a rien ?
Par l’analyse d’impact métier. Elle vous dira quels processus protéger en priorité et avec quels délais — donc ce que doivent contenir vos deux plans.
En résumé
La différence PCA PRA tient en trois idées. Le PCA parle de l’activité, le PRA parle des systèmes. Le PCA relève de la direction, le PRA de la DSI. Le second est un composant du premier, pas son équivalent.
L’erreur coûteuse consiste à s’arrêter au PRA en croyant le sujet traité. Elle se révèle toujours au pire moment : celui où il faut décider, arbitrer et communiquer, sans que personne n’ait prévu qui le fait ni comment.
Prenez rendez-vous avec un expert pour un échange de 30 minutes sur votre dispositif actuel, ou consultez nos autres articles sur la continuité d’activité.
