Accès distant = transfert : ce que le nouveau cadre HDS change pour un éditeur santé

Qu'est-ce qui change quand un accès distant devient un transfert de données de santé ?

Depuis le décret n° 2026-209 du 24 mars 2026, un accès distant à des données de santé depuis un pays tiers à l'Union européenne est juridiquement assimilé à un transfert. La conséquence est concrète pour la chaîne d'hébergement : un simple accès de support, d'administration ou de maintenance opéré depuis hors de l'Espace économique européen doit désormais être documenté, encadré et rendu transparent dans le contrat, comme n'importe quel transfert au sens du RGPD.

Le décret, publié au Journal officiel du 26 mars 2026, crée l'article R. 1111-9-1 du code de la santé publique. Il vise explicitement l'hypothèse d'une prestation qui « implique un transfert, y compris un accès à distance, de données », d'après le texte consolidé sur Légifrance. Ce n'est plus une lecture doctrinale, c'est le droit positif, pris pour l'application de l'article 32 de la loi SREN du 21 mai 2024, qui a modifié l'article L. 1111-8 du code de la santé publique.

Le référentiel HDS v2.1 est-il déjà en vigueur ?

Non. Il faut distinguer deux couches. La couche réglementaire, le décret du 24 mars 2026, est en vigueur. La couche de certification, le référentiel HDS v2.1, est encore en concertation. D'après l'Agence du numérique en santé, sa publication est visée en octobre 2026 et son application interviendrait trois mois plus tard, en décembre 2026. Écrire que « HDS v2.1 exige » aujourd'hui serait faux.

Cette nuance de calendrier est exactement le genre de détail qu'un auditeur relève. L'ANS décrit une évolution « mineure », destinée à « renforcer la transparence sur les éventuels transferts de données et la soumission à des législations de pays tiers », selon son actualité du 15 juillet 2026. Le projet de texte est consultable dans la version en concertation du référentiel et sur la plateforme de concertation de l'ANS. Trois dates coexistent donc : le décret déjà applicable, une publication du référentiel visée en octobre, une application en décembre.

Qui est concerné : l'éditeur de logiciel ou son hébergeur ?

L'obligation pèse d'abord sur l'hébergeur certifié, pas sur l'éditeur. Mais l'éditeur de SaaS santé la subit par cascade contractuelle. Un hébergeur qui doit cartographier ses transferts et déclarer ses accès distants extra-européens va répercuter ces exigences sur sa chaîne de sous-traitance, dont l'éditeur fait partie en tant que responsable de traitement ou sous-traitant. Le questionnaire de conformité de votre client hospitalier va s'alourdir en conséquence.

C'est le point que beaucoup de fondateurs techniques manquent. La certification HDS v2 certifie l'hébergeur, jamais l'éditeur. Mais quand l'hébergeur durcit ses obligations de transparence sur les transferts, l'éditeur qui s'appuie sur un hyperscaler ou sur un support offshore devient le maillon qui fait échouer la démonstration. Le sujet remonte alors sur la table du CTO, souvent au pire moment, pendant la négociation d'un contrat.

Comment un accès distant devient-il un transfert au sens du RGPD ?

Parce que la donnée devient accessible, en clair, depuis une juridiction qui n'offre pas un niveau de protection adéquat. L'article R. 1111-11 modifié impose désormais d'indiquer, si l'hébergeur ou un sous-traitant relève d'un pays tiers, la liste des réglementations extra-européennes applicables, l'existence ou non d'une décision d'adéquation, et à défaut les mesures d'atténuation et les risques résiduels. Un accès administrateur depuis un pays tiers ouvre cette exposition.

Le mécanisme est le même que celui du CLOUD Act et de l'extraterritorialité des lois américaines : ce n'est pas la localisation physique du disque qui compte, c'est la possibilité d'un accès en clair par une entité soumise à une injonction étrangère. Le décret ajoute d'ailleurs une obligation de rendre publique et de tenir à jour la cartographie des transferts hors UE. Un accès distant non chiffré depuis un pays tiers n'est plus un détail d'exploitation, c'est une ligne de cette cartographie.

Quelles obligations contractuelles nouvelles pèsent sur la chaîne d'hébergement ?

