Liste de  cours management

Guide de formation sur les principes de base de la continuite d'activite et son management

Télécharger

Guide de formation sur les principes de base de la continuité d'activité et son management

Tester le plan de continuité

À ce stade de son élaboration, le plan de continuité ne correspond qu’à une suite de travaux, de réflexions et de décisions synthétisés dans plusieurs docu­ments. Après cette organisation théorique, il est maintenant indispensable de tester le plan de continuité afin de s’assurer de ses applications concrètes.

Cela permet de valider la stratégie, les hypothèses, l’attribution des missions, les plannin


gs et les recommandations qui ont été mis au point lors des étapes précédentes. Il vaut mieux, en effet, que les difficultés potentielles soient ren­contrées durant un exercice de test plutôt qu’au moment de l’exécution du plan, en situation réelle de sinistre.

Cadrage des tests

Il est indispensable de définir une politique de tests pluriannuelle. L’objectif général est divisé en objectifs tactiques respectant un calendrier précis et validé par les différentes parties prenantes. Ces aspects de gouvernance sont abordés dans le chapitre 11.

On devra également déterminer la méthode à suivre pour appliquer les diffé­rents types de tests afin d’atteindre les objectifs fixés. L’entreprise doit en effet mettre en œuvre une démarche qui lui permette de vérifier, d’assimiler et de se familiariser avec son plan de continuité, ayant recours aux tests pour l’améliorer.

Objectifs

Un exercice test peut avoir un ou plusieurs objectifs. Il est important de définir à l’avance cet objectif, car le déroulement et le suivi des tests en dépendent gran­dement.

Management de la continuité d’activité

Valider l’efficacité du plan

Les exercices de test du plan de continuité permettent de vérifier son bon fonc­tionnement. Les points suivants doivent être validés ou, le cas échéant, faire l’objet d’un plan d’action qui les rendra plus adaptés ou efficaces :

  • les responsabilités définies dans le plan sont prises en charge par les bonnes personnes ;
  • les activités sont convenablement définies et produisent les résultats attendus ;
  • la synchronisation, les durées et les charges prévues dans le planning sont bonnes ;
  • les étapes définies dans le planning se déroulent comme prévu ;
  • les processus critiques sont redémarrés en temps voulu.

Identifier les points faibles

Aucun plan n’étant parfait, l’exercice de test est l’occasion de détecter certains points faibles, parmi lesquels on distingue :

  • les difficultés d’accès à la documentation, aux listes de références, de noms, de configurations ;
  • les délais pour constituer les groupes, en raison de l’indisponibilité immé­diate des responsables ;
  • le caractère irréaliste ou incomplet de la stratégie de continuité se révélant dans son application ;
  • les erreurs dans les documents ou listes de contacts, de ressources, etc. ;
  • les omissions de personnes ou de tâches nécessaires ;
  • la différence entre la réalité et ce qui est prévu dans le plan : conditions du matériel informatique (tel serveur censé être sauvegardé régulièrement mais qui ne l’est pas, par exemple), ressources présentes sur le site de secours, etc. ;
  • les soucis imprévus de dernière minute (tel logiciel ne peut être utilisé car la clé logique n’est pas attribuée, telle porte est fermée à clé et celle-ci est introuvable...).

Il n’y a pas de clé, hélas !

La société BCD doit interrompre son alimentation électrique sur toute sa salle informati­que pour cause de travaux. Elle décide à cette occasion de simuler une panne de courant, tout en prévenant le personnel, afin d’observer comment se passe l’arrêt des serveurs en salle.

Le jour j arrive : le courant est coupé, et on passe alors sur les onduleurs, qui assurent, pré­voit-on, environ 50 minutes d’autonomie. Les opérateurs lancent les procédures d’arrêt des machines correctement. Pour certaines d’entre elles, il faut se rendre dans la salle informatique : tout se passe bien, les opérateurs prévus ont effectivement les droits.

