Plan de reprise d'activité (informatique) — Wikipédia

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

Le fond de cet article sur l'informatique est à vérifier (septembre 2016).

Améliorez-le ou discutez des points à vérifier. Si vous venez d’apposer le bandeau, merci d’indiquer ici les points à vérifier.

Un plan de reprise d'activité (PRA) est un ensemble de procédures (techniques, organisationnelles, sécurité) qui permettent à une entreprise de prévoir par anticipation, les mécanismes pour reconstruire et remettre en route un système d'information en cas de sinistre important ou d'incident critique^[1].

En cas de sinistre, Le PRA permet de reconstruire les serveurs en leur affectant les données répliquées et ainsi de redémarrer les applications sous quelques minutes ou quelques heures, suivant les solutions retenues. Il existe plusieurs niveaux de capacité de reprise, et le choix doit dépendre des besoins exprimés par l'entreprise.

Les entreprises actuelles dépendant de plus en plus de leur informatique, elles ne peuvent donc plus se permettre de ne pas avoir une solution face à un incident informatique, qui pourrait leur être fatal ou entraîner une paralysie de l’activité professionnelle. Le plan de reprise d’activité a alors un rôle majeur pour assurer le redémarrage structuré des systèmes d’information. Ce plan peut être détenu par l’entreprise ou confié à un prestataire.

Le PRA est comme une assurance, tant qu'il n'y a pas d’accident, on ne voit pas l’intérêt.

Aujourd’hui, la simple sauvegarde ne suffit plus.

Voici quelques chiffres clés pour comprendre la mise en place du plan :

• 76 % des entreprises déclarent la perte de données informatiques sur les deux dernières années^[2].
• 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 hiérarchiquement l’ensemble des mesures qui doivent être mises en place lors de la survenue d'un sinistre ou d’un incident majeur ayant entraîné une interruption de l'activité. Le PRA définit les architectures, les moyens et les procédures nécessaires à mettre en œuvre pour assurer la protection des applications qu’il couvre.

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 :

Les États-Unis depuis plusieurs années ont déjà imposé des contraintes aux entreprises quant à leurs sauvegardes de données (HIPAA, pour les caisses d’assurances maladie et PCI-DSS pour le milieu bancaire)

La France y arrive peu à peu, en imposant de plus en plus le PCA, notamment grâce aux nouvelles législations qui imposent à certains types d’entreprise la maîtrise de leurs activités essentielles et des risques attachés. Le CRBF (Comité de la réglementation bancaire et financière) par exemple pour le secteur bancaire.

Il y a trois grandes catégories de sinistres pouvant causer la perte totale ou partielle de votre système d’information. Certains d’entre eux impliquent une perte de données ne pouvant être récupérées que par une sauvegarde externalisée.

Le terme « catastrophe naturelle » évoque un événement soudain qui expose les habitants d’une ville et leurs infrastructures à de lourds dégâts. Elles peuvent être de différentes formes : tempêtes, inondations, cyclones, tremblements de terre, 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. Elle peut entraîner la perte d’un centre de données, qui est une conséquence dramatique pour l’entreprise.
• Désastre à grande échelle (ville, région, pays) : Ce sont des sinistres dont la très faible probabilité nécessite d’être évoquée compte-tenu de 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.

Ce sont des sinistres, d’origines variées qui peuvent affecter les installations. Ils peuvent être intentionnels (vol, attentat, sabotage) ou non intentionnel (incendie, dégâts des eaux).

Selon une étude menée par Symantec, les cybers-criminels planifient avec rigueur leurs offensives. Les entreprises sont de plus en plus ciblées car les informations qu’elles détiennent sont d’une grande valeur. Le détournement de ces données est source d’enrichissement illicite. Les cyber-escrocs les mieux organisés ne se contentent plus de contaminer de front les réseaux, ils préfèrent s’introduire dans les systèmes par le biais de partenaires commerciaux. En 2014, le pourcentage d’incidents attribués aux fournisseurs de services, consultants ou sous-traitants a progressé respectivement de 18 % et 15 %.

