Données de santé : ce qu'un éditeur healthtech doit chiffrer pour signer ses clients hébergeurs

La certification HDS concerne-t-elle un éditeur de logiciel ?

Pas directement, et c'est un point mal compris. La certification HDS s'applique à l'hébergeur de données de santé, pas à l'éditeur qui édite le logiciel. Mais un éditeur healthtech vend à des établissements et à des hébergeurs certifiés HDS, qui lui répercutent leurs exigences par contrat et par questionnaire sécurité. En pratique, l'éditeur doit prouver que son logiciel chiffre correctement les données de santé pour que son client reste conforme. La conformité HDS de votre client devient votre problème commercial.

Trente-trois millions de Français ont vu leurs données de santé exposées en janvier 2024, dans l'attaque de Viamedis et Almerys : numéros de sécurité sociale, dates de naissance, garanties de mutuelles, aspirés via des identifiants de professionnel de santé usurpés. Pas de faille sophistiquée, un mot de passe volé. C'est la moitié de la population française, l'une des fuites les plus graves d'Europe, et le point de départ d'une série qui n'a pas cessé depuis.

Que dit précisément le référentiel HDS sur le chiffrement ?

Le référentiel HDS impose le chiffrement des données de santé en transit et au repos. Sa version 2 est en vigueur : elle résulte de l'arrêté du 26 avril 2024, publié au Journal officiel le 16 mai 2024, avec une mise en conformité des hébergeurs au plus tard le 16 mai 2026. Le référentiel exige des algorithmes robustes au repos et un chiffrement des flux, et il renforce les exigences de localisation des données dans l'Espace économique européen.

Ce référentiel est publié par l'Agence du Numérique en Santé (ANS). Le chiffrement s'y ajoute au socle du RGPD : l'article 9 classe les données de santé parmi les catégories particulières de données, soumises à un régime renforcé, et l'article 32 fait du chiffrement une mesure pratiquement incontournable pour tout traitement de données médicales. Pour un éditeur, cela veut dire que le chiffrement au niveau applicatif est le moyen le plus direct de tenir cette exigence, quelle que soit l'infrastructure de l'hébergeur client.

Pourquoi le secteur reste-t-il massivement exposé ?

Parce que les données les plus sensibles cohabitent avec les infrastructures les moins financées. Le rapport de la Cour des comptes de décembre 2024 sur la sécurité informatique des établissements de santé est sans appel : investissements insuffisants, gouvernance éclatée, remédiation trop lente face à l'accélération des menaces.

La cascade d'incidents le confirme. L'hôpital d'Armentières a vu 18 Go de données médicales publiés en février 2024, urgences fermées. L'hôpital de Cannes, 61 Go rendus publics deux mois plus tard : comptes rendus opératoires, RIB, cartes d'identité. Dans chacun de ces cas, les données exfiltrées étaient exploitables immédiatement, publiées en clair. Aucun établissement n'a pu invoquer le chiffrement at-rest comme facteur atténuant, ni bénéficier de l'exemption de notification prévue par l'article 34 du RGPD pour les données rendues incompréhensibles.

Le rapport Thales Data Threat Report 2024 indique que seulement 57 % des données sensibles stockées dans le cloud sont chiffrées, tous secteurs confondus. Dans la santé, où la migration cloud est moins avancée, le taux est probablement inférieur. L'ANSSI classe la santé parmi les secteurs les plus ciblés dans son panorama de la cybermenace 2024.

Comment un éditeur healthtech intègre-t-il le chiffrement sans refondre son produit ?

Par le chiffrement applicatif au niveau du champ, exposé en API. Plutôt que de chiffrer un disque entier ou d'attendre une refonte d'infrastructure, l'éditeur chiffre à la source les champs sensibles (numéro de sécurité sociale, diagnostic, résultat d'analyse) dans son application, avec un algorithme robuste et des clés gérées hors de la base. C'est la seule voie réaliste quand un logiciel de santé doit s'intégrer à des dizaines de systèmes hétérogènes côté client.

