Comment évaluer et définir un Plan de Continuité Informatique en PME ?

La grande difficulté rencontrée par les responsables informatiques est de persuader leur direction générale de l’utilité d’un tel plan. Souvent dépourvus d’un montant financier, qu’il soit fiable ou exorbitant, et sans estimation du risque couru par l’entreprise, les responsables informatiques peuvent difficilement convaincre.

Il est vrai que ce type de plan de « secours » n’apporte pas de valeur ajoutée dans une exploitation classique, tant que tout va bien… Or, un sinistre n’est pas forcément un incendie ; il peut s’agir tout aussi bien de l’application malheureuse d’un correctif.
En faisant l’analogie du secours avec une assurance voiture, espérons-nous avoir un accident pour nous convaincre de la pertinence de l’investissement ?

Comment donc traduire un investissement qui ne rapporte pas ?
La valeur du SI est égale à l’utilité multipliée par la garantie (cf. ITIL V3)

Il est donc important de définir les enjeux financiers liés à un arrêt de production dans une entreprise et d’évaluer le budget correspondant à la limite de l’interruption supportable. Il s’agit d’apprécier la zone de rupture, au-delà de laquelle l’entreprise risque un point de non-retour (perte d’exploitation, image client, annulation de commandes…). Ce montant motivera les limites de l’investissement et permettra de valider le type de secours à mettre en œuvre, celui-ci pouvant être différent selon l’activité de l’entreprise et selon l’identification des risques réels.

1 - Tout d’abord, identifier les risques

Deux étapes :

Effectuer une étude d’impact (Business Impact Analysis ou BIA)

Cette phase permet de distinguer les risques réels des risques perçus lors de l’interview d’un utilisateur. Il est fréquent que la mesure perçue de disponibilité des applications diffère entre un utilisateur et le besoin réel de l’entreprise. La paie, par exemple, peut être perçue comme une application devant être disponible sur l’ensemble du mois, alors qu’elle ne doit être opérationnelle que quelques jours par mois (risque bas).

Cette étude permet de référencer toutes les applications de l’entreprise et de définir leur niveau d’arrêt maximal supportable.

Faire un état des lieux

Cet exercice consiste à identifier toutes les faiblesses composant le système d’information, qu’elles soient d’ordre technique, organisationnel ou environnemental. Il s’agit de détecter les « SPOF » (Single Point Of Failure).

2 – Mesurer le Risque Maximal Tolérable (RMT)

Il s’agit de définir, suite à un arrêt de production, le temps maximal tolérable avant un impact financier préjudiciable à la santé de l’entreprise. Cette méthode aide les décideurs à mettre en place les technologies et services correspondant réellement au besoin.

Ce procédé peut s’appliquer à l’ensemble de l’entreprise ou à des directions opérationnelles, voire aux applications et à l’infrastructure les hébergeant.

3 – Synthétiser l’étude d’impact, l’analyse du risque et le risque maximal tolérable)

Grâce à l’ensemble des données collectées, cette synthèse permet d’affiner le résultat et de mettre en place les moyens nécessaires, soit :

Etude d’impact :

Connaissance du temps d’arrêt maximal des applications et organisation des services utilisateurs en cas d’arrêt prolongé.

SPOF (Single Point of Failure) :

• Correction des SPOF mineurs,
• Identification et mise en place des procédures sur les SPOF non corrigeables (solution de contournement notamment)
• Correction des SPOF majeurs par des solutions de secours en fonction du niveau de couverture (cette dernière étape est traitée lors de la définition des moyens technologiques)

Synthèse :

Définition précise du temps d’arrêt maximal de l’ensemble des éléments en regroupant Risque réel / SPOF / RMT (Risque Maximal Tolérable)

Les étapes suivantes sont souvent dépendantes les unes des autres car elles concernent les procédures et les moyens technologiques.

4 – Définition et mise en place des procédures et processus.

Cette approche consiste à définir le ou les processus accompagnant les solutions de secours en prenant en compte leur efficacité (test régulier) et l’évolution du SI.
Le principe est basé sur le cycle de Deming (*) qui permet une amélioration continue des services de secours en imposant des étapes nécessaires au bon fonctionnement.

Les différents points consistent à :

• Définir l’organisation et créer les différentes procédures concernant le SI
• Former les équipes concernées et gérer les processus auxquels le secours fait appel (gestion des changements par exemple)
• Créer la documentation
• Tester le secours
• Auditer régulièrement pour notamment accueillir les évolutions du SI

5 - Choix de la technologie

Le choix de la technologie est motivé par le temps maximal de redémarrage. En fonction du temps acceptable, qui se mesure de quelques semaines à quelques secondes, les solutions s’imposent et plus ce temps est court, plus le coût sera important.

Même si la maintenance peut contribuer partiellement à la prévention des risques, aucune garantie de redémarrage n’est assurée, car seule la réparation est prise en compte. La maintenance reste en revanche la base incontournable et nécessaire à un Plan de Continuité pour l’entreprise.

Quelques solutions à titre d’exemple :

• Externalisation des sauvegardes (jusqu’à 1 semaine pour un redémarrage)
• Le backup à froid par remplacement de la machine (jusqu’à 3 jours)
• Le cluster et la réplication disque à disque (jusqu’à J+1)
• Le backup à chaud ou « HA » (High Availability) et ses variantes (jusqu’à H+8)

En résumé, le secours doit permettre la préservation de l’activité au plus juste, sa valeur correspondant à une meilleure disponibilité du SI en fonction du métier de l’entreprise. Il permet de prévenir tout sinistre, il peut même tenir un rôle organisationnel et permettre d’améliorer la performance.

(*) Deming : la roue de Deming est une illustration de la méthode de gestion de la qualité PDCA (Plan-Do-Check-Act). Son nom vient du statisticien William Edwards Deming. Ce dernier n'a pas inventé le principe du PDCA, mais il l'a popularisé dans les années 50 en présentant cet outil au Nippon Keidanren, l’équivalent japonais du Medef (source : Wikipédia).