Trois, cumulatives. Localiser le stockage exclusivement dans l'UE ou l'EEE, sauf décision d'adéquation ou garanties appropriées au sens des articles 45 et 46 du RGPD. Déclarer dans le contrat toute soumission à une législation extra-européenne, avec les mesures d'atténuation. Publier une cartographie des transferts. Les contrats déjà signés doivent être mis à jour le cas échéant, et l'absence de ces mentions sera traitée comme une non-conformité lors des audits.

Ces exigences figurent dans le décret n° 2026-209, dont certaines dispositions entrent en vigueur six mois après la publication, soit à l'automne 2026. La CNIL, dans sa délibération n° 2025-098 du 16 octobre 2025, a relevé que le projet reprenait largement des exigences déjà présentes dans le référentiel HDS tout en renforçant leur portée réglementaire, précisant que l'objectif n'est pas d'imposer à lui seul le recours exclusif à des acteurs européens, mais d'orienter vers des offres immunes au risque d'accès extra-européen. Pour l'éditeur, cela veut dire des garanties appropriées, pas seulement un drapeau.

En quoi le chiffrement applicatif est-il une mesure d'atténuation recevable ?

Parce que le décret demande précisément des « mesures techniques et juridiques mises en œuvre pour limiter » le risque d'accès extra-européen. Le chiffrement des champs sensibles au niveau applicatif est l'une de ces mesures : si la donnée est chiffrée avant d'atteindre l'infrastructure, un accès distant, même administrateur, ne voit que du chiffré. La donnée reste inintelligible pour qui ne détient pas la clé.

Concrètement, un modèle en enveloppe cryptographique sépare la clé de chiffrement de la donnée et la clé qui la protège. Si les clés sont détenues et opérées en France par un opérateur qui n'est pas soumis au CLOUD Act, un accès distant depuis un pays tiers à l'infrastructure d'hébergement porte sur des données inexploitables. MAFATE fournit cette brique : chiffrement AES-256-GCM en enveloppe via une API et des SDK, avec gestion du cycle de vie des clés en France. La documentation de cette mesure alimente directement le champ « mesures d'atténuation » que le contrat doit désormais renseigner.

Le chiffrement dispense-t-il de la certification HDS de l'hébergeur ?

Non, et le prétendre serait une faute. Le chiffrement applicatif réduit l'exposition d'un accès distant, il ne remplace pas la certification HDS de l'hébergeur ni les obligations de localisation du stockage. MAFATE n'est pas hébergeur de données de santé et ne se substitue pas à cette certification. La conformité HDS reste une responsabilité de l'hébergeur, que l'éditeur choisit et documente.

Il faut aussi être exact sur la brique de chiffrement elle-même. Le module matériel de sécurité de MAFATE est aujourd'hui un HSM logiciel PKCS#11, la migration vers un HSM matériel étant planifiée. Les rapports de conformité générés contribuent au dossier de l'éditeur, ils ne constituent pas un certificat et ne sont pas signés cryptographiquement. Ces nuances comptent : un auditeur qui repère une affirmation exagérée sur la brique de chiffrement doute ensuite de tout le reste du dossier.

Que doit préparer un CTO d'éditeur santé d'ici décembre 2026 ?

Trois chantiers. Cartographier les accès distants à sa donnée santé, y compris le support et l'infogérance opérés hors UE, car chacun est désormais un transfert à documenter. Vérifier avec son hébergeur l'état de sa mise en conformité au décret et son calendrier v2.1. Documenter les mesures techniques d'atténuation, dont le chiffrement applicatif et la localisation des clés, pour renseigner honnêtement le contrat.

Le sujet n'est pas théorique : dès décembre 2026, tous les audits HDS, initial, de surveillance et de renouvellement, seront menés selon la v2.1, d'après l'ANS. Un éditeur qui aura déjà chiffré ses champs sensibles et maîtrisé la localisation de ses clés aborde ces questionnaires avec des réponses factuelles plutôt qu'avec des promesses. C'est aussi la logique de fond du RGPD article 32, déjà en vigueur, qui attend des mesures adaptées à l'état de l'art. Pour approfondir l'architecture, notre dossier sur le chiffrement d'un éditeur SaaS en dossier HDS détaille les preuves attendues par un auditeur.