PlanContinuiteActivite PDF

Dossier technique
Plan de Continuit dActivit

---
Stratgie et solutions de secours
du S.I.

Septembre 2003

COMMISSION TECHNIQUES DE SECURITE LOGIQUE

CLUB DE LA SECURITE DES SYSTEMES DINFORMATION FRANAIS
30, rue Pierre Semard, 75009 PARIS
Tl. : +33 153 25 08 80 Fax : +33 1 53 25 08 88
e-mail : clusif@clusif.asso.fr - Web : http://www.clusif.asso.fr

TABLE DES MATIERES

1 Introduction................................................................................................................. 1
2 Stratgie de secours..................................................................................................... 3
2.1 Dfinitions.............................................................................................................................................. 3
2.2 Dmarche ............................................................................................................................................... 3
2.2.1 Les phases de la dmarche......................................................................................................... 3
2.2.2 Phase de lancement..................................................................................................................... 4
2.2.3 Phase d'tude fonctionnelle........................................................................................................ 5
2.2.4 Phase d'tude de vulnrabilit.................................................................................................... 5
2.2.5 Phase d'analyse des risques........................................................................................................ 6
2.2.6 Phase d'orientation : cible fonctionnelle et choix des solutions techniques de secours.............. 7
3 Le Plan de Secours Informatique .............................................................................. 9
3.1 Introduction........................................................................................................................................... 9
3.2 Organisation .......................................................................................................................................... 9
3.2.1 Le Comit de Crise..................................................................................................................... 9
3.2.2 La Cellule de Coordination...................................................................................................... 10
3.2.3 Les quipes dintervention....................................................................................................... 10
3.2.4 Les services utilisateurs............................................................................................................ 10
3.3 Dclenchement..................................................................................................................................... 11
3.4 Les dispositifs de secours .................................................................................................................... 11
3.5 Documentation .................................................................................................................................... 13
3.5.1 Les documents de communication sur le plan de secours........................................................ 13
3.5.2 Les documents de mise en uvre du Plan de secours.............................................................. 13
3.5.3 Les documents de gestion du plan de secours.......................................................................... 14
3.5.4 Les documents de contrle du plan de secours......................................................................... 14
3.6 Maintenance du plan........................................................................................................................... 14
3.6.1 Organisation............................................................................................................................. 14
3.6.2 Outils........................................................................................................................................ 14
3.7 Plan de test........................................................................................................................................... 15
4 Les solutions de secours............................................................................................ 17
4.1 Les solutions de secours informatiques ............................................................................................. 17
4.1.1 Typologie et modes de gestion des moyens de secours............................................................ 19
4.1.2 Type de moyens mis en uvre................................................................................................. 22
4.1.3 Niveau de prparation et disponibilit des moyens.................................................................. 25
4.2 Le secours de la tlphonie ................................................................................................................. 27
4.2.1 Le raccordement au rseau....................................................................................................... 27
4.2.2 Les moyens tlphoniques de secours...................................................................................... 28
4.2.3 Le routage des liaisons tlphoniques (sur numro unique)..................................................... 28
4.3 Le sauvetage des locaux et des quipements ..................................................................................... 29
4.4 Les sauvegardes / restaurations ......................................................................................................... 29
4.4.1 Les types de sauvegarde........................................................................................................... 29
4.4.1.1 Sauvegarde physique................................................................................................................ 30
4.4.1.2 Sauvegarde logique.................................................................................................................. 30
4.4.1.2.1 Sauvegarde logique complte......................................................................................... 30
Plan de Continuit dActivit CLUSIF 2003
Stratgie et solutions de secours du S.I.
I
4.4.1.2.2 Sauvegarde incrmentale................................................................................................ 30
4.4.1.2.3 Sauvegarde applicative................................................................................................... 30
4.4.1.2.4 J ournalisation.................................................................................................................. 31
4.4.2 Les techniques de duplication, de sauvegarde et de restauration.............................................. 31
4.4.2.1 la rplication ;........................................................................................................................... 31
4.4.2.1.1 Cas 1 : la rplication immdiate...................................................................................... 31
4.4.2.1.2 Cas 2 : Les mises jour sont transmises intervalles rguliers..................................... 31
4.4.2.2 la sauvegarde classique............................................................................................................. 32
4.4.3 La synchronisation des donnes............................................................................................... 33
4.4.4 Les solutions de sauvegarde / restauration. .............................................................................. 33
4.4.4.1 Architectures dites "centralise"............................................................................................... 33
4.4.4.2 Architecture distribue ou client / serveur.......................................................................... 33
4.4.5 Les procdures, les tests, le suivi.............................................................................................. 34
4.5 Le secours des impressions et de la mise sous pli ............................................................................. 34
4.6 Le secours des accs au rseau Internet ............................................................................................ 35
4.6.1 Le raccordement au rseau Internet.......................................................................................... 35
4.6.2 Le reroutage des flux Internet................................................................................................... 35
4.7 Le contrat de secours .......................................................................................................................... 35
4.7.1 Objet du contrat........................................................................................................................ 36
4.7.2 Nature dtaille des prestations .......................................................................................... 36
4.7.3 Procdure de dclenchement.................................................................................................... 36
4.7.4 Conditions de fonctionnement.................................................................................................. 36
4.7.5 Logistique................................................................................................................................. 37
4.7.6 Tests et rptitions.................................................................................................................... 37
4.7.7 Gestion de priorits................................................................................................................... 37
4.7.8 Engagements et responsabilits................................................................................................ 38
4.7.9 Aspects financiers..................................................................................................................... 39
4.7.10 Evolution de la configuration................................................................................................... 39
4.7.11 Confidentialit.......................................................................................................................... 39
4.7.12 Quelques recommandations...................................................................................................... 40
5 Annexe : fiches guides danalyse des risques.......................................................... 41
5.1 Locaux et infrastructure..................................................................................................................... 41
5.2 Equipements informatiques et de tlcommunication ..................................................................... 46
5.3 Systme d'exploitation, applications, donnes et flux ...................................................................... 48
5.4 Services, fournitures et prestations extrieurs.................................................................................. 50
5.5 Ressources humaines .......................................................................................................................... 52
6 Table des figures et tableaux.................................................................................... 55
7 Glossaire..................................................................................................................... 57

II
REMERCIEMENTS
Le CLUSIF tient mettre ici l'honneur les personnes qui ont rendu possible la ralisation de
ce document, tout particulirement :

Robert BERGERON CAP GEMINI ERNST & YOUNG
Annie BUTEL PRICEWATERHOUSECOOPERS
J ean-Claude GANDOIS LEGRAND
Guy JOVER CNAMTS
Guy KHOUBERMAN ACOSS CNIR SUD
Siegfried NOEL TELINDUS

Nous tenons galement remercier la commission Espace RSSI et son prsident, Pierre
SINOQUET, pour les changes fructueux que nous avons eus sur le thme de la continuit
dactivit.
III
IV
1 INTRODUCTION

Ce document sadresse avant tout aux responsables scurit, directions informatiques, risk
managers ou au contrle interne. Elle concerne aussi tout acteur (Direction Gnrale,
Direction J uridique, Direction des Ressources Humaines, Direction Administrative et
Financire, ...) ds lors que sa fonction contribue entre autres dfinir, implmenter,
maintenir ou garantir la scurit. Il a pour objectif d'apporter une aide au choix et la mise en
uvre de moyens visant assurer une disponibilit des systmes d'information adapte aux
besoins de l'entreprise.
Le problme de la continuit du systme dinformation (SI) peut tre abord diverses
occasions, comme par exemple :
dans le cadre d'un Plan de Continuit d'Activit (PCA). Ces projets stratgiques
d'entreprise sont raliss la demande des Directions Gnrales. Ils ont pour but de
garantir la survie de l'entreprise. Le secours de moyens informatiques ne constitue que
l'un des aspects d'un PCA ;
lors de l'laboration d'un Plan de Secours Informatique (PSI). Le PSI concerne le
secours des moyens informatiques. Il doit cependant susciter une implication forte de
la Direction Gnrale. Le Plan de Secours Informatique vise garantir le service
minimum requis pour les systmes d'information ;
lors de la mise en place d'une nouvelle application, lors de changements importants
concernant les architectures techniques ou lors de ngociation de contrats de service.
Il s'agit alors de rpondre un besoin ponctuel prcis, tout en s'intgrant dans une
stratgie globale (PCA, Plan de Secours Informatique), si elle existe.
Le document comporte trois parties principales :
La prise en compte des besoins et la dfinition d'une stratgie de secours (chapitre 2).
Ce chapitre fournit des lments d'aide :
l'analyse pralable des risques ;
au choix des dispositifs mettre en uvre (dispositifs permanents relevant de la
qualit ou dispositifs de secours dclencher uniquement en situation de
sinistre).
Llaboration du Plan de Secours Informatique (chapitre 3). Ce chapitre dcrit son
organisation, ses composants essentiels et son intgration dans un plan plus global de
continuit d'activit.
La prsentation des principaux dispositifs pouvant tre retenus pour assurer la
disponibilit d'un systme d'information (chapitre 4).
Un glossaire est disponible la fin de ce document.
1
2
2 STRATEGIE DE SECOURS

L'laboration d'un Plan de Secours Informatique est une opration complexe par le nombre de
situations envisager (sinistre de locaux, panne de matriel, erreurs, malveillance, etc) et par
le nombre et la difficult des tches raliser pour rtablir une situation acceptable pour
l'entreprise. Cette opration est toujours longue mettre en place et suppose une charge de
travail importante des quipes concernes. Les exigences de continuit de service sont de plus
en plus fortes et conduisent des solutions coteuses. Aussi convient-il de dfinir une
stratgie de secours adapte aux enjeux et aux contraintes de l'entreprise.
Ce chapitre prsente les tapes classiques conduisant la dfinition de la stratgie de secours.
On pourra se reporter utilement aux documents du CLUSIF consacrs aux mthodes et en
particulier MEHARI qui dtaillent les dfinitions et les tapes d'tude des vulnrabilits et
d'analyse des risques.
2.1 Dfinitions
Dans la suite du document, nous ferons rfrence certaines notions d'analyse de risques,
selon les mthodes MARION ou MEHARI :
L'impact : le niveau d'impact mesure les consquences de la ralisation d'un risque sur
l'entreprise. La dfinition des niveaux d'impact permet de prciser les situations non
supportables par lentreprise (pertes financires, atteinte limage, dsorganisation, ...) et de
disposer ainsi dune rfrence commune pour lvaluation des risques.
La potentialit : le niveau de potentialit permet dapprhender d'une manire simplifie la
probabilit de ralisation d'un risque. On utilise habituellement 4 5 niveaux, ce qui est
suffisant pour faire la part des choses entre le cas d'cole et le risque qui a de fortes chances
de se raliser court terme.
La gravit : combinaison de l'impact et de la potentialit. Le niveau de gravit d'un risque
mesure son degr d'acceptabilit par la Direction Gnrale.
2.2 Dmarche
2.2.1 Les phases de la dmarche
La dmarche pour la dfinition de la stratgie de secours peut tre dcompose en 5 phases :
3
Lancement
Etude fonctionnelle
Etude de
vulnrabilit
Anal yse des risques
Orientations
Champ de ltude
Enjeux, critres dvaluation des impacts, service minimum
Bilan des scurits existantes ou prvues
Scnarios de sinistre, priorits
Cibles fonctionnelles et techniques
Scnarios de solutions
Chaque rsultat de
phase conditionne la
phase suivante et
doit faire lobjet
dune rception
formelle par le
Comit de Pilotage.

