Mon service doit-il être hébergé HDS ? L'arbre de décision

« Est-ce que mon appli doit être en HDS ? » est la question qui revient le plus souvent au démarrage d’un projet de santé. Elle a une réponse structurée, et elle tient en quatre questions.

Question 1 — Manipulez-vous des données de santé à caractère personnel ?

Une donnée de santé n’est pas seulement un diagnostic. Sont concernées les données relatives à la santé physique ou mentale, passée, présente ou future, y compris celles qui révèlent un état de santé par déduction.

Les cas évidents : résultats d’examens, prescriptions, comptes rendus, constantes, antécédents.

Les cas que l’on sous-estime : une prise de rendez-vous dans un service spécialisé (elle révèle une pathologie), une liste de médicaments, un motif de consultation, une donnée d’activité physique interprétée dans un contexte médical.

Si la réponse est non, l’obligation HDS ne s’applique pas. Passez néanmoins à la question du RGPD, qui, lui, s’applique dès qu’il y a des données personnelles.

Question 2 — Dans quel contexte ont-elles été recueillies ?

C’est le critère le plus discriminant, et celui que la plupart des porteurs de projet oublient. Le texte vise les données recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi médico-social.

C’est ici que se joue la différence entre une application de bien-être et une application de santé. La même mesure — un rythme cardiaque, un poids, un score de sommeil — peut être hors périmètre dans un usage grand public autonome, et dans le périmètre dès qu’elle est recueillie dans le cadre d’un suivi assuré par un professionnel.

Conséquence stratégique : un produit peut naître hors périmètre et y entrer dès son premier partenariat avec un établissement ou un réseau de soins. Si c’est votre trajectoire commerciale, la bonne décision est de construire dès le départ comme si l’obligation s’appliquait.

Question 3 — Hébergez-vous pour le compte d’un tiers ?

L’obligation vise l’hébergement pour le compte de tiers. Un établissement de santé qui gère son propre système d’information n’a pas à être certifié.

En revanche, dès que vous hébergez les données d’un professionnel, d’un établissement ou d’un autre organisme, vous êtes dans le champ — y compris si vos utilisateurs finaux sont des patients, dès lors que les données sont traitées pour le compte du professionnel qui les prend en charge.

Question 4 — Exercez-vous réellement une activité d’hébergement ?

C’est la question qui détermine qui doit être certifié, vous ou votre fournisseur.

Le référentiel distingue l’hébergeur d’infrastructure physique — sites physiques et infrastructure matérielle — de l’hébergeur infogéreur — infrastructure virtuelle, administration du système d’information, sauvegarde externalisée.

Un éditeur SaaS classique, qui déploie son application chez un fournisseur certifié sans exercer lui-même ces activités, n’a pas à se certifier : c’est le certificat de son fournisseur qui répond à l’obligation. Mais la frontière se déplace dès que vous assurez vous-même l’administration ou les sauvegardes pour le compte de vos clients — c’est le point que le référentiel de 2024 a précisément entrepris de clarifier.

Les trois erreurs de qualification les plus fréquentes

« Nous ne stockons pas de données médicales, seulement des données administratives. » Vérifiez le détail. Un motif de rendez-vous, un service de destination, une liste de praticiens consultés sont des données révélant l’état de santé.

« Nous sommes hébergés chez un fournisseur certifié, donc nous sommes conformes. » Vous répondez à l’obligation d’hébergement. Vous ne répondez ni aux exigences de sécurité applicatives, ni au RGPD, ni au statut réglementaire éventuel de votre logiciel.

« Nous verrons ça plus tard, quand nous aurons des clients. » C’est la décision la plus coûteuse. À ce stade, la mise en conformité devient une migration.

Si vous ne parvenez pas à trancher

C’est le cas le plus courant, et ce n’est pas un aveu d’incompétence : la qualification dépend de votre modèle de données, de vos flux et de votre positionnement commercial, pas d’une grille universelle. Ce qu’il faut éviter, c’est de trancher implicitement — en démarrant le développement sans avoir posé la question.