Plan de Reprise d'Activité (PRA)

Les risques informatiques qui peuvent rendre indisponible le système informatique de l’entreprise sont nombreux. Des solutions techniques permettent de se prémunir efficacement de certaines menaces, qu’elles soient d’origine physique (panne, sinistre…) ou humaine (erreur, malveillance…). Mais le risque zéro n’existe pas.

Le Plan de Reprise d’Activité (PRA) est destiné à faire face à la crise quand elle survient. Le PRA consiste à anticiper à la fois les moyens techniques et l’organisation nécessaire pour retrouver un fonctionnement normal du système informatique dans un délai qui aura été convenu à l’avance.

Quelques définitions

RTO = Recovery Time Objective

C’est la durée maximale d’interruption de l’outil informatique que l’entreprise peut tolérer. Le RTO dépend de la ressource informatique considérée : une application qui conditionne la production aura un RTO faible ; on pourra (peut-être) tolérer un RTO plus long pour une application de messagerie par exemple.

RPO = Recovery Point Objective

C’est la durée maximale d’enregistrement des données que l’entreprise peut tolérer de perdre. De la même façon, le RPO dépend du type de donnée considérée : par exemple le RPO est nul pour des transactions bancaires mais on peut tolérer un RPO plus long pour des données que l’on peut ressaisir.

Plus les objectifs pour les RTO et RPO seront ambitieux, plus les investissements informatiques seront élevés et plus l’organisation et les processus seront importants pour le bon déroulé du PRA.

On parle plutôt de Plan de Continuité d’Activité (PCA) dans le cas d’un RTO minimal et RPO nul. Cela nécessite une infrastructure à haute disponibilité.

Mise en place d’un PRA

Analyse préalable des risques

Cette analyse préalable consiste à réaliser un audit à la fois :

• sur le plan organisationnel, pour bien identifier et hiérarchiser les processus de l’entreprise afin de déterminer les enjeux, le périmètre, les objectifs…
• sur le plan technique, pour recenser les vulnérabilités du système informatique et identifier les solutions qu’il est possible de mettre en place.

Ce n’est qu’à l’issue de cette analyse qu’il sera possible d’arbitrer entre les risques dont on veut se prémunir, les objectifs que l’entreprise va se fixer (RTO/RPO, mode dégradé…) et les coûts pour répondre à ces exigences de reprise.

Définition du PRA

Parce que cela n’est pas qu’un Plan de Secours Informatique (PSI), mais aussi une organisation et des processus associés, la définition d’un PRA nécessite un contexte d’entreprise stable.

Au niveau organisationnel, l'ensemble des acteurs concernés par le PRA doivent être impliqués : les objectifs – et les arbitrages – doivent être fixés et partagés par tous.

Au niveau technique, a minima tous les points critiques mis en évidence par l’audit technique doivent être corrigés avant de formaliser le PRA.

Organisation du PRA

Formalisation des procédures

Les modalités d’activation et de conduite du PRA doivent être formalisées :

• au niveau organisationnel, il faut identifier les acteurs (cellule de crise) et leur rôle pendant le déclenchement, la période de secours et enfin le retour à la normale ;
• au niveau technique, les procédures pour dérouler le plan de secours informatique doivent évidemment être décrites dans le détail.

La formalisation du PRA est indispensable : c'est en effet un ensemble documentaire qui va ensuite « vivre » en fonction des retours d'expérience et des évolutions de l'environnement de l'entreprise.

Test du PRA

Le test du PRA est fondamental ! Tant qu’un PRA n’a pas été testé, il n’a pas fait preuve de son efficacité.

Un PRA peut buter sur un « simple » détail qui n’a pas été anticipé pendant la phase de définition : un mot de passe administrateur qui n’est pas connu de l’intervenant informatique le jour de la panne, un CD-ROM d’installation introuvable, etc. Il vaut bien mieux découvrir les problèmes pendant les tests que pendant la crise.

Le retour d’expérience (analyse post mortem) est dans tous les cas indispensable car il permet de consolider ce qui a fait preuve de son efficacité et de corriger ce qui n’a pas bien fonctionné.

Maintien en conditions opérationnelles (MCO)

Les modifications de l’environnement de l’entreprise sont constantes : évolution de l’organisation (et donc peut-être des enjeux et des objectifs), turnover du personnel, changements sur le système informatique…

Le PRA doit donc évoluer en conséquence et être testé régulièrement car il peut devenir rapidement inopérant...

Découvrez aussi cette présentation plus complète réalisée lors d'un session animée par WIXXIM dans la cadre du dispositif régional Competi'TIC de la CCI de Marseille Provence.

Auteur : Pascal GUENOT
Dernière mise à jour : 17/11/2012