PRA et PCA : construire une vraie continuité de service

Pour une organisation qui dépend de son système d'information, une interruption de service n'est jamais un simple incident technique. Elle se traduit par des opérations bloquées, des engagements non tenus, des équipes immobilisées et parfois une perte directe de chiffre d'affaires. Pourtant, beaucoup d'organisations confondent encore deux dispositifs qui répondent à des questions différentes : le Plan de Reprise d'Activité (PRA) et le Plan de Continuité d'Activité (PCA). Les distinguer clairement est la première condition d'une continuité réellement robuste.

PRA et PCA : deux logiques, deux temporalités

Le PRA répond à une question précise : comment redémarrer le système d'information après un sinistre ? Il s'active une fois l'incident survenu (perte d'un datacenter, corruption de données, panne majeure) et vise à restaurer les services dans un état nominal. C'est une logique de reprise.

Le PCA se place en amont et autour : comment continuer à délivrer les fonctions critiques pendant la crise, y compris en mode dégradé ? Il englobe le PRA mais ne s'y limite pas. Il couvre aussi l'organisation humaine, les locaux de repli, les procédures manuelles de secours et la communication. C'est une logique de continuité.

Concrètement :

• Le PRA est un sous-ensemble technique du PCA.
• Le PCA répond à « comment l'activité tient-elle ? », le PRA à « comment l'informatique repart-elle ? ».
• Un PRA sans PCA laisse l'organisation sans cadre pendant la phase critique. Un PCA sans PRA crédible reste théorique.

Commencer par l'analyse d'impact métier

Aucun plan sérieux ne se construit à partir de l'inventaire technique. Le point de départ est l'analyse d'impact métier (BIA, Business Impact Analysis). Elle consiste à identifier, fonction par fonction, ce qui se passe quand le service s'arrête : pertes financières, risques de conformité, atteinte à la réputation, effets sur les clients.

Cette analyse permet de hiérarchiser les processus. Toutes les applications n'ont pas le même poids : un moteur de traitement des paiements n'a pas la même criticité qu'un outil de reporting interne. Sans cette hiérarchisation, on protège tout de la même façon, ce qui revient à mal protéger l'essentiel.

L'analyse d'impact alimente directement les deux indicateurs structurants de tout dispositif de continuité.

RTO et RPO : fixer les bons objectifs

Deux paramètres pilotent l'ensemble de l'architecture de reprise :

• RTO (Recovery Time Objective) : le délai maximal acceptable pour rétablir un service. Combien de temps l'activité peut-elle tenir sans cette fonction ?
• RPO (Recovery Point Objective) : la quantité maximale de données que l'on accepte de perdre, exprimée en temps. Jusqu'à quel point de sauvegarde peut-on revenir ?

Ces deux objectifs ne sont pas des choix techniques : ce sont des décisions métier. Un RPO proche de zéro impose de la réplication synchrone et un coût d'infrastructure élevé. Un RTO de quelques minutes suppose des environnements de secours déjà actifs. Le rôle de la DSI est de traduire les exigences métier en architecture, et d'expliciter le coût de chaque niveau d'exigence pour que l'arbitrage soit éclairé.

Ces objectifs doivent par ailleurs être documentés et justifiables. Une direction, un client ou un auditeur n'attend pas seulement un dispositif, il attend la démonstration que les seuils retenus sont cohérents avec la criticité des activités.

Des procédures, pas seulement de la technologie

Une infrastructure de reprise sans procédures exécutables n'est qu'une promesse. La continuité repose sur des documents opérationnels, précis et à jour :

• procédures de bascule vers le site de secours, étape par étape ;
• chaînes de décision et d'escalade clairement nommées (qui déclenche, qui valide) ;
• modes opératoires en cas de fonctionnement dégradé ;
• plan de communication interne et externe pendant la crise.

Ces procédures doivent rester lisibles dans des conditions de stress, par des personnes qui ne sont pas forcément les concepteurs du système. Un plan compréhensible uniquement par son auteur n'est pas un plan de continuité.

Tester, encore et toujours

Un plan jamais testé est un plan dont on ignore la fiabilité. Les tests réguliers sont la seule manière de vérifier que les RTO et RPO théoriques tiennent dans la réalité. Plusieurs niveaux se complètent :

• tests sur table : on déroule le scénario à l'oral pour valider la logique et les rôles ;
• tests partiels : bascule d'un périmètre limité, sans impact sur la production ;
• tests grandeur nature : simulation complète d'un sinistre, idéalement à intervalle planifié.

Chaque test produit des écarts : procédures obsolètes, dépendances oubliées, délais sous-estimés. C'est précisément leur intérêt. Un plan de continuité est un dispositif vivant, qui se corrige au fil des exercices et des évolutions du système d'information. La traçabilité de ces tests permet aussi de prouver les progrès et de décider les investissements utiles.

La continuité ne s'improvise pas le jour du sinistre. Elle se construit en amont, se documente et se vérifie dans la durée. C'est l'approche que défend RB Conseil IT : partir des enjeux métier, formaliser des procédures réellement exécutables, et inscrire les tests dans le temps long plutôt que dans un projet ponctuel. Mobiliser des profils capables de relier technique, organisation et exploitation permet d'éviter l'écueil le plus fréquent, celui d'un plan techniquement complet mais inapplicable le moment venu. Pour échanger sur votre dispositif, contactez-nous.