Points clés
- La multiplicité des systèmes et des formats dans les SI de santé est une source de complexité technique qui amplifie les risques de sécurité et les coûts de gestion.
- La coexistence de formats legacy (HL7 v2, CDA) et modernes (FHIR R4) crée des zones de friction où les mécanismes de sécurité sont souvent les moins bien maîtrisés.
- La standardisation des formats d'échange est un facteur de réduction des risques — mais sa mise en œuvre doit intégrer la sécurité dès la conception, pas comme une couche ajoutée après.
- La gestion de la multiplicité impose une discipline de catalogage et de gouvernance des formats, intégrée dans le schéma directeur du SI de santé.
La coexistence de formats legacy et modernes
Les SI de santé matures cumulent des années de stratification technologique. Des interfaces HL7 v2.3 de 2005 coexistent avec des APIs FHIR R4 déployées en 2022. Des documents CDA R2 générés par un DPI côtoient des bundles FHIR consommés par une application mobile. Chacun de ces formats a ses spécificités de sécurité, ses vulnérabilités connues, et ses exigences de validation. Maintenir un niveau de sécurité homogène sur cet écosystème hétérogène est l'un des défis les plus complexes de la gouvernance de la sécurité des SI de santé.
Les risques spécifiques aux parseurs et transformateurs
Les composants qui transforment les données d'un format à l'autre (HL7 v2 vers FHIR, CDA vers FHIR) sont des points de vulnérabilité documentés. Ces parseurs manipulent des données structurées qui peuvent contenir des charges malveillantes : injections XML dans les transformateurs CDA (attaques XXE), injections dans les parseurs HL7 v2, ou dépassements de tampon dans des parseurs développés en interne. La validation des entrées doit être implémentée avant et après chaque transformation — pas uniquement en entrée du système.
La gestion des versions : un défi de sécurité
La multiplicité des versions d'un même format (FHIR R3, FHIR R4, FHIR R5) implique des mécanismes de validation différents, des profils différents, et des niveaux de maturité des implémentations différents. Maintenir une cartographie des versions en production et des vulnérabilités connues de chaque version est une discipline qui s'ajoute à la gestion des versions de composants logiciels classiques. Le passage de FHIR R3 à R4 n'est pas uniquement une migration fonctionnelle — c'est également une mise à jour de sécurité qui corrige des vulnérabilités identifiées dans les spécifications précédentes.
La standardisation comme stratégie de réduction des risques
La migration progressive vers des standards modernes — FHIR R4, IHE XDS.b, MSSanté — présente des avantages de sécurité tangibles : meilleure documentation des spécifications de sécurité, implementations open source auditées et maintenues par des communautés actives, meilleures pratiques de sécurité intégrées dans les spécifications. Cette migration doit être planifiée dans le schéma directeur du SI de santé, avec une priorisation des interfaces les plus critiques et les plus exposées. Elle ne doit pas être conduite uniquement pour des raisons fonctionnelles — la sécurité doit être un critère de priorisation explicite.
Gouverner la multiplicité
À défaut de pouvoir supprimer immédiatement la multiplicité des formats et des systèmes, elle doit être gouvernée. Un catalogue des formats et des versions en production, maintenu à jour, permet de visualiser la complexité et de piloter sa réduction progressive. Des standards de sécurité applicables à tous les formats, quel que soit leur âge (chiffrement, authentification, journalisation), permettent de maintenir un niveau minimum homogène. Et un programme de décommissionnement planifié des interfaces legacy les plus risquées permet de réduire la surface d'attaque dans la durée.