Chapitre 6 – Tester le plan de continuité

La plupart des machines en salle sont accessibles sans difficulté et peuvent donc être arrêtées. Mais certaines d’entre elles se trouvent dans une armoire fermée à clés, sans que cela ait été prévu. Cherchant alors les clés, on finit par les trouver mais elles ne sont pas clairement identifiées, ce qui fait perdre du temps pour les essayer une à une. Or, le chronomètre tourne !

En fin de compte, il reste deux machines dont l’accès est impossible : la clé d’armoire est trouvée mais pas la deuxième nécessaire pour activer le clavier ! Ces deux machines finis­sent par s’arrêter, faute de courant, ce qui n’était pas prévu. Or il se trouve que ces machi­nes sont justement jugées critiques.

Moralité : un petit oubli a failli tout faire échouer ! Concernant les machines critiques, il vaut mieux analyser à l’avance et dans le détail les problèmes potentiels.

Vérifier la validité du plan

Le plan de continuité part d’une photographie de l’entreprise et de ses partenai­res à un moment donné. En raison des évolutions qui ne manqueront pas de se produire, le plan ne sera donc pas toujours d’actualité et il faudra régulièrement procéder à une mise à jour. La liste des éléments à remettre à jour est longue. Une procédure particulière est normalement prévue pour cela (voir le chapi­tre 12), mais elle n’est pas toujours appliquée correctement. Parmi ces élé­ments, on peut citer :

  • les organigrammes et les listes de contacts ;
  • les informations concernant les partenaires (fournisseurs de sites de secours, dépanneurs, etc.) ;
  • les caractéristiques des systèmes techniques de toute sorte, connaissant des modifications régulières qui doivent être suivies afin que leur secours soit de même niveau.

Aucun exercice de test ne se révèle sans surprise sur ces aspects. L’exercice permettra non seulement la mise à jour des listes, mais surtout l’amélioration de la procédure de tenue à jour elle-même, en détectant ses faiblesses. L’un des meilleurs résultats que l’on puisse obtenir est d’ailleurs la sensibilisation des responsables chargés de cette mise à jour.

Former les employés

Cet objectif est très souvent mis en avant par ceux qui pratiquent des tests régu­liers. Pour les employés comme pour les responsables, le premier test est le plus difficile car « on ne sait pas ce que l’on a à faire ». Les tests suivants ressemblent davantage à des répétitions et des exercices de rodage.

Dans l’idéal, les employés devraient parvenir à :

  • respecter les affectations aux groupes et attributions d’activités prévues par le plan ;
  • réagir efficacement face à toute sorte d’imprévu (absence de personnel, allon­gement des délais, situations non conformes au plan, etc.) ;

Management de la continuité d’activité

  • se familiariser avec les locaux de secours, le centre de gestion de crise, les tra­jets à effectuer, les lieux à visiter (pour récupérer des bandes, par exemple) de manière à parer à toute éventualité ;
  • utiliser aisément les moyens de communication et avoir le réflexe de rendre des comptes (reporting).

L’exercice de test se révèle ainsi être un bon moyen de former les employés, qui peuvent eux-aussi proposer des améliorations du plan.

Pour les employés non directement impliqués dans les tests, la sensibilisation aux problèmes de continuité est un résultat intéressant de la campagne de tests.

Méthodes de test

Il existe plusieurs méthodes pour tester un plan, que celui-ci concerne la conti­nuité ou pas d’ailleurs. Les principales méthodes en usage sont décrites ci-après. Le coût et le risque associés au test sont variables en fonction de la méthode choisie.

Test de vérification (check-list)

