Discussion:Plan de continuité d'activité (informatique)
Cet article est indexé par le projet Sécurité informatique.
Les projets ont pour but d’enrichir le contenu de Wikipédia en aidant à la coordination du travail des contributeurs. Vous pouvez modifier directement cet article ou visiter les pages de projets pour prendre conseil ou consulter la liste des tâches et des objectifs.
| Avancement | Importance | pour le projet | |
|---|---|---|---|
| B | Élevée |  | Sécurité informatique (discussion • critères • liste • stats • hist. • comité • stats vues) |
Cet article comporte une liste de tâches suggérées :
Votre aide est la bienvenue pour corriger les liens, présents dans l'article, vers les pages d'homonymie Foisonnement ⇒ Quelques explications pour effectuer ces corrections. -- 4 mai 2019 à 08:46 (CEST)
Établissements bancaires modifier
Un plan de continuité est dorénavant obligatoire pour les établissements bancaires: Le Règlement du CRBF 2004-02 (Art 14 du 97-02) oblige à la mise en place d’un plan de continuité des activités élargi aux process bancaires. Le PCA se décline donc pour l'indisponibilité du système d'information mais aussi pour l'indisponibilité du personnel, l'indisponibilité des locaux, l'indisponibilité des partenaires ou prestataires. Pascal bonneville
Ceci est exact, mais pour compléter :
cette obligation découle des accords dits "Bâle 2" au terme desquels les banquiers ont définis
de nouveaux ratios pour le calcul de leurs fonds propres. Dans ces calculs rentre entre autres l'analyse des risques "opérationnels", c'est-à-dire tous les risques pouvant survenir sur leurs ressources humaines, matérielles, immobilières, informatiques, etc.
Bernard Chanssaud-Sigma-Risk- Lyon
Confusion PCA / PRA modifier
Il ne faut pas confondre PCA (Plan de continuité d'activité) et PRA (plan de reprise d'activité).
Comme son nom l'indique, le plan de continuité prend en compte toutes les mesures qui permettent d'assurer la continuité des activités métiers. Ce qui inclut la reprise d'activités, le PRA fait donc partie intégrante du PCA.
Selon les résultats de l'étude d'impact (BIA - Business Impact Analysis), nous choisirons des mesures garantissant l'ininterruption de service (la haute disponibilité - high availability) pour les éléments critiques ou dont le facteur impact/probabilité est inacceptable. Exemples de mesures: mirroring, clustering, doublement des lignes de communications ou des systèmes, etc. Lorsque les systèmes sont moins critiques ou que le facteur impact/probabilité est faible, seul un plan de reprise d'activités est établi.
Usuellement, les entreprises commencent par établir leur plan de reprise d'activité et ensuite elle considère la haute disponibilité afin de réduire leur exposition à des risques. Cependant dans la pratique, les informaticiens ont tendance à mettre en place des mesures de hautes disponibilités, sans une analyse d'impact formelle préalable, pour les systèmes qu'ils ont identifiés comme étant critique pour l'entreprise. Ainsi, bien qu'aucun plan de continuité formel n'existe, souvent des mesures sont déjà en place.
Il est a relever que l'établissement d'un plan de continuité n'est pas du ressort de l'informatique mais bel et bien du métier. Il ne faut pas perdre de vue que l'on parle de plan de continuité ou de reprise d'activités métiers. Bien d'autres éléments que l'informatique sont nécessaires pour l'exécution des processus métier.
J.Gasser CISM - CISSP
- "Il ne faut pas confondre PCA (Plan de continuité d'activité) et PRA (plan de reprise d'activité)." Je suis tout à fait d'accord.
- Ce qui ne me convient pas, c'est que justement, quand on cherche "Plan de reprise d'activité", on tombe sur : : http://fr.wikipedia.org/wiki/Plan_de_reprise_d%27activit%C3%A9 qui affiche la page Plan de continuité
- Alors qu'elle devrait afficher : http://fr.wikipedia.org/wiki/Disaster_Recovery_Process
- « Plan de reprise d'activite » redirige maintenant sur « Disaster Recovery Plan ». On a donc maintenant une distinction correcte entre PCA et PRA.
- Reste a reecrire Disaster Recovery Plan qui n'est a l'heure actuelle qu'une ébauche peu satisfaisante. --Tieno (d) 31 mars 2008 à 19:24 (CEST)
- Et puis, ce serait bien de creer un article specifique sur PRA, car ce n'est pas exactement la meme chose qu'un DRP. --Tieno (d) 31 mars 2008 à 19:29 (CEST)
Tableau recapitulatif des differents plans existants modifier
| Nom français | Nom anglais | Objectif | Périmètre | |
|---|---|---|---|---|
| Plan de continuité d'activité (PCA) | Business Continuity Plan (BCP) | Fournir les procédures nécessaires pour maintenir les activités essentielles suite à une importante perturbation. | Processus métier. Les processus IT ne sont traités que s'ils sont supports aux processus métier de l'organisme. | |
| Plan de reprise d'activité (PRA) | Business Recovery (Resumption) Plan (BRP) | Fournir les procédures nécessaires à la reprises des activités immédiatement après une catastrophe. | Processus métier. Non lié aux Technologies de l'information. Les processus IT ne sont traités que s'ils sont supports aux processus métier.(c'est ce qui amène souvent la confusion entre PRA et PRI, (PRI:Plan de Reprise Informatique) | |
| Plan de continuité des opérations (PCO) | Continuity of Operations Plan (COOP) | Fournir les procédures et les capacités nécessaires pour transférer et maintenir les fonctions stratégiques et essentielles d'une organisation vers un autre site. | Sous-ensemble des mission de l'organisation qui sont considérées comme les plus critiques. Le plan est généralement écrit au niveau du siège de l'organisation. Non lié aux Technologies de l'information. | |
| Plan de communication de crise (PCC) | Crisis Communications Plan (CCP) | Fournir les procédures nécessaires pour diffuser les rapports de situation aux employés et au public. | Communications avec le personnel et le public. Non lié aux Technologies de l'information. | |
| Plan de réponse aux incidents informatiques (PRII) | Cyber Incident Response Plan (CIRP) | Fournir des stratégies pour détecter, répondre, et limiter les conséquences d'une actions malveillante. | Centré sur les réponses aux incidents ayant un impact en terme de sécurité de l'information sur les systèmes et les réseaux. | |
| Disaster Recovery Plan (DRP) | Disaster Recovery Plan (DRP) | Fournir les procédures détaillées nécessaires pour faciliter la reprise des activités à partir d'un autre site. | Souvent lié aux Technologies de l'information. Limité aux importantes perturbations avec des effets à long terme. | |
| Plan d'intervention d'urgence (PIU) | Emergency Response Plan (ERP) | Fournir les procédures nécessaires pour réduire au minimum les pertes en vies humaines et proteger les biens contre des dommages, en cas de menace physique. | Centré sur le personnel et les biens. Non lié aux processus métier lié aux Technologies de l'information. |
PCA et PRA - Distinction floue modifier
--146.255.170.130 (discuter) 2 janvier 2019 à 16:47 (CET)William Sydney-Smith
Il me semble, en lisant les différents articles sur ces sujets dans Wikipedia et d'autres blogs, qu'il existe plusieurs écoles :
o Celle qui inclue le PRA dans le PCA.
o Celle qui distingue le PRA et qui ignore le PCA.
o Celle qui confond( dans le sens de mélanger) les deux .
Je suis dans ce métier depuis le début des années 80 pendant lesquelles j'ai pris le rôle de Disater Recovery manager, j'ai toujours organiser ces sujets de la manière suivante :
x Plan qui protège des pannes : comment assurer un niveau de disponibilité élevé et quelles sont les mesures à prendre en fonction des risques.
x Plan qui protège des sinistres : comment reprendre l'activité de l'entreprise après un sinistre majeur.
Dans les deux cas l'étude de l'entreprise et des ses activités reste un préalable incontournable .
Les risques de pannes dans un Data Center et son ecosysteme doivent être analysées et évaluées en fonctions de différents critères tels que : type de matériels , quantité, protection embarquées, niveau de contact avec le constructeurs, type de contrats de maintenance, proximité avec les intervenants, etc....
Tout cela pour dire que certaines entreprises ne chercherons pas à monter un PRA car il n'aura pas d'utilité pour elles, alors que la mise en oeuvre de mesure permettant de prendre en charge les pannes (en maintenat un niveau d'indisponibilité bas) dans un PCA pourrait être un plus non négligeable pour leurs opérations. Et bien sur d'autres entreprises axeront tout leurs efforts sur un objectif de o indisponibilité, y compris en cas de sinistre majeur qui détruirait complètement le Data Centre de l'entreprise. Donc, attention de ne pas complexifier les sujets inutilement. Voir article sur le PRA qui reprend cette notion de PRA et de catastrophe ....