PRA ou PCA : lequel construire en premier ?

Reprise et continuité : deux réponses à deux moments de la crise

Les deux sigles sont souvent employés l’un pour l’autre, et cette confusion fausse les arbitrages. Le PRA — plan de reprise d’activité — décrit comment remettre votre informatique en service après une panne majeure, un sinistre ou une cyberattaque : restaurer les données, redémarrer les serveurs dans le bon ordre, revenir à la normale. Le PCA — plan de continuité d’activité — organise ce qui se passe pendant l’indisponibilité : quelles fonctions maintenir, avec quels moyens de contournement, en acceptant un fonctionnement dégradé.

Les deux plans se complètent : le PCA réduit l’impact de l’interruption, le PRA en raccourcit la durée. Avec un PRA seul, l’entreprise reste à l’arrêt le temps de la restauration ; avec un PCA seul, elle fonctionne en mode dégradé sans horizon de retour à la normale. La bonne question n’est donc pas « lequel choisir », mais dans quel ordre les construire — et sur quelles fondations communes.

RTO et RPO : le langage commun de la direction et de la technique

Le RTO (Recovery Time Objective) est la durée d’interruption maximale que vous visez pour une activité donnée. Le RPO (Recovery Point Objective) est l’ancienneté maximale acceptable des données restaurées — ce que vous acceptez de perdre entre la dernière sauvegarde et l’incident. Ces objectifs se définissent activité par activité, avec les responsables métier, puis se valident avec la direction : ce sont des décisions d’entreprise, pas des réglages techniques.

Leur intérêt : faire dialoguer les deux plans dans la même langue. Côté PRA, ils dimensionnent les dispositifs : plus le RTO et le RPO sont courts, plus les moyens sont conséquents — réplication, environnement de secours, copies hors site. Côté PCA, ils dimensionnent l’organisation : c’est le RTO qui dit combien de temps le mode dégradé devra tenir.

Ils sont enfin le meilleur garde-fou contre le surdimensionnement. Exiger « le plus court possible » sur toutes les activités conduit à un dispositif coûteux et mal hiérarchisé ; l’analyse d’impact sert précisément à distinguer ce qui doit repartir en premier de ce qui peut attendre.

Pourquoi le PRA nourrit le PCA — et rarement l’inverse

Les livrables du PRA sont les fondations du PCA. L’analyse d’impact — activités critiques, applications qui les portent, dépendances techniques — est commune aux deux plans et se mène une seule fois. La cartographie des serveurs, du réseau et du cloud, l’annuaire de crise, la matrice de responsabilités : tout cela sert directement le volet continuité.

Surtout, le PCA a besoin de capacités vérifiées. Écrire « en cas d’indisponibilité du site, les équipes basculent en télétravail » n’a de valeur que si l’accès distant est dimensionné, si les documents restent accessibles depuis les outils collaboratifs et si la téléphonie peut être renvoyée vers des postes logiciels. Ces capacités relèvent de l’inventaire et des dispositifs que le PRA formalise ; un PCA rédigé sans ce socle est une liste d’intentions.

L’inverse est moins vrai : un PRA se construit et se teste sans PCA. L’entreprise accepte alors d’être à l’arrêt pendant la restauration — un choix défendable lorsque le RTO validé par la direction le permet. C’est ce qui fait du PRA le premier chantier naturel dans la majorité des situations.

Par où commencer selon la taille de votre entreprise

TPE et petites structures : visez d’abord le socle du PRA. Des sauvegardes conformes à la règle 3-2-1 — trois copies, deux supports, une hors site — réellement testées en restauration, une procédure écrite de remise en service, un annuaire de crise à jour. Le volet continuité peut tenir en quelques pages : qui prévient qui, comment travailler depuis un autre lieu, quels services suspendre en premier.

PME établies, multi-services ou multi-sites : le PRA reste le premier chantier, mais engagez le volet PCA dans la foulée pour les fonctions dont l’arrêt se voit de l’extérieur — téléphonie, messagerie, prise de commandes. Les renvois téléphoniques, les postes logiciels et le travail à distance se préparent avant l’incident, pas pendant.

Entreprises soumises à des exigences externes — donneurs d’ordre, assureurs, réglementations sectorielles : menez les deux volets ensemble, à partir d’une analyse d’impact unique. Ces interlocuteurs demandent fréquemment un plan documenté et exercé ; un dispositif partiel mais éprouvé vaut mieux qu’un classeur complet resté sans test.