Ce type de test est peu onéreux et permet de préparer des tests plus approfon­dis. Il consiste à passer en revue le plan de continuité et les documents associés pour en vérifier l’exactitude et l’applicabilité, tout en inspectant la disponibilité des ressources prévues. En particulier, cela revient à vérifier :

  • l’exactitude des listes de contacts et des numéros de téléphone ;
  • la bonne documentation des applications critiques et des systèmes informa­tiques associés ;
  • la bonne description des dossiers vitaux (existence, lieu de conservation, etc.) ;
  • la présence effective des sauvegardes dans les lieux prévus, sous la forme attendue, aux dates voulues ;
  • l’existence des formulaires nécessaires aux procédures dégradées, avec la bonne description desdites procédures ;
  • la bonne tenue des manuels d’installation ou d’intervention prévues sur le site de secours ;
  • la présence sur le site de secours du matériel et des documents qui sont cen­sés s’y trouver ;
  • la présence au centre de gestion de crise des matériels et équipements pré­vus, en bon état de fonctionnement.

Ces vérifications peuvent se faire régulièrement. L’implication des groupes d’intervention, même si elle est intéressante, n’est pas nécessaire.

Inspection de documents (walk-through)

Appelé parfois « test en chambre », l’inspection de documents consiste à lire les documents constituant le plan de continuité pour en dérouler, virtuellement ou à blanc, le scénario d’exécution.

Chapitre 6 – Tester le plan de continuité

Avant de réaliser ce type de test, il faut déterminer un scénario précis de sinistre. Par ailleurs, on doit avoir remis aux membres de l’équipe de test une description de leurs responsabilités, des activités à effectuer et des procédures à suivre. Le test consiste ensuite, pour les personnes impliquées, à jouer le rôle de leur res­ponsabilité, en « déroulant » les activités à effectuer, tout en suivant les procé­dures avec leur équipe. Le but est de vérifier que l’ensemble est correctement conçu et opérationnel.

Le fait de rassembler des groupes avec des responsabilités diverses dans le même exercice se révèle très intéressant, car cela permet éventuellement de :

  • détecter des recouvrements de missions (deux groupes voulant faire la même chose) ;
  • découvrir des lacunes (personne pour certaines activités) ;
  • constater des trous dans les procédures, ou encore des points inapplicables ou inutiles ;
  • observer éventuellement des difficultés dans les activités ou réajuster le planning.

Ce genre de test a l’avantage de familiariser les équipes avec leurs collègues, les rôles de chacun, les sites de secours et leurs ressources, les circuits de décision et de reporting. Les personnes impliquées apprennent ainsi à vivre le plan de continuité. Afin de rendre les tests plus réalistes, les équipes peuvent d’ailleurs être dépêchées sur les lieux réels d’intervention.

Simulation

Ce test est plus élaboré et plus coûteux que les précédents. Il s’agit en effet de simuler une interruption d’activité due à un sinistre et d’exécuter la portion du plan de continuité correspondante.

La mise en œuvre de ces tests peut comporter plusieurs variantes, dont vont dépendre le degré de perturbation des activités de l’entreprise et le coût du test :

  • simuler des activités (l’arrêt d’un serveur, par exemple) ou les effectuer réelle­ment (arrêter effectivement le serveur) ;
  • faire la simulation sur un site de production réel ou sur un site de secours ;
  • demander aux employés concernés par les activités touchées d’arrêter effecti­vement de travailler ou les laisser continuer ;
  • faire travailler une partie du personnel sur le site de secours ou employer les moyens de secours avec des procédures dégradées ;
  • se limiter à certaines portions du plan, concernant une activité de l’entreprise en particulier ou une partie d’un site ;
  • se concentrer uniquement sur certaines étapes du plan, comme les trois pre­mières, qui peuvent nécessiter un rodage particulier.

clip_image024.gifZone de Texte: 137Zone de Texte:  En outre, ces tests de simulation peuvent être particulièrement intéressant pour vérifier certains points particuliers tels que :

