« Si l’informatique est en panne, c’est le DSI qui ira devant le juge. »

Le contexte est en général le suivant : un logiciel (ou un matériel piloté par un logiciel) est utilisé dans la chaîne de prise en charge des patients : urgences, réanimation, bref, des secteurs critiques en termes de disponibilité des outils. Que ce soit à l’occasion d’un déploiement dudit logiciel, d’un changement de fournisseur ou de version, la MOA impose une exigence de disponibilité ou de délai de remise en service après arrêt non programmé (RTO : Recovery Time Objective), qui soit relève de l’impossible, soit échappe au niveau de service que la DSI est en mesure de fournir avec les moyens dont elle dispose.

Cette exigence peut prendre plusieurs formes : « Le logiciel ne doit pas être indisponible plus de 5 minutes », « en cas de panne, il faut le relancer dans les 10 minutes en 24-365 », « impossible de faire des mises à jour qui dureraient plus de 15 minutes », etc. Tous les DSI et RSSI ont déjà été confrontés à ce genre de demandes : je suis même tombé une fois sur des contrôleurs de gestion qui m’expliquaient que leurs logiciels à produire des camemberts en couleurs devaient être disponibles 99,999 % du temps – authentique ! Comme élément de comparaison, quasiment aucune DSI hospitalière ne peut s’engager sur un RTO de 2 heures en heures ouvrables et de 4 heures en heures non ouvrables : celui qui vous affirme l’inverse est soit très riche, soit très menteur.

La plupart du temps, une explication de texte sur les processus mis en œuvre et leurs limites suffit, mais on tombe parfois sur des dinosaures qui éructent et vous balancent à la figure que si le machin ne redémarre pas dans les 5 minutes, c’est vous (DSI/RSSI) qui irez devant le juge quand il y aura des morts (voire agrémentent leur argumentaire avec des phrases comme « On verra comment vous réagirez si votre fils/fille/conjoint(e) est à l’hôpital pendant que le bidule tombe en panne »). Sauf que non. Petite analyse sous l’angle processus, pour laquelle le modèle Itil fournit une aide précieuse.

Tout processus peut se modéliser selon trois paramètres : le SLA (Service Level Agreement, ou accord sur le catalogue de services rendus aux « clients » incluant les limites desdits services), l’OLA (Operational Level Agreement, ou accord décrivant les groupes de soutien internes mis en œuvre pour délivrer le SLA) et les UC (Underpinning Contracts, ou contrats passés avec ses propres fournisseurs pour que l’OLA soit capable de délivrer le SLA). Toute organisation se modélise en cascade de processus, chaque processus étant le client de celui du dessous et le fournisseur de celui du dessus, le SLA de l’un devenant donc l’UC de celui du dessus et ainsi de suite.

Grossièrement (c’est évidemment plus compliqué), le bloc opératoire pilote un processus dont les « clients » sont les patients (« clients » est bien à entendre au sens des processus et non pas au sens commercial, je précise…), dont un des fournisseurs est la DSI, qui elle-même a des fournisseurs, notamment les éditeurs, et des services techniques internes pour la délivrance d’un truc légèrement utile que l’on appelle le courant électrique dans les datacenters.

Dans un monde idéal, chaque processus dans la chaîne affiche son SLA, et surtout l’a formalisé en tenant compte de ses UC, et donc des SLA de ses propres fournisseurs. C’est tout simplement une erreur de gestion pour la DSI que d’affirmer que le datacenter ne tombera jamais en panne d’électricité (ou, pour être plus précis, qu’une panne électrique n’affectera pas le SI), alors que les UC avec le fournisseur de courant ne prévoient pas d’onduleur, ou pas de contrat de remise en service de l’alimentation électrique dans un délai inférieur à celui qui correspond à la capacité des onduleurs s’il y en a, voire (c’est « tricky ») aucun contrat de remise en service de l’onduleur si ce dernier tombe en panne. Il ne viendrait d’ailleurs pas à l’idée d’un DSI (en tout cas j’espère) de balancer aux services techniques que si le courant est coupé 5 minutes, ce seront eux qui iront devant le juge en cas de souci avec l’informatique. Dans ce cas précis (UC inférieure au SLA des datacenters), il revient à la DSI de mettre en œuvre d’autres dispositifs pour pallier cette différence UC/SLA : c’est ce que l’on appelle une procédure dégradée et, dans le cas d’une DSI, un plan de secours informatique (à ne pas confondre avec un PCA-PRA). Mais ces dispositifs ont eux-mêmes une limite, qui porte le nom de risque résiduel.

Pour en revenir au dernier processus avant le patient dans la chaîne (le bloc dans l’exemple ci-dessus), si le SLA du bloc est différent de son UC avec la DSI (temps de remise en service d’un logiciel), il existe plusieurs contre-mesures : dédoubler les logiciels (ce qui va imposer une double saisie, des contrats de maintenance en plus, etc.), mettre en place des procédures dégradées métiers (plus ou moins complexes selon les cas d’usage), etc. Bref, l’organisation n’est pas sans réponse face à cette situation très courante, et qui le devient d’ailleurs de plus en plus avec l’informatisation galopante d’à peu près tout le monde. Mais, là encore, ces dispositifs ont une limite : encore ce fichu risque résiduel.

Il semble nécessaire d’attirer l’attention des lecteurs sur les fondamentaux suivants :

– Un responsable de processus ne peut pas se décharger juridiquement d’une différence entre son propre SLA et ses UC : il lui appartient de vérifier que ses fournisseurs lui délivrent un niveau de service compatible avec ses propres engagements et, dans la négative, soit réduire son SLA (et l’afficher), soit mettre en œuvre des solutions de contournement (il y en a toujours) – et afficher l’incontournable risque résiduel, encore lui ;

– Une DSI doit afficher la couleur sur ses SLA. Rien n’est pire que l’absence de communication sur ce sujet ; c’est le seul point qui peut engager éventuellement la responsabilité d’un DSI (ou de tout fournisseur de SLA, ce que nous sommes tous d’une manière ou d’une autre) ;

– Et, surtout, le RSSI doit pister et débusquer les distorsions SLA/UC dans les organisations. D’expérience, c’est une source d’incidents potentiellement graves, et parfaitement évitables grâce au PCA-PRA.

Dernière précision : Itil précise qu’un SLA doit s’entendre « dans 80 % des cas ». Dans 80 % des cas, le RTO à la suite d’une panne électrique est de 5 minutes (temps de bascule sur le datacenter de secours), dans 80 % des cas les mises à jour de la téléphonie induisent une coupure de moins de 15 minutes, etc. Mais, à chaque élément de la chaîne, on peut avoir une rupture du contrat de service du SLA d’un étage, ce qui induit l’UC de l’étage supérieur et ainsi de suite jusqu’au « client » final. Les dispositifs de redondance, de procédures dégradées et j’en passe ne sont là que pour ajouter des plaques à l’ensemble des plaques de Reason (le schéma en tranches de gruyère), les cas à la marge relevant de ce que l’on appelle le risque résiduel technique (pour un étage) ou encore le risque résiduel systémique ou organisationnel quand l’ensemble du mille-feuille des processus est touché. Mais ce dernier point nécessiterait toute une série d’articles.

L'auteur 

Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé.