Sous-traitance HDS : quand un éditeur SaaS santé doit-il être certifié lui-même ?
« Notre cloud est certifié HDS, donc nous sommes conformes. » Cette phrase revient dans presque tous les appels d’offres e-santé — et elle est fausse dans la majorité des configurations. La certification HDS ne couvre pas une entreprise : elle couvre des activités, listées une à une par le code de la santé publique. Si vous en exercez une sans certificat, le fait que votre fournisseur d’infrastructure soit irréprochable ne vous sauve pas. Voici comment cartographier la chaîne éditeur → hébergeur → infogérant, et ce qu’il faut exiger par écrit.
La certification porte sur des activités, pas sur une entreprise
L’article L.1111-8 du code de la santé publique impose un certificat de conformité à toute personne qui héberge des données de santé à caractère personnel pour le compte de tiers. L’article R.1111-9 décompose cet hébergement en six activités :
- mise à disposition et maintien en condition opérationnelle des sites physiques accueillant l’infrastructure matérielle ;
- mise à disposition et maintien en condition opérationnelle de l’infrastructure matérielle ;
- mise à disposition et maintien en condition opérationnelle de l’infrastructure virtuelle ;
- mise à disposition et maintien en condition opérationnelle de la plateforme d’hébergement d’applications ;
- administration et exploitation du système d’information contenant les données de santé ;
- sauvegarde des données de santé.
Deux périmètres de certificat en découlent : « hébergeur d’infrastructure physique » pour les activités 1 et 2, « hébergeur infogéreur » pour les activités 3 à 6. Un acteur qui exerce les deux métiers doit détenir les deux certificats. Le certificat est délivré pour trois ans par un organisme certificateur accrédité par le Cofrac, avec un audit de surveillance annuel. Restent hors champ les prestations de saisie, de mise en forme, de matérialisation ou de dématérialisation de documents : numériser des dossiers n’est pas héberger. Notre article sur qui est vraiment concerné par la certification HDS détaille ce test d’entrée.
Pourquoi le cloud certifié ne vous couvre pas
Un éditeur SaaS santé typique loue de l’infrastructure virtuelle à un fournisseur certifié pour les activités 1 à 3. Puis il fait le reste lui-même : il déploie, patche, supervise, gère les accès, orchestre les sauvegardes. Or « administrer et exploiter le système d’information contenant les données de santé » (activité 5) et « sauvegarder » (activité 6) sont deux activités certifiables à part entière. Elles ne sont pas couvertes par le certificat de votre fournisseur, parce qu’il ne les réalise pas.
La question n’est donc jamais « mon hébergeur est-il certifié ? » mais « qui fait quoi, activité par activité, et cet acteur est-il certifié pour cette activité-là ? ». La réponse ne dépend ni de votre taille, ni de votre chiffre d’affaires, ni de votre volonté : elle dépend de votre architecture d’exploitation.
Tableau : qui doit être certifié, dans quelle configuration
| Configuration | Activités exercées par l’éditeur | Certification HDS de l’éditeur |
|---|---|---|
| L’éditeur vend une licence installée chez le client, qui exploite tout | Aucune | Non requise |
| L’éditeur revend le SaaS d’un tiers certifié, sans accès d’exploitation | Aucune | Non requise, mais contrat à répercuter |
| L’éditeur loue de l’IaaS certifié et administre lui-même sa plateforme | 5, souvent 6 | Requise pour les activités exercées |
| L’éditeur délègue l’exploitation à un infogérant certifié, sans accès admin | Aucune | Non requise si la délégation est réelle et documentée |
| L’éditeur héberge sur ses propres serveurs et exploite | 1 à 6 selon le montage | Requise, potentiellement les deux certificats |
| L’éditeur traite uniquement ses propres données, sans clients tiers | Hors champ | Non requise (pas d’hébergement pour autrui) |
Le quatrième cas est le plus intéressant commercialement : externaliser l’exploitation vers un hébergeur infogéreur certifié évite à l’éditeur de porter lui-même la certification. Mais la délégation doit être effective. Conserver un accès d’administration « pour le support » suffit à réintégrer l’activité 5 dans votre périmètre — et à rendre votre montage non conforme.
Lire un certificat HDS : cinq vérifications, pas une
L’Agence du Numérique en Santé publie la liste des hébergeurs certifiés, avec pour chacun les activités couvertes, la version du référentiel appliquée et l’organisme certificateur. D’après le décompte publié par l’ANS, plus de 400 hébergeurs y figuraient au printemps 2026. Avant de signer :
- L’entité juridique. Le certificat vise une personne morale précise. Une filiale, une marque commerciale ou une société sœur ne sont pas couvertes.
- Les activités. Un certificat « infrastructure physique » ne dit rien de l’infogérance. Confrontez la liste des activités couvertes à celle des activités que vous déléguez.
- La version du référentiel. La révision approuvée par l’arrêté du 26 avril 2024 a remplacé la v1.1 ; la date limite de migration pour les certificats historiques était fixée au 16 mai 2026. Un prestataire encore affiché en v1.1 est un signal d’alerte (le détail de la révision 2024).
- Les dates. Délivrance et renouvellement doivent figurer au contrat ; demandez confirmation de validité à l’organisme certificateur nommé.
- Les sites. Les lieux d’hébergement effectifs, pas la nationalité du groupe.
Ce que le contrat doit contenir
L’article R.1111-11 du code de la santé publique fixe une liste de clauses minimales, qui s’ajoutent — et ne se substituent pas — à celles exigées par l’article 28 du RGPD pour la sous-traitance. On y trouve notamment le périmètre du certificat et ses dates, la description des prestations avec les garanties de disponibilité, d’intégrité, de confidentialité et d’auditabilité, l’indication des lieux d’hébergement, les modalités d’exercice des droits des personnes prévus aux articles 15 à 21 du RGPD, le signalement des violations, les indicateurs de niveau de service, l’information sur le recours à des prestataires externes avec engagement de protection équivalente, l’information sur les transferts vers des pays tiers, l’interdiction d’utiliser les données de santé à d’autres fins que l’hébergement, et tout le volet de sortie : prestations de fin d’hébergement — y compris en cas de perte ou de retrait de la certification —, réversibilité, restitution intégrale des données, puis destruction sans copie après accord formel du responsable de traitement.
La règle qui piège les éditeurs
Le point décisif est ailleurs. Le même article prévoit que lorsqu’un responsable de traitement (ou un patient) confie ses données à un prestataire qui recourt lui-même à un hébergeur certifié, le contrat entre le responsable de traitement et ce prestataire reprend les clauses telles qu’elles figurent dans le contrat liant le prestataire et l’hébergeur certifié.
Autrement dit : vos conditions générales d’éditeur doivent refléter le contrat que vous avez signé avec votre cloud. Vous ne pouvez pas promettre à un CHU une réversibilité ou une localisation que votre propre fournisseur ne vous garantit pas. C’est une contrainte de cohérence contractuelle sur toute la chaîne — et la première chose que regardera un acheteur hospitalier averti.
Ce qui change au 26 septembre 2026
Le décret n° 2026-209 du 24 mars 2026 a modifié ces dispositions. Il crée un article R.1111-9-1 posant le principe d’un stockage des données de santé exclusivement sur le territoire d’un État membre de l’Union européenne ou partie à l’accord sur l’EEE. Les transferts vers un pays tiers restent possibles dans les conditions du RGPD — décision d’adéquation au titre de l’article 45, ou garanties appropriées au titre de l’article 46 avec droits opposables et voies de recours effectives — étant entendu qu’un accès à distance depuis un pays tiers vaut transfert. Le décret ajoute par ailleurs une clause contractuelle spécifique : lorsque l’hébergeur est soumis à une législation extra-européenne susceptible d’imposer un accès aux données, le contrat doit énumérer ces réglementations, indiquer l’absence de décision d’adéquation le cas échéant, décrire les mesures d’atténuation et les risques résiduels. Ces dispositions entrent en vigueur six mois après la publication du décret, soit le 26 septembre 2026. Si votre pile technique repose sur un cloud extra-européen ou sur un support opéré depuis un pays tiers, c’est maintenant qu’il faut documenter la chaîne.
HDS, RGPD, ISO 27001 : trois plans distincts
Un certificat HDS ne vaut pas conformité au RGPD : bases légales, information des personnes, registre, analyses d’impact et contrats de sous-traitance restent à traiter en propre, des deux côtés de la relation. Symétriquement, ISO/IEC 27001 ne remplace pas le HDS : c’est le socle de management de la sécurité sur lequel s’adosse le référentiel, pas un titre d’habilitation à héberger des données de santé en France. Le bon réflexe est de mutualiser le système de management et de ne pas payer deux fois le même travail — notre comparatif HDS vs ISO 27001 pose les termes de l’arbitrage, et notre article sur ISO 27001 face au RGPD et à NIS2 montre comment les trois plans s’articulent.
Ce que dit la recherche sur le risque de la chaîne
Le législateur n’a pas inventé ce risque. Thomas H. McCoy et Roy H. Perlis, dans le JAMA en 2018, ont analysé les violations de données de santé déclarées aux autorités américaines entre 2010 et 2017 : plus de 2 100 incidents, plus de 176 millions de personnes concernées, avec un basculement progressif du vol de supports physiques vers le piratage et les incidents informatiques (voir l’étude). Juhee Kwon et M. Eric Johnson avaient de leur côté montré en 2013, dans le Journal of the American Medical Informatics Association, que la conformité réglementaire des organisations de santé dépend moins de mesures techniques isolées que de configurations cohérentes de pratiques de sécurité (voir l’étude). Traduction opérationnelle pour un éditeur : un maillon certifié dans une chaîne mal cartographiée ne produit pas de conformité.
Passez à l’action
Posez à plat votre architecture d’exploitation, activité par activité, et confrontez-la aux certificats réellement détenus par chaque maillon — y compris le vôtre. Si une activité reste orpheline, deux options : la déléguer à un acteur certifié pour cette activité, ou vous certifier (les étapes et l’audit, le budget à prévoir). La fiche certification HDS donne la vue d’ensemble du dispositif, et l’ebook offert qui l’accompagne déroule la cartographie complète.
Questions fréquentes
+S'appuyer sur un cloud certifié HDS suffit-il pour un éditeur de logiciel santé ?
Non, pas dans le cas général. La certification porte sur des activités précises et chaque acteur doit être certifié pour celles qu'il exerce lui-même. Un éditeur qui administre et exploite le système d'information contenant les données, ou qui gère ses propres sauvegardes, exerce des activités listées par le code de la santé publique et doit être certifié pour celles-ci, même si l'infrastructure est louée à un cloud certifié.
+Comment vérifier le certificat HDS d'un prestataire ?
L'Agence du Numérique en Santé publie la liste des hébergeurs certifiés, avec les activités couvertes et la version du référentiel appliquée. Vérifiez que l'entité juridique listée est bien celle qui signe votre contrat, que les activités couvertes correspondent à celles que vous déléguez, et confirmez la validité du certificat auprès de l'organisme certificateur indiqué.
+Les clauses obligatoires du contrat HDS s'appliquent-elles à un contrat entre un éditeur et son client ?
Oui. Le code de la santé publique prévoit que lorsqu'un responsable de traitement passe par un prestataire qui recourt lui-même à un hébergeur certifié, le contrat entre le responsable de traitement et ce prestataire reprend les clauses telles qu'elles figurent dans le contrat liant le prestataire à l'hébergeur certifié. Ces clauses s'ajoutent à celles de l'article 28 du RGPD.