Les attaques sont variées : virus, cyberattaque, piratage informatique, logiciels malveillants. Le sabotage d’installations industrielles est une autre alternative. Dans certains cas, ces attaques peuvent paralyser l'activité professionnelle, ou encore entraîner une perte de données conséquente

Les conséquences de ces incidents peuvent être diverses, notamment entraîner 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.

Les autres causes de pertes de services ou de données sont dues à des facteurs internes aux organisations ou à leur partenaires proches :

• pertes de services essentiels (électricité, communications),
• erreurs de manipulation (saisies, erreurs de programmation, de configuration de l'infrastructure),
• vols de matériel,
• pannes matérielles.

Ces causes de panne sont souvent négligées car sous estimées : on fait confiance aux fournisseurs de téléphonie, aux employés, à la qualité du matériel utilisé.

En France, nombreuses sont les entreprises qui négligent ces aspects^[4]

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 :

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.

Les mesures préventives peuvent inclure :

• des sauvegardes de données très régulières,
• de prévoir un plan de reprise d'activité précis et testé régulièrement.
• d’installer des générateurs et de conduire des inspections du quotidien.

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 pour diminuer le phénomène de shadow IT,
• Installer des logiciels de contrôle/surveillance des serveurs et des réseaux,

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 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.

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

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.

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.

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.

À 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.

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é…

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 toutes 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.

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.

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.

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.

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 reprise 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.

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

• Coût pouvant être élevé, si investissement dans les infrastructures. Ici les nouvelles solutions de PRAaaS (as a Service) dans le Cloud Public Cloud computing^[7] permettre de faire disparaître cet inconvénient ;
• 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.

La révolution du Cloud et de son modèle aaS ouvre de nouveaux horizons pour la mise en oeuvre d'un PRA^[8] en proposant des solutions permettant de réduire significativement les coûts d'investissement liés à un PRA traditionnel. Les plans de secours traditionnels basés sur des infrastructures propriétaires migrent donc progressivement vers le PRAaaS ou Disaster-Recovery-as-a-Service (aussi appelé simplement RaaS : Recovery-as-a-Service). Cette évolution a été constatée notamment aux États-Unis^[9].

Bien que les avantages du Cloud Computing^[7] commencent à être connus, les PME et certaines ETI ne franchissent pas encore totalement le pas ; elles ne pensent au Cloud que pour certaines applications périphériques ou pour tester une nouvelle application. Passer l'intégralité de son système d'information dans le Cloud suppose, pour en tirer tous les avantages, de modifier en profondeur son mode d'achat et de consommation de l'informatique. 

Mettre en place un PRA dans le Cloud présente des avantages :

• Les délais de redémarrage sont plus rapides^[10] qu’avec des sites distants classiques et cela grâce à l’élasticité du Cloud. Il devient possible d’atteindre un délai de redémarrage de quelques heures.
• Le PRA dans le Cloud présente un meilleur rapport qualité-prix par rapport aux solutions classiques, grâce au principe du paiement à l’usage (pay as you go). Les entreprises nord-américaines qui ont opté pour le PRA dans le Cloud (DRaaS), par exemple Aws ont atteint une réduction de 30 à 70 % de leur budget PRA^[11],[12] ;
• L’amélioration du contrôle de son PRA^[10]et notamment la possibilité de le lancer depuis une console d’administration (de façon automatisée) sans requérir l’intervention du fournisseur de PRA a un effet très positif sur les délais de redémarrage. Il devient alors plus facile de réaliser des tests de la solution, ce qui améliore la confiance que l’on place dans son PRA ;
• L’évolution de périmètre^[13], à la hausse comme à la baisse, est beaucoup plus aisée, puisqu’il ne s’agit plus d’investir dans du matériel mais plus simplement de répliquer des données ;
• Permet aux DSI de se recentrer sur le corps de métier de l'entreprise, sur l'innovation ;
• Enfin, les fournisseurs offrent des contrats beaucoup plus flexibles^[10],[14], en termes de durée : 3 ans minimum pour des solutions classiques, contre 1 an, ou moins, pour des solutions de PRA dans le Cloud, avec des clauses de réversibilité peu onéreuses^[15].

Le choix du Cloud, notamment public, est une opportunité pour les PME et ETI de mettre en place un véritable Plan de Reprise d'Activité et non plus de se limiter à de simples sauvegardes dont la restauration reste le plus souvent aléatoire en l'absence de tests.

Les risques liés au PRA dans le Cloud sont similaires à ceux du Cloud en général, mais également chez un prestataire traditionnel de PRA ^{[réf. nécessaire]} :

• Risques liés à la confidentialité des données^[16] : les données très critiques d’une entreprise, ainsi que celles sensibles vis-à-vis de la législation RGPD, devront être protégées par des solutions de chiffrement ;
• Risques liés au contrat^[17] : clauses de réversibilité, engagements concernant les niveaux de services, durée d’engagement ;
• Risques de performances : sur les vitesses de réplication, sur les temps de redémarrage, l’accès aux données… ^[17]

Certains risques sont spécifiques au modèle PRA dans le Cloud :

• La capacité du Cloud à fournir une architecture de sécurité de même niveau que le système d’information origine (équivalent VLAN, règles de pare-feu adaptées, monitoring des serveurs, filtrage URL, …) ;
• L’architecture du cloud qui doit offrir des débits importants en interne entre les disques de stockage de données et son infrastructure de serveurs virtuels (VM).

Il existe encore des limites à la mise en œuvre d’un PRA dans le Cloud qui sont principalement :

• Certaines applications très anciennes (exemple : serveur Windows 2000) ne sont pas virtualisables, ou alors la virtualisation de certaines fonctions n’est pas souhaitable pour des raisons de performances (exemple : très grande base de données) ; 
• Certains protocoles ne sont plus acceptés dans le Cloud pour des raisons de sécurité (TLS1.0 et SSL, ce qui induit que certains OS comme Windows Server 2003 ne sont plus compatibles) ;
• Certains systèmes d’exploitation propriétaires (OS/400, Z/OS d’IBM, HP-UX…) ne sont pas supportés dans les principaux Cloud publics ;
• Les coûts télécoms, liés à la zone d’implantation de la salle informatique (pas de solution de lien fibre ou télécom) sont trop élevés pour permettre la réplication des données en mode asynchrone ;
  • Dans ces cas particuliers, il faut alors se rediriger vers des offres classiques de PRA (au moins pour les applications impactées par ces limites).

Dans tous les cas (PRA traditionnels et PRA Cloud) les sujets qui doivent être vérifiés et testés :

• Le fonctionnement du PRA par des tests au moins semestriels ;
• La reconnexion des utilisateurs au site de secours informatique par un moyen de télécommunication adapté (réseau MPLS, lien de secours 4G, …).

Il est donc important d’analyser ces différents points lors du choix d’un prestataire de PRA Cloud.

En cas de sinistre, d'incident critique ou simplement de test, le site informatique principal est déclaré hors service. Tout se passe maintenant dans le Cloud pour la Reprise d’Activité.

Les données, d’applications et de systèmes, qui avaient été répliquées dans le Cloud pendant la phase de sauvegarde, y sont restaurées sous forme de disques virtuels. Ils sont attachés aux serveurs virtuels (VM) qui sont maintenant réveillés dans le Cloud.

Le système de télécommunications, qui avait été configuré au préalable, est activé pour permettre la connexion des utilisateurs. Il est opéré, en mode sécurisé, à travers un réseau privatif ou Internet.

• Plan de continuité
• Méthode harmonisée d'analyse des risques (|MEHARI)
• Sécurité des systèmes d'information
• Plan de continuité d'activité (informatique)

• 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, 318 p)
• Plan de continuité d'activité : secours du système d'information de Patrick Boulet. (2008, 232 p)
• Plan de continuité d'activité et système d'information : vers l'entreprise résiliente de Matthieu Bennasar. (2006, 267 p)

• Club de la sécurité de l'information français (CLUSIF)

• Portail de la sécurité informatique
• Portail de l’informatique
• Portail des entreprises