Hébergement HDS : comprendre les enjeux pour les applications de santé

Qu'est-ce que l'HDS ?

HDS signifie Hébergement de Données de Santé. En France, lorsqu'une application héberge des données de santé à caractère personnel pour le compte d'un tiers, l'hébergement doit être réalisé chez un prestataire certifié HDS. Cette certification est encadrée par le Code de la santé publique, l'Agence du Numérique en Santé (ANS), et s'appuie sur des exigences proches des standards de sécurité type ISO 27001.

L'objectif n'est pas seulement « d'avoir un serveur sécurisé », mais de garantir :

• la confidentialité des données,
• la traçabilité des accès,
• la résilience de l'infrastructure,
• les procédures de sauvegarde et de reprise,
• la gestion des incidents,
• la maîtrise opérationnelle de l'environnement technique.

Toutes les applications de santé ont-elles besoin du HDS ?

Non. C'est un point important, car beaucoup de projets surestiment — ou sous-estiment — leurs obligations.

Généralement concernés par l'HDS

• dossiers patients,
• comptes-rendus médicaux,
• questionnaires de santé,
• données de suivi thérapeutique,
• agendas médicaux associés à des patients,
• plateformes de coordination de soins,
• applications manipulant des données médicales identifiantes.

Pas forcément concernés

• site vitrine d'un cabinet,
• formulaire de contact simple,
• prise de rendez-vous sans donnée médicale,
• application interne sans hébergement externalisé,
• outils statistiques totalement anonymisés.

La frontière dépend surtout des données réellement manipulées, du niveau d'identification possible, et du rôle exact de l'application.

HDS ne veut pas dire « application conforme »

C'est probablement l'un des malentendus les plus fréquents. Un hébergement HDS ne rend pas automatiquement une application conforme RGPD, ni intrinsèquement sécurisée. Une application peut être hébergée chez un excellent hébergeur HDS tout en présentant des failles applicatives, une mauvaise gestion des droits, des accès trop permissifs, des exports non sécurisés ou des problèmes organisationnels.

À l'inverse, une bonne posture sécurité repose sur plusieurs couches : hébergement HDS, chiffrement, authentification robuste, journalisation, gestion fine des permissions, limitation des accès, sauvegardes, supervision, politique de mise à jour, et sensibilisation des utilisateurs.

Le vrai enjeu : penser la sécurité dès l'architecture

Dans les projets santé, la sécurité ne doit pas être « ajoutée à la fin ». Les décisions prises très tôt ont souvent un impact majeur : séparation des environnements, cloisonnement des données, stratégie multi-tenant, gestion des accès professionnels, architecture API, stockage documentaire, politique de logs, gestion des sauvegardes, stratégie d'authentification.

C'est particulièrement vrai dans les projets institutionnels où plusieurs structures coexistent — établissements, associations, CPTS, réseaux de soins, ARS, coordinateurs, professionnels libéraux, patients. Une architecture mal pensée au départ devient rapidement difficile à sécuriser et coûteuse à faire évoluer.

Cloud public et HDS : une approche devenue mature

Aujourd'hui, de nombreux projets santé s'appuient sur des infrastructures cloud modernes certifiées HDS. Des plateformes comme Google Cloud, Microsoft Azure ou AWS proposent désormais des environnements compatibles avec des architectures de santé robustes et scalables.

Cela permet une meilleure résilience, des sauvegardes automatisées, de la haute disponibilité, une supervision avancée, une montée en charge progressive et une maîtrise plus fine des coûts. La question n'est donc plus « cloud ou HDS ? », mais « comment concevoir une architecture cohérente, sécurisée et adaptée aux usages réels ? ».

Le piège des projets surdimensionnés

À l'inverse, certains projets santé deviennent inutilement complexes dès le départ : infrastructure trop lourde, multiplication des outils, exigences irréalistes, surcoûts d'exploitation, architecture difficile à maintenir.

Dans beaucoup de cas, une approche pragmatique permet d'obtenir un bon niveau de sécurité, une conformité adaptée et une excellente fiabilité, tout en conservant un budget réaliste. Le bon équilibre dépend toujours du niveau de risque, du nombre d'utilisateurs, des usages métiers et des objectifs du projet.

Concevoir un projet santé crédible

Un projet numérique de santé ne repose pas uniquement sur une interface ou des fonctionnalités. Il doit inspirer confiance — aux professionnels, aux institutions, aux partenaires, et surtout aux patients.

L'hébergement HDS fait partie de cette crédibilité, mais il ne représente qu'un élément d'un ensemble plus large : architecture, sécurité, gouvernance, exploitation, maintenance, et compréhension du terrain métier. Chez Dawi, nous considérons ces sujets comme des éléments de conception à part entière, au même titre que l'expérience utilisateur ou les fonctionnalités métier.

En résumé

L'HDS n'est ni une case à cocher ni un sésame. C'est une exigence ciblée, qui s'applique quand des données de santé identifiantes sont hébergées pour le compte d'un tiers — pas systématiquement, et pas suffisamment seule. Bien posée dès l'amont, elle s'intègre naturellement à une architecture santé moderne. Mal posée, elle devient un coût subi sans gain de sécurité réel.

La bonne question à se poser au démarrage d'un projet n'est pas « est-ce que mon hébergeur est certifié ? », mais : quelles données vais-je manipuler, pour quels usages, avec quels acteurs, et comment construire l'ensemble pour que la sécurité soit cohérente de bout en bout ? Si vous portez un projet de ce type, c'est exactement le genre de sujet que nous aidons à cadrer dès la conception.