Certification HDS : quelle approche de l’activité 5 ?

Ce niveau 5 étonne d’autant plus que les cinq autres niveaux (il en existe 6) obéissent à une logique de couche technique (mise à disposition de locaux, d’OS, de VM, etc.) ou de sauvegarde externalisée, mais pas à la question de savoir qui opère véritablement le système. Ce qu’il faut savoir surtout, c’est que ce N5 vient d’un problème rapidement identifié dans le décret, à savoir qu’il est facile à contourner si l’on s’en tient à une définition d’hébergement physique au sens strict. Admirez un peu la construction : un établissement de santé loue un local à une SSII (local qui donc lui appartient si le contrat de location est bien fichu), y dépose ses serveurs (dans ce local qui lui appartient et qui échappe donc à l’HDS) et souscrit avec la SSII en question un second contrat d’exploitation. Avec un simple artifice contractuel, on parvient à héberger les serveurs d’un établissement de santé chez un prestataire sans relever de l’HDS. Bon, certains avocats avec qui j’en ai discuté sont dubitatifs, arguant que le contrat de location entre professionnels ne peut pas (comme quand je loue mon appartement) impliquer un transfert temporaire de propriété du local, mais en fait on s’en fiche : j’ai raison, ou plutôt j’ai raison tant qu’un juge ne m’a pas dit que j’avais tort. En gros, il faut retenir que l’HDS est dans certains cas facile à contourner, d’où l’existence de ce niveau 5 qui bloque (ou essaye de bloquer) la construction contractuelle susnommée. Mais la critique est facile : pas certain que si c’était moi qui avais dû rédiger le décret, j’aurais trouvé une solution plus propre.

En tout état de cause, ce N5 bloque potentiellement pas mal d’opérations : télémaintenance, assistance ponctuelle ou régulière des équipes infra, etc. Alors comment sortir de ce piège à souris ? Il y a globalement deux méthodes. La première relève de la pure mauvaise foi, où j’ai terminé deuxième au dernier championnat du monde. On peut ergoter sur l’expression « pour le compte du responsable de traitement » et prétendre que (dans l’exemple du confrère) le DBA externalisé n’agit pas pour la MOA (responsable de traitement), mais en sous-traitance de la DSI, qui est elle-même sous-traitante (au sens RGPD) du traitement métier (le progiciel, le système, etc.). C’est limite car, stricto sensu, s’il s’agit d’une DSI interne, elle fait juridiquement partie de la MOA, mais bon, si par malheur vous avez un contrôle, le temps que le contrôleur comprenne l’enfumage, vous avez le temps de tuer un âne à coups de figues molles. L’autre truc (mon préféré, et là, au prochain championnat, j’ai au minimum les félicitations spéciales du jury), c’est de contractualiser avec la SSII uniquement sur l’administration, et pas sur l’administration ET l’exploitation. C’est complètement fumeux, mais en même temps mettre deux termes aussi proches dans un décret sans les définir m’autorise à les interpréter comme je veux, en utilisant notamment la définition du Larousse[2] du verbe « exploiter » : « Faire valoir quelque chose, un bien ; en tirer parti par le travail productif : Exploiter une ferme. » Dans l’exemple du confrère, la prestation du DBA relève de l’administration, et pas de l’exploitation : on échappe donc à la réunion des deux conditions qui relèverait du N5. J’en suis à la cinquième relecture du présent paragraphe, j’arrive presque à me persuader que c’est vrai : c’est fin, cela se mange sans faim, et si un jour on monte une ANMFI (Agence nationale de la mauvaise foi informatique), je veux en être.

Sinon, il y a la méthode intelligente, mais là, il faut en revenir à la stratégie d’interprétation des textes. Il y a globalement deux approches, par couches techniques et par traitement (au sens RGPD) : personnellement, je trouve que la première permet de sortir du piège. Certains éditeurs vendent des solutions (Pacs, souvent) en mode « FULL administré » : ils déposent leur serveur chez le client et s’occupent d’absolument tout du sol au plafond, de l’OS à la sauvegarde, uniquement sur leur serveur. Prétendre que ce type d’offre tombe sous le coup du N5 est logique, on est bien dans l’esprit de la loi (bon courage pour aller expliquer cela à Global Électrique ou Septmiens). Mais prétendre que la fourniture de service d’une seule couche dans la pile (par exemple la DB) relève du N5 semble excessif. C’est ainsi que l’on peut interpréter « administration et exploitation », à savoir comme la prise en compte de plusieurs couches allant de l’OS et de ses patchs jusqu’à la partie applicative.

Le décret HDS va de toute manière devoir évoluer. Par exemple, il est à ce jour basé sur une version de l’ISO (2013) qui va rapidement devenir obsolète : les organismes de type Afnor ou BSI ne vont même plus avoir le droit de certifier sur cette version d’ici à deux ou trois ans au maximum, et les établissements HDS vont être bloqués pour le renouvellement. Le niveau N5 touche à la question complexe car mouvante de l’externalisation, pas certain que l’on arrive avec une seule mouture à balayer tous les cas d’usage. D’autant qu’il y a cinq ans, au moment de l’entrée en vigueur de la loi sur les GHT, on entendait un peu partout que ces derniers devaient externaliser leur SI, sauf que cela coûte une blinde et que les infrastructures (datacenters) patiemment construites pendant des décennies auraient dû partir à la casse : des solutions très diverses ont été mises en place un peu partout ; rien que l’état des lieux va prendre des années.

[1]   https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000036650041/ 

[2]   https://www.larousse.fr/dictionnaires/francais/exploiter/32282 

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