secours dans les temps, et votre méthode restauration du système. Chaque étape doit être exécutée complètement et les données doivent être testées en profondeur par les services d’utilisateurs finaux, pour valider la reprise. Les tests à mener sont très divers :

• un test technique complet de la restauration des systèmes d’applications de production sur l’iSeries et autre matériel critique
• un test technique des réseaux (LAN et WAN), y compris les éventuels mécanismes de basculement du WAN
• un test de la solution haute disponibilité qui bascule vos utilisateurs vers le local secondaire, puis vérifie la validité des données

Un test technique démontre votre capacité à transférer le traitement vers le local de reprise, dans le délai imparti. Le test doit être planifié de la manière suivante :

1. Au moins 60 jours avant, planifiez le test avec votre fournisseur de site de secours. Informez les participants au plan de la date et heure choisies.
2. Rassemblez l’équipe de reprise IT pour établir les objectifs du test, 30 jours avant sa date. Cette réunion mettra en lumière les besoins des participants au test et vous permettra d’élaborer un calendrier réaliste.
3. Une semaine avant l’exercice, adressez le plan de test aux participants et confirmez la date.
4. Déclenchez le transfert des bandes du bureau de stockage hors site, vers le local des services de reprise.

Pendant un test technique, le rôle du responsable du plan consiste à
• s’assurer que chaque objectif est pleinement atteint
• s’assurer que chaque participant au test suit les procédures du plan de reprise d’aussi près que possible
• documenter les changements nécessaires pour que les procédures DRP fonctionnent
• enregistrer les problèmes et leurs solutions au fur et à mesure
• enregistrer la durée de chaque procédure
• récapituler tous les changements apportés au DRP

Ces exercices contribueront à changer la perception de la direction et peut-être la vôtre. Souvent, le test révèlera des aspects non techniques. Dans l’industrie informatique, nous sommes généralement compétents techniquement, mais rétifs à l’aspect procédural. J’ai souvent constaté que la direction est incapable de bien déclarer un sinistre, tout simplement par méconnaissance des procédures. Le test crée une situation concrète et convaincante, qui ne gêne personne. Chacun peut démontrer ses capacités et comprendre l’importance relative de ces procédures, sans dégâts ni grosses dépenses.

Engager la direction à tester, valider et rafraîchir régulièrement votre DRP peut protéger la société contre le plus grand de tous les risques : le laxisme. Les environnements informatiques contemporains sont confrontés à de rapides changements commerciaux et technologiques. La plus petite modification d’une application ou d’un système critique peut causer une défaillance imprévue qui pourrait bien ne pas être rattrapable faute d’avoir été testée.