10 conseils d'experts pour réaliser un Plan de Reprise d'Activité informatique (PRA)

Quand survient un incident, ou une catastrophe, un plan de reprise peut permettre de relancer rapidement l'activité d'une entreprise. Le plus souvent, cela passe par une réflexion sur l'informatique.

1) Penser la catastrophe

Penser la catastrophe ou le simple incident n'est pas à la portée de tout le monde. Et pourtant, il faut se pencher sur des scenarii que personne ne souhaite voir se produire. C'est la première étape de conception d'un Plan de Reprise d'Activité (PRA).

Il faut arriver à imaginer l'inimaginable, comme un incendie par exemple, pour pouvoir imaginer un scénario de reprise. On pense que ça ne peut pas arriver, et pourtant, c'est dans ces moments là qu'il faut prévoir un plan.

Mais, les PRA sont aussi souvent déclenchés pour des incidents mineurs, qui impactent aussi la performance du système d'information. Surchauffe d'un système de ventilation, coupure électrique, autant d'imprévus que l'élaboration d'un PRA peut permettre en amont de détecter et de déjouer.

2) Prévoir comment gérer le risque

Un point capital de la mise en place d'un PRA concerne le processus de gestion du risque. Qui fait quoi en cas de problème ? Quelle est la responsabilité définie de chacun ? Souvent, ce ne sera ni le PDG ni le DSI qui vont devoir intervenir dans l'urgence et gérer la crise. Les personnes seront sélectionnées dans l'entreprise au préalable et cela permettra généralement un gain de temps appréciable en cas de problème.

C'est ce processus de gestion du risque qui va permettre de régler les responsabilités au niveau organisationnel. Prévoir un volet technique, c'est bien, mais s'assurer d'un volet humain, c'est mieux. Les équipes, les relais en cas de problème entre les responsables, les procédures, autant de facteurs qu'il faut prendre en considération .

3) Procéder à l'inventaire applicatif

Une fois que la conception du PRA est partagée entre les différentes entités de l'entreprise, la DSI peut concrètement démarrer son travail interne.

L'idée au départ, c'est de réaliser un audit, une cartographie des risques. Il s'agit ensuite de détailler les challenges qui sont provoqués par ces risques, et de trouver une stratégie de mitigation des risques.

Chaque module applicatif doit être évalué pour en déterminer sa criticité en cas de crise, et le traitement dont il doit faire l'objet pour le préparer aux incidents. Une opération par couches . "On procède au mapping des applications, on descend au niveau des bases de données, des systèmes d'exploitation, et ainsi de suite".

Enfin, l'inventaire des applications et des environnements applicatifs ouvrira sur un travail de définition de la criticité de ceux-ci, et du besoin de sauvegarde et de restauration. "Il faut définir un RTO (Recovery Time Objective) et un RPO (Recovery Point Objective) pour chaque application. Une fois que ce référencement est effectué, il faut prioriser en fonction de ce qui est plus ou moins critique pour le business de l'entreprise".

4) Définir des priorités, des techniques et un prix

Si bon nombre de DSI ne souhaitent perdre aucune données en cas de crash, il faut se rendre à l'évidence : en fonction des secteurs d'activité, des métiers, les exigences vis-à-vis du système d'information seront diverses.

"Il faut arriver à considérer que l'indisponibilité peut être autorisée, en fonction du degré de criticité des données métiers et des données techniques. Une disponibilité en dessous de la minute, par tranche de dix secondes, double le prix de l'infrastructure. Parfois, le coût n'en vaut pas la peine", explique David Milot chez Unisys. "Il est possible de fonctionner en mode dégradé, mais cela doit être conçu au moment du design du PRA", précise t-il.

Une réflexion qui doit émerger dès la conception du PRA. De là va découler le choix de l'équipement de sauvegarde et de reprise de l'activité, mais aussi le budget consacré au PRA.

"Il s'agit là de déterminer les meilleures technologies qui correspondent au RTO ( Recovery Time Objective) et au RPO (Recovery Point Objective) que l'on a choisis. Les données de certaines applications dont le RTO et le RPO permettent un délai pourront être sauvegardées sur bandes. Mais pour des applicatifs dont le RTO et le RPO sont proches de 0, des technologies comme le self mirror seront nécessaires", détaille Bruno Picard de Netapp.

"A la suite de ce diagnostic, il faudra calculer, et souvent négocier un prix de mise en œuvre. Si la sauvegarde et la reprise d'activité doit s'effectuer en moins d'une minute, on doit mettre en place des environnements synchrones, et le coût de l'infrastructure monte très vite", ajoute t-il pour rebondir sur l'augmentation géométrique du coût de l'infrastructure en fonction de l'exigence de reprise.

5) Choisir le matériel de crise adapté

Certains PRA prévoient la construction d'un site distant, qui va prendre le relais en cas de catastrophe sur le site principal. Dans ce cas, la matériel de remplacement devra d'une part être constamment prêt à l'emploi, mais aussi être adapté à cette situation de crise, qui dans une majorité de cas ne durera que quelques temps.

Les performances du système d'information seront dégradées, mais devront permettre d'assurer la poursuite de l'activité le temps que tout rentre dans l'ordre. C'est l'objet même d'un PRA et il est inutile de souhaiter simplement dédoubler son matériel principal.

"Il ne s'agit pas de faire de copier - coller de son existant sur un site distant. Il faut que le matériel destiné à reprendre l'activité soit adapté à la situation de crise. De toute manière, les performances seront dégradées quoi qu'il arrive et il faut en tenir compte", rappelle David Milot chez Unisys.

