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

Le décret n° 2026-209 du 24 mars 2026 crée l'article R. 1111-9-1 du code de la santé publique, qui assimile à un transfert un accès distant à des données de santé opéré depuis un pays tiers à l'Union européenne. Attention à la date : cette disposition n'est pas entrée en vigueur avec le décret. Son entrée en vigueur est différée de six mois après la publication au Journal officiel du 26 mars 2026, soit fin septembre 2026. À cette échéance, un accès de support, d'administration ou de maintenance opéré depuis hors de l'Espace économique européen devra être documenté, encadré et rendu transparent dans le contrat, comme n'importe quel transfert au sens du RGPD.

L'article 3 du décret est explicite : le texte entre en vigueur le lendemain de sa publication, « à l'exception des 2° et 3° de l'article 1er qui entrent en vigueur dans un délai de six mois ». Or c'est le 2° de l'article 1er qui crée le R. 1111-9-1, portant l'hypothèse d'une prestation qui « implique un transfert, y compris un accès à distance, de données », d'après le texte sur Légifrance. Le socle du décret est donc applicable depuis le 27 mars 2026, mais le principe qui donne son titre à cet article ne devient opposable qu'à l'échéance des six mois, autour du 26 septembre 2026. Le décret est 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.

Faut-il attendre fin septembre pour agir ? Non. Indépendamment du décret, un accès en clair à des données depuis un pays tiers est déjà analysé comme un transfert au titre du chapitre V du RGPD, comme le rappelle la CNIL sur les transferts hors UE. Le décret ne crée pas ce principe, il le codifie dans le champ HDS et le rend contrôlable à l'audit. Pour un éditeur, l'échéance de fin septembre 2026 est une date de mise en conformité formelle, pas le point de départ du risque.

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

Non, et il faut même distinguer trois couches, pas deux. La couche réglementaire du décret comporte elle-même deux temps : son socle est en vigueur depuis le 27 mars 2026, mais les dispositions sur le stockage et les transferts (2° et 3° de l'article 1er, dont le R. 1111-9-1) sont différées à fin septembre 2026. 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. Plusieurs échéances se succèdent donc : le socle du décret déjà applicable, ses dispositions sur les transferts opposables fin septembre 2026, une publication du référentiel visée en octobre et 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 devra 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. C'est déjà la logique du chapitre V du RGPD. Le décret la transpose dans le champ HDS : à compter de fin septembre 2026, l'article R. 1111-11 modifié imposera 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 ajoutera d'ailleurs, à la même échéance, 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 ne sera plus un détail d'exploitation, ce sera une ligne de cette cartographie.

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

Trois, cumulatives, et toutes portées par les dispositions différées à fin septembre 2026. 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 devront ê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 aux 2° et 3° de l'article 1er du décret n° 2026-209, dont l'entrée en vigueur est différée de six mois après la publication du 26 mars 2026, soit autour du 26 septembre 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 devra 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, avec deux échéances en ligne de mire : fin septembre 2026 pour les obligations du décret, décembre 2026 pour l'audit v2.1. Cartographier les accès distants à sa donnée santé, y compris le support et l'infogérance opérés hors UE, car chacun deviendra 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.