Figure 1 : Dmarche de stratgie de secours
2.2.2 Phase de lancement
Avant de commencer une tude de Plan de Secours Informatique, il est essentiel den prciser
le champ. Il convient en particulier de faire valider par la Direction de lentreprise, via un
comit de pilotage, les activits concernes et les types de risques prendre en compte. Il peut
sagir de lensemble des activits ou au contraire dun plan de secours limit un domaine
stratgique. Pour chaque activit concerne, on dsignera un correspondant PSI de lquipe
projet.
La difficult de ce type dtude rside essentiellement dans la mise en oeuvre dun PSI adapt
l'environnement. Ladoption dune mthodologie personnalise, facilitera lappropriation
par les responsables concerns.
Il y a lieu de faire prciser par la Direction les risques quelle souhaite couvrir. Selon les
choix exprims, les objets risque concerns (matriels informatiques, matriels de
tlphonie, fournitures externes, personnel, locaux, ...) et la nature des risques (faut-il par
exemple traiter le risque social ?) seront prciss.
Selon les risques retenus et le primtre souhait, le plan de secours sera un Plan de Secours
Informatique ou sapparentera un Plan de Continuit dActivit.
Les fiches guides danalyse de risque fournies en annexe de ce document listent par grandes
familles les objets risques pouvant tre pris en compte dans un PSI ainsi que les principaux
risques associs.
4
2.2.3 Phase d'tude fonctionnelle
La phase dtude fonctionnelle a pour but de dfinir pour chaque activit les exigences de
continuit. Il convient pour cela dexaminer les enjeux, didentifier les activits essentielles et
dvaluer les consquences dinterruption ou de dgradation de ces activits (arrt temporaire
ou dfinitif, perte de donnes, dgradation du service). La comparaison de ces diffrentes
situations doit permettre dtalonner les niveaux dimpacts (dfinition du caractre non
supportable dune situation) qui seront utiliss ultrieurement, dans la phase danalyse des
risques.
Ltude fonctionnelle doit galement permettre de prciser les conditions minimales
permettant dassurer un niveau dactivit acceptable en toutes circonstances. Il faut pour cela :
rpertorier les lments du systme dinformation indispensables la poursuite de
lactivit (applications, moyens de communication, informations) ;
prciser par activit le service minimum acceptable :
les applications ncessaires ;
les ressources humaines ;
les locaux ;
les quipements (postes de travail, tlphones, imprimantes, rseau ...) ;
le dlai de reprise dactivit ;
la dure du service minimum ;
le niveau de dgradation du service acceptable (temps de rponse, activits
pouvant tre manuelles...) ;
les conditions de retour la normale ;
les fournitures externes indispensables.
Le recensement sera ralis avec plus de profit en runissant des groupes fonctionnels
reprsentant chaque mtier de lentreprise. Dans ce cas il est ncessaire de procder ensuite
des consolidations et de vrifier la cohrence globale des besoins exprims (une tendance
naturelle conduit souvent les responsables utilisateurs considrer que leur activit est
stratgique). Si ncessaire, un arbitrage sera ralis par la Direction Gnrale. Lorsque les
solutions mettre en oeuvre auront t chiffres, la notion de service minimum acceptable
pourra tre reconsidre (processus itratif).
On dduira de cette phase la liste des applications constituant le noyau stratgique du PSI.
2.2.4 Phase d'tude de vulnrabilit
Comme dans toute tude de scurit, il est ncessaire dvaluer les dispositifs de scurit
actuels ou prvus. Si cette valuation na pas dj t ralise dans le cadre dune tude
globale, il faut au minimum faire une revue des thmes suivants :
lorganisation de la scurit ;
la couverture assurance des risques informatiques ;
la scurit gnrale (environnement, accs physiques, scurit incendie et dgts des
eaux, consignes de scurit) ;
les moyens de secours en place ou prvus (serveurs, rseau, terminaux, alimentation
lectrique, climatisation, fournitures, personnel, ..., selon le champ de ltude). Il est
important ce stade de ltude dapprcier le degr de confiance quil est possible
daccorder ces moyens de secours (les dlais de mise en uvre sont-ils garantis ?,
ces moyens sont-ils documents et tests ?) ;
les moyens de protection des informations stockes :
5
supports informatiques : sauvegardes de recours, archives (accompagns de
procdures de restauration fiables) ;
supports papier (dossiers, archives, documentation, ...) ;
les moyens mis en uvre pour assurer la scurit des changes extrieurs (protection
du rseau, ...) ;
les contrats de maintenance des matriels et des logiciels (vrification du degr
dengagement des prestataires) ;
les contrats fournisseurs pour les fournitures sensibles (garanties de rtablissement de
service en cas dinterruption) ;
les moyens dadministration et dexploitation des systmes (audit des vulnrabilits
des systmes et des applicatifs, suivi des alertes, ...).
Lexamen de ces thmes pourra conduire des mesures prventives visant rduire la
potentialit des risques.
Pour la ralisation de cette tude, on pourra sappuyer utilement sur les questionnaires daudit
des mthodes MARION ou MEHARI.
2.2.5 Phase d'analyse des risques
La phase danalyse des risques a pour objet la classification des risques dindisponibilit
totale ou partielle du systme dinformation et la mise en vidence des priorits dans le
traitement des risques. La ralisation dun plan de secours ou dun Plan de Continuit
dActivit est une opration lourde. La dfinition de priorits peut faciliter sa ralisation par
tranches.
Lanalyse des risques peut tre dcompose en deux tapes :
une tape technique dtude des scnarios de sinistres ;
une tape fonctionnelle dtude dimpact.
Ltude technique consiste, en sappuyant sur le constat de la phase prcdente, rpertorier
pour chaque objet risque un ou plusieurs risques significatifs, puis, pour chaque risque
retenu, tudier et dcrire les consquences directes de sa ralisation sur le systme
dinformation. A ce stade, on ne se proccupe pas encore de limpact du sinistre. Lobjectif
est de raliser un bilan des consquences directes en termes :
de dure dindisponibilit des moyens (applications, services, ...) ;
de perte dinformation (dernires mises jour, flux, archives, ...) ;
de potentialit du risque. Selon la mthode utilise lors de la phase prcdente, la
potentialit sera soit directement attribue, soit calcule.
Ltape fonctionnelle consiste mesurer limpact des risques potentiels laide de critres
dfinis lors de la phase de lancement. Cette valuation doit tre ralise avec le concours de
responsables fonctionnels afin de tenir compte des moyens de contournement existants
ventuels.
Une mesure de gravit est alors dtermine en combinant impact et potentialit (cf. Mthodes
MARION et MEHARI Table daversion des risques). La hirarchisation des risques est
ralise selon leur niveau de gravit dcroissant. Elle permet de prciser les risques prendre
en compte dans le plan de secours ainsi que leur priorit de prise en compte.
Remarque : des fiches guides danalyse des risques sont fournies en annexe de ce document. Elles
proposent des risques types pour chaque famille dobjet risque, avec pour chacun deux des
exemples de consquences analyser et de parades envisager ( ce stade de ltude, on utilisera ces
fiches pour vrifier lexistence ventuelle des parades).
6
2.2.6 Phase d'orientation : cible fonctionnelle et choix des solutions techniques de
secours
La cible fonctionnelle se dtermine par lanalyse de lorganigramme fonctionnel du systme
dinformation et la classification des fonctions et sous fonctions selon les besoins en
disponibilit estims par les directions oprationnelles. Cette classification permettra de
dterminer le noyau fonctionnel stratgique et minimum pour la survie de lentreprise.
Sur la base de scnarios de sinistres, il faudra estimer la dure dinterruption de service
associe chaque fonction vitale, en tentant de les regrouper selon des critres de gravit (4
5 maximum) pralablement dtermins et pouvant aller dune situation de dsastre un
simple arrt du service.
Tous les objets du systme dinformation (applications, matriels, quipements rseaux,
fournitures, ) ncessaires au fonctionnement de ce noyau seront identifis et regroups en
sous ensembles indissociables.
Au regard de ces lments, il sera ds lors possible denvisager et dvaluer des scnarios de
reprise et des moyens de secours appropris pour ramener limpact estim un niveau
acceptable. On sassurera aussi de conserver la cohrence densemble des lments
constitutifs du secours du noyau stratgique. Le dveloppement dinterfaces spcifiques ou la
dfinition de procdures manuelles sont souvent ncessaires pour obtenir le niveau de service
souhait ou dgrad selon les contraintes et les moyens retenus.
Il faudra aussi tablir un plan de circulation des informations et valuer les besoins en
surfaces de bureaux et postes de travail pour permettre aux utilisateurs stratgiques
dassurer le service minimum en situation de crise.
Enfin, pour repartir aprs sinistre, il faudra tudier les moyens pour restaurer et synchroniser
les donnes associes ce noyau fonctionnel.
La dmarche dcrite ci-dessus aboutit au cahier des charges du Plan de Secours Informatique.
7
8
3 LE PLAN DE SECOURS INFORMATIQUE
3.1 Introduction
Aprs laboration du cahier des charges du plan de secours, une tude des solutions doit tre
mene tant sur les aspects techniques que sur les aspects organisationnels. A lissue de cette
tude, un dossier de choix de solutions sera soumis aux instances de dcision afin de dfinir le
contenu dfinitif du Plan de Secours Informatique (les diffrents types de solutions
envisageables seront prsents dans le chapitre 4). A ce stade de ltude, le chiffrage des
solutions peut conduire un ajustement des moyens demands.
Un plan de prparation sera alors excut pour la mise en place des solutions retenues. Ce
plan comporte les phases dtude dtaille, de mise en place, de test et de formalisation des
procdures oprationnelles. Lensemble de ces solutions et de ces procdures constituent le
plan dexcution activ en cas de sinistre.
Le plan de prparation pourra avec profit faire lobjet dun tableau de bord, dsignant les
responsables des actions, et en mesurant lavancement.
Lobjet de ce chapitre est de prciser les principaux thmes traiter au cours du plan de
prparation. La documentation produite dans cette phase constituera le Plan de Secours
Informatique.
3.2 Organisation
Les diffrentes tches de pilotage et de mise en uvre du secours doivent tre affectes des
acteurs . Ces acteurs sont des entits oprationnelles prdfinies composes de personnes
en nombre suffisant, de manire ce que, en cas de sinistre, la ralisation de la tche soit
garantie.
Les premiers intervenants sont chargs dappliquer les consignes et de donner lalerte, selon
les procdures descalade dfinies.
En cas de sinistre, on distinguera ensuite :
le comit de crise ;
la cellule de coordination ;
les quipes dintervention ;
les services utilisateurs.
On dsignera galement par structure de crise lensemble Comit de Crise-Cellule de
Coordination.
3.2.1 Le Comit de Crise
Le comit de crise doit tre compos au minimum des Directions suivantes : Direction
Gnrale, Principales Directions utilisatrices, Direction des Services Gnraux et des
Ressources Humaines, Direction Informatique, Direction de la Communication, Responsable
du Plan de Secours. Le comit de crise prend les principales dcisions concernant le secours.
Il juge en particulier de lopportunit de dclencher tel ou tel volet du Plan de Secours
Informatique, en fonction du contexte. Le Comit de Crise peut se faire assister de
comptences spcifiques, internes ou externes, notamment pour la communication et les
aspects juridiques.
Des moyens de communication avec le comit de crise doivent tre prdfinis et garantis en
cas de sinistre (lieu de runion, numros de tlphone, de fax, ...).
9
3.2.2 La Cellule de Coordination
Le pilotage proprement dit des oprations de secours peut tre confi une cellule de
coordination, qui dchargera le comit de crise de tches de coordination.
La cellule de coordination sera idalement compose dun petit nombre de personnes : le
Responsable du Plan de Secours Informatique (personne matrisant lensemble du Plan) et les
personnes charges de la coordination des oprations informatiques et de la logistique.
Certaines dcisions peuvent tre dlgues cette cellule de coordination par le comit de
crise, notamment lanticipation du dclenchement de certains dispositifs (exemple :
rservation du site de secours chez un prestataire).
3.2.3 Les quipes dintervention
La ralisation des tches de secours incombe aux quipes dintervention dfinies selon les
comptences requises, la disponibilit et le lieu dintervention. On devra sassurer que les
contrats de travail sont compatibles avec un dplacement des quipes concernes sur un autre
site.
Exemples :
quipe logistique charge du transport des matriels ;
quipe dintervention informatique, compose dun spcialiste rseau et dun agent de
maintenance, charge des oprations sur le site de secours ;
quipe charge de la communication de crise ;
quipe dintervention rseau charge du paramtrage rseau sur le site de secours des
utilisateurs ;
etc.
Notons enfin que certains acteurs externes lentreprise doivent galement tre identifis :
prestataire de secours, fournisseurs dnergie, oprateur tlphonie, fournisseur daccs
Internet,
Lensemble des intervenants internes et externes avec leurs coordonnes doit tre rpertoris
dans un annuaire du plan de secours tenu jour.
3.2.4 Les services utilisateurs
Les services utilisateurs prennent en charge leur propre plan de reprise dactivit en fonction
des moyens de secours mis leur disposition. Parmi les tches qui incombent aux
responsables de ces services, on notera :
les tches dattente du secours ;
lorganisation du redmarrage (normal ou dgrad) ;
la mise en place de procdures de contournement ventuelles ;
lorganisation de travaux exceptionnels (exemple : rattrapages).
Il est important de sassurer que des comptences humaines seront bien disponibles en toutes
circonstances et connaissent les procdures techniques suivre dans le contexte du systme de
secours. Si besoin, il est possible de sappuyer sur des comptences des intervenants externes,
qui ont dj particip des tests de continuit prcdents.
10
3.3 Dclenchement
Evnement
Procdure descalade
Convocation
Structure de crise
Runion
Structure de crise
Activation du PCA
Invoquer ?
Dlai de dcision
rassembler plus
dinformation
Pas dinvocation Non
Oui

