Réflexions autour du décret de signalement des incidents de sécurité

Le décret fait référence à une obligation de déclaration des événements « graves » ou « significatifs », et la question que tout le monde se pose est : à partir de quel moment le niveau d’un événement SI va-t-il nécessiter de le signaler ? Pour ce faire et alimenter le débat, prenons l’exemple du DPI, qu’il suffit ensuite de généraliser à tous les composants critiques du SI (logistique, laboratoires, etc.).

Tout RSSI qui se respecte doit parvenir, pour le DPI, à fixer en collaboration avec la DSI et les métiers (MOA) deux durées qui se déclenchent à partir du t0 d’une panne : la durée au bout de laquelle la MOA décide de passer en procédure dégradée, et la durée au bout de laquelle la DSI s’engage – contractuellement – à remettre en service le DPI. Supposons, pour l’exemple, que ces durées respectives soient institutionnellement fixées à 1 heure et 4 heures. Cela signifie qu’en cas de panne, les MOA attendront 1 heure avant de prendre la décision de déclencher les procédures dégradées. Pourquoi 1 heure et pas aussitôt ? Parce que le passage en procédure dégradée a un coût organisationnel, que dans la plupart des cas (heureusement) la panne est de courte durée et que l’on ne va pas engager des frais en interne s’il suffit à la DSI de rebooter un serveur pour relancer le service. Cela signifie enfin que, toujours à partir de ce t0, la DSI dispose de 4 heures pour remettre en service le DPI : jusqu’à 3 h 59 min, elle est dans son contrat de service et personne n’a rien à lui reprocher ; à partir de 4 heures pétantes, elle va devoir rendre des comptes, d’où l’importance de formaliser ces durées.

Que se passe-t-il si une panne dure 3 heures ? Est-ce qu’un signalement à l’ARS est nécessaire, au motif que l’incident (ici, de disponibilité) aurait « une conséquence potentielle ou avérée sur la sécurité des soins » ? Selon nous, absolument pas. La durée de 4 heures, délai admissible de temps de remise en service du DPI par la DSI (durée qui, rappelons-le, a fait l’objet d’une négociation entre la DSI et la MOA, arbitrée par le RSSI), signifie bien que, pendant ce laps de temps, il n’y a pas de conséquences autres qu’organisationnelles et internes (rappel de personnel, mensualités de remplacement, etc.) sur les soins. C’est donc au-delà de cette durée de 4 heures qu’un incident est susceptible de déclencher un signalement aux autorités. 

Bien évidemment, l’exercice de quantification de ces heures est un peu plus complexe : la durée maximale admissible n’est pas la même selon que l’on est en heures ouvrables ou pas, et il faut bien entendu faire une évaluation de durée pour tous les composants (matériels ou logiciels) sensibles du SI, ce qui dans un CHU représente entre 50 et 100 items.

Pourquoi vouloir border à ce point le signalement des incidents ? Parce que le monde dans lequel on vit cherche toujours un coupable, c’est ainsi. Le risque est, sur une panne de 15 minutes qui aurait conduit à un retard de prise en charge de patients aux urgences par exemple, de voir les pouvoirs publics reprocher à l’établissement de ne pas avoir signalé immédiatement cet incident, même sans l’avoir évalué et qualifié au préalable (ce qui est souvent tout sauf évident). Et dans ce cas, la réaction de l’établissement sera prévisible : puisqu’on nous reprochera de ne pas avoir signalé un incident, alors on va tous les signaler et envoyer toutes les alertes Nagios aux autorités, soit plusieurs milliers de mails par jour, juste histoire de se couvrir. Et, au final, le signalement ne servira à rien.

[1]   http://www.ticsante.com/Securite-informatique-un-decret-detaille-les-incidents-devant-etre-signales-par-les-etablissements-de-sante-NS_3189.html 

[2]   /article/2527/declaration-des-incidents-de-securite-si-demarrage-en-octobre.html ; /article/2529/michel-gagneux-nous-sommes-maintenant-tres-presents-sur-le-front-hospitalier.html