Management de la continuité d’activité

  • le degré de réactivité des prestataires impliqués ;
  • l’efficacité de la sortie des sauvegardes de leur lieu de conservation ;
  • la faisabilité de l’utilisation de tel ou tel site en secours pour les bureaux ;
  • le temps à prévoir pour certains déplacements ;
  • la durée nécessaire à la reconstitution des données sur le site de secours ;
  • la viabilité des procédures manuelles ;
  • l’efficacité du plan en cas d’absence de téléphonie ou de messagerie ;
  • l’efficacité des circuits de décision en cas d’absence de certains responsables.

La simulation peut d’ailleurs être centrée sur des points particuliers pour les­quels des doutes subsistent. Dans ce cas, les résultats permettent d’apporter de réelles améliorations au plan.

Test parallèle

En informatique, le test parallèle s’emploie pour remplacer un système par un autre et ainsi vérifier qu’ils donnent le même résultat. Ce genre de test permet d’asseoir la confiance dans un système de secours et dans les procédures de res­tauration des données. Dans le cadre de la continuité d’activité, il s’agit de faire fonctionner le système de secours en parallèle du système principal, afin qu’il soit le plus ressemblant possible. Pour atteindre cet objectif, on procède comme suit :

  1. le système principal fonctionne normalement sur son site ;
  2. à un moment donné, on fait comme si un sinistre s’était produit : on com­mence à garder une trace manuelle des transactions saisies sur le système principal (en faisant comme s’il n’existait plus) ;
  3. le système de secours prévu est mis en route sur le site de secours ;
  4. les diverses sauvegardes disponibles sont récupérées et restaurées sur le système de secours, en appliquant au besoin les journaux ;
  5. les transactions manuelles (du point 2) sont saisies sur le système de secours ;
  6. on compare alors les deux systèmes, en notant tout écart concernant les données.

Les écarts de données sont dus aux périodes durant lesquelles l’enregistrement des transactions n’a pas été fait ou communiqué – par exemple, le laps de temps entre la dernière sauvegarde et le sinistre simulé. Les raisons peuvent être diver­ses et les solutions techniques proposées également. Dans tous les cas, cela doit donner lieu à un plan d’action.

Ce type de test est délicat et parfois coûteux ; on l’effectue en général quand les autres tests ont été menés avec succès. Le test parallèle peut être réalisé assez facilement sur certaines solutions techniques (telles que le SGBD, voir le chapi­tre 8).

Chapitre 6 – Tester le plan de continuité

Grâce à ce test, il est également possible de vérifier si les employés ont bien accès au système de secours. Enfin, il peut se révéler utile pour mesurer le temps nécessaire à chaque récupération. On pourra ainsi analyser la manière de réduire ces délais s’ils s’avèrent trop longs.

Test interruptif total

C’est le test complet. Tout se passe comme si un sinistre avait réellement eu lieu. Le plan est activé en grandeur nature et les activités qu’il prévoit sont réel­lement exécutées.

Si le test le permet, l’activité « normale » peut continuer. Il faut bien évidem­ment avertir les clients, fournisseurs et partenaires de cette interruption pro­grammée. On cherchera pour cela à éviter les périodes de grande activité ou les pointes de transactions.

Comme il s’agit du test le plus onéreux, il ne sera réalisé que lorsque les autres tests auront été effectués et que les améliorations à apporter découvertes au cours de ceux-ci auront été intégrées. Ce genre de test est très rarement prati­qué.

Faut-il annoncer le test ?

Faut-il prévenir les employés et les partenaires de l’entreprise que le plan de continuité sera testé (en leur indiquant le site, le jour et l’heure précis) ? Ou vaut-il mieux, au contraire, garder le secret et le déclencher à l’improviste ? Les avis divergent, mais la façon de procéder dépendra aussi de chaque situation.