Figure 2 : Dclenchement
La structure de crise est compose du comit de crise et de la cellule de coordination.
Les procdures descalade sont essentielles. Lorsquun incident survient, la personne
informe qui est souvent un poste de scurit de lentreprise doit savoir qui contacter et
comment contacter (notamment en cas dindisponibilit des moyens habituels de
communication). Cette personne doit son tour, selon le type et la gravit de lincident,
connatre les personnes contacter pour avoir des prcisions ou bien mobiliser la structure de
crise. Il est important de dfinir lavance qui est habilit activer la structure de crise et
surtout nappeler que les personnes strictement dsignes afin dviter un encombrement
inutile des lignes.
3.4 Les dispositifs de secours
Un plan de secours est compos de dispositifs lmentaires (procdures techniques ou
organisationnelles) dont lactivation dpendra de lvnement survenu et du contexte gnral.
Le dclenchement de certains dispositifs ou leurs modalits dexcution peuvent en effet
dpendre de nombreux lments (exemple : la communication de crise).
Les dispositifs dun plan de secours peuvent tre classs par types dactivit :
la mobilisation des ressources ncessaires :
ressources humaines : mobilisation des quipes dintervention ;
rservation des moyens de secours (rquisition de moyens, alerte dun prestataire
externe, ...) ;
11
rcupration des sauvegardes ;
rcupration de la documentation ;
le secours des quipements informatiques :
restauration des environnements systme ;
adaptations techniques (le matriel de secours nest pas toujours identique au
matriel dorigine) ;
restauration des applications ;
validation des restaurations ;
le secours des rseaux :
mise en place des quipements de secours ;
basculement sur liaisons de secours ;
paramtrage des diffrents quipements ;
le secours de la tlphonie :
reroutage des appels ;
mise en place dquipements de secours ;
paramtrage ;
la reprise des traitements :
adaptations logicielles ;
adaptation des procdures dexploitation ;
rcupration de flux et synchronisation des donnes ;
traitements exceptionnels ;
validations fonctionnelles ;
la logistique :
transports ;
fournitures ;
gestion de crise du personnel (choix des personnels mobiliser, rotation des
quipes, prise en compte des situations individuelles , ...) ;
le relogement :
organisation du relogement durgence ;
prparation des sites daccueil ;
la reprise des activits des services utilisateurs :
tches utilisateurs avant mise en place des moyens de secours ;
organisation dun service minimum ;
travaux exceptionnels (procdures de contournement, rattrapages, ...) ;
la communication de crise :
interne (personnel, autres entits, ...) ;
externe (clients, partenaires, public, ...) ;
les dispositifs de post-reprise :
dispositifs pralables et daccompagnement (assurance, remise en tat des locaux,
sauvetage des matriels, ...) ;
dispositifs de retour la normale (constituent un plan spcifique).
12
Pour tre oprationnels, ces dispositifs de secours doivent tre accompagns de dispositifs
permanents destins les maintenir niveau (exemples : le plan de sauvegarde, les
procdures de mise jour et de formation des acteurs du PSI, ...).
3.5 Documentation
La documentation constitue un lment essentiel dun plan de secours. Elle est en gnral
assez volumineuse et trs volutive (nouvelles affectations de personnel, volution de
configurations, nouvelles applications, ...). Pour toutes ces raisons, il est conseill de grer la
documentation laide dun outil spcialis dans la gestion de plans de secours ou de plans de
continuit dactivit. On veillera galement la confidentialit de ces documents, susceptibles
de contenir des informations stratgiques de lentreprise et nominatives.
La documentation dun plan de secours peut tre structure en 4 niveaux, selon lobjectif
vis : communiquer, mettre en uvre, grer, contrler.
3.5.1 Les documents de communication sur le plan de secours
La communication interne sur le plan de secours ne doit pas tre nglige. Elle doit permettre
aux diffrents responsables davoir une bonne vue densemble des solutions prvues et de
leurs conditions gnrales de mise en uvre. Cette documentation inclura notamment :
un rappel des objectifs de continuit de service ;
une description gnrale des diffrents dispositifs du plan de secours (secours des
quipements informatiques, secours des tlcommunications, solutions de relogement,
communications de crise, ...) ;
une description gnrale de la structure de crise ;
les principes dalerte de la structure de crise et de pilotage des oprations ;
un rappel des risques rsiduels.
3.5.2 Les documents de mise en uvre du Plan de secours
Ces documents constituent le cur du plan de secours. Ils sont destins aux personnes ayant
la responsabilit des diffrents dispositifs du plan et dcrivent tous les lments utiles leur
mise en uvre : procdures, documentation technique, lments de synchronisation,
contrats, La documentation technique devra, par son niveau de dtail, permettre de rduire
les erreurs humaines lies au stress.
Concrtement, cette documentation comportera au minimum :
un annuaire du plan de secours, rpertoriant tous les intervenants potentiels, internes
ou externes, avec leurs coordonnes ;
une description de la stratgie de secours retenue pour chaque risque identifi. Ce
document est destin la structure de crise pour laider dans ses dcisions. La stratgie
de secours dfinit lensemble des dispositifs de secours dclencher selon le contexte
de lincident (type dvnement, tendue des dgts, ...) ;
le planning des diffrentes phases de reprise ;
les fiches de tches raliser, structures par acteur et / ou dispositif de secours ;
la feuille de route de chaque acteur du plan, pour chaque cas rpertori ;
lensemble des annexes utiles (documents de procdures, documentation technique,
copies de contrats, schmas, ...).
Associe un outil de pilotage, cette documentation permettra galement la structure de
crise le suivi du droulement des oprations.
13
Un exemplaire de cette documentation (papier et / ou outils de gestion du plan) sera conserv
lextrieur de lentreprise, dans un lieu scuris dont laccessibilit doit tre compatible avec
les objectifs de redmarrage.
3.5.3 Les documents de gestion du plan de secours
Pour la gestion du plan de secours, il convient dtablir une documentation complmentaire
destine aux responsables du plan et des dispositifs associs. Cette documentation a pour but
de faciliter les volutions ultrieures. Elle peut tre constitue de tableaux danalyse des
ressources et de leur utilisation, de listes de diffusion des documents. Elle inclut galement
lhistorique des rsultats de tests et les plans dajustement conscutifs.
3.5.4 Les documents de contrle du plan de secours
Tableaux de bord :
Planning de tests ;
Compte-rendu dtaill des tests ;
Indicateurs de qualit des dispositifs et du plan ;
Evaluation des risques rsiduels.
3.6 Maintenance du plan
3.6.1 Organisation
Un responsable du plan de secours sera nomm. Il aura pour missions principales :
effectuer, suivre et grer les tests et les modifications qui en dcoulent
engager et suivre le processus dactualisation du plan de secours en fonction de
lvolution des risques (nouvelles menaces, nouveaux projets, nouvelles technologies,
) ;
maintenir, scuriser et diffuser la documentation du plan de secours.
Des circuits dinformations seront mis en place afin quil ait connaissance :
des nouveaux risques ;
des volutions techniques et structurelles ;
des nouveaux projets.
Un comit plan de secours compos des responsables des diffrents dispositifs et des
responsables des moyens techniques (informatique, Services gnraux) sera runi
rgulirement (au moins 2 fois par an ). Ce comit anim par le responsable du plan, aura la
charge dvaluer les nouveaux risques et de proposer un plan dactions qui traitera de :
la mise en uvre des moyens de scurit ;
lactualisation de la documentation ;
lvolution ventuelle du contrat avec le prestataire ;
les tests des nouveaux secours.
Le responsable du plan assurera la coordination de lensemble de ces actions.
3.6.2 Outils
Un plan de secours est la fois complexe (il est compos de nombreux dispositifs destins
faire face toutes sortes de situations), et trs volutif (changements dorganisation,
dactivits, denjeux, de personnes, darchitectures techniques, dapplications, ...). Sa gestion
laide dun simple outil de traitement de texte est illusoire.
14
La maintenance dun plan de secours est grandement facilite par lutilisation dun outil
spcialis. On recherchera notamment dans cet outil les fonctionnalits suivantes :
la gestion complte de la documentation de mise en uvre de chaque dispositif
constitutif du Plan ;
la gestion des ressources ncessaires la mise en uvre des dispositifs ;
la production du planning des oprations de reprise, selon la situation traiter ;
la gestion des tests (planification, suivi des rsultats, mesure defficacit du plan, ...) ;
la gestion des stratgies de secours, en fonction des types de sinistre et de leur gravit ;
la production dindicateurs de qualit et defficacit des diffrents dispositifs et du
plan global ;
les modes de diffusion de la documentation (listes de diffusion automatises, intranet,
...) ;
le contrle de la mise jour rgulire de la documentation.
On prfrera un outil sappuyant sur une base de donnes et qui facilitera ltude dimpact des
volutions (recherche des tches qui incombaient une personne mute, identification des
dispositifs impacts par un changement applicatif, recherche des scnarios de sinistre revoir
suite un dmnagement de service, ...).
3.7 Plan de test
Le Plan de Secours Informatique doit tre valid par un plan de test permettant en premier
lieu de rceptionner chacun des dispositifs de secours, leur synchronisation, et ensuite de
contrler par des tests rguliers, plus ou moins proches de situations relles, le caractre
oprationnel du plan de secours.
Trois catgories de tests sont distinguer :
les tests techniques unitaires : ces tests techniques sont destins valider un lment
du secours (par exemple le secours dun serveur) : validation de la configuration de
secours, validation des procdures et des dlais, validation du choix des intervenants,
validation de la documentation ;
les tests dintgration : les tests dintgration doivent permettre de valider la
compatibilit des diffrents lments de secours, la synchronisation des oprations
techniques et la charge des diffrentes quipes ;
les tests en vraie grandeur : ce dernier type reprend les caractristiques des tests
dintgration avec comme objectif supplmentaire un test de ractivit des quipes et
une vrification de bon fonctionnement par un travail effectif dutilisateurs dans des
conditions proche dune situation de crise (moyens rduits, documentation absente ou
rduite, ...). Les tests en vraie grandeur ne pourront tre excuts que si les tests
dcrits prcdemment sont russis. Ils peuvent constituer un risque pour lactivit quil
convient dvaluer pralablement. Ces tests pourront tre blanc (travail des
utilisateurs en parallle sur des copies jetables des applications de production), ou tre
rels et prvoir dans ce cas la fin du test lintgration du travail effectu dans les
bases de production. Les tests en vraie grandeur permettent galement de tester le
pilotage des oprations (structure de crise et outils de pilotage). Les tests en vraie
grandeur pourront tre impromptus (au moins vis vis des quipes dintervention).
15
Dans le cadre du plan de test on sassurera que chaque anne les dispositifs les plus critiques
du Plan de Secours Informatique font lobjet dun ou plusieurs tests. Le nombre de tests
dintgration ou en vraie grandeur conseill est de 1 2 par an. Les tests techniques unitaires
seront raliss priodiquement (1 fois par trimestre) et systmatiquement aprs toute volution
de lquipement secourir ou aprs toute modification concernant le dispositif de secours.
Pour chaque test, on ralisera les oprations suivantes :
la formalisation des objectifs viss ;
la description du scnario de test : prparation, simulation, cas tests, modalits de
tests utilisateurs, travail blanc ou rel, modalits de validation, ;
la prparation du test : rservation des moyens techniques et humain, prsentation et
validation des tches et du planning (sauf si test impromptu), remise de
documentation, ;
la dsignation dun ou plusieurs observateurs chargs de suivre le droulement des
oprations et de noter les problmes rencontrs ;
la rdaction dun compte-rendu de test et dun bilan permettant de prononcer la
validation de tout ou partie du plan de secours et proposant les actions correctives
ncessaires.
16
4 LES SOLUTIONS DE SECOURS
4.1 Les solutions de secours informatiques
La solution globale est la rsultante de plusieurs solutions adaptes en fonction des exigences
de reprise demandes et des pertes de donnes acceptes par les utilisateurs. Chacune dentre
elles tant la combinaison dun certain nombre dattributs qui peuvent globalement tre
regroups en 3 grandes classes :
a. le mode de gestion contractuelle des moyens de secours (comment les conditions de
dclenchement et de mise disposition sont-elles formalises ? Comment sont gres les
priorits dans le cas de moyens mutualiss) ;
b. le type de moyens mis en uvre (moyens fixes ou mobiles, locaux ou distants, ) ;
c. le niveau de prparation et de disponibilit des moyens (les moyens sont-ils prts
lemploi , ou ncessitent-ils des prparations complmentaires ?) et les limites
dutilisation des moyens de secours (les moyens mis en uvre ont-ils une limitation dans
le temps, pour des raisons contractuelles, techniques, de performances, de monte en
charge, ?).

Par le terme combinaison , on entend quil existe un nombre important de solutions
rsultant de lassociation des diffrentes valeurs possibles pour ces attributs. Par exemple,
dans une situation donne, la solution optimale peut tre :
Gestion =accord contractuel avec fournisseur externe pour des moyens mutualiss
Moyens =container mobile
Etat de Disponibilit =matriel oprationnel sans fichiers

Dans un autre cas de figure, cest la solution suivante qui peut tre la mieux adapte :
Gestion =interne, avec des moyens ddis
Moyens =installation fixe sur site interne distant
Etat de disponibilit =configuration miroir
Il est cependant important de noter que toutes les solutions dignes de confiance ncessitent
des investissements (matriels et immatriels) et des dpenses permanentes en temps normal.
Cest dangereux de croire que lon pourra attendre le jour du sinistre pour dfinir prcisment
et mettre en place une solution de secours. De la mme faon quil nexiste pas et nexistera
jamais dassurance du lendemain , il est totalement illusoire de penser que lon trouvera
toujours, au pied lev, un fournisseur, ou une relation qui pourra dpanner au moins
quelques temps , et que cela ne dpend que du prix que lon est alors prt payer.
Les scnarios de solutions labors dans la phase Orientation de la dmarche
dlaboration dun Plan de Secours Informatique (cf. 2.2.6.) sont constitus dun ensemble
de dispositifs destins assurer la continuit de la chane informatique ncessaire aux
activits stratgiques, pour un ensemble dfini de risques.
Dans un contexte dinformatique rpartie, le scnario retenu sera le plus souvent constitu
dun ensemble de solutions techniques et / ou organisationnelles qui seront combines selon la
situation. Ces solutions lmentaires seront des solutions de secours propres diffrents
domaines tels que :
le rseau local ;
les accs rseau externes ;
17
le cas particulier des accs Internet ;
le secours de serveurs stratgiques devant assurer un service 24h / 24 ;
le secours de serveurs pouvant supporter une indisponibilit de 24h ;
le secours de la fonction tlphonie ;
le secours dun call-center ;
le secours dun plateau utilisateurs ;
etc.
De trs nombreuses solutions de secours sont possibles, stageant de la mise en place et de
lexploitation permanente dinstallations compltement dupliques, jusqu la conclusion plus
ou moins formelle daccords daide rciproque entre socits.
On sassurera de la cohrence globale des choix raliss pour chacun de ces sous-systmes. Il
est notamment ncessaire, avant validation du scnario retenu de solution, de faire une
analyse des risques rsiduels afin dune part de vrifier que les risques qui devaient tre traits
le seront effectivement et que les solutions envisages ninduisent pas de nouveaux risques
inacceptables.
Les critres dvaluation dune solution de secours peuvent tre classs en deux groupes.
A - Les critres permettant de vrifier quun scnario de solution rpond aux besoins
exprims dans le cahier des charges du plan de secours :
le dlai de reprise : le dlai total de reprise est la somme des dlais de dclenchement,
temps de mise en uvre (approvisionnement, restauration, tests, ...), et temps de re-
synchronisation des donnes. Ce facteur, ainsi que la dure maximale de disponibilit
des installations de secours sont des paramtres essentiels pour calculer les pertes
dexploitation rsiduelles ventuelles, donc lefficacit de la solution. Une attention
particulire devrait tre porte aux dlais de dtection et de prise de dcision, afin de
les minimiser ;
le degr de fracheur des donnes remises disposition des utilisateurs ;
le degr de couverture : la solution envisage permet-elle de couvrir les risques
retenus ? Quels sont les risques rsiduels non traits ? La solution est-elle utilisable
hors sinistre (dmnagement, conversion, ...) ?
B - Les critres permettant dvaluer les avantages et inconvnients des scnarios envisags :
la vraisemblance de la solution : une solution peut paratre viable et digne de
confiance un moment donn, mais la garantie de sa disponibilit et de son volution
dans le temps paralllement celle des besoins de lentreprise nest pas acquise. En
outre certaines solutions doivent tenir compte de possibilits daccumulation de
risques gographiques, sectoriels, - et enfin, la ralisation de tests ralistes
rguliers est un facteur dterminant et une preuve de vraisemblance (ou
dinvraisemblance !) ;
la souplesse de mise en place du Plan de Secours Informatique : il est souvent
difficilement envisageable de traiter rapidement tous les risques inacceptables. Une
solution souple permettra de construire le plan de secours de manire modulaire, par
tranches, et permettra ainsi de sadapter diffrentes contraintes (budget, disponibilit
des ressources internes, synchronisation avec dautres projets de lentreprise,
acquisition du savoir-faire, degr de maturit du march, ...) ;
lvolutivit de la solution : traduit sa capacit prendre en compte les volutions au
sein de lentreprise (architecture technique, organisation, enjeux, nouveaux risques,
...) ;
18
les cots : chaque type de solution entrane un cortge de frais fixes, variables,
rcurrents :
les cots de prparation (mise en place) de la solution ;
les abonnements et contrats divers ;
les cots ultrieurs de maintenance et de ractualisation de la solution (tests,
volutions des configurations, charge dexploitation supplmentaire,
consommations...) ;
les cots dutilisation de la solution (une partie de ces cots peut tre prise en
charge par une assurance).

