Certification HDS : quand un éditeur de logiciel en a-t-il besoin ?

Un acheteur hospitalier vous envoie son questionnaire de sécurité. Ligne 14 : « Êtes-vous certifié HDS ? Joindre le certificat. » Selon votre architecture, la bonne réponse peut être « oui, pour les activités 4 et 5 », « non, et nous n'en avons pas besoin », ou « non, et nous sommes en infraction ». Héberger des données de santé pour un tiers sans certificat est puni de trois ans d'emprisonnement et de 45 000 euros d'amende, et le décret du 24 mars 2026 a durci les règles de localisation depuis le 26 septembre 2026. Voici comment un éditeur de logiciel détermine, architecture par architecture, s'il doit être certifié, sur quoi, ou s'il lui suffit de s'appuyer sur un hébergeur certifié.

Ce que la loi appelle héberger des données de santé

L'article L. 1111-8 du Code de la santé publique vise toute personne qui héberge des données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte de ceux qui les produisent ou les recueillent, ou pour le compte du patient lui-même. Sur support numérique, cet hébergeur doit être titulaire d'un certificat de conformité.

Deux conditions, cumulatives, déclenchent donc l'obligation.

• Des données issues d'un parcours de prévention, de soins ou de suivi. Le dossier patient d'un logiciel de cabinet, les comptes rendus d'un laboratoire, les mesures d'un télésuivi prescrit. Une application de méditation grand public, sans professionnel dans la boucle, n'en relève pas en principe. Elle traite pourtant des données de santé au sens de l'article 4.15 du RGPD, avec les contraintes de l'article 9.
• Un hébergement pour le compte d'un tiers. Le client, établissement, professionnel ou patient, vous confie ses données. Le centre de santé qui fait tourner son logiciel sur ses propres serveurs n'a besoin d'aucun certificat : c'est l'externalisation qui déclenche l'obligation, chez celui qui reçoit les données.

L'article R. 1111-8-8 prévoit une seule exclusion : ne constitue pas un hébergement le fait de se voir confier des données pour une courte période afin d'en assurer la saisie, la mise en forme, la matérialisation ou la dématérialisation. Le même article oblige le client à vérifier que son prestataire est certifié. C'est pour cela que la question arrive dans vos appels d'offres : votre client engage sa propre conformité en vous choisissant.

Les six activités du référentiel HDS v2, et celles qui touchent un éditeur

La certification ne se délivre pas en bloc. L'article R. 1111-9 découpe l'hébergement en six activités, et l'hébergeur est celui qui assure, pour le compte de son client, « tout ou partie » d'entre elles :

1. la mise à disposition et le maintien en condition opérationnelle des sites physiques ;
2. la mise à disposition et le maintien en condition opérationnelle de l'infrastructure matérielle ;
3. la même chose pour l'infrastructure virtuelle ;
4. la même chose pour la plateforme d'hébergement d'applications ;
5. l'administration et l'exploitation du système d'information contenant les données de santé ;
6. la sauvegarde des données de santé, y compris, depuis le décret du 24 mars 2026, leur conservation dans le cadre d'un archivage électronique.

Le certificat mentionne les activités couvertes. C'est là que se joue la question de l'éditeur. Les activités 1 à 3 relèvent du datacenter et du fournisseur cloud. Les activités 4 et 5 sont celles d'un éditeur SaaS : il fait tourner l'application, administre les bases, applique les mises à jour, surveille la production. L'activité 6 concerne quiconque garde une copie des données hors de l'environnement principal.

Conséquence directe : un fournisseur cloud certifié pour les activités 1 à 3 ne couvre pas ce que vous faites au-dessus. Le certificat de votre hébergeur ne se prête pas. Il atteste de ce que lui fait, pas de ce que vous faites sur son infrastructure.

L'arbre de décision de l'éditeur de logiciel

Quatre questions, dans cet ordre, suffisent à qualifier une situation. Chaque réponse doit pouvoir être prouvée par l'architecture technique et par le contrat, pas seulement affirmée.

