Faut-il un HSM pour un éditeur de logiciel de santé ? La nuance logiciel et matériel

Un HSM est-il obligatoire pour un éditeur de logiciel de santé ?

Non, pas en tant que tel. Le cadre HDS certifie l'hébergeur, et ni le RGPD ni le référentiel HDS n'imposent nommément un module matériel à l'éditeur. Ce qu'attend un auditeur, c'est la démonstration que la clé maîtresse n'est jamais exposée en clair et que son usage est tracé. Le module matériel devient un argument à mesure que le donneur d'ordre est exigeant, pas un prérequis universel.

Le référentiel de certification HDS v2, publié par l'Agence du numérique en santé, porte sur les activités d'hébergement, pas sur le détail du module de clés de l'éditeur (ANS, certification HDS). La CNIL, dans ses fiches de 2024 sur le chiffrement dans le cloud, insiste sur la maîtrise et la protection des clés, sans prescrire une technologie de module unique (CNIL, pratiques de chiffrement dans le cloud).

Que fait un HSM, concrètement ?

Il garde la clé maîtresse hors de la mémoire applicative et lui fait exécuter les opérations sensibles en interne. La clé n'en sort jamais en clair : les clés de données y entrent pour être enveloppées ou déroulées et en ressortent chiffrées. Un module matériel ajoute une protection physique contre l'extraction, un module logiciel apporte le même cloisonnement logique sans la barrière matérielle.

Un HSM protège ainsi la KEK au cœur de l'architecture d'enveloppe. MAFATE pilote ce module via l'interface standard PKCS#11, ce qui rend la couche interchangeable (documentation, architecture de sécurité). La gestion des clés qui s'appuie sur ce module, côté KMS, couvre création, rotation et désactivation (documentation, concepts de clés).

Où se situe MAFATE aujourd'hui sur ce point ?

Sur un module logiciel, et il faut le dire clairement. MAFATE utilise aujourd'hui un HSM logiciel PKCS#11, avec une migration vers un HSM matériel certifié planifiée. Ce n'est pas un détail à masquer dans un questionnaire de sécurité : le prétendre matériel certifié quand il ne l'est pas se retournerait contre l'éditeur qui le relaie à son propre auditeur.

Cette transparence est la position tenable pour une structure jeune. Le module logiciel assure le cloisonnement des clés et leur usage tracé, ce qui répond à l'essentiel de l'exigence pour un déploiement mid-market, et la feuille de route vers un module matériel est présentée comme un engagement daté, pas comme un acquis. Le RGPD Article 32, consultable sur EUR-Lex, demande des mesures proportionnées au risque, ce qui laisse place à cette progressivité assumée.

Qu'est-ce que la bascule FIPS de septembre 2026 change ?

Elle déplace la référence du marché de FIPS 140-2 vers FIPS 140-3. Le NIST fait passer, le 21 septembre 2026, tous les modules encore validés FIPS 140-2 en liste historique. Ce n'est pas une révocation : les modules restent utilisables pour les systèmes existants, mais les nouveaux marchés se tourneront vers des modules validés FIPS 140-3.

Le NIST documente cette échéance et le passage en liste historique dans son programme de transition (NIST CSRC, FIPS 140-3 Transition Effort), une date confirmée par les acteurs spécialisés du domaine (SafeLogic, échéance du 21 septembre 2026). La norme FIPS 140-3 remplace FIPS 140-2 et s'aligne sur la norme internationale ISO/IEC 19790 (NIST, FIPS 140-3).

Faut-il exiger un module validé FIPS de son fournisseur ?

Cela dépend de votre donneur d'ordre. Pour un contrat de santé français en mid-market, la validation FIPS relève du marché fédéral américain et n'est pas une exigence réglementaire directe. Elle peut le devenir dans un appel d'offres précis. La bonne posture est de connaître le statut réel de son fournisseur et de le déclarer sans le surestimer, plutôt que d'afficher une validation qu'on ne détient pas.

L'ANSSI cadre pour sa part le choix des mécanismes cryptographiques dans son guide version 3.00 du 20 mars 2026, référence plus pertinente qu'une validation américaine pour un éditeur français (ANSSI, guide des mécanismes cryptographiques PG-083). L'important reste la démonstration de la protection des clés, quel que soit le référentiel invoqué.

Que retenir sur le HSM pour un dossier de santé ?

Que la vraie exigence est la protection et la traçabilité de la clé maîtresse, pas l'affichage d'un matériel. Un module logiciel isolé y répond pour l'essentiel, un module matériel renforce la garantie, et l'honnêteté sur le niveau réel est ce qui tient face à un auditeur. La bascule FIPS de septembre 2026 rappelle simplement que le référentiel de validation évolue.

MAFATE assume ce niveau et sa feuille de route, décrits sur la page de preuve sécurité et sur la page solutions santé. Cet article clôt le dossier ouvert par le pilier sur l'architecture de chiffrement en HDS et prolongé par l'article sur l'architecture DEK/KEK. Pour situer votre besoin réel de module de clés, parlez à un ingénieur.