Le dveloppement ci-dessous va passer en revue les diffrentes typologies de solutions de
secours pour chacun des attributs mentionns au dbut, ainsi que leur adquation aux critres
qui viennent dtre dfinis.
4.1.1 Typologie et modes de gestion des moyens de secours
A Typologie des solutions de secours
Trois grands types de solutions sont habituellement rencontrs, faisant appel soit des
moyens internes, soit des moyens externes lentreprise :
Accords de rciprocit (entre sites dune mme entreprise ou entre entreprises
diffrentes) :
Si ce type de solution est trs attirant sur le plan financier (il sagit souvent daccords
gracieux), il est dans la plupart des cas totalement illusoire sur le plan de la vraisemblance
et de lefficacit, notamment depuis la gnralisation des traitements interactifs :
difficults de suivi et de synchronisation de lvolution des parcs informatiques des
partenaires , invraisemblance du maintien permanent dune surcapacit dans chacun
des sites, sous-estimation des problmes de conflits de priorits et dintrts risquant de
natre au moment du sinistre, graves problmes juridiques potentiels de validit des
pouvoirs des signataires et de transfert et de limitation de responsabilits en cas de non-
respect des engagements, quasi-impossibilit de faire des tests, oubli ou sous-estimation
des problmes de logistique dans lespace et le temps (accueil utilisateurs, connectique,
...).
Pour les mmes raisons, et du fait de labsence de professionnalisme, les notions de dure
de mise disposition et de temps de mise en uvre sont immatrielles, car pouvant tendre
respectivement vers zro et linfini sous la pression de la ralit.
La capacit couvrir dautres cas que des sinistres est en gnral nulle, du fait de la
probabilit deffets de cascade.
Compte tenu de lvolution de la complexit des architectures des systmes
dinformation, ce type de solution nest envisageable que dans des cas trs particuliers et
ne peut tre que partielle.
Appel des moyens de secours partags (ventuellement spcialiss) :
Dans ce cas, plusieurs entits prvoient de pouvoir avoir recours un mme ensemble de
moyens pouvant tre ddis usage de secours. Les modalits de gestion possibles seront
examines au paragraphe suivant. En temps normal, ces moyens peuvent tre affects
dautres tches non prioritaires permettant de leur confrer une certaine rentabilit
19
(service bureau non rptitif, mise au point dapplications, banc dessai ou de simulation,
dmonstrations, ).
La vraisemblance de la solution est acceptable si on est attentif matriser le nombre
dentits partageant les structures, lhomognit des niveaux de prvention en place chez
les partenaires, la non-accumulation de risques sectoriels, et la qualit des tests.
Le cot de ce type de solution varie suivant le degr de mutualisation des installations, et
des possibilits de rentabilisation : comme cette dernire peut tre alatoire (puisque les
installations ne peuvent abriter que des activits non prioritaires), le cot peut tre dj
significatif (plusieurs pourcents du cot dacquisition des moyens mis en uvre).
La protection vis--vis de sinistres rsultant derreurs ou de malveillances logiques peut
mme tre envisage si la structure de secours dispose dtalons anti-virus ou est
alimente partir de sauvegardes prpares selon des procdures THS (Trs Haute
Scurit).
Elles ne sont cependant pas acceptables dans les cas o il est impratif que les moyens de
secours ne soient pas mutualisables en cas de sinistre (puisque par dfinition, dans le cas
de moyens partags, le risque de collision de besoins nest jamais nul). Elles ne
doivent donc pas tre retenues dans le cas dentits soumises des astreintes de service,
o lorsque les risques rsiduels ne peuvent pas tre transfrs aux assurances.
Limitation contractuelle : dans le cas de moyens partags, le prestataire (surtout sil est
extrieur lentreprise) peut avoir dfini une dure limite de mise disposition, de faon
borner ses risques dappels simultans aux mmes ressources.
Appel des moyens ddis (ventuellement spcialiss) :
Dans cette catgorie, on considre que chaque entit dispose dun environnement quelle
est la seule pouvoir rquisitionner en cas de sinistre. Ceci nexclut pas que les
installations soient affectes dautres tches non prioritaires en dehors des situations de
crise.
Cette solution reprsente la version optimale en matire de vraisemblance, puisque lon
peut pr-dfinir avec certitude la disponibilit, les dlais de mise en uvre, et les niveaux
de dgradation fonctionnels ; en outre, il est ais de conduire des tests frquents, et
lutilisation des infrastructures est possible pour rsoudre des cas dindisponibilit ne
rsultant pas de sinistres matriels.
Le seul inconvnient est en gnral le cot de cration et dentretien de telles
infrastructures. Ce type de solution est en gnral rserv des besoins de haute
disponibilit, ou rendu ncessaire par la spcificit des quipements.
Limitation logistique : les moyens mis en uvre, notamment au niveau des infrastructures
de repli doivent tre acceptables, y compris en cas dutilisation prolonge du site de
secours.
B Modes de gestion des moyens de secours
On distingue gnralement 4 mthodes de gestion des solutions de secours, selon leur degr
de formalisation et dexternalisation :
Gestion formelle externe :
Dans ce cas, il est prvu dobtenir les moyens de secours auprs dune entit extrieure
lentreprise, soit auprs dune socit spcialise, soit auprs dune autre entreprise
garantissant de dgager et / ou mettre disposition une capacit de traitement adquate au
moment dun sinistre ; les relations entre demandeur(s) et fournisseur(s) sont rgies par
20
des accords contractuels prcis (en termes de services devant tre fournis et de
manquements aux engagements) et tests rgulirement (voir la fiche Contrat ).
Il est possible dans ce cas de garantir raisonnablement un bon niveau de vraisemblance, et
de bien cerner les paramtres de dlais et dures.
La vraisemblance est notamment bien mise en valeur par la conduite rgulire des tests
contractuels. Il est noter que les points dlicats se trouvent au niveau :
des clauses de limitations de responsabilits du fournisseur, si celui-ci est amen
faillir sa mission du fait de conflits de priorits ou de problmes techniques ;
de la capacit du fournisseur sadapter rapidement aux volutions
technologiques ;
du maintien de la scurit du S.I., notamment dans le cas de moyens partags.
Il est en outre possible, dans la plupart des solutions appartenant cette catgorie, de
couvrir des risques lis des conflits sociaux.
Gestion formelle interne :
Ici, les solutions de secours sont internes lentreprise (vs. prestataire externe), et sont
rgies, comme ci-dessus, par des contrats de service prcis et testes rgulirement.
Les avantages de ce type de solution rsident dans la souplesse de ladquation aux
besoins, dutilisation et dvolution.
Au niveau des cots, il est difficile de prjuger de lintrt de cette solution par rapport
la prcdente, dans la mesure o dune part elle comporte certains lments de rduction
des cots (conservation des investissements en interne, effets dchelle sur des
infrastructures existantes), mais qui peuvent tre annuls par des lments contraires (cot
de la phase dapprentissage, difficult maintenir le niveau doprabilit de la solution,
ncessit de ddoubler les investissements en cas dvolution matrielle divergente des
sites, ).
La couverture de risques sociaux est en gnral plus difficile avec ce type de solutions et
on doit souvent craindre une propagation des problmes.
Gestion formelle mixte (type GIE) :
Ici, les solutions de secours sont partages entre plusieurs entits ayant une communaut
dintrt, dans un cadre lgal et contractuel prcisant parfaitement les conditions du
partage des cots et des moyens.
Les avantages fonctionnels de ce type de solution sont nombreux (cot global, adquation
de la solution, utilisation pour des tches non prioritaires, ), mais la mise au point
contractuelle est en gnral dlicate (comportement en cas de conflits de priorit, gestion
des besoins spcifiques et des cas dvolutions divergentes des entits membres, risque
daccumulation de risques sectoriels, admission et retrait de membres, imputation et
proprit des investissements, gestion de la phase transitoire de cration, attribution des
responsabilits danimation du groupe et dadministration des moyens, ).
Pour maintenir la vraisemblance de la situation (notamment au niveau de la conduite des
tests, de ladministration des moyens, et de la gestion des obsolescences), ces structures
confient gnralement la gestion des moyens de secours des socits spcialises dans
ce domaine.
21
Gestion informelle (interne ou externe) :
Dans ce cadre, les solutions de secours (quelles soient internes lentreprise ou attendues
dune entit externe) sont supposes tre disponibles en dehors de tout cadre contractuel
srieux : les hypothses relatives aux dlais de mise en uvre, aux dures de mise
disposition, aux comptabilits matrielle et logicielle, aux limitations de responsabilit, ...,
ne sont pas documentes et / ou contresignes par les diffrentes parties concernes.
Ce type de gestion peut induire des risques juridiques importants, des perturbations
majeures sur le site daccueil, de grandes difficults de mise en uvre et de test.
A lheure des rseaux, de linformatique rpartie et du caractre de plus en plus
stratgique des moyens informatiques et de communication, la gestion informelle doit tre
proscrite.
4.1.2 Type de moyens mis en uvre
Un Plan de Secours Informatique doit permettre de traiter la fois des incidents techniques et
des sinistres majeurs. Le tableau suivant prsente un ensemble de solutions considrer,
locales et externes, selon le niveau dexigence de disponibilit du S.I.
Ces solutions sont dveloppes dans la suite du chapitre.
22

Haute Disponibilit Moyenne Disponibilit Faible disponibilit
Sous-systmes

Reprise immdiate ou quasi-immdiate
(quelques minutes).
Perte de donnes trs limite.
Secours en quelques heures (moins de 12
heures).
Perte de donnes limite (quelques minutes
quelques heures).
Secours en 48 heures ou plus.
Perte de donnes en gnral infrieure
24 heures.
Serveurs stratgiques Serveurs de secours ddis,
gographiquement distants, internes ou
externes, en fonctionnement (applications et
donnes).
Architecture haute disponibilit : solutions de
type load balancing, cluster de serveurs,
mirroring (applications et donnes).
Serveurs de secours ddis,
gographiquement distants, internes ou
externes, interconnects avec les serveurs
secourir.
Systme prt fonctionner, de type : mirroring
distant o copie distante des mises jours et
mise niveau priodique des bases de
donnes de secours.
Moyens de secours gographiquement
distants, internes ou externes et pouvant
tre mutualiss.
Rseau local Redondance des quipements.
Matriels et rocades de secours avec bascule
automatique.

Matriels et rocades de secours.

Kit de cblage volant
Existence de locaux de secours
utilisateurs externes pr-cbls et pouvant
tre quips rapidement (postes de
travail, fournitures, ...).
Accs rseaux externes (voix,
images et donnes)
Au moins deux arrives externes spares, si
possible sur deux sites distincts et via des
oprateurs diffrents.
Basculement des communications sur le site de
secours en cas de sinistre, avec un maximum
dautomatismes.
Maillage du rseau dentreprise.
Nud de secours externe avec basculement
automatique ou manuel (paramtrage).
Contrat prvoyant lintervention de loprateur
pour une remise en tat des liaisons dans un
dlai dtermin.
Matriels de secours.
Engagement dintervention du fournisseur
avec obligation de rsultats.
Transfert des appels par le fournisseur
vers un site de secours.

Tlphonie (quipements) Secours de lautocommutateur, si possible dans
un local loign et basculement automatique
des communications.

Contrat prvoyant le transfert des appels par
le fournisseur vers un site de secours prt
prendre les appels (quipements
tlphoniques et humains en place).
Autocommutateur de secours.
Transfert des appels par le fournisseur
vers un site de secours.
Mise en place dun message pr-
enregistr.

Cas particulier des accs
Internet (site web)
Double connexion Internet sur chaque site
(site principal et site de secours) avec des
fournisseurs daccs diffrents.
Le basculement peut alors tre automatique
grce la mise jour des DNS et / ou politique
de peering entre les fournisseurs daccs.
Connexion Internet sur le site de secours avec
basculement manuel des connexions du site
principal vers le site de secours par mise
jour des DNS notamment.
Connexion Internet sur le site de secours
avec basculement manuel des connexions
du site principal vers le site de secours
par mise jour des DNS notamment.