6) Tester régulièrement le PRA

Une fois que le PRA est en place, l'importance de faire des tests de manière régulière pour évaluer sa fiabilité est une étape importante, et ce en dépit du coût de tels tests.

"Le coût d'un test est important mais le coût d'un risque est plus important encore. Je n'ai pas vu une seule entreprise qui à la suite d'un test ne remette pas en question son PRA. Souvent, on se rend compte que les questions de personnes n'ont pas été étudiées. Un exemple tout simple, en cas de déménagement dans un autre local, il faut savoir absolument qui possède la clé de ce local. D'expérience, je peux vous dire que ce n'est pas une gageure", explique Lionel Pelletier chez Colt.

Un avis que partage Bruno Picard de Netapp : "Il est nécessaire de tester deux fois par an son PRA pour faire fasse à l'imprévu. Cela coûte de l'argent et révèle bien souvent des faiblesses de l'infrastructure."

L'importance des tests est révélée par des données officieuses qui tendent à montrer qu'au cours du premier test, tout ce passe convenablement, mais que dès le second test, l'infrastructure informatique ayant été modifiée, les processus n'étant peut être plus respectés, 60% des tests échouent.

7) Faire évoluer le PRA en fonction des changements apportés au système d'information

Si le PRA est réalisé à un moment précis pour répondre aux contraintes de service d'un actif informatique, il faut que des procédures permettent d'inclure au Plan de Reprise d'Activité les évolutions postérieures du système d'information.

Un travail compliqué, qui demande de mettre en conformité les nouvelles applications avec le plan de relance déjà établi.

"Chaque changement applicatif ou matériel doit être réalisé de manière à ce que le PRA puisse fonctionner en prenant en compte ce changement", explique Bruno Picard de Netapp.

Cette démarche permet aussi de considérer si de nouvelles applications doivent ou non entrer dans le cadre du PRA en fonction de leur criticité pour l'activité de l'entreprise. Ce travail de suivi demandera de se référer régulièrement au PRA, ce qui demande que ce dernier soit correctement documenté.

8) Encourager le retour d'expérience

La prise en compte des tests et de leurs péripéties n'est parfois pas transmise à qui de droit. De même, les incidents du systèmes d'information au quotidien sont souvent peu documentés.

Un problème de partage de la connaissance du système d'information qui impacte directement les performances en cas de PRA déclenché pour une raison réelle.

"Il faudrait rendre obligatoire le retour d'expérience. Normalement, un journal d'évènements devrait rendre compte des problèmes rencontrés pour y faire face plus tard. Mais il faut bien admettre que la culture professionnelle française à tendance à mettre un tabou sur les échecs, ce qui ne leur permet pas d'être source d'enseignements", reconnaît Lionel Pelletier de Colt.

Un véritable souci quand on connaît par ailleurs le turn over de certaines structures. Difficile de transformer ses erreurs en enseignements pour le futur !

9) Prendre en compte les contraintes réglementaires

Le Plan de Reprise d'Activité est de plus en plus demandé, tant par les autorités de régulation de certaines activités comme la banque et la finance, que par les banques et les compagnies d'assurance qui souhaitent s'assurer que leurs clients ont pris les précautions nécessaires en cas de problème.

"La présence d'un PRA est une exigence contenue dans des règlementations telles que Bâle II. Les acteurs qui y sont soumis sont obligés de fournir un PRA et un PCA (Plan de Continuité de l'Activité), et ils nous délèguent ces responsabilités opérationnelles", explique Lionel Pelletier, consultant senior chez Colt.

"Certains de nos clients exigent de nous voir équipé d'un PRA pour faire des affaires avec vous", précise David Milot, directeur du Conseil en technologie chez Unisys. Il faut préciser enfin que des cadres de bonnes pratiques comme ITIL préconisent la mise en place de PRA pour assurer le bon fonctionnement de son système d'information.

Mieux vaut donc prévoir la mise en place de ces plans qui permettent de prévoir que faire en cas d'accident, et comment assurer la reprise de l'activité, de plus en plus soutenue par le système d'information.

10) Promouvoir l'élargissement du PRA en dehors du cadre de la DSI

La question du PRA dépasse le simple cadre de l'infrastructure informatique. D'où des réflexions transverses sur les processus à mettre en place en cas de problème.

"Quel PRA pour quels risques ? Cela passe par l'étude des conséquences d'un incident. Il ne faut pas faire un PRA pour faire un PRA. Le désastre peut être une grève, un incendie, une coupure d'électricité, une surchauffe qui met les machines en veille", explique David Milot, directeur du Conseil en Technologie chez Unisys.

Lionel Pelletier chez Colt propose lui trois éléments qui permettent de jouer sur différents processus en fonction du type de crise. "D'un côté, on va trouver le Plan de Repli Utilisateur. En cas de pandémie par exemple, il faudra définir des règles de fonctionnement des équipes. Ensuite, vient le Plan de Reprise Métier, qui définit quels sont les éléments de la chaîne de production qui sont prioritaires et qui doivent être repris en main pour faire redémarrer la production. Enfin, le Plan de Repli Informatique doit permettre de définir les priorités en termes de système d'information en cas de crise. Au final, en fonction de la nature de la crise, on fait jouer les trois éléments".

Inutile de réaliser donc un PRA au niveau de la DSI s'il n'est pas partagé par les directions métiers.

Sources : JDN