Accueil🇫🇷Chercher

Plan de reprise d'activité (informatique)

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.

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 :

Durée maximale d'interruption admissible (Recovery Time Objective : RTO[3]) C’est le délai de rétablissement d’un processus, à la suite d'un incident majeur, pour éviter des conséquences importantes associées à une rupture de la continuité d'activité. Il définit le temps alloué pour faire le basculement vers le nouveau système.
Perte de données maximale admissible (Recovery Point Objective : RPO) Le RPO commence à s’exprimer à l'instant où l’incident majeur arrive et peut être exprimé en secondes, minutes, heures ou jours. Il s’agit donc de la quantité maximale acceptable de perte de données. C'est la durée des fichiers ou des données dans le stockage de secours exigé par l’organisation pour reprendre des opérations normales après l’incident. Ce critère définit l'état dans lequel doit se trouver le nouveau système après basculement.

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.

Les trois types de sinistres informatiques et leurs conséquences

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.

Catastrophes naturelles

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.

Sinistres sur les installations

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

Cybercriminalité et malveillance

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.

Autres causes

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]

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.

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.

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

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)[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 :

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

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

Inconvénients

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.

Le PRA dans le Cloud : le modèle as a service du cloud au service du PRA

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. 

Le bénéfices du PRA dans le cloud

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

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 [16] :

  • Risques liĂ©s Ă  la confidentialitĂ© des donnĂ©es[17] : 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[18] : 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… [18]

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

Les limites

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

Les points de vigilance

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.

MĂ©canisme d'action lors d'un sinistre

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.

Principales différences entre un PRA traditionnel, un PRA dans un Cloud privé et une solution dans le Cloud public

Solutions de PRA internes à l’entreprise Plan de Reprise d'Activité informatique dans le Cloud privé Plan de Reprise d'Activité informatique dans le Cloud public
Délais de redémarrage le plus souvent supérieurs à 48 heures En cas de sinistre ou d'incident, capacité à démarrer les applications critiques en quelques heures En cas de sinistre ou d'incident, capacité à démarrer les applications critiques en quelques heures
Nécessité d'investir dans des matériels : serveurs, stockage, réseau Début de mutualisation de l’investissement si le Cloud privé est partagé entre plusieurs clients, mais engagement contractuel en général de 3 ans pour garantir le retour sur investissement Limitation de la facturation aux seules données répliquées ; les serveurs ne sont facturés que lorsqu'ils sont utilisés lors des tests ou en cas de reprise effective d'activité – Pas d’engagement contractuel de durée (1 an)
Mobilisation de ressources internes (DSI) pour la maintenance des infrastructures Libération de ressources permettant à la DSI de se consacrer à l’amélioration de l’efficacité des métiers, la mise en œuvre de nouveaux projets Libération de ressources permettant à la DSI de se consacrer à l’amélioration de l’efficacité des métiers, la mise en œuvre de nouveaux projets
DifficultĂ©, complexitĂ© et coĂ»ts pour organiser les tests de plan de reprise informatique et tĂ©lĂ©com, qui sont ainsi rarement faits Test de restauration des environnements variable suivant technologies employĂ©es  Test de restauration automatisĂ© et industrialisĂ© des environnements 
Prise en compte de l'Ă©volution du pĂ©rimètre Ă  secourir (ajout et suppression d'applications) complexe Ă  mettre en Ĺ“uvre Prise en compte de l'Ă©volution du pĂ©rimètre Ă  secourir (ajout et suppression d'applications) complexe Ă  mettre en Ĺ“uvre Mise Ă  jour du pĂ©rimètre très facile grâce Ă  la souplesse du Cloud public 

Références

  1. Matthieu Bennasar, Plan de Continuité d'Activité et système d'information : vers l'entreprise résiliente, Paris, Dunod, , 266 p. (ISBN 2-10-049603-4), p. 26
  2. (en) Ponemon Institute, « Closing Security Gaps to Protect Corporate Data: A Study of US and European Organizations », Ponemon Institute© Research Report,‎ (lire en ligne)
  3. « Karim Abdi, Exam-PM, Sinistres informatiques » (consulté le )
  4. Clusif, « Rapports sur les Menaces Informatiques et Pratiques de Sécurité en France (MIPS) », sur Clusif.fr
  5. (en) « Disaster Recovery Journal » (consulté le )
  6. (en) « SANS Insititute, Disaster Recovery Plan Strategies and Processes » (consulté le )
  7. Guillaume Plouin, Cloud Computing, Dunod, , 288 p. (ISBN 978-2-10-074259-2, lire en ligne)
  8. Benoit Grass et Nicolas Planson, « Le Disaster Recovery as a Service (DRaaS) révolutionne-t-il le plan de reprise IT ? », IT-Expert Magazine,‎ (lire en ligne)
  9. (en) « Magic Quadrant for Disaster Recovery as a Service », sur Gartner, (consulté le )
  10. (en-US) « Cloud-Based Disaster Recovery: Why DRaaS is a Welcome Game-Changer - Leapfrog IT Services », Leapfrog IT Services,‎ (lire en ligne, consulté le )
  11. (en) « advantages of cloud computing » (consulté le )
  12. (en) « Reducing the Total Cost of IT Infrastructure », sur aws (consulté le )
  13. (en) Matt Edgley, « DRaaS vs traditional disaster recovery », Teledata,‎ (lire en ligne, consulté le )
  14. (en) « advantages of cloud computing »
  15. Nuabee, Livre Blanc : Plan de Reprise d’Activité (PRA) dans le Cloud pour les PME et ETI (PRA as a Service), , 12 p. (lire en ligne), p. 7
  16. (en) « What are the pros and cons of using the cloud for a disaster recovery plan? - Quora », sur www.quora.com (consulté le )
  17. (en-US) « 5 advantages and disadvantages of Cloud Storage », Big Data Made Simple - One source. Many perspectives.,‎ (lire en ligne, consulté le )
  18. (en-US) « What is Disaster Recovery as a Service (DRaaS)? - Definition from WhatIs.com », SearchDisasterRecovery,‎ (lire en ligne, consulté le )

Voir aussi

Articles connexes

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, 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)

Liens externes

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.