23
Avant mme de dfinir les moyens informatiques mettre en uvre, il y a lieu dexaminer le
type dinfrastructure dans ou partir de laquelle ils doivent oprer. Quatre grandes familles
peuvent tre considres :
Installations fixes :
Deux cas dutilisation sont envisager :
soit un (ou plusieurs) site informatique distant intgr la production et capable
dassurer lui seul le secours chaud des moyens informatiques ;
soit un (ou plusieurs) site distant en attente dutilisation en cas de sinistre.
Site informatique distant intgr la production et capable dassurer lui seul le secours
chaud des moyens informatiques :
Cette solution correspond au besoin de haute disponibilit et aux contraintes de temps rel
sans perte de donnes. Elle conduit au doublement dquipements informatiques, mais
elle allge considrablement les procdures de reprise dactivit en cas de sinistre. Son
cot doit tre apprci dans sa globalit.
Le choix de larchitecture dpend des objectifs en termes de dlais de reprise des activits
et de fracheur des donnes.
Quelle que soit larchitecture, ces solutions supposent de disposer dune copie des
donnes sur les quipements de secours et de serveurs prts fonctionner, cest dire
sous tension, et avec les applications.
Ce qui diffrenciera les diffrentes architectures possibles, cest :
la frquence de mise jour de la copie distante des donnes (cf. la rplication,
4.4.2), qui peut tre immdiate ou diffre de plusieurs minutes ou plusieurs
heures ;
la participation ou non des quipements du second site la production. Cette
participation peut tre ralise soit par rpartition de la charge dune mme
application sur les deux sites, ce qui suppose un mirroring intgral des donnes
entre les deux sites, soit par rpartition des applications en production sur les
deux sites, chaque application disposant dune copie en attente sur lautre site. Ce
dernier cas est techniquement moins complexe que le prcdent et supporte une
rplication diffre.
La compltude de la solution est troitement lie aux capacits des systmes
dexploitation, des systmes de gestion de bases de donnes et des applicatifs.
Site distant en attente dutilisation en cas de sinistre :
Cest la solution la plus traditionnelle ; dans le cas dun dclenchement, un certain
nombre des personnels de lentit sinistre (informaticiens et ventuellement utilisateurs)
se dplace sur le site de secours pour y soumettre les transactions et effectuer les
traitements. Ce type de solution possde priori des moyens de tlcommunications
relativement limits, et exclut notamment la connexion distance des terminaux habituels
(les solutions bases sur des tlcommunications sophistiques sont examines au
paragraphe suivant).
Ces solutions entranent des consquences ngatives importantes au niveau de
lorganisation du travail des quipes dexploitation (dplacements, clatement possible
des quipes, modification des flux dentres / sorties, loignement des archives et
documentations), et ne peuvent en gnral se concevoir raisonnablement que si le centre
de secours est peu de distance du site protger (ce qui entrane une fragilit vis--vis
de risques sectoriels).
24
Sites de secours utilisateurs :
Le plan de secours utilisateurs est dfinir dans le cadre dun Plan de Continuit
dActivit et nentre pas de ce fait dans le champ de ce document consacr au Plan de
Secours Informatique (PSI). Cependant, lors du choix du site de secours informatique, il
convient de prendre en compte les possibilits daccs des sites susceptibles dhberger
des utilisateurs.
Dans le cas o ltude du Plan de Secours Informatique sinscrit dans un projet plus large,
les choix raliss pour lhbergement des utilisateurs peuvent avoir un impact sur la
rpartition de certains matriels de secours, entre le site ddi au secours informatique et
celui ou ceux prvus pour les utilisateurs (notamment pour des raisons de performances).
Moyens mobiles :
Dans ce type dorganisation, on prvoit de transporter et dinstaller, aprs la notification
du sinistre, linfrastructure daccueil informatique, soit auprs du site sinistr, soit
proximit dun autre site de repli (que celui-ci ait t planifi ou non).
Les solutions consistent habituellement soit en des structures de type container
modulaires, soit en des units de type gonflables, quipes dans les deux cas (en standard
ou en option) de matriels de conditionnement dair et de courant, de dispositifs de
scurit, de moyens de pr-cablage, ... Elles peuvent tre ou non livres peuples avec
des moyens de traitement.
Les avantages de ce type de solution tiennent leur souplesse dadaptation en fonction
des conditions relles du sinistre, et la limitation des perturbations au niveau des
utilisateurs, des quipes informatiques (qui restent proches de leur point dattache et des
utilisateurs), et des circuits dentres / sorties des informations ; en outre, la re-connexion
du rseau est relativement aise, si on a bien pris soin de ddoubler prventivement les
ttes de lignes.
Ces solutions ne sont videmment viables que lorsque les situations gographiques et
topologiques sy prtent (ce qui exclut en gnral le cur des agglomrations).
Le dlai de reprise initiale est videmment handicap par les dlais dacheminement et de
montage des installations, et de la sensibilit aux impondrables lis aux transports.
Intgration de services :
Lensemble des solutions ci-dessus peut tre ou non assorti de la prestation de
services (fournis par des quipes internes lentreprise, ou par des fournisseurs
extrieurs).
On y trouve, entre autres, lassistance la mise au point du Plan de Reprise du site
protger, lassistance la mise en place des amnagements dinfrastructure (matrielle ou
logicielle), lassistance aux tests, lassistance au re-dmarrage, le stockage de doubles de
matriels ou de fournitures spcifiques au site protg, le stockage de sauvegardes, la
mise disposition de personnels dexploitation, la gestion des astreintes, la fourniture
dassurances complmentaires de frais supplmentaires et reconstitution de mdia, ...
4.1.3 Niveau de prparation et disponibilit des moyens
Pour des raisons dquilibrage cot / performance des moyens de secours, on peut tre amen
dfinir des solutions dont le niveau de prparation oprationnelle peut varier. Diffrents
niveaux peuvent tre envisags :
25
Environnement peupl latent :
Dans ces solutions (galement appeles salles rouges , mme lorsquil sagit de
moyens mobiles), lensemble des quipements informatiques de secours est prsent en
permanence dans linfrastructure de secours ; ils sont videmment conservs en tat de
marche permanent, mais les donnes et programmes de lentit potentiellement utilisatrice
ny sont pas chargs en rsidant (cette absence peut mme stendre au systme
dexploitation).
Le degr de vraisemblance est lev, condition videmment de conduire rgulirement
des tests pousss.
Les cots sont videmment significatifs, et ils atteignent couramment plusieurs pour-cent
du budget informatique mme pour des installations partages dans des conditions
raisonnables de probabilits dutilisation simultane des moyens.
Le dlai de reprise peut tre de plusieurs dizaines dheures, puisquil faut recharger tout
ou partie du systme dexploitation, en adapter les paramtres, recharger les applications
et donnes utilisateurs, re-constituer les informations perdues du fait du cycle de
sauvegardes, re-synchroniser les applications, ...
Environnements miroirs partiels ou complets :
Ici, non seulement les matriels sont oprationnels en permanence, mais tout ou partie du
systme dexploitation, des programmes, et des donnes de lentit utilisatrice y rsident
en permanence.
Suivant les architectures systme et les technologies employes, ceci peut ne pas tre
compatible avec des solutions partages.
Mme lorsquon parvient les partager, ces solutions sont coteuses, car elles impliquent
des travaux dinfrastructure significatifs pour permettre lalimentation permanente en
donnes fraches et le ddoublement des rseaux locaux et distants. Leur mise en
place peut par contre permettre dallger (mais surtout pas de supprimer !) les procdures
de sauvegarde, dans la mesure o les mmes informations rsident simultanment sur
deux sites diffrents (on suppose videmment que la configuration miroir est une
distance gographique raisonnable du site protger !).
Le degr de vraisemblance que lon est en droit dattendre est videmment maximum,
puisque les contraintes logistiques et les temps de basculement sont quasiment nuls. Les
risques de d-synchronisation des installations sont levs, et le maintien permanent de la
cohrence logique est un problme significatif.
Il faut noter une sensibilit particulire de ce type de solutions aux sinistres immatriels
(erreurs et malveillances logiques, virus), toute intervention effectue sur linstallation
principale tant immdiatement active sur linstallation miroir, sauf installer des
filtres complexes.
Une certaine gradation peut tre considre dans ces solutions :
les secours de premire urgence , dits aussi back-up dastreinte ;
Il sagit de moyens de secours de primtre trs limit, mais permettant la reprise
quasi instantane des applications les plus stratgiques, permettant une certaine
rmanence des systmes, pendant les quelques heures durant lesquelles
seffectue le rechargement de la solution de secours principale (dite back up
lourd).
26
Ils sont typiquement ddis des systmes hautement transactionnels cycle trs
rapide (GPAO flux tendus, pilotage de caisses enregistreuses ou dautomates
bancaires, EDI avec dlais de relev des botes lettres, serveurs Web,).
Ils sont en gnral construits sur une drivation spcialise du rseau, dont ils
coutent en permanence les transactions pour maintenir niveau leurs
fichiers, et certains peuvent dmarrer automatiquement en labsence de signaux
reus de linstallation quils protgent. Evidemment, du fait de leur taille
restreinte, leurs performances, ainsi que la pertinence des donnes quils
contiennent se dgradent trs vite ds quils passent en autonome, mais ceci doit
tre suffisant pour assurer un relais.
Du fait de larchitecture restreinte de cette solution, les cots dexploitation
peuvent tre limits, surtout si on parvient partager les moyens. Par contre, les
frais dtude et de mise en place peuvent tre levs, puisquil faut analyser les
caractristiques de lapplication plastron minimale.
les moyens production rpartie ;
Dans ce cas, les deux centres (secouru et de secours) se partagent en permanence
la charge de travail ; tous les fichiers et accs rseau stratgiques sont dupliqus,
et les mises jour se font au fil de leau ; idalement, les traitements sont
effectus indiffremment (et alternativement) sur chacun des sites, depuis lun
quelconque dentre eux.
Ces solutions ncessitent bien sr daccepter une dgradation notable en cas de
sinistre, mais le redmarrage peut tre fiable et trs rapide. Par contre, les
sinistres immatriels (y compris les mouvements sociaux) restent trs dlicats
aborder.
Les cots sont importants, mais videmment moins levs que dans la solution ci-
dessous.
les environnements de miroir intgral .
Dans ce cas extrme, toutes les activits stratgiques de lenvironnement de
production sont en permanence doubles dans lenvironnement de secours, dont
cest la seule mission. Contrairement la solution prcdente, lenvironnement
de secours ne participe pas la production quotidienne.
Les temps de redmarrage sont videmment trs rduits, ainsi que le niveau de
dgradation fonctionnelle.
Les cots de possession sont trs levs, pouvant aller jusquau doublement du
budget dexploitation.
4.2 Le secours de la tlphonie
4.2.1 Le raccordement au rseau
Le premier point de vulnrabilit concerne laccs physique au rseau public. Il est en gnral
unique ou secouru par un second cblage passant dans la mme tranche.
Diffrents niveaux de secours peuvent tre considrs pour le secours de ce raccordement :
un double raccordement la boucle locale. Les deux raccordements sont
physiquement distincts et loigns. Ce type de solution peut tre envisag lorsque le
site sy prte (campus, btiment donnant sur plusieurs rues, ...) ;
27
un double raccordement la boucle locale, avec accs deux centraux diffrents.
Cette solution permet de se prmunir la fois contre les risques de rupture du
raccordement, de coupure de la boucle locale et dindisponibilit du central
tlphonique ;
raccordement de secours physiquement distinct vers un second oprateur ;
dautres solutions de secours sur site peuvent tre envisages en fonction des
conditions locales.
4.2.2 Les moyens tlphoniques de secours
Secteur particulirement sensible en matire de scurit, lautocommutateur reste le lien
indispensable toute entreprise sur les aspects communications tlphoniques et parfois
informatiques.
Selon la nature des risques couvrir, et de dlai dinterruption tolrable, plusieurs solutions
de secours peuvent tre envisages :
une redondance des quipements de lautocommutateur et du cblage :
autocommutateur matre et autocommutateur(s) satellite(s) avec duplication des
annuaires, si possible dans des btiments diffrents ;
un renvoi automatique des appels sur un site secondaire oprationnel dans un dlai
requis ;
un contrat prvoyant la livraison dquipements de secours mobiles de tlphonie dans
des dlais garantis qui devront tre vrifis ;
des lignes directes, hors autocommutateur.
Remarque : dans le cas dune tlphonie sous IP, on se reportera galement aux solutions de secours
du rseau informatique.
Lutilisation de GSM peut tre envisage, mais, dans le cas de catastrophes touchant une
population importante, cette solution peut savrer totalement inoprante pour cause de
saturation du rseau ou de dtrioration dantennes relais. Il est donc important de prvoir
dautres solutions de secours (autocommutateur dans un autre site, ligne double avec un
centre oprateur, Internet, ou autres moyens de communication).
Il est clair quune flotte de lignes se ngocie auprs des oprateurs, mais ne couvrira en aucun
cas la totalit des besoins pour des raisons principalement budgtaires.
4.2.3 Le routage des liaisons tlphoniques (sur numro unique)
Dans le cas o un quipement tlphonique de secours est disponible sur un site distant, se
pose le problme du transfert des appels entrants vers ce nouveau site.
Il est possible dans ce cas de souscrire un contrat spcifique de transfert des appels du site
sinistr vers le site de secours auprs de loprateur tlphonique.
Deux solutions sont envisager :
soit le reroutage de lensemble des numros SDA (Slection Directe lArrive) vers
un numro unique ;
soit le reroutage lidentique des numros SDA du site sinistr vers le site de secours.
Dans le premier cas, il est ncessaire de prvoir un filtrage des appels entrants par un
oprateur, ce qui peut poser des problmes en cas de mixit entre des appels vocaux et des
transmissions de fax ou des transmissions informatiques. Dans ce cas, il peut tre envisag un
filtrage des trames Numris avant lautocommutateur, condition que le numro initialement
appel soit retransmis par loprateur.
28
Dans tous les cas, une tude de faisabilit technique doit tre ralise par loprateur en
fonction de la localisation du site secourir et du site de secours.
Remarque : une solution alternative peut consister demander loprateur la mise en place dun
message personnalis prenregistr fournissant les nouvelles modalits dappel.
4.3 Le sauvetage des locaux et des quipements
Dans le cas dun sinistre matriel (incendie, dgts des eaux, ...), il convient de prserver au
mieux ce qui peut tre sauv afin de faciliter le retour ultrieur sur site ou de rcuprer des
donnes sur des supports endommags.
Les dispositifs suivants doivent en particulier tre tudis :
le gardiennage du site sinistr, afin dviter des vols ou des actes de vandalisme et
pour prserver les lments de preuves ventuels ;
le recours des socits spcialises dans le sauvetage de locaux et dquipements : en
cas dincendie, par exemple, de nombreux quipements peuvent tre endommags par
des fumes et vapeurs corrosives, une intervention rapide permet de placer ces
quipements dans une atmosphre contrle et de freiner la progression de la
corrosion. Un nettoyage peut ensuite tre entrepris ;
le recours des socits spcialises dans la reconstitution dinformation (archives
inondes, disques endommags).
Au minimum, on maintiendra jour dans le Plan de Secours Informatique une liste des
socits susceptibles dintervenir.
4.4 Les sauvegardes / restaurations
Le plan de sauvegardes / restaurations est un dispositif essentiel du Plan de Secours
Informatique. Il doit garantir la restauration des informations et des outils stratgiques en
toutes circonstances par des moyens adapts et des procdures rigoureuses dexcution et de
contrle. La nature des supports et les rgles dutilisation et de prservation sont primordiales
la qualit des sauvegardes et surtout de leur restauration.
4.4.1 Les types de sauvegarde
Les sauvegardes peuvent tre diffrencies selon leur utilisation et leur mode de ralisation.
En fonction des destinations, il y a lieu de distinguer les sauvegardes de production des
sauvegardes de recours. Les premires sont destines faire face un incident courant
dexploitation tel que lcrasement dun fichier. Elles doivent tre accessibles rapidement et
peuvent donc tre stockes sur le site dexploitation. Les secondes sont destines faire face
un sinistre majeur ncessitant le recours des moyens externes. Elles doivent notamment
permettre de faire face une destruction du site dexploitation et seront donc imprativement
achemines sans dlais sur un site distant. Les sauvegardes de recours (ou encore de dernier
recours ) doivent tre absolument fiables et ne seront utilisables que sur autorisation spciale
de la structure de crise. Afin de garantir leur fiabilit et leur intgrit, elles doivent tre
ralises selon des procdures de scurit renforces (procdures de sauvegardes scurises et
diffrentes des procdures de sauvegardes dexploitation, contrles renforcs, scurit
renforce des transferts et des lieux de stockage).
Une troisime catgorie de sauvegarde peut tre considre pour larchivage. Dans le cas de
larchivage, les exigences de dlais de reprise sont en gnral plus faibles que pour les deux
autres catgories mais le caractre de preuve doit souvent y tre prserv.
29
Enfin, il est toujours prudent deffectuer une sauvegarde avant toute opration rpute
dangereuse sur un disque (maintenance par exemple ou changement de release) ou sur
lensemble de la configuration.
Plusieurs modes de ralisation des sauvegardes sont envisageables :
sauvegarde physique ;
sauvegarde logique.
4.4.1.1 Sauvegarde physique
Il sagit de la sauvegarde volume par volume de tout ou partie des donnes.
Elle est utilise pour la restauration dun disque aprs un incident dexploitation (atterrissage
de tte, problme darrt intempestif, ...). Il est souhaitable que ces sauvegardes fassent lobjet
dune dure de conservation tudie. Elles peuvent galement tre utilises dans le cadre dun
plan de secours si la configuration de secours est identique et si le matriel le permet.
Le recours la technologie de disques RAID permet galement de faire face ce type
dincidents dexploitation par une redondance des donnes sur des disques diffrents et grce
des dispositifs de remplacement de composants sans arrt de la production.
4.4.1.2 Sauvegarde logique
Il sagit de la sauvegarde par entits logiques.
4.4.1.2.1 Sauvegarde logique complte
Elle est essentiellement utilise pour reconstituer le systme dinformation sur une
configuration de secours plus ou moins rduite par rapport la configuration dorigine. Son
principal avantage est de faciliter la synchronisation des donnes mais en contrepartie sa
dure dexcution est longue. Il convient de sassurer de la cohrence des niveaux systme,
application et donnes restaures.
4.4.1.2.2 Sauvegarde incrmentale
Elle consiste sauvegarder des fichiers qui ont t modifis entre deux moments identifis.
Ce type de sauvegarde est souvent indispensable si une sauvegarde complte journalire est
trop longue ou impossible.
Elle ncessite une organisation (logicielle ou manuelle) facilitant le reprage des supports et
des fichiers sauvegards.
La sauvegarde incrmentale est rapide mais ne doit pas tre utilise sur une longue priode,
car il y a des risques dincohrence. Il faut alors pouvoir disposer dune sauvegarde complte
dont lanciennet ait encore un sens pour les utilisateurs. Ce type de sauvegarde est
frquemment associ la sauvegarde complte.
4.4.1.2.3 Sauvegarde applicative
Il sagit de la sauvegarde de lensemble des fichiers, ncessaires la bonne excution ou la
bonne reprise dune application.
Ce type de sauvegarde permet dassurer la cohrence des informations, notamment dans le
cadre dun plan de secours lorsquon a dcid la reprise totale ou partielle dune application.
Il faudra ventuellement prvoir des procdures spcifiques de scurit (convoyage,
conservation, scellement, audit, ...) en fonction de limportance stratgique de lapplication.
Ces sauvegardes sont lies au cycle de production et leur frquence sera directement fonction
du nombre de traitements excuts.
30
4.4.1.2.4 Journalisation
La journalisation consiste crer un journal de toutes les oprations de mises jour effectues
sur un fichier.
En cas de problme sur le fichier, la dernire sauvegarde sera restaure et on appliquera tous
les mouvements de mises jour enregistrs dans le journal.
Les SGBD disposent en gnral de procdures de journalisation. Cependant, dans certains cas,
il peut tre ncessaire de prvoir cette journalisation au niveau du dveloppement de
lapplication.
En fonction de la frquence de mise jour de la base, et du temps acceptable de reconstitution
des donnes, les journalisations peuvent tre priodicits diffrentes (quotidiennes,
hebdomadaires, ...).
La difficult des procdures de journalisation rside dans la synchronisation entre la
sauvegarde gnrale et le dmarrage dun nouveau journal. Cette difficult est
particulirement aigu dans le cas dun service 24 h sur 24.
Les journaux peuvent faire lobjet dune sauvegarde spcifique afin de restaurer des donnes
plus fraches.
4.4.2 Les techniques de duplication, de sauvegarde et de restauration
Le choix des techniques de sauvegarde / restauration dpend la fois des exigences
fonctionnelles (fracheur des donnes restaurer, dlais de mise disposition, cohrence entre
les ensembles de donnes restaures) ainsi que des contraintes techniques (dlais
dacheminement sur le site de secours, volumes restaurer, performances des outils de
sauvegarde et de restauration). La combinaison de ces objectifs et contraintes conduit
envisager les diffrentes techniques suivantes :
4.4.2.1 la rplication ;
La rplication consiste dupliquer les informations sur des disques distants de manire
pouvoir allger la phase de restauration, voire de sen dispenser. Les mises jour sont
transmises intervalles rguliers sur le site distant, puis intgres la copie de secours des
disques de production. Les diffrentes solutions de rplication diffrent selon la frquence
denvoi des mises jour et le dlai de rtention avant mise niveau des supports de secours.
Il est important de noter quen cas daltration des donnes de production, les donnes sur le
site de secours sont galement altres. Cette solution ne dispense donc pas dune sauvegarde
priodique de recours dont le contenu devra tre garanti.
4.4.2.1.1 Cas 1 : la rplication immdiate
Ce mode de rplication est directement assur par le systme, lapplication ou le SGBD. Il
permet de rpercuter instantanment une modification de donne sur lenvironnement de
production et sur celui de secours.
La perte de donnes est dans ce cas nulle ou quasi nulle et le dlai de reprise ne dpend que
du niveau de prparation des serveurs et du rseau.
4.4.2.1.2 Cas 2 : Les mises jour sont transmises intervalles rguliers
31
Les mises jour sont transmises intervalles rguliers (quelques minutes plusieurs heures)
sur le site de secours, soit comme prcdemment par lapplication ou le SGBD, ou par un
dispositif spcifique (logiciel de sauvegarde volu, transmission des journaux de mise
jour). Lapplication des mises jour sur les supports de secours peut galement tre diffre,
avec une autre priodicit (exemple : mise niveau quotidienne aprs validation dun tat
stable des donnes de production). En cas de sinistre, et selon la nature de celui-ci, les
dernires mises jour reues peuvent tre appliques pour limiter la perte dinformation (sous
rserve du maintien de la synchronisation des donnes).
4.4.2.2 la sauvegarde classique.
La sauvegarde de recours classique consiste dupliquer les informations (systmes,
applications et donnes applicatives) sur des supports amovibles achemins sans dlai sur un
site de stockage loign et scuris. Sa dure de conservation est le temps optimal entre la
ncessit dune remise jour (traitement, rexploitation) et la capacit raliser lopration
(temps de traitement, cohrence logiciel et matriel).
Les contraintes logiques, techniques, volumtriques et financires ncessitent frquemment
dorganiser le plan de sauvegarde en mixant les diffrentes solutions. Par exemple,
sauvegarde physique pour les disques systmes, incrmentale pour les batchs, logique et
journalisation pour les bases.
Il convient de prter une attention particulire la synchronisation des donnes et des
systmes et applications lors des sauvegardes et des oprations de restauration. Il est
ncessaire par exemple de prciser dans la restauration, les patchs de lditeur qui doivent tre
appliqus.
La gestion des supports de sauvegarde et des procdures de restauration peut tre automatise
par lutilisation dun logiciel spcialis de sauvegarde / restauration coupl un robot.

