Des petits PRA pour garantir le SI ? par admin
Comme je change régulièrement de mission, j’ai régulièrement l’occasion de voir des mises en œuvre de Plan de Reprise d’activité, 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
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 un PRA ».
Lorsque l’application est bien isolée du reste du SI (pas de mutualisation et pas de flux de donnés), 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).
Dernier élément qui a son importance, tous les PRA que j’ai vu 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.