1. Les données relèvent-elles d'un parcours de soins, de prévention ou de suivi médico-social ? Si non, le Code de la santé publique ne s'applique pas. Le RGPD, lui, continue de s'appliquer. Si oui, question suivante.
2. Les données quittent-elles le système d'information du client ? Si le logiciel est installé et exploité chez le client, sans copie chez vous et sans accès de vos équipes, vous n'hébergez rien. Si oui, question suivante.
3. Qui exploite chaque couche ? Listez qui fournit le datacenter, les serveurs, la virtualisation, la plateforme applicative, l'administration des bases, les sauvegardes. Chaque couche que vous opérez vous-même, pour le compte du client, est une activité pour laquelle il vous faut un certificat.
4. Ce que vous n'opérez pas est-il opéré par un hébergeur certifié pour cette activité précise ? Vérifiez le périmètre exact du certificat de votre fournisseur sur la liste publiée par l'Agence du numérique en santé (ANS), pas sur sa page commerciale.

Le résultat tombe dans l'une de trois cases : aucune obligation, adossement à un hébergeur certifié suffisant, ou certification propre sur une ou plusieurs activités.

Six architectures d'éditeur, six réponses

SaaS sur un cloud certifié, application opérée par vous

C'est le cas le plus fréquent et celui qui génère le plus d'erreurs. Votre fournisseur est certifié pour les activités 1 à 3, parfois 4 et 6. Vous déployez l'application, administrez la base PostgreSQL, gérez les accès et les montées de version. La pratique des organismes certificateurs tend à considérer que l'éditeur qui administre lui-même l'application et ses bases exerce l'activité 5, voire la 4, et doit être certifié sur ce périmètre. La parade partielle consiste à confier aussi l'exploitation à un infogéreur certifié pour les activités 4 et 5, ce qui suppose que vos équipes n'aient plus d'accès administrateur à la production.

SaaS sur infrastructure propre

Vous louez des baies, possédez vos serveurs, opérez la virtualisation. Vous exercez potentiellement les six activités. Si le datacenter est fourni par un tiers certifié pour l'activité 1, le reste vous incombe. Le périmètre de certification est large, et le chantier aussi.

Logiciel installé chez le client

Licence, installation sur les serveurs de l'établissement, maintenance à distance. Vous n'hébergez pas. La situation reste fragile sur deux points : la télémaintenance, si vos techniciens se connectent à la base de production, et les copies de données faites pour reproduire un bogue. La CNIL a sanctionné un éditeur de logiciels de laboratoires d'analyses médicales de 1 500 000 euros le 15 avril 2022 (SAN-2022-009) : à l'occasion de migrations demandées par ses clients, il avait extrait plus de données que nécessaire, et un fichier de près de 500 000 personnes s'était retrouvé en ligne. Le manquement retenu tenait au RGPD, pas au HDS, mais il illustre le risque d'un éditeur qui manipule des données qu'il n'est pas censé détenir.

Infogérance ou tierce maintenance applicative

Vous exploitez pour le compte d'un établissement un logiciel hébergé chez lui ou chez un tiers. L'activité 5, administration et exploitation, est au cœur de votre prestation. La certification sur cette activité est la réponse attendue, même si vous ne stockez rien chez vous.

Sauvegarde externalisée

Vous proposez une option de sauvegarde vers votre propre stockage, ou vous conservez des exports chiffrés chez un autre fournisseur. C'est l'activité 6. Le chiffrement ne fait pas disparaître la qualification : une sauvegarde reste un hébergement des données.

Support avec accès à la production

Votre application tourne chez un infogéreur certifié pour les activités 1 à 5, mais votre équipe support se connecte régulièrement à la production pour diagnostiquer. Rien dans le texte ne fixe un seuil de fréquence. Plus l'accès est régulier, nominatif et outillé, plus il ressemble à de l'exploitation. Deux options tiennent : un accès qui passe par l'infogéreur, tracé et à la demande du client, ou une certification sur l'activité 5. Dans tous les cas, cet accès doit apparaître dans la cartographie des accès, surtout s'il part d'un pays tiers.

Point de vigilance. L'exclusion des traitements de courte durée de l'article R. 1111-8-8 ne couvre pas un environnement de recette alimenté par des copies de production, ni des exports conservés « au cas où ». Pour une migration ponctuelle, la lecture la plus sûre est de limiter la durée, le volume et l'accès, et de détruire les données à la fin, preuve à l'appui.

Ce qui a changé le 26 septembre 2026 : localisation et accès depuis un pays tiers

La loi SREN du 21 mai 2024 a ajouté à l'article L. 1111-8 des obligations de stockage dans l'Union et de transparence sur les accès extra-européens. Le décret n° 2026-209 du 24 mars 2026 les a précisées, avec une entrée en vigueur différée au 26 septembre 2026. Trois règles comptent pour un éditeur.