ADEQUATION RISQUES / SAUVEGARDES
CATEGORIE
SAUVEGARDE
LIEU DE STOCKAGE
DUREE DE
CONSERVATION
UTILISATION
PRODU-
CTION
RECOURS
ARCHIVAGE
SUR SITE
HORS
SITE
TEMPO-
RAIRE
LONGUE
DUREE

Incident
dexploitation
X X X

Remise
disposition
dapplicatifs
X X X

Audit
X ou X X X ou X X X

Remise
disposition lgale
X X ou X X

Sinistre
X X X ou X
Tableau 1 : Adquation risques / sauvegardes
32
4.4.3 La synchronisation des donnes
La synchronisation des donnes est un problme important traiter dans un plan de
sauvegardes / restaurations. Un moyen simple pour le rsoudre est de stopper les mises jour
sur lensemble des informations synchroniser, pendant toute la dure des sauvegardes. Cette
solution est malheureusement de moins en moins praticable car la fentre utile pour raliser
les sauvegardes est souvent insuffisante, voire nulle.
Dautres solutions doivent alors tre envisages :
la rplication (cf. ci-dessus) ;
la technique du snapshot , offerte par certains outils (SGBD, logiciels de
sauvegarde, ...) et qui consiste figer un tat des fichiers un instant t et de
raliser ensuite la sauvegarde partir de cet tat, tout en autorisant la poursuite des
mises jour des fichiers.
4.4.4 Les solutions de sauvegarde / restauration.
A ce jour, il existe deux grands types de moyens de sauvegardes que sont :
les moyens centraliss ou propritaires qui sont mono-systme dexploitation ;
les systmes de sauvegarde en architecture distribue sur le mode client serveur et
capables de fonctionner dans des environnements multi-systmes.
Compte tenu de lvolution des architectures informatiques dans ces dernires dcennies, les
systmes ouverts dominent le march actuel.
4.4.4.1 Architectures dites "centralise"
La particularit de ces systmes de sauvegardes tient au fait quils sont aussi bien capables de
gnrer des sauvegardes physiques (un disque, un ensemble de disques ou un serveur
complet) que des sauvegardes logiques. Ils sont pilots par un des serveurs dont ils assurent la
sauvegarde et permettent de constituer des supports bootables, trs utiles en cas de
reconstitution complte dun serveur. Selon les configurations et le volume des donnes
traiter, ces systmes de sauvegardes sont relis des priphriques du serveur qui les hberge
ou des robotiques plus ou moins complexes.
4.4.4.2 Architecture distribue ou client / serveur
Le systme de sauvegarde est en principe install sur un serveur ddi auquel sont rattachs
une ou plusieurs robotiques en mode canal ou rseau. Lensemble des sauvegardes est gr au
niveau dun catalogue (objet trs sensible) qui doit lui-mme tre rgulirement sauvegard.
Les serveurs sauvegarder sont relis aux serveurs de sauvegarde soit par le rseau
dentreprise, soit via un rseau ddi ce besoin, et le logiciel client est install sur chacun
dentre eux. Dans le premier cas, il convient de bien dimensionner le rseau afin de ne pas
perturber les oprations courantes.
Le dclenchement des sauvegardes peut tre :
soit pilot par le serveur de sauvegardes lui-mme travers son planificateur de tches
(dclenchement temporel) ;
soit par lagent du client qui peut tre conditionn par un vnement interne ou externe
(sauvegardes vnementielles). Exemple : dclenchement dune sauvegarde avant ou
aprs un traitement prcis.
33
Les sauvegardes sont dites logiques (fichier par fichier, ou rpertoire par rpertoire) et sont
dcrites le plus souvent de manire explicite, ce qui implique un plan de sauvegarde rigoureux
et des moyens de contrle appropris. Les sauvegardes peuvent tre totales ou incrmentales.
Ces systmes de sauvegarde ne sachant pas gnrer de supports dits bootables , il faut
stocker indpendamment des donnes, les moyens de reconstituer chaque systme
dexploitation, ainsi que le serveur et le logiciel de sauvegarde eux-mmes.
4.4.5 Les procdures, les tests, le suivi
Les sauvegardes doivent faire lobjet de procdures crites par les techniciens. Les
restaurations doivent galement faire lobjet de procdures crites qui prcisent notamment
les personnes habilits les dclencher.
Ces procdures sont ncessaires mais ncessitent galement davoir au quotidien :
un tableau de bord du suivi des sauvegardes ;
une remonte centralise des alertes indiquant tout problme survenu lors des
sauvegardes avec revue et prise en compte des alertes remontes selon des consignes
crites.
Ceci apporte une fiabilit aux sauvegardes et donc aux restaurations faire en cas de sinistre.
Des tests priodiques de restauration (complets et / ou partiels) doivent tre mens
intervalles rguliers afin de vrifier que les procdures sont suivies et jour et que les
sauvegardes fonctionnent bien. Ces tests feront lobjet de comptes-rendus et de suivi afin que
tout dysfonctionnement soit corrig.
4.5 Le secours des impressions et de la mise sous pli
Le secours des impressions et de la mise sous pli pose des problmes spcifiques. Les moyens
de secours ne sont en gnral pas fournis directement par les offreurs de secours informatique.
Il convient soit dtudier un secours interne, si plusieurs lignes dimpression / mise sous pli
existent, en sparant physiquement ces diffrentes lignes, soit davoir recours certains
professionnels tels que les imprimeurs ou les socits ralisant des mailing. Ces solutions
peuvent galement contribuer absorber la charge dimpression en priode de pointe.
Comme pour le secours informatique, ces solutions doivent faire lobjet de contrat et tre
testes priodiquement.
Dautres points importants sont prendre en compte :
le stock dimprims ;
Prvoir un stock dimprims lextrieur du site, en interne ou chez un fournisseur. Dans
le cas dun stock externe, il convient de surveiller les conditions de stockage du papier et
de procder un roulement de manire limiter le vieillissement du stock (qualit du
support et maintien jour des donnes imprimes).
Dans certains cas, des impressions dgrades, sur papier vierge sont envisager ;
les aspects contractuels (sur la conservation des stocks, la mise disposition des
quipements, ... ;
les relations avec les entreprises dacheminement du courrier
Il est important de prvoir lavance le circuit des documents en situation de secours. Le
secours du courrier classique sera trait dans le cadre du Plan de Continuit dActivit.
Par contre lenvoi de masse de la production informatique doit tre trait dans le Plan de
Secours Informatique. Il convient notamment de se coordonner avec ces entreprises,
surtout lorsque les volumes qui seront traits par le site de secours sont importants. Des
34
navettes pourront tre organises pour la livraison des ditions en interne ou vers des
partenaires ;
laffranchissement ;
les quipements spciaux : prvoir le secours de machines signer ;
la confidentialit des documents produits ;
...
4.6 Le secours des accs au rseau Internet
4.6.1 Le raccordement au rseau Internet
L'accs au FAI (Fournisseur dAccs lInternet) est le premier point de vulnrabilit pour le
raccordement de l'entreprise Internet. Diffrentes solutions peuvent tre envisages :
deux raccordements distincts vers le mme FAI (l'un matre et l'autre esclave) mais sur
deux cartes rseaux diffrentes ;
un raccordement vers deux FAI diffrents avec partage de charge sur les deux plans
dadressage IP ;
un raccordement vers deux FAI diffrents (l'un matre et l'autre esclave) en ralisant,
entre eux, un accord d'change de trafic (dte politique de peering ) ainsi
l'entreprise conserve le mme adressage IP lors du basculement ;
une redirection des flux Internet par le rseau interne de l'entreprise vers un autre point
d'accs lors de la perte du lien principal.
4.6.2 Le reroutage des flux Internet
Lors de la mise en fonctionnement du site de secours, plusieurs solutions peuvent tre
envisages :
une connexion de secours vers le mme FAI permettant de conserver le mme plan
d'adressage ;
un nouvel accs Internet compltement d-corrl de celui du site sinistr. Dans ce
cas, une plage d'adresses IP correspondant au besoin du site de secours doit tre
rserve l'avance et les DNS matres du domaine de l'entreprise doivent tre mis
jour lors du redmarrage, avec le nouveau plan d'adressage.
4.7 Le contrat de secours
Quelle que soit la solution de secours retenue (interne, externe, repeuplement de salle
blanche, ...), il est indispensable de formaliser les relations entre l'utilisateur des moyens de
secours, et les entits qui mettront disposition lensemble des moyens pour garantir la
continuit de service (serveurs, rseau, postes de travail, ...).
Dans les dveloppements suivants, on utilisera conventionnellement les termes de
souscripteur , prestataire , et contrat , tant donc bien entendu que cette relation peut
s'appliquer tous les cas de figure (clients / socit de services, divisions ou tablissements
d'une mme entreprise, entreprises utilisatrices lies par des engagements rciproques, ...).
Il faut en consquence interprter le texte suivant, dont certaines clauses peuvent ne pas avoir
de signification ou doivent tre extrapoles en fonction des moyens et relations prvus.
35
4.7.1 Objet du contrat
Le Contrat liant prestataire et souscripteur doit tout d'abord indiquer l'objet gnral
de l'engagement des parties :
nature des moyens mis disposition et leurs conditions de mutualisation
(environnement fixe ou mobile, avec ou sans tlcommunications, ...) ;
les situations ouvrant droit la mise disposition des moyens de secours (sinistre
matriel, sinistre immatriel, crtage de charge, indisponibilits volontaires telles que
migrations ou dmnagements, conflit social, ...). Il est souhaitable que les exclusions
soient explicitement mentionnes (formulation de type "tout sauf ...") ;
les dlais de base de mise disposition des moyens de secours, et la dure maximale
de mise disposition ;
etc.
4.7.2 Nature dtaille des prestations
Cette clause prcise les moyens mis disposition, leur lieu de mise disposition (en cas de
sinistre partiel, il peut tre envisag une clause spcifique prvoyant la livraison des
quipements de secours par le prestataire chez le client) et les services additionnels qui sont
ventuellement fournis. Par exemple, la prestation inclue-t-elle, le montage et la mise sous
tension des matriels, la configuration du systme (standard ou personnalise), la connexion
aux rseaux locaux et distants, le rechargement des donnes du souscripteur , l'assistance
d'ingnieurs et / ou de personnels d'excution ?
Le problme du droit dutilisation des logiciels sur site de secours doit tre tudi en fonction
des choix effectus.
On peut galement dtailler ici la dure de mise disposition des moyens de secours (dure
contractuelle de base, clauses de prolongation, monte en rgime ou au contraire rduction
progressive de la puissance de moyens mis disposition, ...). Les clauses doivent videmment
tre cohrentes avec les dlais de rapprovisionnement et de reconstruction habituels la
technologie employe.
4.7.3 Procdure de dclenchement
Le prestataire doit prciser en dtail les modalits de dclenchement des interventions
(procdure, moyens employs - tlphone, fax, confirmation crite - heures limites de prise en
compte des appels, astreintes de jours fris, ...).
En particulier, le contrat doit comporter une liste exhaustive des reprsentants du
souscripteur habilits dclencher une intervention, ainsi que les procdures
d'authentification et d'accus de rception des appels.
Certains contrats peuvent comporter un dclenchement en deux temps (premire alerte,
dclenchant une pr-chauffe sur le site de secours, suivie d'une confirmation dfinitive du
souscripteur, aprs qu'il ait fait l'inventaire dtaill des dgts et parcouru ses procdures
d'escalade).
4.7.4 Conditions de fonctionnement
Dans le cas de recours un site fixe, le Contrat doit prciser clairement les heures
d'ouverture de ce site, les procdures de scurit et de contrle d'accs, le plan d'accs, les
moyens de parking, Il peut tre souhaitable de joindre au "contrat" tout ou partie du
rglement intrieur du site, et de prciser les situations qui peuvent engager la responsabilit
du souscripteur .
36
Dans le cas o le prestataire met une salle privative permanente la disposition du client pour
le secours de serveurs stratgiques, le contrat prcisera les moyens de scurit pour garantir la
protection des quipements client (contrle daccs, scurit incendie, alimentation
lectrique, ...) et pour assurer et scuriser les changes externes. Le contrat prcisera
galement dans ce cas lentit qui gre lexploitation et, le cas chant, le partage des
responsabilits en matire dexploitation de ses quipements.
4.7.5 Logistique
Le contrat doit prendre en compte les implications logistiques identifies dans les plans de
reprise (tlphone, tlcopie, accs rseau, impressions, accs Internet, telex, secrtariat,
hbergement des quipes du souscripteur , installation et / ou stockage de matriels
complmentaires, ...). Il faut en effet veiller garantir la mise disposition d'un minimum de
confort des quipes soumises de trs fortes pressions.
4.7.6 Tests et rptitions
Les solutions de secours n'ont de sens que si elles sont testes rgulirement. Il est donc
essentiel que les parties se mettent d'accord sur une frquence et un protocole de tests
rguliers. Ces tests doivent faire partie intgrante du contrat , et faire l'objet de comptes-
rendus co-signs. Le contrat doit prciser les consquences du non-respect de cette clause, que
ce soit du fait du prestataire ou du souscripteur .
Certaines solutions de secours sont difficiles tester (accords rciproques en l'absence de
surcapacit, repeuplement de salle blanche, dplacement dutilisateurs, perturbation de
services), mais il faut s'imposer d'aller le plus loin possible. Une solution de secours
impossible tester augure mal dune mise en uvre relle.
Chaque prestataire doit sengager assurer et tester linteroprabilit avec les moyens des
autres prestataires. Le contrat contiendra en annexe les coordonnes des contacts chez ces
diffrents prestataires.
Il est conseill dassortir le contrat d'une clause de recette contractuelle, ne liant d'une
faon durable prestataire et souscripteur qu' l'issue de tests approfondis faisant l'objet d'un
protocole contradictoire (adquation de la configuration fournie, tests des interfaces et des
rseaux, des impressions, ...).
4.7.7 Gestion de priorits
Sauf dans le cas de configurations miroir , ou la totalit des quipements critiques est
double, la majorit des moyens de secours est base sur le partage par deux ou plusieurs
entits d'un ensemble limit de matriels et installations.
Il est donc possible que ces entits souhaitent recourir simultanment ces moyens, et il est
essentiel de dfinir clairement des rgles de priorits, pour tre mme de rsoudre d'emble
les situations de conflit d'accs. Elles doivent tenir compte au moins des lments suivants :
la cause de la demande d'intervention (sinistre total, partiel, crtage de charge, tests,
anticipation en cas dvnement quasi certain, ...) ;
le mode d'utilisation demand / possible (exclusif, partag) ;
la dure de mise disposition (tant la dure demande que la dure maximale
contractuelle restante courir, car on peut mettre au point des systmes priorit
dcroissante dans le temps) ;
37
dans le cas d'une relation client / fournisseur externe (bien que ceci puisse avoir une
signification mme dans le cas de relations internes), les catgories de clients pouvant
entrer en comptition pour l'acquisition des ressources, et le jeu rciproque de ces
relations contractuelles (client ponctuel, abonn service bureau, abonn repeuplement
contre abonn service complet, ...).
Ces clauses de priorits peuvent prendre en compte la disponibilit ventuelle chez le
prestataire de moyens de secours de deuxime niveau. Si ces moyens prsentent des
fonctionnalits infrieures celles des moyens principaux, il peut y avoir lieu de dfinir les
compensations qui seront garanties au souscripteur pour compenser la dgradation.
Elles peuvent, d'une faon symtrique, amener le souscripteur enrichir son Plan de
Secours (en dveloppant des hypothses du type si le Centre de Secours de premier niveau
n'est pas disponible, alors ... ).
4.7.8 Engagements et responsabilits
Le prestataire doit indiquer le nombre maximum de souscripteurs auxquels il peut
s'engager fournir assistance avec un environnement donn.
Dans le cas d'une relation client / fournisseur externe, cette notion revt une importance
particulire, car elle dfinit la probabilit du fournisseur de se trouver confront des
situations de dbordement, donc de conflits de priorit et par consquent d'insatisfaction d'un
ou plusieurs clients.
Ceci est d'autant plus grave que la totalit des fournisseurs externes de moyens de secours
n'endosse que des engagements de moyens (ils mettent tout ce qu'ils peuvent la
disposition de leurs clients), et non des engagements de fin (en cas de sinistre, le fournisseur
ne peut garantir qu'il pourra satisfaire un client dtermin, puisque ses moyens sont limits).
Il n'est pas possible de faire de recommandation quant au nombre optimal de sites pouvant
tre supports : il s'agit en effet d'un quilibrage entre le cot de la prestation (inversement
proportionnel au nombre de sites protgs), et la probabilit de collision de demandes
d'intervention. Or ce dernier paramtre varie beaucoup en fonction de la technologie
considre (partageable ou non), de la qualit des actions de prvention de la clientle, de la
taille globale du prestataire (loi des grands nombres), de la psychologie de la clientle
( mieux vaut un petit contrat que rien du tout , ou au contraire, recherche du sur
mesure ), ...
Le taux de mutualisation est examiner systmatiquement au cas par cas en fonction
notamment de la technologie mise en uvre (systmes d'exploitation partageables ou virtuels,
tat moyen des dlais de livraison pour des matriels neufs et d'occasion), du
professionnalisme des partenaires, de la nature des risques couverts, de l'aggravation
ventuelle des risques de l'entreprise (lis son exposition des malveillances, au montant de
ses enjeux, ses obligations ventuelles d'astreinte, une accumulation de risques au niveau
du prestataire, ... Voir le dernier paragraphe de ce chapitre).
Dans tous les cas de figure, le contrat doit prciser les responsabilits du prestataire
lorsqu'il n'est pas en mesure de respecter ses engagements, qu'il ait ou non appliqu
rigoureusement les rgles de priorit, et explicit les limitations de responsabilit qui peuvent
en rsulter.
Enfin, il est frquent (et normal) que la responsabilit du prestataire soit dgage au
niveau de la qualit des programmes, donnes, procdures et sauvegardes du souscripteur
(ce qui souligne nouveau la quasi impossibilit pour un prestataire de s'engager sur des
rsultats).
38
4.7.9 Aspects financiers
La mise en place de moyens de secours reprsente le plus souvent des investissements
importants, tant en temps qu'en matriel.
Il est donc ncessaire que les cots associs soient clairement dfinis. Outre les cots de
dveloppement des Plans de Reprise, il y a lieu d'identifier :
les cots d'abonnement ventuels qui doivent tre pris en compte mme en cas
d'accords rciproques ou internes, car cet abonnement permettra de complter les
quipements pour pouvoir honorer les engagements. Dans le cas de fournisseurs
externes, cet abonnement permettra de financer les quipements partags, et de
maintenir oprationnelle en permanence toute la structure d'accueil. Le cot est alors
proportionnel la configuration souscrite ;
les cots de dclenchement d'intervention (cot de prparation et de mise en uvre
des tests et interventions relles) ;
les cots d'utilisation effective, pendant et aprs la dure contractuelle de base. Ils
peuvent tre lis la puissance rellement consomme (et bien sr la dure
d'utilisation). Il est frquent de mettre en place des taux croissants dans le temps, qui
encouragent le souscripteur librer au plus tt les installations de secours. Ils
peuvent galement varier en fonction des plages d'utilisation.
La typologie de rpartition de ces cots varie beaucoup d'un type de prestation l'autre :
certains contrats peuvent avoir un cot d'abonnement lev, mais par contre offrir une
franchise au niveau des cots de dclenchement et d'utilisation. A l'oppos, certaines solutions
peuvent prsenter des cots d'abonnement limits, assortis de cots d'utilisation - en test ou en
rel- levs.
L'ensemble de ces cots peut tre dtaill en termes de prestation de base et services
complmentaires (aide au redmarrage, ...).
Par exemple, certains contrats (notamment avec des fournisseurs externes) peuvent tre
assortis de contrats d'assurance couvrant les cots engendrs par une mise en uvre relle des
moyens de secours (clauses dites de Frais Supplmentaires et ventuellement de
Reconstitution de Mdias ). Il faut alors prciser le montant des capitaux garantis,
dterminer qui prend la charge de l'assurance, et s'assurer que la clause couvre spcifiquement
tous les frais lis la mise en uvre et l'exploitation des moyens de secours lors du sinistre.
4.7.10 Evolution de la configuration
Les configurations informatiques changent rapidement. Il convient que le contrat vive
avec elles, et prenne en compte les volutions du souscripteur et ventuellement du
prestataire (ce point, particulirement vident, est souvent oubli par les accords
rciproques formels et informels, qui sont le plus souvent bass sur une vague ressemblance
des configurations au moment de l'accord, mais ignorent dlibrment qu'elles vont
probablement diverger trs rapidement).
Il importe donc que le contrat prcise la dure de sa validit technologique , les
dispositions qui sont prises pour se tenir au courant mutuellement des volutions, des
implications rsultant de la ncessit de faire voluer l'une et / ou l'autre des configurations.
4.7.11 Confidentialit
Il est d'usage que le prestataire et le souscripteur concluent un accord rciproque de
confidentialit (particulirement si le souscripteur souhaite tre couvert face des fraudes,
malveillances, mouvements sociaux, ...).
39
Pour certains secteurs, cette notion de confidentialit peut mme avoir un impact notable sur
le droulement des tests, et donc sur les cots (par exemple, interdiction de recourir des
personnels externes pour la reconfiguration et le rechargement des donnes, destruction des
supports magntiques aprs usage, impossibilit d'utiliser des configurations et / ou rseaux
partags, ...).
4.7.12 Quelques recommandations
Les points les plus dlicats de ces contrats sont les suivants :
backup de deuxime niveau : le prestataire doit, dans toute la mesure du possible,
disposer son tour d'une solution de secours en cas d'indisponibilit de ses propres
installations (suite sinistre, dbordement, mouvements sociaux, impossibilit d'accs,
...). Dans le mme ordre d'ides, il est souhaitable que le prestataire s'engage
informer son (ou ses) souscripteur(s) de la survenance de toute situation l'empchant
d'honorer ses engagements de premier niveau ;
accumulation de risques : il faut vrifier que le prestataire n'est pas dans une situation
forte probabilit de collision de demandes de mise en uvre par exemple, les
solutions de secours de type corporatif (GIE et autres) sont attirantes, mais une
situation de mouvements sociaux sectoriels peut se rvler catastrophique. Il peut en
tre de mme pour des accumulations de risques gographiques. Il est conseill
dajouter au contrat la dfinition dun primtre de scurit lintrieur duquel le
prestataire sengage fournir les moyens demands, mme en cas de collision ;
limitation des responsabilits : comme indiqu plus haut, cot et degr de certitude de
disponibilit sont deux paramtres opposs : une solution parfaitement fiable risque
d'tre d'un cot dcourageant, ce qui aboutit l'oppos du but recherch. Inversement,
une solution bon march peut tre totalement illusoire ;
transfert de moyens au prestataire : dans le cas o le contrat prvoit galement la mise
en oeuvre du secours avec les moyens mis disposition par le client (logiciels,
donnes, moyens humains, ...) il faut prciser les responsabilits, notamment vis--vis
du respect de la rglementation .
respect des rgles de nombre d'abonns et d'application des priorits : dans le cas de
relations clients / fournisseurs externes, il est frquent (et normal) que le prestataire
refuse de divulguer l'identit de ses autres clients, puisqu'il peut tre tenu vis vis
d'eux ainsi que mentionn, par des rgles de confidentialit. Ceci peut tre en
contradiction avec la ncessit de transparence de la bonne application des
engagements contractuels au niveau du nombre maximum d'adhrents, et de
l'application rigoureuse des rgles de priorit en cas de conflit d'accs. Il peut donc
tre souhaitable que le contrat identifie une tierce partie, tenue la confidentialit,
habilite auditer tout moment la matrialit des services, le professionnalisme de la
gestion des installations de secours, et le respect des rgles contractuelles.

En conclusion, les prestataires ne pouvant en gnral endosser que des obligations de
moyens, il appartient au souscripteur de s'assurer que la prestation fournie reprsente bien
pour lui l'optimum entre la rduction de ses enjeux en cas de sinistre, le budget qu'il y
consacre, et la vraisemblance de la solution mise au point.
40
5 ANNEXE : FICHES GUIDES DANALYSE DES
RISQUES
5.1 Locaux et infrastructure
Risques d'indisponibilit dfinitive

Menaces types Consquences prciser Parades considrer
1
Destruction totale (site ou
btiment)
Site et / ou services concerns
Dure d'interruption totale
Service dgrad
Perte d'information
Dplacement de personnel
Sauvegardes externes
Sites et moyens de secours
Informatique
Utilisateurs
Plans de reprise formaliss
Locaux
Equipements
Activits
Destruction salle
informatique
Idem Site et / ou services
concerns
Dure d'interruption totale
Service dgrad
Perte d'information
Placer toutes les sauvegardes
l'extrieur de la salle
Local de secours
Secours des quipements
Interne
Externe
Livraison
Maintenance
Secours du cblage
Destruction d'un local
nodal
Fonctionnement dgrad du
rseau local
Interruption des liaisons
externes
Architecture scurise
Possibilit de reconfigurer via un
autre LTE (local technique
d'tage)
Kit d'urgence
Cbles
Matriels rseau
Destruction d'un local
technique d'tage (LTE)
Interruption temporaire du
rseau dans les zones
concernes
Service dgrad
Architecture scurise
Possibilit de reconfigurer via un
autre LTE
Kit d'urgence
Cbles
Matriels rseau

1
Toutes les parades considrer ne peuvent tre efficaces que si elles sont formalises et rgulirement testes
41

Destruction de la
mdiathque
Perte darchives
Perte de sauvegardes
Perte de donnes applicatives
Externalisation dune copie des
informations sensibles
(sauvegardes, archives lgales)
Etude des possibilits de
reconstitution (rcupration
externe, trace papier)
Copies sur disque
Destruction d'une zone
utilisateurs ou d'une zone
d'archivage (fonction du
cloisonnement incendie)
Perte de documents
Perte totale d'information (si
sauvegardes locales)
Service dgrad
Sauvegardes extrieures la
zone
Secours des quipements
locaux
Serveurs
Parc de PC / Imprimantes
Equipements spcifiques
Secours des supports
physiques de flux et des
dossiers (papier, disquette, )
Copie externe
Numrisation
Possibilit de reconstitution
Locaux de secours utilisateurs
Destruction du systme de
climatisation
Panne disque et dtrioration
de donnes
Arrt de serveurs
Altration de supports
Dans certains cas,
indisponibilit de limmeuble
Redondance des quipements
de climatisation (centrale eau
glace, armoires, )
Protection des locaux
techniques (accs, incendie)
Plan et moyens de secours
pour les serveurs et
applications indisponibles
Destruction dquipement
dalimentation lectrique
(transformateur, armoire
lectrique, ...)
de donnes
Arrt de serveurs
Altration de supports
Indisponibilit de limmeuble
Groupe lectrogne
rgulirement tests
Ddoublement des arrives et
postes de transformation
lectriques
Moyens de secours externes
Informatique
Utilisateurs
Contrat dintervention rapide
Respect des charges
d'utilisation recommandes par
les constructeurs
Onduleur +arrt scuris des
machines
42