En effet, plusieurs éléments doivent être pris en considération pour déterminer la méthode à adopter, dont certaines prêchent en faveur d’une annonce :

  • si le plan de continuité n’est pas encore tout à fait maîtrisé, rien ne sert de compliquer les choses en réalisant des tests à l’improviste ;
  • si le plan comporte des défauts, que le test soit annoncé ou non, ils seront tout de même constatés ;
  • si le test est annoncé, l’entreprise peut en réduire l’impact et donc le coût. D’autres incitent plutôt à privilégier la surprise :
  • seul le test non annoncé permet de vérifier la bonne réactivité des employés ;
  • le sinistre réel ne prévenant pas, le test sera lui aussi réalisé à l’improviste, par souci de réalisme ;
  • la surprise empêchera que certaines personnes soient tentées de rectifier à l’avance des situations dommageables à la continuité, que l’on ne découvrira donc pas.

En conclusion, les tests réalisés à l’improviste ne sont recommandés que si l’entreprise possède une bonne maîtrise de son plan de continuité, acquise à la suite de tests annoncés. Toujours dans une démarche de progression, les pre­miers tests non annoncés se feront sur un périmètre limité et viseront essentiel‑

Management de la continuité d’activité

lement à évaluer la réactivité des personnes sur les premières étapes du planning.

Document de préparation

Pour réussir l’exercice du test, il est important de bien le préparer. Le manque de préparation peut générer des doutes quant au sérieux du plan et décrédibiliser toute action ultérieure. En effet, la direction générale accorde à ces tests un temps et une attention qui n’est conséquente que si les résultats sont à la hau­teur des attentes. Enfin, pour être crédible, il est nécessaire d’être réaliste et pragmatique.

On devra donc décrire ce que l’on attend concrètement du test dans un docu­ment qui couvre les points suivants :

  • le dispositif humain et technique pour mener le test ;
  • les points du plan de continuité à tester ;
  • la date, le lieu et la durée du test ;
  • les ressources nécessaires ;
  • les actions à mener avant, pendant et après ;
  • la méthode d’évaluation des points qui ressortiront à travers ce test ;
  • le dispositif de surveillance et de compte rendu des événements et constatations.

Avant de développer le plan de test proprement dit, les points de ce document devront être approuvés préalablement par la direction des services concernés.

Contraintes des tests

Un test peut perturber le déroulement habituel des activités des employés. Avant de le mettre en application, il est donc judicieux d’en définir les limites de concert avec les opérationnels concernés. En effet, pour obtenir leur accord sur un calendrier annuel et les perturbations acceptables, il faudra les convaincre de l’utilité des tests en leur montrant qu’ils ont tout à y gagner. Concrètement, on validera avec eux un certain nombre de points :

  • les répercussions acceptables sur le service ;
  • les contraintes financières, le budget alloué et surtout ce que le test coûtera à ceux qui en seront les « victimes » ;
  • les niveaux de sécurité à respecter : certaines dérogations sont-elles possibles ? dans quelles conditions ?
  • les limites de temps et de coûts pour la mise à disposition de moyens de secours, de sites et d’employés ;
  • la disponibilité du support technique fourni par les opérationnels en phase de préparation et d’exécution du test, puis lors de la remise en état normal ;
  • la détermination de toute autre contrainte ou limite aux actions de test (par exemple : exécution uniquement le week-end ou la nuit, etc.).

Chapitre 6 – Tester le plan de continuité

Élaborer un plan de test

clip_image030.gifPour chaque test programmé, un plan est établi afin d’en préciser formellement le cadrage et de prévoir le planning de son déroulement. Ce plan se déroule selon sept phases, devant chacune produire des résultats tangibles (livrables) :

  1. revue des tests antérieurs ;
  2. description des objectifs, périmètre et contraintes ;
  3. définition de la tactique du test ;
  4. mise en place de la logistique du test ;
  5. planning et calendrier du test ;
  6. revue des risques éventuels avant exécution ;
  7. documentation du test.

Phase 1 – Revue des tests antérieurs

