Le plan de reprise d’activité, ou PRA, décrit la manière dont une organisation reconstruit son informatique après un sinistre majeur : incendie, panne étendue, rançongiciel, défaillance d’un prestataire. Le document fixe l’ordre de restauration des applications et des données, les délais visés et les équipes mobilisées pour revenir à un fonctionnement normal.
Dans la banque et l’assurance, où l’arrêt prolongé d’un système de paiement se répercute immédiatement sur les clients, ce dispositif fait partie du socle attendu par les superviseurs. Il reste souvent confondu avec le plan de continuité, dont il constitue en réalité le volet informatique.
Ce qui distingue le PRA du PCA
Le plan de continuité d’activité vise à maintenir les opérations essentielles pendant la crise, au besoin en mode dégradé, en s’appuyant sur des solutions de repli ou des procédures manuelles. Le PRA, lui, organise la remise en état des systèmes eux-mêmes, de la restauration des données à la bascule vers un environnement de secours puis au retour à la normale : il prend en charge la reconstruction pendant que les mesures de continuité maintiennent l’activité par d’autres moyens.
Les deux plans partagent la même analyse préalable : l’identification des activités critiques et de leurs dépendances informatiques, souvent formalisée dans un système de management de la continuité d’activité.
RTO et RPO, les deux paramètres qui dimensionnent le plan
Le dimensionnement repose sur deux indicateurs. Le RTO (Recovery Time Objective) fixe la durée d’interruption admissible avant la reprise d’un service : quelques minutes pour un système de paiement, parfois plusieurs jours pour un outil interne secondaire. Le RPO (Recovery Point Objective) mesure la perte de données tolérée, c’est-à-dire l’ancienneté maximale de la dernière sauvegarde exploitable.
Ces objectifs se fixent activité par activité, à partir des besoins métiers et de l’appréciation du risque cyber, et non des capacités techniques déjà en place. L’écart entre l’objectif et la capacité réelle oriente les investissements, qu’il s’agisse du mode de réplication, de la fréquence des sauvegardes ou de la nature du site de secours, maintenu à chaud ou reconstruit à la demande.
Les composantes d’un PRA
Des scénarios de sinistre explicites
Un PRA se construit sur des situations décrites précisément. La perte d’un centre de données, l’indisponibilité prolongée d’un fournisseur ou une erreur humaine aux effets en cascade figurent parmi les cas de référence. Les pannes des grands fournisseurs cloud ont montré que ce scénario n’a rien de théorique.
Le scénario cyber appelle un traitement particulier. Un rançongiciel peut chiffrer les sauvegardes en même temps que la production, et certaines corruptions de données se retrouvent répliquées dans les copies avant d’avoir été détectées. Avant toute restauration, une phase d’investigation doit établir la date et le périmètre de la compromission ; sans elle, les équipes risquent de remettre en service un système où l’attaquant conserve ses accès.
La stratégie de secours et les sauvegardes
Le choix technique découle des objectifs retenus. Un environnement répliqué en permanence autorise une bascule en quelques minutes, au prix d’une infrastructure doublée ; à l’autre bout du spectre, la restauration depuis les sauvegardes suffit pour les applications qui tolèrent plusieurs jours d’arrêt. La reconstruction à la demande dans le cloud occupe une position intermédiaire. Pour les services externalisés, la réflexion s’étend aux plans de sortie cloud, qui conditionnent la capacité à reconstruire ailleurs si le prestataire fait défaut.
Sur les sauvegardes, l’ANSSI recommande de conserver des copies déconnectées du réseau ou immuables, hors de portée d’un attaquant ayant compromis le SI de production, et de vérifier régulièrement qu’elles se restaurent réellement. Les retours d’expérience sur les sauvegardes hors ligne face aux rançongiciels vont dans le même sens : les organisations reparties vite disposaient de copies isolées et testées.
L’ordre de reprise
Tout ne redémarre pas en même temps. La séquence part des briques d’infrastructure (annuaire, réseau, supervision), dont dépend l’ensemble du reste, puis remonte vers les applications selon leur criticité. Cette hiérarchie s’appuie sur la cartographie du SI et sur des scénarios documentés, comme ceux du référentiel des scénarios de risques cyber.
L’organisation et les procédures
Reste la dimension humaine. Qui décide de déclencher le plan, sur quels critères, avec quelles équipes et quelles procédures : ces éléments doivent exister par écrit et rester accessibles quand le SI est à l’arrêt, sous forme imprimée ou hébergée hors du périmètre touché. Le dispositif s’articule avec la cellule de crise décrite dans le PCA.
Tester le PRA
Un plan jamais déroulé en conditions réelles comporte des inconnues, durées de restauration sous-estimées ou dépendances jamais recensées, que les tests servent à faire apparaître avant l’incident.
Les formats vont du déroulé sur table à la bascule réelle d’applications critiques vers l’environnement de secours, en passant par des restaurations de données grandeur nature et des simulations de crise associant équipes techniques et directions métiers. Chaque exercice mesure les RTO et RPO effectivement atteints ; l’écart constaté avec les objectifs alimente ensuite le plan d’amélioration.
La réglementation bancaire française exige de longue date un dispositif de continuité éprouvé, sous le contrôle de l’ACPR ; le règlement européen DORA y ajoute des exigences de tests de résilience opérationnelle, y compris sur des scénarios de perturbation sévère.
Questions fréquentes sur le PRA
Qu’est-ce qu’un PRA en informatique ?
Le plan de reprise d’activité est l’ensemble documenté des moyens, procédures et responsabilités permettant de reconstruire les systèmes informatiques et de restaurer les données après un sinistre majeur, dans des délais et avec une perte de données définis à l’avance par le RTO et le RPO. Il couvre les scénarios de panne, de destruction physique et de cyberattaque.
Quelle est la différence entre PCA et PRA ?
Le PCA maintient les activités essentielles pendant la crise, éventuellement en mode dégradé, tandis que le PRA reconstruit les systèmes pour revenir à un fonctionnement normal. Le PRA est généralement considéré comme le volet informatique du dispositif global de continuité ; les deux plans se complètent et se testent ensemble.
Que signifient RTO et RPO ?
Le RTO désigne la durée maximale d’interruption admissible d’un service avant sa reprise ; le RPO correspond à la perte de données maximale admissible, mesurée par l’ancienneté de la dernière sauvegarde utilisable. Fixés par les métiers pour chaque activité, ces deux objectifs dimensionnent la stratégie de secours et son coût.
À quelle fréquence tester un PRA ?
La pratique observée dans le secteur financier retient au moins un exercice annuel pour les systèmes critiques, complété après tout changement significatif d’architecture ou de prestataire. Les référentiels de continuité conseillent de varier les formats, du test sur table à la bascule complète, et de couvrir le scénario cyber, qui suppose de vérifier l’intégrité des sauvegardes avant restauration.
