Manager par le risque : mais qu’est-ce qu’on est nul !

Première remarque : il ne s’agit pas de dérouler une appréciation des risques à la Ebios Mehari pendant des plombes – y a bien que des consultants encravatés incapables de justifier les nombres de jours stratosphériques sur leurs devis pour s’adonner à des âneries pareilles. Juste dire « Vent de travers à 20 nœuds, zone interdite de survol en montée initiale et VOR en maintenance » suffit. Le premier bénéfice est d’activer la mémoire à court terme, histoire d’être moins surpris en cas de problème, par exemple pendant la phase critique qu’est le décollage. Le deuxième bénéfice, mais qui est en fait le premier, est d’avoir un peu réfléchi au sujet et surtout de partager cette analyse avec son copilote quand on en a un. Le troisième est d’avoir réfléchi aux contre-mesures avant d’en avoir besoin, histoire de ne pas se laisser surprendre : manche dans le vent, virer à 20° à gauche dès l’altitude de sécurité atteinte, utiliser le GPS.

Par exemple, ce n’est pas du tout la même chose de planifier un changement majeur de version sur le DPI (je prends exprès le progiciel le plus complexe et sensible du SI d’un établissement de santé) en abordant le sujet par la méthode « classique » (liste des actions, prévenir les utilisateurs de l’arrêt programmé, estimation de la plage horaire d’indisponibilité, etc.) que d’envisager le sujet dans une approche pure par le risque. Dans la deuxième méthode, vous allez devoir répondre à des questions très désagréables telles que le dispositif de retour arrière en cas de mise à jour qui se passe mal, le plan B en cas de dépassement de la plage horaire prévue, la gestion des services critiques pendant l’opération de maintenance (urgences, Samu, réa, etc.). Et surtout, et c’est certainement le point majeur, tous les acteurs auront la même vision de cette matrice de risques.

Seconde remarque : dans l’approche « classique », les débats tournent autour de la liste des opérations techniques à dérouler, les risques étant l’un des éléments du sujet (quand ils sont évoqués). Dans la seconde approche, on considère que les informaticiens connaissent les opérations techniques à enchaîner, avec pour centre de gravité la gestion des risques : les opérations techniques se calent sur la gestion des risques, et non l’inverse. De la même façon que la phase de décollage se cale sur les risques identifiés, et non l’inverse.

Vous seriez surpris du nombre d’informaticiens qui font des yeux ronds comme des ballons de foot quand on leur pose cette question. « Ben, on avisera », « Ben, on improvisera », « Ben, on appellera un collègue. » Ben non : les emmerdes ayant une fâcheuse tendance à voler en escadrille, on constatera le phénomène classique de sidération, il manquera toujours un numéro de téléphone, et le collègue en question (le seul qui sait relancer la DB ou basculer la ferme de VMs) sera au cinoche avec sa nouvelle copine, GSM éteint. J’ajoute au demeurant que la question ne concerne pas que les adminsys (un peu trop facile de taper toujours sur les mêmes), mais aussi la gestion de projets fonctionnels. Je peux voir la matrice de risque dans la phase projet ? Quelqu’un a-t-il évalué le risque de décalage de la mise en production (facile celle-là), quel dispositif a été mis en place pour faire face à la surenchère fonctionnelle dans le nouvel outil de GED (tricky la question, j’adore) ?

En théorie, le RGPD impose une appréciation des risques systématique et suspensive AVANT la mise en production – j’ai dit « en théorie ». En théorie aussi, l’homologation est une phase obligatoire dans tout projet, même pour ceux qui ne traitent pas de données personnelles – un jour, j’ai dû vivre « en théorie », là où tout se passe bien. Les adminsys se font auditer par tous les bits depuis des années (HDS, ISO, cela vous parle ?), faudra que je pense pendant mon prochain passage dans une DSI à auditer le processus de gestion des risques du secteur appli/Amoa de la DSI, ça risque de piquer.

Ce sera le moment où je péterai totalement les boulons et où je demanderai urbi et orbi si une évaluation des risques a été faite AVANT la prestation : au type qui vient changer l’alim de la baie de serveurs, au gars qui intervient sur la clim, à l’avocate qui vient présenter son livrable/rapport/modèle de contrat pour mettre mon datacenter Algeco dans un pré à vaches (loué) sans respecter l’HDS, etc.

À découvrir → ISO 27001 : introduction au concept de classe de risques

Et un beau jour je verrai débarquer un jeunot exalté qui viendra me demander si j’ai fait une évaluation des risques d’une éventuelle incomplétude de mes propres procédures d’audit. Et meeeeerde !

[1]   https://skybrary.aero/articles/threat-and-error-management-tem

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