Plan antisinistre

informatique.

  Le plan antisinistre doit aussi préciser le niveau du système d’exploitation et le logiciel applicatif qui doivent être présents sur le site de secours. Il faut aussi la liste à  jour des noms et des numéros de téléphone des personnes concernées dans l’entreprise. Il faut stocker cette information sous la forme d’une page Web afin de pouvoir la mettre à  jour facilement et aussi en avoir un exemplaire imprimé à  portée de la main.

  Lorsqu’on conçoit le plan antisinistre, il faut d’abord calculer le coût que représentera l’incapacité du système à  traiter les demandes de la clientèle. L’immobilisation du système entraîne bien sûr d’autres coûts, mais l’impossibilité de traiter les demandes des clients (accepter et expédier les commandes, par exemple) peut détruire une société en quelques jours. S’il est possible de traiter temporairement les demandes des clients par un procédé manuel, pendant combien de temps pourra-t-on le faire avant que le volume des demandes et le manque d’accès aux données submergent la solution temporaire ?

  Muni de statistiques sur les coûts potentiels, la probabilité des divers types de catastrophes et la capacité de la société à  se remettre d’un arrêt prolongé, la tâche suivante consiste à  dégager le budget du plan antisinistre. Pour cela, il faut considérer à  la fois des défaillances limitées à  court terme comme un crash de disque et des défaillances plus globales, comme une catastrophe naturelle. A cela s’ajoutent des problèmes plus ordinaires, comme une erreur de programmation détruisant des données historiques ou la
perte de compétence due au départ d’un employé important.

  Et, bien sûr, il faut tester le plan antisinistre comme toute autre composante du système informatique. Il n’est pas facile de tester un tel plan. En effet, comment peut-on fabriquer un élément inattendu capable de balayer le centre informatique. Pour ce genre de test, il faut donc prévoir les pires des scénarios puis concevoir des tests qui vérifient les principaux éléments du système. Il est important de tester les gens et les procédures tout autant que la validité des données, la qualité de la sécurité, le fonctionnement du matériel, et la disponibilité du logiciel.

  En testant le plan antisinistre, on accomplit deux choses : (1) on détermine, avant qu’un problème ne survienne, si le plan inclut tous les éléments nécessaires, et (2) on aide les employés à  savoir quoi faire pendant une crise, où l’on a souvent peu de temps pour donner des directives ou pour réfléchir aux procédures. Tout comme les écoles font des exercices pour apprendre aux élèves la marche à  suivre en cas d’incendie, il faut conduire un test approfondi du plan antisinistre. Qui appelle les opérateurs au repos pour les avertir ? Qui est chargé de récupérer les bandes de sauvegarde les plus récentes et où se trouvent-elles ? S’il existe un  » hot site « , qui doit s’y rendre ? Qui constituera la seconde équipe si le sinistre se prolonge ou si un ou plusieurs des membres de la première équipe sont indisponibles ?

  Les questions sont pratiquement sans fin et l’on ne saurait tester tous les scénarios possibles. Ce que l’on peut faire de mieux est de constituer une équipe de personnes qui comprennent l’objectif et la mise en oeuvre du plan antisinistre. En cas de vraie catastrophe, l’équipe doit prendre des décisions inévitables sur place. On voit donc que la partie reprise d’un plan antisinistre consiste à  recenser les ressources (y compris les gens, les bandes de sauvegarde et les installations  » hot site « ) et les procédures pour traiter un problème inconnu. En outre, la création et le test d’un plan antisinistre permettent de prévoir les sauvegardes nécessaires.