• Stockage exclusivement dans l'Union ou l'EEE (article R. 1111-9-1). Une sauvegarde répliquée dans une région américaine par défaut est désormais hors des clous.
• Accès à distance depuis un pays tiers encadré. Un support offshore, un sous-traitant qui administre depuis l'Inde ou un éditeur de base de données qui intervient depuis les États-Unis réalisent un transfert. Il n'est permis que sur une décision d'adéquation de la Commission ou avec les garanties appropriées de l'article 46 du RGPD, auquel cas le contrat doit le dire et décrire ces garanties.
• Transparence sur les lois extraterritoriales (article R. 1111-11, 15° et III). Si l'hébergeur ou l'un de ses sous-traitants est soumis à la législation d'un pays tiers, le contrat liste ces lois, les mesures d'atténuation et les risques résiduels. L'hébergeur publie et tient à jour une cartographie des transferts et des accès distants.

Pour les États-Unis, la décision d'adéquation du 10 juillet 2023 (Data Privacy Framework) peut servir de base à un accès à distance par une entreprise adhérente. Elle ne dispense pas de lister le Cloud Act parmi les lois extraterritoriales applicables. Le risque n'est pas théorique : le juge des référés du Conseil d'État l'avait déjà pris au sérieux le 13 octobre 2020 (n° 444937), en exigeant que le Health Data Hub obtienne de Microsoft un avenant contractuel sur la loi applicable. Le sujet est détaillé dans notre analyse sur l'hébergement chez un acteur américain face au Cloud Act.

Dans son avis du 16 octobre 2025 sur le projet de décret (délibération n° 2025-098), la CNIL rappelle l'objectif affiché par le ministère : faire converger les exigences HDS avec celles de la qualification SecNumCloud de l'ANSSI. Aujourd'hui, SecNumCloud n'est pas exigé pour être hébergeur de données de santé. Mais si votre feuille de route vise l'hôpital public, choisir un socle qui peut évoluer vers cette exigence vous évitera une seconde migration.

S'appuyer sur un hébergeur certifié : ce que votre contrat doit reprendre

Quand l'arbre de décision conclut qu'un hébergeur certifié suffit, la conformité ne s'arrête pas au choix du fournisseur. L'article R. 1111-11 impose au contrat d'hébergement quinze clauses minimales, parmi lesquelles :

• le périmètre du certificat et ses dates de délivrance et de renouvellement ;
• les lieux d'hébergement ;
• les indicateurs de qualité de service et les pénalités, ou leur absence ;
• les conditions de recours à des sous-traitants techniques ;
• la réversibilité, y compris en cas de perte ou de retrait de la certification ;
• la restitution de la totalité des données en fin de prestation, puis leur destruction sans copie ;
• depuis le 26 septembre 2026, les mentions sur les transferts, les accès distants et les lois extraterritoriales.

Le II du même article vise exactement votre situation : quand le client fait appel à un prestataire qui recourt lui-même à un hébergeur certifié, le contrat entre le client et ce prestataire reprend les clauses du contrat signé avec l'hébergeur. Votre contrat SaaS doit donc répercuter, à l'identique, ce que votre hébergeur vous garantit. Un contrat d'abonnement standard qui renvoie à des conditions générales muettes sur ces points ne passe pas l'audit d'achat d'un groupement hospitalier. Les clauses à négocier avec vos clients établissements sont détaillées dans notre guide sur les clauses à verrouiller dans un contrat SaaS santé.

Côté amont, la négociation du contrat avec l'hébergeur lui-même, mention par mention et à jour du décret du 24 mars 2026, est traitée dans notre guide des clauses à vérifier dans un contrat avec un hébergeur de données de santé.

Conseil d'avocat. Avant de signer avec un hébergeur, je demande toujours deux documents : le certificat, pour lire le périmètre exact des activités couvertes, et le contrat d'hébergement type, pour vérifier qu'il contient les quinze clauses dans leur rédaction en vigueur depuis le 26 septembre 2026. Un certificat sans le bon périmètre, ou un contrat antérieur au décret, sont les deux défauts que je rencontre le plus souvent.

Certification HDS : étapes, délais et coûts réels

