Gestion des annuaires, à la frontière de la SSI

Il est cependant des sujets posés de temps en temps sur le bureau du RSSI qui interrogent, dans la mesure où ils ne relèvent pas explicitement et clairement de son terrain de jeu, mais en même temps leur non-traitement va finir par déclencher des sujets SSI : la gestion, ou plutôt la mauvaise gestion des annuaires.

Un annuaire est une collection de données qui varient – relativement – peu, qui sont indispensables à un logiciel ou à un traitement automatisé, et qui sont souvent partagées entre plusieurs logiciels ou traitements. Les premiers annuaires à avoir historiquement été mis en place dans un CH sont ceux des patients, ceux des agents et ceux des structures (structures à entendre au sens logique, tels les UF ou les CR, et sans lesquelles la comptabilité est impossible). Sans annuaire des patients, par exemple, il faudrait saisir autant de fois l’identité d’un patient qu’il y a de logiciels qui manipulent cette information (pharmacie, biologie, imagerie, rendez-vous, DPI, etc.) et, sans même parler de la charge de travail induite (plus de 100 logiciels impactés dans un gros CHU), les erreurs de saisie ou de recopie généreraient un risque d’identitovigilance massif.

En plus des trois précités, il existe six autres annuaires principaux : celui des locaux, des équipements lourds, des correspondants externes, de l’offre de soins, des prestataires et des habilitations. Très souvent, les difficultés d’informatisation d’un métier sont imputables à la question de l’annuaire : existence, exhaustivité, responsabilité de sa gestion, etc. D’autres annuaires existent, mais leur dénombrement exhaustif sortirait du cadre de cet article.

Mettre en place un corpus d’annuaires est indispensable à l’urbanisation rationnelle d’un SI, surtout dans un CH/CHU dont le SI est, toutes choses égales par ailleurs, parmi ce qui se fait de plus complexe comparativement à des entreprises publiques ou privées de taille équivalente. Ce travail obéit à des règles qui ont fait l’objet d’études théoriques poussées au moment de la création des premiers SGBD (systèmes de gestion de bases de données relationnelles), notamment par le D^r Codd, un chercheur d’IBM dans les années 1960, et qui sont connues sous le nom de « formes normales ». Les décrire demanderait un ouvrage entier, mais on peut donner quelques exemples simples. Un objet (ou enregistrement dans un annuaire) est identifié de manière unique et existe en un seul exemplaire. Si vous trouvez un annuaire RH avec des agents connus sous plusieurs numéros de matricule, c’est une anomalie. Autre exemple : le code d’identification (ID) ne doit pas être porteur de sens, mais juste incrémental : le premier agent porte le numéro 0000001, et ainsi de suite. Vouloir donner un sens à un ID est une anomalie qui « brûle » des plages entières de numéros et sera source de soucis ingérables lorsqu’un conflit sémantique se produira : l’exemple paraît trivial, mais avoir distribué des numéros Insee commençant par 1 pour les hommes et 2 pour les femmes engendre des difficultés très difficiles à gérer pour les transgenres (problème inexistant au moment de la mise en place de ces numéros Insee dans les années 1970). Autre exemple et pas des moindres : un annuaire existe en un seul exemplaire qui seul fait foi, tous les autres logiciels qui ont besoin de cette donnée en font une copie (plus ou moins en temps réel) en mode maître/esclave : l’idée de faire des copies dans les deux sens mène invariablement à des catastrophes. Dernier exemple : un annuaire traite d’une seule unité sémantique et ne doit donc pas stocker des objets de sens différents. L’annuaire des structures stocke des UF, qui sont des objets d’imputation analytique : vouloir créer des UF qui sont des lieux de livraison (c’est un grand classique de la mise de place de logiciels de transport logistique) est une bêtise qui se paye au prix fort quelques années plus tard.

Le plus délicat avec ces règles, c’est qu’il est parfois difficile de déterminer, sur le moment, ce qui risque de poser souci à l’avenir. Qui aurait pensé, au moment de la création des plaques minéralogiques des véhicules en 1893 qu’un jour l’apposition du numéro de département ferait perdre des plages entières et deviendrait problématique pour les départements surpeuplés ? Mais une chose est certaine : s’en affranchir est le signe d’ennuis futurs, qui ne manquent jamais de se produire. Votre serviteur aurait dû parier des sous à chaque fois qu’il a mis en garde un chef de projet Amoa sur ces questions.

Il s’agit d’un sujet qui, stricto sensu, relève de la responsabilité de la cellule Urbanisation d’une DSI ou tout simplement du DSI lui-même. Et c’est le genre de sujet qui démontre qu’après tout la mission première d’une DSI est de garantir la cohérence des flux dématérialisés. Quand un RSSI est confronté à des soucis d’annuaires qui génèrent des problèmes de sécurité du SI, il s’agit souvent de questions d’annuaires qui n’ont pas été traitées quelques années auparavant – et qui peuvent être d’une complexité high level, comme c’est le cas pour l’identitovigilance. Les DSI ont fort à faire avec ces sujets épineux.

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