Destruction de londuleur
gnral (ou ddi une
salle)
de donnes
Arrt de serveurs
Basculement sur le rseau (si
possible automatique)
Redondance de londuleur avec
basculement automatique
Scurisation du local onduleur
(accs, incendie, ...)
Moyens de secours
informatiques externes
Contrat de maintenance
prvoyant le remplacement
dans un dlai appropri

Tableau 2 : Locaux et Infrastructure (risque dindisponibilit dfinitive des locaux)

43
Risques d'indisponibilit temporaire des locaux

Inaccessibilit temporaire sans
destruction
suite menace (alerte la
bombe, pression sur le
personnel, )
Arrt des activits du site
Inaccessibilit des consoles
de pilotage
Risque de dtrioration des
matriels
Moyens de secours
informatiques et utilisateurs
externes pour un service
minimum temporaire
Procdures d'alerte et mise
en uvre de mesures
d'urgence
destruction
suite accident
d'environnement
Risque d'arrt des
quipements
matriels
Risque de perte de donnes
Moyens de secours
minimum temporaire
Accs et pilotage distant
destruction
suite non conformit des
locaux
Arrt des activits du site Moyens de secours
utilisateurs externes pour un
service minimum temporaire
destruction
suite panne d'un systme
de scurit
Arrt des activits du site Moyens de secours
Blocage des accs suite conflit
social, sans arrt des
quipements

