Dans ma déjà longue vie de consultant, j’ai eu à changer régulièrement de mission, et donc régulièrement l’occasion de voir des mises en œuvre de Plan de Reprise d’Activité (PRA), soit comme acteur, soit comme spectateur attentif.
Deux tendances se dégagent pour mener à bien un projet PRA :
- conduire le projet en prenant l’architecture comme fil conducteur
- conduire le projet en prenant le service à restaurer comme fil conducteur
Un PRA vu comme un Plan de Reprise d’Architecture plus que d’Activité
Ce genre d’approche est typique d’un projet de techniciens et il a l’avantage d’apparaître comme simple : « on dispose de machines et de composants logiciels, sauvegardons-le et sachons les restaurer, nous aurons notre plan de reprise ».
Lorsque l’application est bien isolée du reste du SI (pas de mutualisation et pas de flux de données), cette approche est effectivement simple à mettre en oeuvre et elle aboutit au succès de l’objectif premier qui est de restaurer ce qui est nécessaire à la production du service informatique.
Cette approche pose cependant des problèmes dans le cas de mutualisation (des applications appartenant à plusieurs maîtrises d’ouvrage peuvent poser des problèmes d’écrasement lors de restaurations successives non contrôlées). Ensuite, en cas de restauration, il est nécessaire de ne pas perdre les flux de données qui transitaient au moment du crash, ni de les réinjecter plusieurs fois à la restauration. Seule une vue globale cohérente du SI permet de gérer cet aspect.
Un PRA réellement vu comme un Plan de Reprise d’Activité, c’est-à-dire centré sur la restauration des services
Cette approche, peu courante, nécessite d’auditer les différents métiers de l’entreprise et il aboutit parfois à des résultats surprenants.
Tout d’abord, la production informatique en vient souvent à « redécouvrir » ce qu’elle produit ; en effet, le service de production doit trop souvent porter son attention sur ce qui dysfonctionne ce qui provoque une déformation entre ce qui est important pour le métier de l’entreprise, et ce qu’il est urgent de rétablir dans un service nominal. Lors d’une de mes missions PRA, l’informatique a eu la « surprise » de découvrir qu’une application simple qui ne posait jamais de problème était en fait l’application dont dépendait tout le fonctionnement de l’entreprise.
Le deuxième bénéfice de cette approche est de faire apparaître une priorisation des restaurations en fonction d’un calendrier : en fonction de la date du sinistre, on ne va pas restaurer les applications dans le même ordre, chose qu’il est très important de savoir si les restaurations doivent durer plus de 24h (ce qui est rapidement le cas si le SI devient important).
Cette approche permet également au passage d’aborder les problématiques d’urbanisation du SI.
Dernier élément qui a son importance, tous les PRA que j’ai vus avoir des difficultés d’aboutissement étaient des PRA techniques et le meilleur PRA (en terme de respect des délais et de qualité finale) était un PRA centré sur les services.
Conclusion
Aborder un PRA sous l’angle des services métiers à rendre est une approche qui semble plus efficace que celle qui consiste à n’aborder le problème que sous l’angle technique. Elle permet également de tracer un fil directeur pour la problématique connexe de PCA et ouvre naturellement une porte sur des questions d’urbanisme du SI par exemple.
L’évolution actuelle vers la dématérialisation pose cependant de nouvelles questions : la responsabilité du PRA est transférée à l’hébergeur mais qu’en est-il des interconnexions entre hébergeurs (modèle du cloud computing par exemple) pour ce qui est de restituer un ensemble de données temporellement cohérent après restauration ? Le DSI n’est-il pas amener à renforcer ses capacités juridiques puisqu’il aura à gérer des contrats de services interconnectés par son intermédiaire ?
Philippe RIS,
fondateur d’@uris Solutions
