Plan de reprise d'activité

Pour les articles homonymes, voir Recovery (homonymie) et DRP.

La forme ou le fond de cet article est à vérifier. Améliorez-le ou discutez des points à vérifier. Si vous venez d’apposer le bandeau, merci d’indiquer ici les points à vérifier.

Cet article ne cite pas suffisamment ses sources. Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références » (modifier l'article, comment ajouter mes sources ?).

En informatique, un Plan de reprise d'activité (en anglais : Disaster Recovery Plan ou DRP) permet d'assurer, en cas de crise majeure ou importante d'un centre informatique, la reconstruction de son infrastructure et la remise en route des applications supportant l'activité d'une organisation.

Le plan de reprise d'activité doit permettre, en cas de sinistre, de basculer sur un système de relève capable de prendre en charge les besoins informatiques nécessaires à la survie de l'entreprise. Il existe plusieurs niveaux de capacité de reprise, et le choix doit dépendre des besoins exprimés par l'entreprise.

Le plan de reprise d’activité a actuellement un rôle majeur pour les systèmes d’information. En effet, depuis certains évènements comme les attentats du 11 septembre 2001 notamment, les dirigeants et les responsables d’entreprises sont devenus conscients de l’importance de leur système d’information. Aujourd’hui, la simple sauvegarde ne suffit plus. Voici quelques chiffres clés pour comprendre la mise en place du plan :

• 94% des salariés dans une entreprise déclarent la perte de dossiers informatiques.
• 82% des PME non préparées à un sinistre ne survivent pas à un important crash informatique.

Le Plan de reprise d’activité (PRA) est à distinguer du Plan de continuité d'activité (PCA) : ce dernier a pour objectif de poursuivre l'activité sans interruption du service et d’assurer la disponibilité des informations quels que soient les problèmes rencontrés. Le PRA en est un sous-ensemble, qui décrit les mesures qui doivent être déclenchées à la survenue d'un sinistre ou incident majeur ayant entraîné une interruption de l'activité.

Objectifs et détermination des besoins

Les entreprises ne peuvent pas toujours détourner les catastrophes, mais avec une prévision prudente, les effets d’un sinistre ou d’un désastre peuvent être atténués. L’objectif d’un PRA est de minimiser les temps morts et la perte de données. L’objectif premier est de protéger l’organisation dans l’éventualité qu’une partie ou la totalité de ses opérations et services informatiques soit inutilisables. Le PRA minimise la perturbation des opérations et assure un certain niveau de stabilité organisationnelle et le rétablissement de ces données sera prioritaire après le désastre.

Un système de reprise peut être extrêmement coûteux à mettre en place et à maintenir au sein de l’organisation. Il est donc essentiel de définir convenablement les attentes du système de reprise.

Les besoins de l’organisation sont mesurés à l’aide de deux concepts :

Par exemple, dans le secteur bancaire, et plus particulièrement dans le cadre d'un système de gestion de trading, on peut définir un RTO d'une heure avec un RPO de 0 secondes, sans mode dégradé. Aucune transaction ne sera ainsi perdue, et le service pourra être disponible sous une heure.

Les domaines métiers les plus concernés par des enjeux de continuité d'activité sont la messagerie (pour 61 % d’entre elles), les applications de finance (46 %) et de production (46 %), pour l’industrie notamment. Dans peu de temps, les applications de gestion de la relation client et de ressources humaines seront de plus en plus touchées, ainsi que les applications de communication sous IP et les environnements bureautiques. Il faut aussi citer les applications de commerce électronique, tout particulièrement dans la distribution.

Types de catastrophes et leurs conséquences

Un entreprise peut connaître des catastrophes naturelles, du fait de l’homme (attentat) ou encore de la technologie, pouvant engendrer des conséquences parfois désastreuses.

Catastrophes naturelles et leurs conséquences

Les catastrophes naturelles sont depuis toujours ancrées dans l’histoire humaine. Le terme « catastrophe naturelle » évoque un évènement soudain qui expose les habitants d’une ville et leurs infrastructures à de lourds dégâts. On peut distinguer les catastrophes climatiques et les catastrophes telluriques. Ces deux types de catastrophes sont lourds de conséquences. Concernant les catastrophes climatiques, elles peuvent être de différentes formes : tempêtes, inondations, cyclones, sécheresses ou encore grandes chaleurs. Les conséquences de ces sinistres peuvent être :

• Perte d’un immeuble ou d’un local : elle peut être causé par une coupure électrique, un feu, une tempête, un cyclone, un tsunami ou bien une inondation.  La perte d’un immeuble peut entrainer la perte d’un centre de données, qui est une conséquence dramatique pour l’entreprise. Cela peut impacter l’ensemble des parties prenantes et avoir de graves répercussions.
• Désastre à grande échelle (ville, région, pays) : Ce sont des sinistres avec une très faible probabilité mais qui nécessite d’être évoqué de par leurs conséquences. Les cyclones ou les tremblements de terre peuvent interrompre l’ensemble des activités informatiques d’une zone géographique. Par exemple : Les tremblements de terre au Japon ou le cyclone Katrina.

Catastrophes humaines et technologiques et leurs conséquences

En ce qui concerne les catastrophes humaines et technologiques, nous pouvons distinguer les incidents intentionnels et non intentionnels :

• Les incidents d’origines intentionnelles : le système d’information d’une entreprise ne peut pas être totalement sécurisé car il y a des évènements contre lesquels elle ne peut pas lutter. Exemples : attentats, bombardements, sabotages, émeutes, grèves. Mais il y a d’autres attaques contre lesquels l’entreprise peut tenter de se défendre. Exemples : virus, cyberattaque, piratage informatique, logiciels malveillants.
• Les incidents d’origines non intentionnelles : Il est assez fréquent qu’une application cesse de fonctionner du fait d’une erreur humaine. Cela peut être dû à une mauvaise configuration des éléments composant le réseau (routeurs, pare feux…) ou car une application n’a pas été correctement écrite.

Les conséquences de ces incidents peuvent être diverses, notamment entrainer une coupure des communications, ainsi les systèmes reliés ne peuvent plus échanger de données et on assiste alors à une perte d’informations, une saturation, une panique système ou un arrêt des activités. Une entreprise peut aussi subir la perte des applications installées.

Types de mesures

Le Plan de Reprise d’Activité idéal n’existe pas. Il faut qu’il soit adapté à chaque organisation. Néanmoins, il y a trois stratégies de base qui figurent dans tous les plans de reprise :

Mesures préventives

Les mesures préventives vont tenter de prévoir l’occurrence d’incidents. Ces mesures cherchent à identifier et réduire les risques. Elles sont créées pour atténuer ou prévenir la fréquence des sinistres ou des désastres. Ces mesures peuvent inclure de garder des sauvegardes de données, d’installer des générateurs et de conduire des inspections du quotidien.

Mesures détectives

Les mesures détectives sont prises pour détecter la présence d’éléments indésirables dans le système d’information de l’organisation. Leur but est de découvrir de nouvelles menaces potentielles. Elles peuvent mettre en avant des évènements non-désirés. Ainsi, l’organisation doit mettre en œuvre différentes mesures :

• Installer des logiciels anti-virus à jour et les renouveler,
• Mettre en place des sessions de formation des salariés,
• Installer des logiciels de contrôle/surveillance des serveurs et des réseaux,
• Sauvegarder des données avec des solutions adaptées à l’organisation,
• Mettre en place des systèmes de secours.

Mesures correctives

Les mesures correctives visent à restaurer un système après un événement indésirable (sinistre, désastre). Ces mesures portent sur la fixation ou la restauration des systèmes d’information après l’incident. Elles peuvent inclure la tenue de documents critiques dans le plan de reprise d’activité ou la souscription à des polices d'assurance adaptées à l’organisation. Dans toutes les organisations, un Plan de Reprise d’Activité doit permettre de répondre aux interrogations suivantes :

1. Quel est son objectif et son but ?
2. Quelles sont les personnes ou équipes responsables si des perturbations surviennent?
3. Que feront ces personnes quand l’incident surviendra ?

Exemple

Exemple de mesure : MEHARI (Méthode Harmonisée d'Analyse de Risques) qui est une méthode complète d’évaluation et de management des risques liés à l'information, ses traitements et les ressources mises en œuvre.

Méthodologie

Selon Geoffrey H. Wold (Disaster Recovery Journal)^[2], tel que cité dans un rapport du SANS^[3], le processus entier de développement d'un Plan de reprise d’activité se déroule en 9 étapes :

Étape 1 : Obtenir l'engagement de la haute direction

Pour qu’un plan de reprise d’activité soit réussi, la responsabilité centrale du plan doit dépendre de la direction. Celle-ci est responsable de coordonner le plan de reprise d’activité et d’assurer son efficacité dans l'organisation. Elle est aussi chargée de répartir le temps et les ressources nécessaires, à la fois financières et relatives à l'effort que tout le personnel concerné doit fournir.

Étape 2 : L'établissement d'un comité de planification

La direction générale de l’entreprise nomme un comité de planification pour surveiller le développement et la mise en œuvre du plan. Il inclut des représentants de tous les services fonctionnels de l'organisation et il compte aussi habituellement le directeur du service informatique. Le comité définit aussi la portée du plan.

Étape 3 : Procéder à une évaluation des risques

Le comité de planification prépare une analyse de risque et une analyse d'impact sur l’activité qui inclut une gamme d’incidents possibles, y compris des menaces naturelles, technologiques et humaines. Chaque service de l'organisation est analysé pour déterminer la conséquence potentielle et l'impact associé à plusieurs scénarios de désastre. Le processus d'évaluation des risques évalue aussi la sécurité des documents importants. Traditionnellement, le feu a constitué la menace la plus importante pour une organisation. Cependant on devrait aussi considérer la destruction humaine intentionnelle. L’entreprise doit prévoir un plan minutieux présentant comme situation « le pire cas », c’est-à-dire la destruction du bâtiment principal. Il est important d'évaluer les impacts et les conséquences résultant de la perte d'informations et des services.

Étape 4 : Établir des priorités pour traiter l’incident

À ce point, les besoins critiques de chaque département de l'organisation sont évalués pour établir un ordre de priorités. L'établissement de priorités est important car aucune organisation ne possède des ressources infinies.

Une méthode utilisée pour déterminer les besoins critiques d'un département est de documenter toutes les fonctions exécutées par chaque département. Une fois que les fonctions principales ont été identifiées, les opérations et les processus sont alors classés par ordre de priorité : élément essentiel, important et non essentiel.

Étape 5 : Déterminer les stratégies de récupération

Pendant cette phase, des recherches sur les alternatives les plus pratiques de traitement en cas de désastre sont faites et évaluées. On considère tous les aspects de l'organisation, y compris les installations physiques, le matériel informatique et les logiciels, les lignes de communication, les fichiers de données et les bases de données, les services clients, les opérations d'utilisateurs, les systèmes d'information de gestion, la structure, les systèmes d'utilisateur final et les autres traitements.

Des accords écrits sont préparés en spécifiant la durée de contrat, les conditions de fin, le test de système, le coût, la procédure pour la notification de changement de système, le matériel spécifique, la définition des circonstances constituant l'année de secours, la garantie de compatibilité…

Étape 6 : Organiser et documenter un plan écrit

Ensuite, un plan est préparé pour guider le développement des procédures détaillées. La direction générale passe en revue et approuve le plan proposé. Le plan est utilisé pour la table des matières après la révision finale. D'autres avantages de cette approche sont :

• Il aide à organiser les procédures détaillées,

• Il identifie tous les étapes majeures avant que le processus d'écriture réel ne commence,

• Il identifie des procédures superflues qui doivent être écrites seulement une fois,

• Il fournit une feuille de route pour développer les procédures.

On le considère souvent comme la meilleure pratique pour développer un format standard du plan de reprise d’activité.

L'équipe de direction est particulièrement importante car elle coordonne le processus de reprise. L'équipe évalue l’incident, active le plan de reprise et contacte les directeurs d'équipe. Elle surveille aussi les documents et contrôle le processus de reprise.

Étape 7 : Le développement de critères et procédures d'essai

Les meilleures pratiques dictent que les plans doivent être testés et évalués sur une base régulière (au moins une fois par an). Il faut une documentation avec les procédures pour tester le plan. Les tests fourniront à l'organisation l'assurance que toutes les étapes nécessaires sont incluses dans le plan.

Il existe aussi d'autres raisons de tester le plan de reprise d’activité :

• Déterminer la faisabilité et la compatibilité des installations de secours et des procédures,
• Identifier les zones du plan qui doivent être modifiées,
• Former les managers et les membres des équipes,
• Montrer la capacité de l’organisation à reprendre l’activité,
• Fournir une motivation pour maintenir et mettre à jour le PRA.

Étape 8 : Tester le plan

Après que le test de procédures ait été effectué, "une répétition" initiale du plan est exécutée. Le test fournira des informations supplémentaires quant aux nouvelles étapes qui devront être incluses, aux changements des procédures qui ne sont pas efficaces et aux autres rajustements appropriés. Ceux-ci ne peuvent pas devenir évidents à moins qu'un réel test d'essai ne soit exécuté. Le plan est par la suite mis à jour pour corriger n'importe quel problème identifié pendant le test.

Les différents types de tests sont : tests de liste de contrôle, tests de simulation, tests parallèles et interruption complète.

Étape 9 : Obtention de l'approbation du plan

Une fois que le PRA a été écrit et testé, le plan est alors soumis à la direction pour approbation. Celle-ci doit donner son accord pour la mise en place d’un PRA.

Avantages et inconvénients du PRA

Avantages

Comme chaque plan d’assurance, il y a des avantages qui peuvent être obtenus par l’élaboration d’un PRA. Parmi ces avantages, il y a :

• Assurer la continuité de l’entreprise en cas de catastrophe,
• Apporter un sentiment de sécurité : un plan de continuité est très bien perçu par les actionnaires et par le marché,
• Minimiser le risque de retard dans les activités de l’entreprise,
• Garantir la fiabilité des systèmes,
• Fournir une norme pour tester le plan : Possibilité de tester les procédures de sauvegarde,
• Minimiser la prise de décision pendant l’incident,
• Les paramètres SLA (Service Level Agreement) garantissent une haute qualité de services.

Inconvénients

Voici les inconvénients et les erreurs courantes, liées au PRA que les organisations font :

• Coût élevé
• Manque d’appropriation : les dirigeants ont tendance à voir le PRA comme un simple exercice, et n’en font donc pas une priorité, ce qui est source d’échec du plan.
• La durée maximale d'interruption admissible et la perte de données maximale admissible ne sont pas toujours définies : Chaque article d’un PRA exige de fixer la durée maximale d'interruption admissible, c'est-à-dire qu'il faut définir le temps mort de processus maximal, ou la perte de données maximale admissible, c'est-à-dire le choix d'un point acceptable de reconstitution/reprise. C’est le minimum sinon on risque d'augmenter l'impact du désastre.
• Myopie de système : Une autre source d'échec est de se concentrer seulement sur le PRA sans considérer les plus grands besoins de continuité d'activité (les processus et services de l’entreprise auront besoin du support informatique et donc d’une planification et des ressources.
• Sécurité insuffisante : Quand il y a un incident, les données de l’organisation et les processus deviennent vulnérables. De ce fait, la sécurité peut devenir plus importante que la vitesse impliquée dans l’Objectif de Temps de Récupération du PRA.
• Plans obsolètes : Un autre aspect souvent oublié est la fréquence avec laquelle le PRA doit être mis à jour. On recommande au moins une mise à jour par an, et après chaque acquisition ou changement majeur de l’entreprise.

Références

1. ↑ « Karim Abdi, Exam-PM, Sinistres informatiques » (consulté le 27 novembre 2014)
2. ↑ (en) « Disaster Recovery Journal » (consulté le 27 novembre 2014)
3. ↑ (en) « SANS Insititute, Disaster Recovery Plan Strategies and Processes » (consulté le 27 novembre 2014)

Voir aussi

Liens externes

• http://www.overlap.fr/plan-de-reprise-dactivite

Articles connexes

• Méhari

• Sécurité des systèmes d'information

• Plan de continuité d'activité (informatique)

Ouvrages

• Plan de continuité d'activité : concepts et démarche pour passer du besoin à la mise en œuvre du PCA de Bernard Carrez, Antonio Pessoa, Alexandre Planche, Bruno Brocheton. (2013, 318p)
• Plan de continuité d'activité : secours du système d'information de Patrick Boulet. (2008, 232p)
• Plan de continuité d'activité et système d'information : vers l'entreprise résiliente de Matthieu Bennasar. (2006, 267p)

• Portail des entreprises
• Portail de l’informatique