Certification HDS : le guide complet pour les startups e-santé en 2026
30/01/2026
Vous lancez une application de santé, un logiciel médical ou une plateforme de téléconsultation. À un moment ou un autre, quelqu'un autour de la table va poser la question : "On doit être HDS ?"
La réponse courte : souvent oui. Et si vous ne l'êtes pas, vous exposez votre startup à des sanctions CNIL, à la perte de contrats avec des établissements de santé, et dans le pire des cas, à un arrêt forcé de votre activité.
Ce guide couvre ce qu'est la certification HDS, quand elle est obligatoire, combien ça coûte, quels hébergeurs choisir, et les erreurs classiques à éviter quand on est une startup qui découvre cet écosystème réglementaire.
Qu'est-ce que la certification HDS ?
HDS signifie Hébergeur de Données de Santé. C'est un cadre réglementaire français, défini par la loi, qui impose que toutes les données de santé à caractère personnel soient hébergées chez un prestataire officiellement certifié.
La certification HDS est délivrée par des organismes d'accréditation agréés (comme BSI, Bureau Veritas, LRQA, etc.) sur la base d'un référentiel publié par l'Agence du Numérique en Santé (ANS). Ce référentiel s'appuie sur des normes ISO reconnues, principalement ISO 27001 et ISO 27701.
En clair : ce n'est pas un simple label marketing. C'est une obligation légale, avec des audits tiers, des contrôles documentaires, et des renouvellements périodiques.
Ce que la certification garantit
- Les données de santé sont stockées dans un environnement sécurisé et audité
- Des procédures de gestion des incidents et de continuité d'activité existent
- L'accès aux données est tracé, cloisonné et contrôlé
- L'hébergeur peut être tenu responsable contractuellement
Les 6 activités couvertes par la certification HDS
La certification HDS est modulaire. Un hébergeur peut être certifié sur tout ou partie des activités suivantes :
| Activité | Description |
|---|---|
| 1 — Infrastructure physique | Mise à disposition et maintien en condition opérationnelle des sites physiques (datacenters) |
| 2 — Infrastructure virtuelle | Gestion des ressources de calcul, stockage et réseau virtualisés |
| 3 — Plateforme d'hébergement | Fourniture de services d'hébergement applicatif (PaaS) |
| 4 — Infogérance | Administration et exploitation des systèmes d'information de santé |
| 5 — Édition de logiciel | Conception, développement et maintenance de logiciels de santé |
| 6 — Messagerie sécurisée | Services de messagerie de santé sécurisée (type MSSanté) |
Pour une startup qui développe une application de santé hébergée dans le cloud, les activités 1, 2 et 3 sont les plus pertinentes : ce sont celles que doivent couvrir vos prestataires infrastructure (AWS, OVHcloud, Scaleway, etc.).
L'activité 5 vous concerne directement si vous développez et maintenez un logiciel de santé : vous devenez vous-même un acteur certifié HDS côté éditeur.
Quand la certification HDS est-elle obligatoire ?
C'est la question que tout fondateur se pose. La réponse dépend de ce que vous traitez comme données.
Obligatoire si vous traitez des "données de santé à caractère personnel"
La loi est claire : tout hébergement de données de santé à caractère personnel dans le cadre d'une activité de prévention, de diagnostic, de soins ou de suivi médico-social nécessite un hébergeur certifié HDS.
Êtes-vous concerné ? Ça dépend de ce que fait votre application :
| Cas d'usage | HDS obligatoire ? |
|---|---|
| Dossier médical partagé, historique de soins | Oui |
| Téléconsultation avec données patient | Oui |
| Application de suivi de pathologie chronique | Oui |
| Résultats d'analyses biologiques | Oui |
| Imagerie médicale (radio, scanner) | Oui |
| Application bien-être sans données médicales identifiées | Non (mais attention au fond) |
| Données RH santé (absentéisme) sans données médicales | Non |
| Agrégateur de données anonymisées | Non (si réelle anonymisation) |
Le critère déclenchant, c'est la combinaison de deux éléments : donnée de santé + identification possible de la personne. Si vous traitez des données qui permettent d'identifier un patient et de connaître son état de santé, vous êtes dans le scope HDS.
La zone grise : les applications "bien-être"
Beaucoup de startups tentent de contourner en se positionnant comme "application bien-être" plutôt qu'application médicale. Attention : si votre app collecte un poids, une glycémie, des symptômes ou un suivi de traitement, même dans une logique de wellness, la CNIL et les juridictions françaises peuvent requalifier ces données en données de santé. En cas de doute, l'approche la plus sage est de vous conformer HDS dès le départ.
Les changements du référentiel HDS 2024
Le référentiel HDS a été mis à jour en 2024. Le changement le plus important pour les startups françaises : l'obligation de localisation des données dans l'EEE (Espace Économique Européen).
Ce que ça signifie en pratique
- Les données de santé doivent être stockées et traitées physiquement dans l'EEE
- Les transferts hors EEE sont soumis à des garanties supplémentaires (clauses contractuelles types, etc.)
- Même si votre hébergeur est certifié HDS, si ses datacenters sont aux États-Unis ou en Asie pour les données concernées, vous n'êtes plus conforme
Impact sur les grands providers
Ce point a créé quelques remous chez des startups qui utilisaient AWS ou Google Cloud avec des configurations par défaut pointant sur des régions américaines. La bonne nouvelle : AWS, Azure et Google Cloud ont tous des régions européennes certifiées HDS. Il faut simplement explicitement configurer vos déploiements pour rester dans ces régions.
Le référentiel 2024 a également renforcé les exigences sur la gestion des sous-traitants (votre hébergeur doit lister et auditer ses propres sous-traitants) et sur la traçabilité des accès aux données de santé.
Les hébergeurs certifiés HDS en 2026
Voici les principaux acteurs que vous allez rencontrer en tant que startup e-santé :
Acteurs cloud majeurs (IaaS/PaaS)
| Hébergeur | Activités certifiées | Points forts | Points d'attention |
|---|---|---|---|
| OVHcloud | 1, 2, 3 | Prix compétitif, données en France, souveraineté | Interface moins mature qu'AWS |
| AWS France (Paris) | 1, 2, 3 | Maturité, richesse des services, scalabilité | Configuration EEE à vérifier |
| Microsoft Azure | 1, 2, 3 | Intégration Office 365, forte présence hospitalière | Coût plus élevé |
| Scaleway | 1, 2, 3 | Souveraineté française, bon rapport qualité/prix | Moins de services managés |
| Google Cloud | 1, 2, 3 | IA/ML, BigQuery | Moins de références santé FR |
| Outscale (Dassault) | 1, 2, 3 | Souveraineté totale, SecNumCloud | Coût élevé, moins d'écosystème |
Acteurs spécialisés santé
| Hébergeur | Spécialité | Pour qui |
|---|---|---|
| Atos / Eviden | Hébergement hospitalier, FHIR | Gros projets, contrats publics |
| Claranet | Infogérance, activité 4 | Startups qui veulent déléguer l'ops |
| Cegedim | Logiciels et hébergement santé | Éditeurs logiciels médicaux |
| Maincare | Systèmes d'information hospitaliers | Éditeurs SIH |
Mon conseil pour les startups early-stage
Pour une startup en phase de lancement, OVHcloud ou Scaleway offrent le meilleur compromis : certification HDS, données en France, prix accessibles, et une documentation suffisante pour une équipe technique autonome. AWS Paris est une excellente option si votre équipe connaît déjà l'écosystème AWS, mais pensez à activer les garde-fous de conformité dès le départ (AWS Artifact pour récupérer les attestations HDS, restriction des régions, etc.).
Combien coûte l'hébergement HDS ?
Parlons chiffres.
Surcoût HDS vs hébergement standard
La certification HDS entraîne un surcoût de 20 à 50% par rapport à un hébergement cloud standard équivalent, selon les prestataires. Ce surcoût s'explique par les audits, les mesures de sécurité supplémentaires, et la responsabilité contractuelle accrue.
Estimation de coûts selon la taille du projet
| Stade | Infrastructure typique | Coût mensuel estimé (HDS) |
|---|---|---|
| MVP / prototype | 1 serveur mutualisé ou petit VPS | 50 – 200 €/mois |
| Produit en production | 2-3 serveurs, base de données managée, stockage | 300 – 1 000 €/mois |
| Startup en croissance | Architecture multi-services, redondance, monitoring | 1 000 – 5 000 €/mois |
| Scale-up | Architecture multi-régions, haute disponibilité | 5 000 €+/mois |
Ces chiffres sont des ordres de grandeur. Le coût réel dépend fortement de votre architecture, de vos volumes de données, et du niveau de services managés que vous utilisez.
Ce qu'on oublie souvent dans le budget
- L'audit de certification éditeur (activité 5) : si vous voulez être certifié HDS vous-même (et pas seulement votre hébergeur), comptez entre 10 000 et 30 000 € pour le premier audit, plus des coûts de maintien annuels
- Le DPO ou RSSI externalisé : pas toujours obligatoire, mais fortement recommandé. Comptez 500 à 2 000 €/mois selon le niveau d'implication
- La mise en conformité RGPD santé : distincte de HDS, mais souvent traitée en parallèle
Les erreurs classiques des startups e-santé
On a accompagné plusieurs projets dans le secteur. Les mêmes erreurs reviennent régulièrement.
Erreur 1 : Confondre RGPD et HDS
Le RGPD et la certification HDS sont deux obligations distinctes. Le RGPD s'applique à toutes les données personnelles. La certification HDS s'applique spécifiquement aux données de santé hébergées. Être conforme RGPD ne suffit pas : vous devez l'être sur les deux tableaux. Pour en savoir plus sur vos obligations en matière de données de santé, consultez notre guide dédié.
Erreur 2 : Attendre d'avoir des utilisateurs pour se conformer
La conformité HDS doit être architecturale, pas ajoutée en retard. Migrer une infrastructure existante vers un environnement HDS coûte en moyenne 3 à 5 fois plus cher que de le faire dès le début. De plus, si vous avez déjà collecté des données de santé sans être HDS, vous avez déjà une infraction en cours.
Erreur 3 : Croire que l'hébergeur certifié suffit
Le fait que votre cloud provider soit certifié HDS ne vous certifie pas automatiquement. La certification de l'hébergeur couvre son infrastructure. Pas votre application, pas votre configuration, pas vos pratiques de développement. Si votre app expose des données de santé via une API non sécurisée ou les stocke en clair, vous n'êtes pas conforme, peu importe l'hébergeur.
Erreur 4 : Négliger le contrat d'hébergement
La certification HDS impose des clauses contractuelles spécifiques entre vous et votre hébergeur. Vérifiez que votre contrat inclut : l'engagement de certification HDS, les modalités de transfert et suppression des données, les SLA (disponibilité, RTO/RPO), et les conditions d'audit. Sans ces clauses, même un hébergeur certifié ne vous couvre pas.
Erreur 5 : Ignorer la chaîne de sous-traitance
Si vous utilisez des services tiers dans votre stack (analytics, monitoring, support client, emails transactionnels), chacun de ces services qui traite des données de santé doit aussi être conforme. Un pixel de tracking tiers qui capture des données de navigation sur une page médicale peut suffire à créer une non-conformité.
Checklist de conformité HDS pour votre startup
Les étapes clés pour structurer votre mise en conformité :
- Cartographier vos données : identifier précisément quelles données sont des données de santé dans votre produit
- Choisir un hébergeur certifié HDS pour les activités 1, 2 et 3 (infrastructure)
- Vérifier la localisation EEE : configurer vos déploiements sur des régions européennes
- Signer un contrat HDS avec votre hébergeur (pas juste les CGU standard)
- Mettre en place un registre des traitements (obligation RGPD qui s'applique également)
- Sécuriser votre application : chiffrement des données au repos et en transit, gestion des accès, traçabilité
- Auditer vos sous-traitants : identifier tous les tiers qui touchent à vos données de santé
- Rédiger votre politique de confidentialité spécifique santé
- Envisager la certification éditeur (activité 5) si vous visez des contrats avec des établissements de santé publics
Comment Bob le développeur peut vous accompagner
Chez Bob le développeur, on accompagne les startups e-santé depuis la conception de l'architecture technique jusqu'au déploiement en environnement certifié HDS.
En pratique : choisir la bonne stack dès le départ pour être conforme sans surcoût inutile, structurer votre infrastructure cloud sur les bons services HDS, et sécuriser votre application au niveau du code, pas uniquement au niveau de l'hébergeur.
Si vous êtes en train de concevoir ou de refactoriser une application dans le secteur de la santé et que vous avez des questions sur votre architecture ou vos obligations, c'est exactement le type de projet sur lequel on travaille. N'hésitez pas à prendre contact.
Conclusion
La certification HDS est la colonne vertébrale de la confiance dans le secteur de la santé numérique. Pour une startup, la traiter comme une contrainte à minimiser est une erreur stratégique : les établissements de santé, les mutuelles et les professionnels de santé ne travailleront tout simplement pas avec vous si vous n'êtes pas en mesure de prouver votre conformité.
Avec les bons partenaires techniques et une architecture pensée dès le départ, se conformer à HDS reste accessible pour une startup early-stage. Le coût est réel, mais prévisible et maîtrisable. Ça reste bien moins cher qu'une mise en conformité forcée après coup ou qu'une sanction CNIL.
Si vous souhaitez aller plus loin sur les spécificités réglementaires du développement d'applications santé en France, retrouvez notre guide complet sur le sujet.