Lors de cette première phase, les rapports de tests déjà effectués sont passés en revue pour établir un bilan et capitaliser sur leurs résultats. Ceux-ci contiennent en effet des renseignements utiles, aussi bien au sujet des points du PCA qui posent problème que de ceux qui ont été testés avec succès.

Cela permet également de dresser la liste des points qui n’ont pas encore été testés, le but étant d’améliorer les points défaillants et d’évaluer ceux qui n’ont pas encore été testés.

Quand tout va bien, il faut le dire !

La société Dugroup a racheté la société DBC et fusionné leurs moyens informatiques. Avant la fusion, DBC testait son plan de reprise (PRA) sur un site éloigné.

Après restructuration technique, Dugroup souhaite organiser une campagne de tests et analyse dans ce but les rapports des tests antérieurs menés par DBC. Ces derniers sont très succincts et ne décrivent pas avec suffisamment de précision l’existant technique. Difficile donc de déterminer les éléments qui restent valables dans la nouvelle configura­tion. Par ailleurs, les rapports font surtout état de problèmes de télécommunications qui ne sont plus pertinents dans la nouvelle structure.

Dugroup ne peut quasiment rien déduire des rapports de tests de DBC et réalise de nou­veaux tests, qui recouvrent fort probablement des actions déjà accomplies par DBC et

que l’on aurait pu éviter si leurs résultats avaient été rapportés plus précisément.

Moralité : il est fréquent de trouver dans les rapports de tests uniquement la liste de ce qui ne va pas... les points positifs étant éludés. Sachez que, afin d’optimiser les tests sui­vants, il est également important de les indiquer !

Bien entendu, il faut également intégrer dans la revue les éventuelles modifica­tions subies par l’entreprise qui rendent caducs certains tests réalisés antérieu­rement ou certaines actions correctives.

Par ailleurs, les documents des tests antérieurs peuvent être réutilisés comme modèle pour les nouveaux tests.

Management de la continuité d’activité

À l’issue de cette phase, un document de revue des tests antérieurs doit être produit.

Phase 2 – Description des objectifs, périmètre et contraintes

Les objectifs, le périmètre et les contraintes du test sont définis lors de discus­sions en interne et doivent être rédigés de façon minutieuse. Ces éléments sont d’une importance capitale pour la réussite des phases qui suivent, et ne doivent jamais être perdus de vue tout au long de leur déroulement.

Objectifs

Il s’agit de décrire les objectifs que l’on souhaite atteindre en réalisant le test.

Il est préférable de classer ces objectifs par niveaux de priorité, en distinguant bien ce qui est urgent et indispensable (objectifs prioritaires) de ce qui serait simplement intéressant, et pouvant par conséquent être testé plus tard (objec­tifs secondaires). Un classement en deux ou trois niveaux suffit. En voici quel­ques exemples :

Objectifs prioritaires :

  • déterminer si le PCA est à jour ;
  • vérifier que les ressources prévues en secours sont convenables ;
  • s’assurer que les procédures de restauration de données informatiques fonc­tionnent correctement ;
  • recréer l’environnement informatique de secours sur le site distant et vérifier le temps nécessaire ;
  • relocaliser un service sur un site de secours ;
  • s’assurer que les premières étapes du PCA, en début de crise, se déroulent comme prévu ;
  • vérifier la réactivité des prestataires impliqués dans le plan. Objectifs secondaires :
  • tester l’accès des utilisateurs sur un système de secours, une fois celui-ci mis en route ;
  • vérifier l’ouverture du centre de gestion de crise (à la suite des premières éta­pes du plan) ;
  • tester une application donnée sur un système de secours ;
  • tester le retour à la normale.

Les objectifs dits secondaires seront testés si la charge de travail et le contexte le permettent.

Ne pas dévier de l’objectif !

La société Bontemps teste la capacité à relancer ses serveurs sur un site de secours. Elle possède des serveurs Unix, Windows et un mainframe IBM.

Chapitre 6 – Tester le plan de continuité

