IA et données de santé : construire sous HDS sans renoncer

Peut-on construire une application d’IA qui traite des données de santé en France ? Oui. Nous l’avons fait : une application mobile de recueil et d’analyse de la parole, construite pour un programme de recherche du CNRS, hébergée sous certification HDS. Le projet a été plus exigeant qu’un chantier classique. Il n’a jamais été bloqué.

Cette note résume ce que l’hébergement HDS impose réellement à un projet d’IA sur données de santé, où se logent les vraies difficultés (rarement là où on les attend), et l’ordre de travail qui permet d’avancer dans un cadre réglementé au lieu d’y renoncer.

Ce que l’hébergement HDS impose à une IA sur données de santé

La certification Hébergeur de Données de Santé découle de l’article L.1111-8 du code de la santé publique : héberger des données de santé à caractère personnel pour le compte d’un tiers exige un hébergeur certifié. La certification s’appuie sur ISO 27001, complétée d’exigences propres au secteur, et couvre des activités distinctes, de la mise à disposition de l’infrastructure jusqu’à l’administration et la sauvegarde.

Première bonne nouvelle : vous n’avez probablement pas à devenir hébergeur certifié vous-même. Les grands fournisseurs de cloud, français comme américains, proposent des offres certifiées HDS. Trouver un hébergeur est la partie facile.

Le piège : un hébergeur certifié ne rend pas votre application conforme. La certification couvre l’hébergement, pas votre gestion des accès, pas vos flux sortants, pas vos journaux, pas votre base légale de traitement. Le RGPD s’applique pleinement, avec les données de santé au rang des données sensibles, et la conformité se conçoit dès l’architecture, pas en fin de projet.

Le vrai sujet : où passent les données quand l’IA travaille

Pour une application d’IA, la question centrale est le trajet des données. Un enregistrement vocal à visée médicale est une donnée de santé. L’envoyer à une API de modèle hébergée hors du périmètre certifié, c’est sortir du cadre. Trois voies existent.

La première : déployer le modèle dans le périmètre certifié. Les modèles à poids ouverts le permettent, la donnée ne quitte jamais l’infrastructure HDS. La deuxième : un fournisseur de modèles dont l’offre s’inscrit dans un périmètre certifié, avec les garanties contractuelles qui vont avec. La troisième : une pseudonymisation stricte avant tout appel externe, plus fragile qu’il n’y paraît, car certaines données, la voix par exemple, se réidentifient plus facilement qu’un nom dans un tableau. L’arbitrage entre ces voies est le même que celui entre LLM souverain et API, avec un curseur réglementaire plus strict.

Et le trajet ne s’arrête pas à l’inférence. Les journaux applicatifs qui tracent les requêtes contiennent la donnée. L’outil de monitoring la contient. Le jeu d’évaluation construit à partir de cas réels la contient. Chaque maillon doit rester dans le cadre, et c’est le genre de point qui coûte une réarchitecture quand on le découvre en dernière semaine.

Ce que le projet nous a appris

Trois enseignements de cette construction, transposables à tout projet de santé.

Les contraintes posées au premier jour coûtent peu. Savoir dès le cadrage que l’hébergement sera HDS, que tel flux est interdit et que tel journal devra être purgé oriente des dizaines de décisions techniques qui, prises dans l’ignorance, seraient toutes à refaire. La même contrainte, découverte au moment de la mise en production, se paie en mois.

La conformité se mène en parallèle, pas en préalable. Attendre que toutes les questions juridiques soient closes pour écrire la première ligne de code garantit un an de retard. Les questions se tranchent mieux face à une architecture concrète que sur le papier, et les interlocuteurs conformité travaillent mieux sur un schéma de flux réel que sur une intention.

L’exigence de qualité change d’échelle. Dans un contexte médical, une sortie fausse coûte plus cher qu’ailleurs. Validation, relecture humaine et refus de répondre deviennent des exigences : le contrôle des réponses fausses fait partie de l’architecture au même titre que l’hébergement.

Les questions à régler avant d’écrire du code

Cinq questions suffisent à cadrer l’essentiel :

1. Les données traitées sont-elles des données de santé au sens du code de la santé publique, et lesquelles exactement ?
2. Quel périmètre doit être hébergé sous certification HDS, et chez quel hébergeur ?
3. Par où passe chaque appel de modèle, et qu’est-ce qui sort du périmètre ?
4. Que contiennent les journaux et les outils de monitoring, qui y accède, quand sont-ils purgés ?
5. Qui valide les sorties du système, sur quel critère, et qu’arrive-t-il en cas de doute ?

Ces cinq questions tiennent sur une page. Y répondre au cadrage transforme le réglementé en liste de travail.

La santé regorge de cas d’usage d’IA à forte valeur, et la réglementation y écarte une bonne partie de la concurrence, celle qui renonce. Si vous portez un projet de ce type, c’est le genre de chantier que couvre notre offre d’IA sur mesure : les contraintes HDS posées au premier jour, et une application qui voit le jour quand même.