PCA PRA PCI PRI et PCC = SOS

Nombre d’amalgames sont faits lorsque sont abordés les plans de continuité d’activité, de reprise d’activité, de continuité informatique…
Tentons de clarifier les éléments de vocabulaire.

PCA : Haute disponibilité de la production

Le Plan de Continuité d’Activité (PCA) définit pour l’entreprise les architectures, les moyens et les procédures nécessaires pour assurer une continuité de son activité.
En cas d’incidents, de toute taille et toute nature, l’activité des métiers n’est pas interrompue.
Nous retrouvons ici la mise en oeuvre d’équipements, de procédures qui garantissent la continuité d’activité comme par exemple un système de production électrique en cas de défection du fournisseur d’énergie, des lignes de production « clonées » pour garantir la poursuite de fabrication en cas d’arrêt machines inopinés.

PRA : Reprise en cas de sinistre

Organisation palliative en cas d’absence de PCA, ou élément complémentaire du PCA, le Plan de Reprise d’Activité (PRA) est l’ensemble des processus qui permettent de repartir après un sinistre. Bien souvent sont définis des modes dégradés qui permettent à l’entreprise de redémarrer son activité, dans des locaux de transition, avec des solutions de gestion manuelles. Le sinistre pouvant être la cause d’une dégradation partielle ou totale des outils de production et de gestion. La priorité est de faire repartir les moyens de production ou de service pour reprendre le service client au plus vite et ne pas entraîner d’impacts commerciaux préjudiciables pour la société.

PCI et PRI : Pour les informaticiens

Les directions des systèmes d’information doivent à leur niveau assurer une mise en oeuvre de Plan de continuité et de reprise d’activité informatique.
Pour l’informaticien, d’une part Recovery Time Objective (RTO) qui correspond à la durée nécessaire à une « remise en production » d’un environnement informatique et d’autre part Recovery Point Objective (RPO) qui correspond à la période de données non récupérables, sont parmi les principaux indicateurs.

L’amalgame de terminologie est souvent fait entre métiers et DSI.  PRA et PCA sont utilisés par tous.
Dans l’approche développée chez Ankaa Engineering, nous provoquons une distinction entre les périmètres de responsabilité des métiers et ceux de la DSI.
Nous avons trop souvent rencontré des entreprises dans lesquelles la mise en oeuvre d’un PCA et PRA avaient été transmis à la DSI, DSI qui réduisait à son stricte périmètre de responsabilité son étude et mise en oeuvre de plans.
L’usage de terminologies appropriées apporte une clarification des périmètres et responsabilités.

PCC : L’oublié

Le Plan de Communication en cas de Crise (PCC) est très souvent oublié alors qu’il est essentiel et fondamental.
Deux niveaux sont à considérer :
– L’identification des indicateurs et de leurs  seuils respectifs de déclenchement des PCA, PRA, PCI, PRI (quand doit on activer le(s) plan(s) et comment).
– La diffusion et le contrôle de connaissance des procédures associées aux plans auprès de l’ensemble des salariés et sous-traitants.

La communication en cas de crise aborde en second lieu les besoins éventuels de relations publiques et presse.

Plan SOS

SOS : Le plan général

Selon l’approche méthodologique Ankaa Engineering®, PCA PRA PCI PRI et PCC composent l’ensemble du Suivi Opérationnel de Service (SOS).

Respect des contraintes réglementaires (BALE, SARBANES OXLEY, etc) , priorité aux opérations métier servent de base à l’identification des activités critiques.
A l’inverse d’une approche strictement basée sur le nombre d’appels téléphoniques susceptible d’être reçus par le service support, le serveur à reconstruire ou redémarrer en premier n’est pas celui de la messagerie (Oups !)…mais bien celui qui permet à la production de repartir (GPAO, GC, CRM, etc) et aux factures de ventes d’être émises.

Une analyse de l’exposition aux risques (AMDEC) permet de limiter le périmètre des plans et donc les budgets associés.
Plus l’objectif  de continuité est ambitieux, plus les budgets à affecter aux contournement des risques sont conséquents.

Consultations fournisseurs, aménagements techniques, simulation de crise et rédactions de procédures demandent du temps.
Les processus à activer par les salariés et sous-traitants en cas de crise demandent une organisation de suivi à l’intégration.

Et le travail dans ce domaine est perpétuel…
Chaque changement de processus métier, organisationnel ou réglementaire demandera un contrôle de cohérence du plan en place et un alignement en cas d’écarts.

Gérer un SOS est un vrai métier.

Vendre sa gestion des risques

Dans le domaine de la gestion de projet, la gestion des risques fait partie intégrante de la responsabilité du chef de projet.

En effet, il est de la responsabilité du chef de projet de veiller à ce que les risques potentiels ne se transforment pas en incidents durant les phases de conception ou d’implémentation.
Aussi le chef de projet veillera, dès les phases d’étude de faisabilité et d’étude préalable à mettre en place une gestion de risque organisée et documentée au sein de l’équipe.

Chaque risque identifié durant ces phases préparatoires du projet sera alors recensé, puis évalué individuellement.

En la matière il existe le référentiel AMDEC.
Selon les principes AMDEC, chaque risque est évalué sur les axes « Fréquence ou probabilité d’apparition », « Gravité », « Probabilité de non-détection ».

Face à la difficulté d’évaluation du paramètre « Probabilité de non-détection », pas toujours très évident à quantifier dans les scénarios des projets, nous avons au sein du framework méthodologique Ankaa Engineering simplifié l’approche AMDEC pour ne retenir que les deux premières dimensions.