Tout se passe bien pour le mainframe et les serveurs Windows. Pour les serveurs Unix, en revanche, elle constate qu’il manque certains droits de licence ou, plus exactement, qu’il faut demander une montée de niveau et des correctifs auprès d’un fournisseur.

L’équipe en charge du test contacte alors directement ledit fournisseur. Celui-ci entre à son tour en relation avec le responsable des achats de Bontemps, qui lui n’est pas au cou­rant de la situation. On en reste là, malgré la pression de l’équipe de test.

Moralité : Il ne faut pas perdre de vue l’objectif du test ! Ici, il s’agissait de « vérifier » que l’on pouvait démarrer les serveurs et non pas de « démarrer les serveurs ». Le test aurait donc dû simplement produire le constat qu’il y avait un problème à résoudre pour les ser­veurs Unix et non entraîner sa résolution en catastrophe !

Cela ne signifie pas pour autant qu’il faille automatiquement tout arrêter sur un constat d’impossibilité. Lorsqu’un document est absent, par exemple, on le note, mais si on sait où le trouver, on le cherche ! C’est une affaire de « bon dosage » à trouver.

  1. B. : Au passage, cet exemple montre que le responsable des achats peut lui aussi être impliqué dans les tests.

Périmètre

Définir le périmètre du plan de test consiste à délimiter le champ d’action du test. Celui-ci peut inclure :

  • les portions du PCA que l’on souhaite vérifier(telles que les trois premières étapes du planning ou la formation des groupes, par exemple) ;
  • les activités prévues par le planning sur un site donné ;
  • tout ce qui doit se passer sur un ou plusieurs sites de l’entreprise ;
  • certains partenaires externes et contrats de secours ;
  • une technologie donnée (en particulier, si celle-ci coûte cher pour un niveau de secours qui reste à prouver) ;
  • une action particulière du plan (par exemple : mettre en route le centre de gestion de crise).

Tout ce qui se trouve en dehors du champ d’action peut également être listé, afin que le personnel effectuant les tests connaisse exactement les limites de ses actions.

Pour une série de tests ayant le même objectif, le périmètre, lui, peut changer d’un test à l’autre. Par exemple, il peut être intéressant de tester les mêmes objectifs sur les différents sites de l’entreprise (y compris ceux à l’étranger)

Contraintes

Cet aspect est très important pour la suite. Si les contraintes sont trop fortes, le test risque d’être difficile à mener. À l’inverse, une absence de contrainte peut être préjudiciable à l’entreprise. Voici les différents éléments à déterminer pour le test en prévision :

  • l’enveloppe budgétaire affectée aux coûts des machines de secours, de dépla­cement, de locations diverses, de licence, etc. ;

Management de la continuité d’activité

  • le niveau de perturbation entraîné sur l’entreprise : peut-on réellement arrê­ter telle machine ? combien de temps ? quand ?
  • la sécurité : peut-on obtenir des dérogations ? faut-il prévoir des mesures supplémentaires ?
  • les limites de charge prévues pour les spécialistes mis à disposition pour le test ;
  • pour les locaux prévus en secours, d’éventuelles contraintes d’espace, de limites électriques, de charge de machine à ne pas dépasser ;
  • les approximations nécessaires (utilisation d’un site en secours à la place du site principal, par exemple).

Ces contraintes déterminent souvent les points sur lesquels le test pourra être effectué en situation réelle ou si on devra se contenter de faire une simulation. C’est en effet le test qui doit être adapté aux contraintes posées et non l’inverse.

Phase 3 – Définition de la tactique de test

Maintenant que l’on sait précisément ce que l’on veut vérifier et dans quel cadre, il faut définir la tactique à observer pour parvenir au résultat attendu tout en res­tant dans les limites définies.

Scénario

