|
28/03/2011
Plan de continuité d'activité : les pièges à éviter
|
Manque d'implication, besoins métiers négligés, périmètre mal défini, tests et maintien opérationnels bâclés ou simplement inexistants sont autant de chausse-trappes à esquiver pour parvenir à un PCA opérant. |
Elaboré pour faire face aux situations de crise de nature à perturber et
interrompre l'activité de l'entreprise, le plan de continuité (PCA) doit permettre
d'établir l'ensemble des procédures de rétablissement et de secours. Le PCA
consistera donc à analyser les risques, leurs impacts, à déterminer leur criticité,
puis sur la base d'un arbitrage, à concevoir et mettre en œuvre des solutions.
Réussir son projet de PCA suppose donc rigueur, implication des collaborateurs
et méthodologie. Le parcours est en tout cas jalonné de pièges qu'il est préférable
de savoir éviter, sous peine d'aboutir à un plan de continuité théorique et
à des procédures défaillantes. En voici les plus critiques :
1)
S'interroger superficiellement sur les enjeux pour l'entreprise
"Il ne s'agit pas de faire un PCA pour le plaisir, d'autant que ce type de
projet a un coût non négligeable. Il doit donc correspondre à des vrais enjeux
de l'entreprise. De plus, bien définir ces derniers permet de cadrer l'expression
des besoins utilisateurs. Un responsable fonctionnel aura souvent tendance
à affirmer que son activité revêt un caractère stratégique pour la société",
prévient Robert Bergeron, responsable de l'offre sécurité finance et services
chez Capgemini, et membre du Clusif.
2) Oublier de discuter avec les directions métiers
"La meilleure solution pour bien connaître la criticité des applications,
c'est encore de rencontrer les directions métiers, qui s'exprimeront sur les
délais d'indisponibilité et les niveaux de perte de données acceptables",
recommande Sébastien David, responsable de l'offre PCA Parad chez Devoteam.
3) Négliger le niveau d'implication
Le PCA est un projet d'entreprise. Il doit impérativement bénéficier du support
de la direction, mais aussi des métiers. Attention toutefois, car une implication
suffisante est loin d'être acquise. "Le projet PCA peut être perçu comme une
contrainte plutôt qu'un gain pour l'entreprise", avertit Robert Bergeron.
| "Le projet PCA peut être perçu comme une contrainte
plutôt qu'un gain pour l'entreprise" (S.David - Devoteam) |
Un avertissement réitéré par Sébastien David. "Il est indispensable que
les personnes se sentent impliquées et comprennent les enjeux du plan de continuité.
Mais encore faut-il que celui-ci soit perçu comme nécessaire, qu'il y ait
une sensibilisation et une prise de conscience de son importance. Contrairement
à un projet d'ERP, un PCA n'apporte pas de valeur aux utilisateurs."
4) Délimiter un périmètre trop important
Il est impératif de bien identifier le périmètre des risques que l'entreprise
souhaite adresser. Pour Sébastien David, "si on se concentre dans un premier
temps sur ce qui y a de plus critique, puis que l'on étend ensuite ce cadre,
le plan de continuité sera opérationnel plus rapidement."
L'approche diffère quelque peu pour Robert Bergeron : "On a intérêt
à être assez large au départ. Ce qui coûte cher, ce n'est pas tant l'identification
que la mise en œuvre des solutions. Mieux vaut en conséquence partir d'un
périmètre assez large, puis après analyse faire un premier tri et retenir
les risques les plus significatifs. Ensuite, lors de la recherche des solutions,
un second niveau de filtrage pourra s'appliquer."
5) Ne pas tenir compte de ses partenaires
Pas de nombrilisme lorsqu'on élabore son PCA. Il est rare en effet qu'une
entreprise soit autosuffisante et n'appuie son activité sur les services d'aucun
prestataire. "Il est important d'aborder ces aspects et de prévoir des audits
des PCA des partenaires critiques, de préférence en phase d'appel d'offres",
explique le responsable de Capgemini.
"En
l'espace de quelques semaines, votre plan de secours informatique peut s'avérer
inopérant."
(R.Bergeron - Capgemini) |
6) Réaliser des tests superficiels du PCA
Le plan de continuité formalisé, reste encore à s'assurer de la justesse des
réponses qu'il apporte en cas de survenance des risques identifiés. Ces tests
seront bien entendu multiples et ne se restreindront pas à l'informatique.
La partie métiers (tests de fonctionnement en mode dégradé) et la gestion
de crise (procédures d'alerte, de déclenchement des opérations de secours
et de mise en place de la structure de crise) ne devront pas être occultées.
7) Négliger la problématique de maintien opérationnel du PCA
Le PCA en place, celui-ci n'en est pas pour autant appelé à demeurer figé.
En effet, l'organisation de l'entreprise et son système d'information connaitront
inévitablement des évolutions. Cela impose ainsi de définir les responsabilités
et les procédures pour maintenir le PCA dans un état opérationnel.
"A défaut de mise à jour, les risques sont élevés d'être confronté à une défaillance
au moment de la crise, sans compter les frais découlant d'une réinitialisation
du PCA", prévient le responsable de Devoteam.
"En l'espace de quelques semaines, votre plan de secours informatique peut
s'avérer inopérant. Si vous ne mettez pas à jour votre procédure de reconstruction
du site de secours, au lieu démarrer en 24 heures, ce sera 3 ou 4 jours", corrobore
Robert Bergeron.
|