Chaque risque est alors ventilé dans une matrice à deux dimension :

  • Potentialité d’occurrence établie selon
    nulle = jamais
    faible = deux fois par an
    possible = une fois par mois
    élevée = une fois par semaine
    Très forte = une fois par jour
  •  Impact de l’incident en cas de sinistre
    faible = affecte un individu
    moyen = affecte un service
    important = affecte une unité
    critique = affecte l’organisation

Les niveaux de rapports indiqués ci-dessus servent de référentiels « de base » et peuvent être ajustés en fonction des règles de jugement et d’évaluation au sein de chaque organisation (ajout de niveau de potentialité et d’impact pour gagner en précision si besoin).

Grille aversion aux risques du framework méthodologique Ankaa Engineering

Chaque risque sera alors positionné dans la matrice dans la cellule répondant à la double analyse « potentialité » et « impact ».
Le chef de projet décidera alors de « prendre les risques » pour ceux pour lesquels la matrice annonce un niveau « Nul », « Faible », « Tolérable ».
Bien souvent, les risques « Tolérables » seront d’ailleurs anticipés et gérés grâce au simple fait de les avoir identifiés.

Par contre le chef de projet aura la responsabilité de présenter à la MOA l’inventaire des risques évalués « Insupportables » ou « Inadmissibles » puisque ceux-ci impactent très fortement le périmètre du projet et peuvent être un critère de choix de « NO-GO » au final.
Lors de cette présentation, le chef de projet devra bien entendu apporter à la MOA les alternatives organisationnelles et/ou techniques au sein du projet permettant de contourner ces risques.

Bien souvent les solutions de contournement des risques engendreront des besoins en matière de budget (ressources supplémentaires, équipements de sécurité ou de backup, etc).

Et dans ce contexte, la MOA soucieuse de préserver un périmètre budgétaire raisonnable de son projet évaluera chaque moyen de contournement bien entendu comme onéreux à sur-dimensionné.
La réponse de fin de non-recevoir de la MOA au chef de projet prendra alors des tournures de « tu verras, ça va bien se passer » ou « nous avons toute confiance dans les capacités professionnelles de l’équipe »…

Alors ? Comment vendre sa gestion de risque ?

Comment faire souscrire l’achat d’assurance à la MOA soucieuse de maîtriser les budgets de son investissement ?

Et bien en lui valorisant les risques… en lui donnant le coût des incidents si ces derniers se produisent.
Dans la matrice ci-dessus, chaque entrée du tableau est valorisé
Potentialité
nulle = jamais, soit 0
faible = deux fois par an, soit 2
possible = une fois par mois, soit 12
élevée = une fois par semaine, soit 52
Très forte = une fois par jour, soit 365

Impact
faible = affecte un individu, coût journalier d’un ETP dans l’organisation,
moyen = affecte un service, coût journalier d’un ETP x nb d’ETP du service.
important = affecte une unité, coût journalier d’un ETP x nb d’ETP de l’unité
critique = affecte l’organisation, coût journalier d’un ETP x nb d’ETP de l’organisation, plus les pertes d’exploitation, l’impact commercial, etc

Il va sans dire que la multiplication des deux paramètres va amener à des montants colossaux pour les risques évalués inadmissibles.
En même temps, dans la vraie vie, peu de risques seront positionnés dans ces cellules.
En effet, les organisations soumises à des potentiels de risques importants avec des impacts critiques ne durent pas longtemps…voir ne voient jamais le jour.

L’essentiel des discussions tournera donc autour des risques évalués insupportables.
Et c’est la valorisation des risques qui permettra à la MOA de relativiser les budgets de contournements et autres « assurances ».
L’investissement supplémentaire de gestion de risque apparaîtra alors dérisoire face aux coûts potentiels des incidents.

Au delà de l’exercice de valorisation de risque, il est de la responsabilité du chef de projet d’avoir inventorié les risques encourus et d’avoir proposé les solutions de gestion adaptées.
Et c’est de la responsabilité de la MOA de souscrire aux « assurances » proposées.

Bénéficiez d’une évaluation gratuite de votre niveau de sécurité

L’éditeur de solution de sécurité TREND-MICRO propose un outil d’évaluation de la sécurité de votre système d’information basé sur 25 questions

Cet outil gratuit d’évaluation de la sécurité peut être utilisé pour organiser et déployer des mesures de sécurité nécessaires à la gestion des dispositifs mobiles, à la sécurisation de votre passage au cloud computing et à la protection contre les cyberattaques ciblées.

A noter le benchmark fourni dans le rapport final qui positionne votre niveau de sécurité par rapport à la moyenne des entreprises de votre secteur.
Faire l’évaluation

NB : Il s’agit avant tout d’un outil marketing TREND-MICRO visant à détecter des opportunités de projet.
Toutefois la pertinence des questions posées aide à établir un premier niveau d’analyse et favorise la réflexion sur ce sujet sensible.

La sauvegarde : Assurance-vie de l’entreprise – Source : ITPro

Au cours des deux dernières décennies la dépendance des entreprises à leur système informatique s’est considérablement accrue.
En cas de sinistre, toute perte significative de données entraîne des conséquences dramatiques : interruption temporaire ou définitive d’activité, perte d’exploitation, image dégradée auprès des clients, responsabilité civile du dirigeant engagée … Négliger la sécurité du principal actif de sa société constitue une lourde faute de gestion.
Lire la suite