Le certificat est délivré par un organisme accrédité par le COFRAC ou un homologue européen, sur la base du référentiel élaboré par l'ANS et approuvé par arrêté (article R. 1111-10). La version 2 du référentiel a été approuvée par l'arrêté du 26 avril 2024. Selon l'ANS, les hébergeurs déjà certifiés avaient jusqu'au 16 mai 2026 pour basculer : depuis cette date, seuls les certificats v2 sont valables. Un fournisseur qui vous présente un certificat v1 n'est donc plus certifié.

Le parcours se déroule en quatre temps.

1. Cadrage du périmètre. Quelles activités, quels services, quels sites, quels sous-traitants. C'est l'étape juridique et technique décisive : un périmètre trop large coûte cher, un périmètre trop étroit laisse une activité non couverte.
2. Mise en conformité. Le référentiel s'appuie sur la norme ISO 27001, complétée d'exigences propres aux données de santé, dont la localisation et la transparence sur les transferts. Une base ISO 27001 existante fait gagner plusieurs mois.
3. Audit en deux étapes. Revue documentaire, puis audit sur site par l'organisme certificateur.
4. Vie du certificat. Validité de trois ans, audit de surveillance chaque année. Tout ajout d'activité ou de site se déclare.

Côté délai, il faut compter en pratique six à douze mois entre le lancement et la délivrance pour un éditeur sans ISO 27001, moins s'il l'a déjà. Côté coût, aucune grille officielle n'existe. Le budget se décompose en quatre postes : les frais d'audit de l'organisme, au prorata du périmètre et du nombre de sites ; le temps interne de votre équipe sécurité et de vos développeurs ; l'éventuel accompagnement extérieur ; les chantiers techniques révélés par l'analyse d'écart, journalisation, chiffrement, gestion des accès. Ce dernier poste est souvent le plus lourd. Demandez des devis à plusieurs organismes accrédités, dont la liste est publiée par l'ANS, sur un périmètre écrit.

Pour une startup en amorçage, la séquence raisonnable est souvent de démarrer adossée à un infogéreur certifié pour les activités 1 à 5, puis de viser sa propre certification quand l'équipe d'exploitation interne grandit. C'est ce choix d'architecture, pas la taille de l'entreprise, qui détermine l'obligation.

Ce que risque un éditeur qui héberge sans certificat

• Le pénal. L'article L. 1115-1 du Code de la santé publique punit l'hébergement sans certificat de trois ans d'emprisonnement et de 45 000 euros d'amende. Pour une société, l'amende est portée au quintuple, soit 225 000 euros (article 131-38 du Code pénal), et l'article L. 1115-2 ajoute des peines complémentaires, dont l'interdiction d'exercer l'activité concernée. Vos équipes sont aussi tenues au secret professionnel, sous peine d'un an d'emprisonnement et de 15 000 euros d'amende (article 226-13 du Code pénal, auquel renvoie l'article L. 1111-8).
• Le RGPD. Une sécurité insuffisante au regard de l'article 32 expose à une amende jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires mondial (article 83.4). Une base légale défaillante pour des données de santé relève du plafond supérieur, 20 millions d'euros ou 4 % (article 83.5). L'éditeur sous-traitant est sanctionnable en propre, comme le montre la décision de 2022 citée plus haut.
• Le contractuel et le commercial. Résiliation pour manquement, exclusion des consultations publiques, et une ligne rouge dans la due diligence de votre prochaine levée de fonds.

Par où commencer

Trois actions, dans l'ordre. Cartographiez qui exploite chaque couche de votre architecture, accès du support et sauvegardes compris. Vérifiez le périmètre exact du certificat de chaque fournisseur sur la liste de l'ANS. Mettez votre contrat client en cohérence avec l'article R. 1111-11 dans sa rédaction du 26 septembre 2026. Gardez aussi un œil sur l'espace européen des données de santé, le règlement (UE) 2025/327, qui s'appliquera par étapes à partir de mars 2027 et ajoutera des exigences d'interopérabilité et de journalisation à votre socle HDS : voir notre article sur les obligations de l'EHDS.

J'accompagne les éditeurs de santé sur ces trois chantiers, en lisant l'architecture technique avant le contrat : qualification au regard de l'article L. 1111-8, choix du périmètre, contrats avec l'hébergeur et avec les établissements. Mon accompagnement juridique e-santé et healthtech s'inscrit dans le conseil plus large que je délivre aux éditeurs de logiciels et de SaaS. Faites le test ci-dessous pour situer votre architecture, puis échangeons sur votre situation d'éditeur face au HDS.