Le PCA/PRA : une actualité navale

Déjà, pour commencer, si vous voulez provoquer une belle empoignade dans une réunion de RSSI, vous leur demandez quelle est la différence entre les deux. Il existe au moins trois définitions de chacun de ces deux sigles – et des différences qui en résultent – et pas deux experts ne sont d’accord sur la question. Mais l’important n’est pas là : l’important, c’est que tout le monde, absolument tout le monde, s’entend pour considérer qu’un PCA (ou un PRA, à moins que ce ne soit l’inverse) ne se résume pas à un dispositif technique. Quand un DSI m’explique qu’il a un PCA/PRA parce qu’il a une seconde salle informatique de back-up, je lui rétorque qu’il n’a qu’un PSI (un plan de secours informatique), mais pas du tout un PCA/PRA.

Un PCA/PRA, c’est l’ensemble du dispositif technique et organisationnel qui vise à :

• faire en sorte que la probabilité de survenue d’un gros incident soit la plus faible possible ;
• faire en sorte qu’en cas d’occurrence, malgré tout, dudit incident, son impact soit le plus faible possible.

On retrouve d’ailleurs la théorie du risque qui stipule que RISQUE = PROBABILITÉ x IMPACT : travailler sur le risque, c’est travailler sur les deux éléments de la multiplication.

On trouve donc dans un PCA/PRA :

• des dispositifs techniques : dédoublement de la salle informatique principale, dédoublement de serveurs, virtualisation (ça aide vachement pour les bascules), sauvegardes (ça aide vachement si la restauration fonctionne) ;
• des procédures écrites de déclenchement de ces dispositifs techniques : quand le pépin arrivera et que Kevin (celui qui a mis en place la sauvegarde) et Brad (celui qui a mis en place la virtualisation) seront partis faire du canyoning dans les Cévennes (avec leurs masques FFP2) sans procédure écrite, ça va être compliqué de remettre en service tout le bazar ;
• des procédures dégradées métiers, évidemment ;
• une cellule de crise constituée et entraînée, avec des rôles précis et un ordre d’appel (ce qui suppose d’avoir noté quelque part les numéros de téléphone, c’est le genre de petit détail qui peut vite stresser tout le monde) ;
• un local de repli des informaticiens ; quand le datacenter aura brûlé, ça va être moins pratique de devoir travailler sur un parking ;
• un plan de communication : quand le téléphone va sonner de partout (appels internes et externes), ça va être compliqué de réparer en même temps que de répondre, mieux vaut dédier un responsable à cette tâche ;
• un plan de secours de la téléphonie : si votre PABX a été touché, disposer d’une flotte de GSM va faciliter le travail ; au fait, ils sont où les numéros de téléphone de la flotte ?

Quelquefois, l’actualité est là pour nous rappeler que les gros pépins peuvent venir d’un incident tout ce qu’il y a de plus anodin. Le 23 mars dernier, le porte-conteneurs géant Ever Given s’est mis en travers du canal de Suez, à la suite d’un violent coup de vent doublé d’une tempête de sable, bloquant totalement le trafic du canal (qui représente à lui seul plus de 10 % du commerce maritime mondial). La procédure dégradée existe : elle consiste à contourner l’Afrique par le cap de Bonne-Espérance, mais augmente singulièrement le temps de la traversée (entre 10 et 15 jours selon la taille des bateaux) et bien évidemment son coût (carburant, salaire des marins, retards de livraison, etc.). La remédiation (dégagement du bateau, désensablement, etc.) a coûté une blinde : plus d’un milliard de dollars selon le gouvernement égyptien (qui a d’ailleurs décidé de bloquer l’Ever Given dans l’attente d’un règlement de la facture par le propriétaire et l’armateur du navire, bonjour les procès en perspectives). Et, au final, le blocage aura coûté des sous à tout le monde : à l’Égypte (manque à gagner), aux compagnies maritimes dont les bateaux ont dû faire la queue en attendant de passer, aux clients finaux, etc.

La bonne nouvelle dans le cas de l’Ever Given, c’est que la capacité du moyen nominal (le canal) n’est pas supérieure à celle de la procédure dégradée (il peut passer autant de bateaux par le cap de Bonne-Espérance, c’est juste plus long). L’autre bonne nouvelle, c’est que l’impact de la panne du moyen nominal est facile à calculer : nombre de bateau x coût du retard journalier x nombre de jours de retard.

En même temps, je ne sais vraiment pas pourquoi je détaille cette histoire : aucun établissement de santé n’a poussé la production informatique de sa salle principale au-delà de la capacité de reprise de sa salle de secours, tous les établissements de santé testent régulièrement le bon fonctionnement des procédures dégradées techniques et métiers, et tous les établissements ont finement évalué l’impact de la panne partielle ou totale de leur informatique.