La situation que l’on veut tester est décrite par écrit dans un document qui sera remis à l’équipe de test au début de l’exercice. La description doit être réaliste et crédible, elle ne doit pas révéler par avance ce que les testeurs sont supposés découvrir par eux-mêmes ou évaluer. Elle doit en revanche permettre de limiter la réaction au périmètre recherché.

Il peut être intéressant de prendre pour scénario certaines des catastrophes étu­diées dans l’analyse de risque (voir le chapitre 1). Cela permet de se rapprocher au plus près d’une catastrophe réellement probable.

La narration doit présenter des faits, des dates et heures précises et des cons­tats déjà réalisés. Voici quelques exemples :

Scénario n° 1 : Inondation du site CTI01 Objectif : valider les étapes 1, 2 et 3 du PCA. Périmètre : le site CTI01 et son site de secours. Contrainte : pas d’interruption d’activité. Document remis au chef de gestion de crise.

« À cause de la crue du Loir, l’environnement du site CTI01 est inondé. À 1 h du matin, le 23 mars, le niveau d’eau atteint 30 cm, mesurés à l’entrée servant de référence. La sur­veillance de nuit du centre appliquant la procédure appelle le responsable de site qui vient de vous réveiller. »

Pour toute question : contacter M. Test (numéro de téléphone).

Chapitre 6 – Tester le plan de continuité

Scénario n° 2 : Reprise de l’application SAT02 sur le site d’Angers Objectif : valider la viabilité du contrat avec la société CPPB.

Périmètre : l’application SAT02, le site de Vanves et son site de secours. Contrainte : pas d’interruption d’activité.

Document remis au responsable de récupération des moyens techniques.

« À cause d’un problème grave sur le site principal de Vanves, il a été décidé d’arrêter cer­taines des applications en fonctionnement sur ce site. Le 15 mars à 9 h, il est décidé d’activer la version de secours de l’application SAT02 sur le site d’Angers, comme prévu dans la convention de secours signée avec le CPPB. Il n’est pas possible de se rendre sur le site de Vanves. Le chef de gestion de crise vous transmet ce message. »

Pour toute question : contacter M. Test (numéro de téléphone).

Exceptés les cas où l’on veut simuler un tout début de sinistre et évaluer la manière dont les dommages sont découverts, le scénario doit décrire les dom­mages subis par l’entreprise lors du sinistre. Tout doit être présenté de manière à donner un niveau d’information correspondant à celui obtenu en situation réelle au moment que l’on veut tester.

C’est à partir du problème ainsi posé que le destinataire du message devra enclencher les mesures prévues dans le plan au sein du cadre indiqué.

Choix de la méthode

Les différentes méthodes de test pratiquées ont été présentées dans la première section de ce chapitre. Au cours de l’élaboration de la tactique de test, on déter­mine à quelle méthode on recourt en fonction du scénario prévu.

Dans le cas du scénario n° 2 ci-dessus, le « test parallèle » pourra se révéler per­tinent. Pour le scénario n° 1, induisant des conséquences plus lourdes si on le mène à fond, on préfèrera une revue de documents (walk-through) ou une simula­tion.

Date du test

La date et la durée du test seront fixées en fonction des disponibilités et des diverses contraintes, tout en tenant compte des possibilités d’exercice des par­tenaires locaux ou contractuels. Le planning des tests doit être considéré comme un engagement fort, à respecter absolument.

Une erreur courante consiste à prolonger les tests rencontrant des difficultés. Cette pratique est à éviter, l’objectif du test étant de mettre à jour la difficulté, pas de la résoudre. Il faut donc bien séparer les deux préoccupations : le test doit relever des difficultés, des anomalies ; le temps de leur résolution viendra plus tard. On ne doit pas rester « bloqué » sur un problème, mais le noter et pas­ser outre. C’est pour cette raison que les tests effectués en première instance sont de type check-listwalk-through ou simulation, car on rencontre, à ce stade, trop de problèmes pour pouvoir dérouler l’ensemble d’un scénario en mode réel.

8