de pilotage
Risque d'occupation
Moyens de secours
Impressions dportes
Protection physique du
btiment
Stratgie d'anticipation d'une
aggravation
Occupation des locaux suite
conflit social, sans arrt des
quipements (aggravation du
risque prcdent)
de pilotage
Risque d'arrt des
quipements ou d'actes
malveillants
Moyens de secours
Impressions dportes
Protection physique des
quipements critiques
Procdures d'alerte et mise
en uvre de mesures
d'urgence
44
Occupation des locaux avec
arrt des quipements
(aggravation du risque
prcdent)
Arrt des quipements du
site
matriels
Moyens de secours
minimum temporaire

Tableau 3 : Locaux et infrastructure (risques d'indisponibilit temporaire des locaux)
45
5.2 Equipements informatiques et de tlcommunication
Risques dindisponibilit dfinitive

Menaces types
Consquences prciser Parades considrer
Destruction (accident ou
malveillance)
Perte de donnes
Interruption temporaire ou
dfinitive de service
Dgradation de service
Interruption de flux
Redondance
Mode dgrad
Equipement de secours
rgulirement test
Extension du contrat de
maintenance
Sauvegarde adapte et
complte
Protection physique
Bris de matriel non remplaable
Perte de donnes
Idem destruction +
Veille
Stock de pices de
rechange
Obtention des sources du
systme et des applications
spcifiques
S'assurer de la qualit de la
maintenance
Portabilit des applications
Vol
Perte de donnes
Perte de confidentialit
(donnes et savoir-faire)
Idem destruction +
Chiffrement des donnes
sensibles

Tableau 4 : Equipements informatiques et de tlcommunication (risques d'indisponibilit dfinitive)
46
Risques d'indisponibilit temporaire

Panne, bris de matriel
remplaable,

Perte de donnes
Interruption temporaire de
service
Perte de confidentialit
Procdure scurise de
mise en rparation
Contrat de maintenance
avec obligation de rsultat
Stock de maintenance
Optimisation de l'usage de
l'quipement
Obsolescence
Evolutions retardes ou
impossibles
Veille
Portabilit des applications
Stock de pices de
rechange
Saturation
service
Optimisation de l'usage de
l'quipement

Tableau 5 : Equipements informatiques et de tlcommunication (risques d'indisponibilit temporaire)
47
5.3 Systme d'exploitation, applications, donnes et flux

Perte d'un logiciel
Interruption de service
Perte de donnes
Sauvegarde haute scurit
des logiciels (scellement,
tests priodiques de
restauration)
Conservation des supports
d'origine et des diffrentes
mises jour
Externalisation des
sauvegardes de logiciels
Perte de donnes non
reconstituables
(effacement accidentel, erreur
d'exploitation, virus,
malveillance, destruction
volontaire, erreur de
paramtrage, ...)
Perte de donnes
Sauvegarde haute scurit
des donnes
Externalisation des
sauvegardes

Tableau 6 : Systme d'exploitation, applications, donnes et flux (risques d'indisponibilit dfinitive)
48

Menaces types Consquences
prciser
Parades considrer
flux par attaque logique
(saturation rseau)
Interruption temporaire
d'activit
Utilisation d'un autre moyen de
transmission
Surveillance du rseau
Perte de donnes
reconstituables
(effacement accidentel,
erreur d'exploitation, virus,
malveillance, destruction
volontaire, erreur de
paramtrage, ...)
Perte de donnes
Actions prventives
qualit de l'environnement
d'exploitation
qualit de l'organisation de
l'exploitation
lutte anti-virale
organisation globale de la scurit
Procdures de reconstruction de donnes
( partir de documents originaux, d'autres
fichiers, chez des clients ou partenaires)

Tableau 7 : Systme d'exploitation, applications, donnes et flux (risques d'indisponibilit temporaire)
49
5.4 Services, fournitures et prestations extrieurs

Disparition brutale dun
fournisseur ou d'un prestataire
Arrt du service ou de la
fourniture
Interruption
d'approvisionnement
Perte de donnes
Politique de diversification
envers les fournisseurs
Portabilit des services et
prestations extrieurs
Conformit aux standards du
march
Service ou produit de
substitution
Fonctionnement en mode
dgrad
Veille et audit fournisseurs
Disparition dun service ou d'un
produit
Arrt du service
Interruption
dapprovisionnements
(fournitures, nergie,
matires premires, )
Interruption de flux de
donnes
Perte de donnes
Exigence d'un plan de
secours du fournisseur
Services ou produits de
substitution ou
fonctionnement en mode
dgrad
Clause contractuelle
prvoyant un pravis et / ou
un service ou un produit de
substitution
Veille stratgique
Disponibilit d'une
documentation ncessaire
au service
Stock de secours
Arrt impos dun service ou
d'un produit (rglementation,
embargo, conflit)
Arrt du service
Interruption
dapprovisionnements
(fournitures, nergie,
matires premires, )
Interruption de flux de
donnes
Veille
Anticipation de larrt
Stock
Communication de crise

Tableau 8 : Services, fournitures et prestations extrieurs (risques d'indisponibilit dfinitive)
50

Menaces types Consquences
prciser
Parades considrer
Indisponibilit d'un service
tlcom souscrit auprs
d'un oprateur
Isolement total ou partiel
d'un site (voix,
donnes, )
Souscrire des engagements
contractuels de qualit de service
conformes aux exigences de
service :
garantie de temps de rtablissement
assorti de pnalits,
garantie de disponibilit
scurisation des moyens d'accs
(doublement physique des
infrastructures d'accs)
mise en uvre de solutions de repli
(bascule sur ligne de secours, repli
sur site de secours)
Diversification des fournisseurs (routage
automatique sur un autre oprateur)
Indisponibilit d'un service
oprationnel
contractualis avec un
prestataire extrieur (EDI,
ISP, ASP)
Retard de livraison
Interruption d'activit
totale ou partielle
Souscrire des engagements contractuels
de qualit de service conformes aux
exigences de service.
Certification ISO 9000 des services du
fournisseur
Si ncessaire, vrification d'existence d'un
plan de secours et de rapports de tests.
Diversification des moyens
Interruption prolonge de
la fourniture en nergie
lectrique
Interruption dactivit
totale ou partielle
Perte de donnes
Dysfonctionnements au
redmarrage
Groupe lectrogne rgulirement test
(fonctionnement et endurance)
Ddoublement des arrives et du poste
de transformation lectrique
Moyens de secours externes
Onduleur avec dispositif darrt scuris
des serveurs
Garanties contractuelles sur le dlai de
rtablissement du service
Mauvaise qualit de la
fourniture lectrique
(micro-coupures et
surtensions)
Perte de donnes
Dgradation
dquipements
Interruptions rptitives
dactivit
Mise en place dinterfaces de rgulation
entre larrive et les quipements :
interfaces dynamiques (groupes
dynamiques avec volant dinertie)
interfaces statiques (transfor-mateurs
disolement, rgulateurs de tension,
conditionneurs de rseau, onduleurs)

Tableau 9 : Services, fournitures et prestations extrieurs (risques d'indisponibilit temporaire)
51
5.5 Ressources humaines
Risques d'indisponibilit dfinitive

Disparition de personnel
stratgique
Perte de savoir-faire
Arrt temporaire ou dfinitif
d'activit
Blocage de systme ou
d'application (mot de passe,
maintenance,
exploitation, )
Blocage de dcision
Redondance des
comptences sur les
activits stratgiques
Dlgation de pouvoir
Assurance VIP
Documentation des tches
stratgiques
Consignes de scurit pour
les dplacements en groupe
Plan de remplacement
d'urgence ( recrutement,
sous-traitance, )
Dpart de personnel stratgique
Perte de savoir-faire
Arrt temporaire ou dfinitif
d'activit
Blocage de systme ou
d'application (mot de passe,
maintenance,
exploitation, )
Blocage de dcision
Dgradation de service ou
sabotage li aux conditions
de dpart
Plan de remplacement avec
priode de recouvrement
pour le transfert des
connaissances.
Redondance des
comptences sur les
activits stratgiques
Documentation des tches
stratgiques
Surveillance accrue du
personnel dmissionnaire et
limitation des droits
En cas de risque de
malveillance, dsactivation
immdiate des droits de la
personne (physiques et
logiques)

Tableau 10 : Ressources humaines (risques d'indisponibilit dfinitive)

52

Conflit social
Arrt temporaire, total ou partiel
d'activit
Risque de blocage volontaire de
locaux et / ou d'quipement (cf.
fiche locaux et infrastructure)
Politique sociale adapte la
fonction informatique
Externalisation des fonctions
vitales
Volant de personnel de secours
externe l'entreprise
Locaux et moyens de secours
externes et confidentiels
Difficults de transport
Arrt temporaire d'activits du
site
Risque d'arrt des quipements
Mise en place de moyens de
transport de secours (navettes,
organisation du covoiturage, ...)
Impressions dportes
Moyens de secours utilisateurs
minimum
Indisponibilit
accidentelle massive du
personnel (pidmie,
contamination, )
Arrt temporaire d'activits du
site
Risque d'arrt des quipements
Mdecine prventive
Maintenance prventive de la
climatisation (changement des
filtres, surveillance de la qualit
de l'air)
Volant de personnel de secours
externe l'entreprise

Tableau 11 : Ressources humaines (risques d'indisponibilit temporaire)
53
54
6 TABLE DES FIGURES ET TABLEAUX

Figure 1 : Dmarche de stratgie de secours_____________________________________________________ 4
Figure 2 : Dclenchement__________________________________________________________________ 11
Tableau 1 : Adquation risques / sauvegardes __________________________________________________ 32
Tableau 2 : Locaux et Infrastructure (risque dindisponibilit dfinitive des locaux)_____________________ 43
Tableau 3 : Locaux et infrastructure (risques d'indisponibilit temporaire des locaux) ___________________ 45
Tableau 4 : Equipements informatiques et de tlcommunication (risques d'indisponibilit dfinitive) ______ 46
Tableau 5 : Equipements informatiques et de tlcommunication (risques d'indisponibilit temporaire) _____ 47
Tableau 6 : Systme d'exploitation, applications, donnes et flux (risques d'indisponibilit dfinitive) ______ 48
Tableau 7 : Systme d'exploitation, applications, donnes et flux (risques d'indisponibilit temporaire) _____ 49
Tableau 8 : Services, fournitures et prestations extrieurs (risques d'indisponibilit dfinitive) ____________ 50
Tableau 9 : Services, fournitures et prestations extrieurs (risques d'indisponibilit temporaire) ___________ 51
Tableau 10 : Ressources humaines (risques d'indisponibilit dfinitive) ______________________________ 52
Tableau 11 : Ressources humaines (risques d'indisponibilit temporaire) _____________________________ 53

55
56
7 GLOSSAIRE
PCA [correspond BCP =Business Contingency Plan]
Plan de Continuit d'Activit. Il a pour but de garantir la survie de l'entreprise, en prparant
l'avance la continuit des activits dsignes comme stratgiques. Il n'est pas limit au Plan de
Secours Informatique.

PSI [correspond DRP =Disaster Recovery Plan]
Plan de Secours Informatique. Sous-ensemble du PCA qui couvre les moyens informatiques.
Il garantit la reprise des systmes dsigns comme critiques dans le temps minimum fix. Il
garantit galement la reprise des donnes avec le minimum de perte fix.

Plan de secours
Dans ce document, c'est un terme gnrique qui dsignera soit le PSI, soit le PCA.

Dlai de reprise [correspond RTO =Return Time Objective]
C'est le dlai total ncessaire entre l'arrt de l'activit et la remise disposition de
l'informatique aux utilisateurs.

Degr de fracheur des donnes [correspond RPO =Recovery Plan Objective]
Selon les besoins exprims, le degr de fracheur des donnes correspond la perte des
donnes considre comme acceptable entre l'arrt de l'activit et sa reprise. Par exemple, au
dmarrage aprs sinistre, les donnes peuvent dater de la veille au soir, du matin ou de la
minute du sinistre.

Comit de crise
Il est compos des responsables de chaque Direction utilisatrice concerne par le plan de
secours. Il comprend galement des membres de la Direction Gnrale, de la Direction des
Services Gnraux, de la Direction des Ressources Humaines, de la Direction de la
Communication, de la Direction Informatique et des responsables du plan de secours. Son rle
est de se runir en cas d'incident grave pour dcider de dclencher ou non le plan de secours.

Salle de runion du comit de crise
Dsigne lendroit o le comit de crise se runit en cas de ncessit. Il est situ dans un
primtre proche de l'environnement cibl par le plan de secours mais ne doit pas tre
adjacent celui-ci. Il est en gnral quip dau minimum un tlphone, 1 fax et un coffre-fort
dans lequel se trouvent les procdures du plan de secours.

Procdures techniques
Elles dcrivent les actions faire par la Direction Informatique au quotidien pour garder les
moyens techniques de secours jour. Elles dcrivent galement les actions faire en cas
d'activation du PSI ou loccasion des tests. Elle est crite par la Direction Informatique.

57
Plan de test
Il permet dans un premier temps de valider ce qui a t mis en place par rapport aux besoins
exprims. Puis, intervalle rgulier il permet de garantir le caractre oprationnel du PSI.

Load Balancing
Solution technique, base sur une duplication applicative et mettant en uvre de 2 n
serveurs des fins dquilibrage de ressources. Cette technique permet de maintenir la
disponibilit des applications en cas darrt dun ou plusieurs serveurs. Lintgrit des
donnes est prserve par une propagation des mises jour sur tous les serveurs. Toutefois, la
session en cours est perdue en cas darrt brutal du serveur en cours dutilisation.
Dans le cadre dun PSI, la possibilit de rpartir ces machines sur deux sites
gographiquement diffrents doit tre tudie.

Cluster de serveurs
Solution technique de secours s'appuyant sur 2 n machines en grappe et partageant en
commun lensemble des ressources ncessaires maintenir la disponibilit des services. En
cas darrt brutal dune ressource, seule la transaction en cours est ventuellement perdue.

Mirroring
Solution de secours s'appuyant sur des techniques de duplication en temps rel des donnes
enregistres, soit en mode synchrone, soit en mode asynchrone. La duplication des donnes
dun serveur peut tre partielle ou totale, de prfrence distante, selon le niveau de scurit
atteindre et les contraintes techniques de lenvironnement informatique.

58

PlanContinuiteActivite PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PlanContinuiteActivite PDF

Transféré par

Droits d'auteur :

Formats disponibles

Dossier technique

Plan de Continuit dActivit

Vous aimerez peut-être aussi