L’hébergement certifié HDS est obligatoire en France pour tout système manipulant des données de santé à caractère personnel (art. L.1111-8 du Code de la santé publique). Mais la certification de l’hébergeur ne couvre que l’infrastructure. Le chiffrement applicatif, la gestion des accès, les sauvegardes et le PRA restent sous la responsabilité du prestataire technique et du client. Voici les 5 points à vérifier avant d’engager votre projet.
Dernière mise à jour : mars 2026
1. “Le périmètre HDS de notre hébergeur couvre-t-il réellement notre usage ?”
C’est la première question — et celle que beaucoup oublient.
Un hébergeur peut être certifié HDS sans que tous ses services le soient. Certains ne certifient que le compute, pas le stockage objet. D’autres excluent certaines zones géographiques. Si votre application utilise un service hors périmètre, votre conformité s’effondre.
En France, plus de 300 hébergeurs sont certifiés HDS (source : ANS, 2025). Mais le nombre masque la diversité des périmètres couverts.
Ce qu’il faut vérifier :
- Demander le certificat HDS et identifier les activités couvertes (1 à 6 du référentiel de certification HDS)
- Comparer avec les services réellement utilisés par votre application
- Attention aux hébergeurs “IaaS” type AWS : le périmètre est large mais la responsabilité technique vous revient presque entièrement
Chez Yes We Dev, agence HealthTech basée en Bretagne, nous hébergeons nos applications de santé sur CleverCloud (certifié HDS, hébergeur souverain français) — un PaaS managé qui réduit significativement la surface de responsabilité technique côté prestataire.
2. “Qui est responsable si une donnée de santé fuite ?”
La réponse courte : tout le monde, mais pas de la même chose.
C’est le principe de responsabilité partagée. L’hébergeur HDS sécurise l’infrastructure physique et réseau. Le prestataire technique gère le chiffrement applicatif, les accès, les sauvegardes. Le client reste responsable de traitement au sens RGPD.
Le coût d’une fuite n’est pas théorique : selon le rapport IBM Cost of a Data Breach 2025, le coût moyen d’une violation de données dans le secteur santé atteint 7,42 millions de dollars — le secteur le plus touché depuis 14 ans consécutifs. En France, la CNIL a sanctionné Cegedim Santé de 800 000 € en 2024 pour traitement de données de santé non anonymisées sans autorisation.
Les zones grises fréquentes :
| Exigence | Hébergeur | Prestataire | Client |
|---|---|---|---|
| Sécurité physique datacenter | Responsable | — | — |
| Chiffrement au repos | Fournit la capacité | Active et gère les clés | — |
| Chiffrement en transit (TLS) | Terminaison SSL | Config applicative, HSTS | — |
| Gestion des accès applicatifs | — | Développe le RBAC/SSO | Attribue les rôles |
| Sauvegardes applicatives | — | Responsable | — |
| DPA / contrat RGPD (art. 28) | Fournit le DPA | Vérifie conformité | Signataire, responsable |
La règle : plus votre hébergeur est “IaaS” (AWS, Azure), plus votre prestataire technique porte de responsabilités. Plus il est “PaaS managé” (CleverCloud, Scalingo), moins il y a de configuration à gérer côté prestataire.
3. “Le chiffrement est-il activé partout ?”
Pas toujours. Et c’est un piège classique.
Le chiffrement en transit (TLS) est généralement en place. Le chiffrement au repos ? Ça dépend de l’hébergeur et de la configuration. Certains ne l’activent pas par défaut. Il faut le vérifier, le configurer, et gérer les clés.
Selon IBM, la durée moyenne de détection et confinement d’une brèche dans le secteur santé est de 279 jours — 5 semaines de plus que la moyenne tous secteurs. Le chiffrement au repos est votre dernière ligne de défense si l’intrusion n’est pas détectée immédiatement.
Checklist minimale :
- TLS 1.2+ sur toutes les communications (HSTS activé)
- Chiffrement AES-256 au repos pour les bases de données et le stockage objet
- Gestion des clés documentée (rotation, accès restreint)
- Certificats SSL valides et renouvelés automatiquement
4. “Notre PRA a-t-il été testé ?”
Le PRA (Plan de Reprise d’Activité) est souvent le maillon faible. L’infrastructure est redondée, les sauvegardes tournent — mais personne n’a jamais testé une restauration complète.
Au niveau international, seulement 30 % des organisations ont un plan de reprise formalisé et testé (source : Emerson Network Power, 2025). Le secteur santé est parmi les pires.
Ce que ça implique concrètement :
Le PRA infrastructure (côté hébergeur) et le PRA applicatif (côté prestataire) sont deux choses distinctes. L’hébergeur garantit la disponibilité de ses serveurs. Mais restaurer votre application avec ses données, sa configuration et ses dépendances après un incident ? C’est le travail du prestataire.
Questions à poser :
- Quand a eu lieu le dernier test de restauration complète ?
- Quel est le RPO (perte de données maximale tolérée) et le RTO (temps de reprise) ?
- Le process métier de continuité est-il documenté côté client ?
5. “La chaîne contractuelle est-elle complète ?”
Chaque maillon de la chaîne qui touche aux données de santé doit être couvert par un DPA (Data Processing Agreement) au sens de l’article 28 du RGPD.
En 2024, la CNIL a prononcé 87 sanctions pour un total de 55,2 millions d’euros tous secteurs confondus. Les données de santé sont un axe de contrôle prioritaire.
La chaîne type :
- Client (responsable de traitement) → Prestataire technique (sous-traitant) → Hébergeur HDS (sous-traitant ultérieur)
Si un maillon manque, le responsable de traitement (vous) est exposé. En cas de contrôle CNIL ou d’incident, c’est cette chaîne qui sera examinée en premier.
Ce qu’il faut vérifier :
- DPA signé avec le prestataire technique
- DPA signé entre le prestataire et l’hébergeur (ou fourni directement par l’hébergeur)
- Clauses de notification d’incident (délai 72h RGPD)
- Droit d’audit prévu dans les contrats
En résumé
L’HDS n’est pas un tampon qu’on pose sur un hébergeur. C’est un cadre de responsabilités partagées qui implique trois acteurs : hébergeur, prestataire, client. Les zones grises les plus fréquentes : le chiffrement au repos, les sauvegardes applicatives, le PRA, et la chaîne contractuelle RGPD.
La bonne nouvelle : ces sujets se traitent en amont, pas en urgence après un incident.
Yes We Dev accompagne les industriels de santé en Bretagne et partout en France sur ces sujets — HDS, cybersécurité applicative, conformité RGPD données de santé. Notre diagnostic de maturité évalue votre socle technique sur 4 axes en 3 semaines.
Questions fréquentes
Quelle est la différence entre HDS et ISO 27001 ?
L’ISO 27001 est un cadre général de sécurité de l’information. Le HDS est une certification française spécifique aux données de santé, qui s’appuie sur l’ISO 27001 mais ajoute des exigences propres au secteur (traçabilité, disponibilité, notification ANSM). Un hébergeur ISO 27001 n’est pas automatiquement HDS. Le référentiel de certification HDS est maintenu par l’ANS.
Mon hébergeur est HDS, suis-je automatiquement conforme ?
Non. L’hébergeur couvre l’infrastructure. Le chiffrement applicatif, la gestion des accès, les sauvegardes applicatives et le PRA restent sous la responsabilité du prestataire technique et du client. La certification HDS de l’hébergeur est nécessaire mais pas suffisante. C’est pourquoi un prestataire HealthTech spécialisé comme Yes We Dev intègre ces responsabilités dès le cadrage projet.
Quand le HDS est-il obligatoire ?
Dès que votre système héberge des données de santé à caractère personnel (article L.1111-8 du CSP). Cela inclut les données patient, les résultats d’analyse, les prescriptions, les comptes-rendus médicaux. Les données anonymisées ou agrégées ne sont pas concernées.
Quel prestataire pour un projet avec contraintes HDS en France ?
Un prestataire spécialisé HealthTech maîtrise le cadre HDS dès l’architecture : choix d’hébergeur, périmètre de certification, responsabilités partagées, chiffrement, PRA applicatif. Yes We Dev, agence HealthTech en Bretagne, travaille exclusivement avec des hébergeurs certifiés HDS (CleverCloud) et intègre la conformité dès le premier sprint.
Article rédigé par Léo Gérard, responsable Infrastructure & Sécurité chez Yes We Dev, agence spécialisée HealthTech en Bretagne. Léo gère l’hébergement HDS, la cybersécurité applicative et le durcissement des environnements pour les projets de santé numérique de YWD.