Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Plan de Continuité d'activité : trois écueils à éviter


Lorsqu’on aborde avec des responsables en entreprise la situation du Plan de Continuité, on tombe souvent sur des situations compliquées héritées d’un passé complexe…voici trois écueils courants.



Plan de Continuité d'activité : trois écueils à éviter

La vision incomplète et non coordonnée

Divers responsables en différents endroits de l’organisation ont réfléchi et ont agi ; mais la coordination est faible et la supervision absente. Il n’y a pas un PCA, il n’y a que quelques plans de reprise de moyens limités.

On trouve par exemple :
  • Une direction de la production informatique qui prépare des plans de reprise système ; malheureusement pour les applications, rien n’est fait en cohérence. Les « points propres » applicatifs ne sont pas identifiés ou communiqués à la production.
  • Une maîtrise d’ouvrage qui se préoccupe de faire évoluer ses applications informatiques ; malheureusement dans ses nouvelles architectures elle ne pense pas aux systèmes cibles en production et omet de mettre en place les mécanismes de disponibilité qui seraient nécessaires. « Il sera temps de voir cela plus tard » dit-on souvent…vision partielle.
  • Une direction de l’exploitation informatique décide de renforcer sa résilience et met en place des mécanismes de cluster, de copie synchrone etc. Malheureusement elle ne consulte pas les utilisateurs et court le risque soit de mettre la barre trop haut soit d’en oublier…
  • L’exploitant ne sait pas à quoi sert ce qu’il a en salle et ce qu’il faut en faire en cas de sinistre…en cas de panne électrique : quels sont les serveurs à arrêter en premier ? pour qui ? dans quel ordre ? quels sont ceux qui basculent automatiquement ? et comment savoir que cela se fait bien ? sauf pour quelques cas connus, l’exploitant n’a pas la réponse.

Ces défauts constatés sont dus principalement à un manque de vision d’ensemble et de collaboration études/production. La production finit par se focaliser sur des moyens en oubliant à quoi ils servent ; les études se concentrent sur des développements sans penser aux vingt ans d’exploitation qui suivent…en fait chacun se focalise sur son métier et personne ne pense au service rendu : rien de nouveau sous le soleil !

Ces situations sont courantes et se développent "naturellement", dès lors qu'il n'y a pas de responsabilité transverse liée au PCA, clairement instituée.

Le PRA non actualisé

Voilà une autre catégorie de situations communément rencontrées : vivre avec un acquis sans le remettre en cause. Cela se rencontre souvent chez des gestionnaires de moyens dans l’entreprise : les services généraux, télécom et bien sûr aussi informatiques.

Un Plan de reprise d’activité (PRA) a bien prévu, il y a cinq ans que telle surface de bureau serait à mettre en place sur tel site de secours avec la téléphonie ad-hoc, et que tel serveur serait redémarré chez un prestataire externe en cas de sinistre. Malheureusement ces plans n’ont pas été suivis avec attention : résultat le site prévu n’existe plus (l’entreprise l’a vendu), le nombre de postes est inadapté et le serveur a migré vers un autre système. Le PRA est donc absolument obsolète, alors qu’il coûte, fort probablement.

Pour exagérés qu’ils puissent paraître, ces cas sont plus nombreux que l’on croit. Telle société de la région Rhône-Alpes avait dans son PRA deux serveurs : c’était le mainframe et l’AS400 d’il y a treize ans. Les deux-cent-cinquante serveurs Unix et Windows apparus depuis sont absents de tout PRA…est-ce vraiment représentatif du besoin ?

L’absence de test des PRA est aussi une cause de leur mise en jachère. Une bonne campagne de test doit être définie, qui implique des tests très légers et non perturbateurs associés à des tests plus représentatifs de la réalité. La simple préoccupation de passage des tests-même très légers comme revoir les configurations des machines- est salutaire pour maintenir efficace le PRA.

Malheureusement, ces activités de constitution et de tenue à jour des PRA sont fastidieuses et souvent passées au second plan ou sacrifiées sur l'autel de la réactivité....

L’oubli des objectifs

Normalement « la fin justifie les moyens » or l’erreur est souvent due à un renversement de cette proposition : les moyens ne sont plus justifiés que par eux-mêmes et la fin est oubliée.

Une anecdote illustre pleinement cette situation : un organisme de compensation situé en Région Centre devait transmettre un fichier important à la banque de France toutes les nuits avant sept heures du matin ; il utilisait pour cela un logiciel de transfert de fichier. Lorsque celui-ci "se plantait", il fallait se dépêcher de le remettre en marche, toute affaire cessante. Jusqu’à ce qu’un jour un responsable décide de sortir une cassette et de la confier à un taxi qui dans la nuit fut vite au lieu de destination. La fin « livrer le fichier » est distincte des travaux de réparation des moyens…

Cet oubli des objectifs est très courant actuellement. C’est pourquoi il est fortement recommandé d’analyser les activités de l’entreprise pour déterminer celles qui sont les plus importantes à poursuivre en cas de sinistre. Ces activités critiques devront être maintenues de diverses manières et c’est cela que doit organiser le PCA. Cette analyse s’appelle le BIA (business impact analysis) et est à la base de toute démarche sensée en la matière.

Malheureusement force est de constater que la décision de mener ce BIA est difficile à prendre, souvent par absence de responsable en charge...

Moralité : le rôle du RPCA est important

Manque de vision d’ensemble, absence de suivi dans le temps et oubli des fins au détriment des moyens voilà donc les écueils les plus souvent rencontrés dans les PCA des entreprises.

On le voit, ces situations se développent progressivement et subrepticement, sans que l'on puisse accabler tel ou tel, essentiellement par défaut de prise en charge d'une responsabilité transverse.

Cette responsabilité transverse est celle du RPCA et l'on voit là très clairement se dessiner certaines de ses missions clés :
  • assurer la vision d'ensemble, à partir de visions locales héritées de choix locaux qu'il faut comprendre et structurer ;
  • tenir et faire tenir à jour les PRA et PCA par ceux qui en sont responsables ;
  • rappeler les fins au-delà des moyens en portant en permanence la vision des processus essentiels de l'entreprise
.
Un métier passionnant finalement, non ?

Emmanuel Besluau
Dimanche 7 Décembre 2014

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Dans la même rubrique :
< >

Mercredi 5 Octobre 2016 - 17:48 Attention : un SMCA n'est pas un PCA !


Duquesne Research Newsletter