L'architecture de référence est l'enveloppe cryptographique : chaque donnée est chiffrée par une clé de données (DEK), elle-même protégée par une clé maître (KEK) conservée dans un service de gestion de clés séparé. Le mécanisme recommandé au repos est l'AES-256-GCM, cité par l'ANSSI dans son guide des mécanismes cryptographiques PG-083 v3.00 (20 mars 2026).

Une plateforme de chiffrement applicatif comme MAFATE expose ce chiffrement AES-256-GCM via API et SDK, garde les clés en France chez UNIVILE SAS, opérateur français non soumis au CLOUD Act, et génère un rapport de conformité adossé au journal d'audit réel des opérations. Deux précisions d'honnêteté, parce que le sujet est sensible : ce rapport contribue au dossier de conformité, il ne constitue pas un certificat et n'est pas signé cryptographiquement ; et MAFATE n'est pas hébergeur certifié HDS. MAFATE fournit la brique de chiffrement que l'éditeur intègre, l'hébergement certifié reste le rôle de l'hébergeur HDS du client. Confondre les deux serait vous tromper.

HDS, localisation des données, et le risque CLOUD Act

Le référentiel HDS v2 renforce l'exigence de localisation dans l'EEE et de transparence sur les accès depuis un pays tiers. En clair, il vise le risque qu'un hébergeur soumis au CLOUD Act doive livrer des données de santé aux autorités américaines, même stockées en France. Pour un dossier médical, ce risque est jugé inacceptable par les autorités sanitaires.

Le chiffrement avec des clés conservées hors de l'infrastructure de l'hébergeur, et sous droit français, apporte une réponse technique à ce risque juridique : une injonction adressée au fournisseur d'infrastructure ne produit que des fichiers illisibles si les clés ne sont pas chez lui. C'est un argument concret qu'un éditeur peut porter dans un questionnaire sécurité.

Un mot sur NIS2, souvent citée pour la santé : la directive (UE) 2022/2555 n'est pas transposée en France. La Commission européenne a saisi la Cour de justice de l'Union européenne le 8 juillet 2026 pour défaut de transposition (Le Monde Informatique, juillet 2026). Présenter une obligation NIS2 sur les établissements de santé comme actuelle serait faux. Aujourd'hui, l'exigence présente et opposable vient du RGPD et du référentiel HDS. NIS2 arrive, elle s'anticipe.

Ce que le chiffrement ne résout pas

Il serait malhonnête de le présenter comme suffisant. Le chiffrement protège la confidentialité des données au repos et en transit. Il ne remplace pas le contrôle d'accès, la MFA (dont l'absence a facilité plusieurs des attaques citées), la journalisation ni la détection d'anomalies. C'est le pilier de dernier recours : celui qui transforme une fuite catastrophique de dossiers médicaux en incident maîtrisé, parce que les données exfiltrées restent illisibles. Pour un éditeur, c'est aussi le pilier le plus facile à démontrer dans un audit, à condition qu'il soit adossé à un journal d'audit opposable.

La fenêtre est ouverte maintenant

Le référentiel HDS v2 est en vigueur, la mise en conformité des hébergeurs était attendue au 16 mai 2026, et les questionnaires sécurité des établissements se durcissent après la série d'incidents 2024-2025. Un éditeur healthtech qui sait répondre « oui, nous chiffrons les champs sensibles en AES-256-GCM, les clés sont en France hors CLOUD Act, voici le journal d'audit » se différencie immédiatement de ceux qui répondent « c'est prévu ».

MAFATE fournit cette brique aux éditeurs SaaS régulés, avec l'architecture publiée sur sa page sécurité. Si un contrat avec un hébergeur ou un établissement de santé vous est bloqué sur une exigence de chiffrement, parler à un ingénieur vous fait gagner les semaines de collecte documentaire que réclame chaque questionnaire HDS.