HDS : anticiper sans sur-architecturer

Une HealthTech doit cadrer son périmètre HDS avant d'utiliser la première donnée réelle. Pas pour transformer son MVP en système hospitalier, mais pour savoir quelles données elle manipule, qui les héberge et qui peut y accéder. Attendre le premier contrat expose à une migration coûteuse. Tout industrialiser dès le prototype produit l'effet inverse : le produit avance trop lentement pour vérifier que quelqu'un en a besoin.

Sur Sappy, une plateforme destinée aux services à domicile, le sujet est devenu concret avec le suivi des bénéficiaires et les alertes liées à leur santé. Nous ne pouvions pas traiter l'hébergement comme une ligne à régler juste avant la mise en production. Les environnements, les accès et les responsabilités devaient rester cohérents avec la sensibilité des informations manipulées.

Anticipez les décisions difficiles à inverser. Pour le reste, restez aussi simple que votre stade le permet.

HDS commence par qualifier les données

Le sigle HDS désigne une certification des hébergeurs de données de santé. Ce n'est ni une certification globale de votre produit ni une preuve que toute votre organisation respecte le RGPD. Son périmètre concerne l'hébergement de données de santé à caractère personnel recueillies dans le cadre d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social.

Toutes les informations collectées par une application de bien-être ne sont pas automatiquement des données de santé. À l'inverse, un champ banal peut le devenir par sa destination ou son croisement avec d'autres informations. La CNIL inclut les données qui permettent de déduire un état de santé, même lorsqu'elles ne proviennent pas d'un professionnel. Sa définition des données de santé impose d'examiner l'usage plutôt que le nom du produit.

La première question n'est pas « quel cloud choisir ? ». Demandez quelles informations entrent dans le produit, pourquoi vous les collectez, qui les consulte et ce qu'elles révèlent sur une personne identifiable. Un prototype peut utiliser des données fictives, puis changer de régime lorsque son premier partenaire importe des dossiers réels.

Attribuez ensuite les responsabilités. L'article L.1111-8 du Code de la santé publique encadre l'hébergement réalisé pour le compte du patient ou de l'acteur à l'origine des données. La prestation doit faire l'objet d'un contrat et l'hébergeur numérique doit disposer du certificat correspondant. L'Agence du numérique en santé distingue notamment l'infrastructure, la plateforme applicative, l'administration du système et la sauvegarde. Sa page sur la certification HDS détaille ce découpage.

On parle parfois de « niveaux HDS », mais ce ne sont pas des grades de sécurité. Le certificat précise les activités couvertes. Les activités 1 et 2 concernent le site physique et le matériel. Les activités 3 et 4 concernent l'infrastructure virtuelle et la plateforme qui héberge l'application. L'activité 5 couvre l'administration et l'exploitation du système ; l'activité 6, la sauvegarde externalisée. L'ANS rassemble les activités 1 et 2 sous le certificat « hébergeur d'infrastructure physique », et les activités 3 à 6 sous le certificat « hébergeur infogéreur ». Un prestataire peut n'en couvrir qu'une partie. Comparez donc son certificat aux rôles qu'il assume réellement dans votre architecture.

Un logo HDS sur la page d'un fournisseur ne suffit pas. Vérifiez l'offre exacte, les activités couvertes par son certificat et la répartition des responsabilités. Votre entreprise, l'opérateur cloud et un prestataire d'infogérance peuvent intervenir sur des parties différentes. Si le rôle de votre société reste ambigu, faites valider ce périmètre par un professionnel du droit ou de la conformité.

Découvrir le périmètre après le pilote coûte cher

Le périmètre dérive par petites décisions. Un partenaire envoie un export contenant de vraies informations. Un développeur copie quelques dossiers pour reproduire un bug. Le support demande un accès administrateur. Une sauvegarde part vers un autre service. Prise isolément, chaque action paraît raisonnable. Leur accumulation crée pourtant un système que personne n'avait cadré.

Le coût apparaît au moment de signer le premier pilote avec des données réelles. Le partenaire demande où résident les données, qui administre la base et comment les accès sont tracés. Si les réponses dépendent de plusieurs fournisseurs choisis sans vision commune, l'équipe doit cartographier l'existant sous pression. Elle découvre parfois qu'un service essentiel ne figure pas dans le périmètre certifié attendu, qu'un environnement de test contient des données réelles ou qu'un intervenant peut accéder à la production sans procédure claire.

À ce stade, changer d'hébergement ne se limite plus à déplacer la base de données. Il faut migrer les fichiers, tester les sauvegardes et modifier les contrats. Le Code de la santé publique prévoit la restitution des données à la fin de l'hébergement. Découvrir à ce moment-là qu'il faut migrer peut retarder ou bloquer le pilote.

Les exigences continuent d'évoluer. Le référentiel HDS 2.0 a renforcé la souveraineté et la transparence sur les transferts hors de l'Espace économique européen. L'ANS annonce une version 2.1 pour octobre 2026, applicable aux audits à partir de décembre 2026. Elle doit préciser les informations contractuelles sur les transferts et la soumission à des législations de pays tiers. L'Agence considère notamment un accès distant comme un transfert. Son point d'étape sur HDS 2.1 explique pourquoi le contrat et la cartographie des accès comptent autant que l'infrastructure.

Vous n'avez pas besoin de tout construire immédiatement pour anticiper. Des microservices, plusieurs bases et une couche de sécurité différente par composant peuvent augmenter le nombre d'accès et de procédures à contrôler. Une architecture simple, documentée et maîtrisée protège souvent mieux qu'un système sophistiqué dont une seule personne comprend les dépendances.

Cadrer avant la première donnée réelle

Dessinez le trajet d'une information sensible. D'où vient-elle ? Quel service la reçoit ? Où est-elle stockée ? Passe-t-elle par un outil d'email, d'analyse, de support ou d'intelligence artificielle ? Qui peut la lire en production ? Le fondateur, le développeur et le conseil juridique pourront alors parler du même produit.

Séparez ensuite les environnements et les usages. Un développeur ne devrait pas avoir besoin d'un dossier réel pour corriger un affichage. Préparez des données fictives qui reproduisent les cas métier importants sans identifier une personne. Si une investigation exige exceptionnellement un accès à la production, définissez qui l'autorise, pourquoi, pendant combien de temps et quelle trace reste après l'intervention.

Regardez aussi les services périphériques. La base principale peut être hébergée dans une offre adaptée tandis qu'une pièce jointe, une sauvegarde ou un journal applicatif quitte le périmètre prévu. Les erreurs arrivent aux frontières : export envoyé au support, capture d'écran dans un ticket, notification trop détaillée, copie locale laissée sur un ordinateur. Le choix d'un hébergeur ne remplace pas cette revue des flux.

Le contrat et l'architecture doivent décrire les mêmes responsabilités. Le contrat précise les activités confiées, les lieux de stockage, les sous-traitants, les accès et la fin du service. Vérifiez le certificat du fournisseur et son périmètre au moment de signer. Une certification peut évoluer, tout comme l'offre utilisée.

Nommez un responsable de la décision. Le développeur peut expliquer les flux et les accès. Le DPO ou le conseil juridique qualifie les obligations. Le fondateur arbitre le calendrier, le budget et le niveau de risque acceptable. Sans propriétaire, chacun suppose qu'un autre a vérifié. Si ces responsabilités restent floues, un CTO à temps partiel peut cadrer le produit avec les spécialistes concernés sans transformer la mission en audit permanent.

Décider selon le stade de la HealthTech

Le bon niveau d'investissement dépend du prochain engagement réel, pas de la vision à cinq ans. Avec des données fictives, rendez les flux futurs visibles et gardez la possibilité de changer de fournisseur sans déplacer un historique patient.

Avant un pilote avec de vraies données, qualifiez le périmètre, contractualisez les responsabilités et vérifiez les activités certifiées. En production, revoyez les droits, testez la restauration et suivez les changements de fournisseurs. Une intégration, y compris un service d'IA, peut ajouter un sous-traitant ou modifier le trajet des données. La décision HDS ne se termine pas à la mise en ligne.

Posez une question : pouvez-vous expliquer le trajet d'une donnée sensible et nommer l'organisation responsable à chaque étape ? Si la réponse contient plusieurs « normalement », ne commandez pas une architecture plus complexe. Clarifiez d'abord le périmètre.

On retrouve les mêmes arbitrages dans les cinq décisions invisibles d'une architecture SaaS B2B : séparation des données, permissions, traçabilité, droits liés au produit et capacité de reprise. Dans une HealthTech, ces choix arrivent plus tôt parce que la nature des données réduit votre marge d'improvisation.

Cadre réglementaire vérifié le 21 août 2026. Cet article aide à cadrer une décision technique ; il ne remplace pas un conseil juridique adapté à votre situation.

Ce qu'il faut retenir

HDS ne commence pas avec une liste d'hébergeurs. Le travail débute quand vous qualifiez les données, les flux et le rôle de chaque acteur. Cette décision doit précéder le premier pilote utilisant des informations réelles, car une migration tardive touche l'architecture, les contrats et les opérations.

Anticiper ne veut pas dire sur-architecturer. Utilisez des données fictives pour explorer, gardez une architecture réversible et ajoutez les contrôles quand le produit entre dans leur périmètre. La sécurité dépend autant de la maîtrise du système par l'équipe que du certificat affiché par son fournisseur.

Questions fréquentes

Une startup HealthTech doit-elle être certifiée HDS ?

Cela dépend des activités qu'elle réalise et de la manière dont elle fournit son logiciel. L'ANS précise qu'un fournisseur qui héberge des composants ou fournit le système en SaaS sous sa responsabilité doit justifier la certification correspondant à son périmètre. Un cloud certifié ne dispense donc pas automatiquement l'éditeur de vérifier sa propre situation.

Un hébergeur certifié HDS suffit-il ?

Non. Son certificat doit couvrir l'offre et les activités que vous utilisez. Vous devez encore maîtriser les accès, les sous-traitants, les environnements, les sauvegardes et les contrats de votre produit.

Peut-on développer un prototype sans hébergement HDS ?

Un prototype fondé sur des données entièrement fictives, non dérivées de personnes identifiables, n'héberge pas de données de santé personnelles réelles. Utilisez cette phase pour cartographier le futur périmètre. Faites qualifier la situation avant tout import provenant d'un patient, d'un bénéficiaire ou d'un partenaire de santé.

Conclusion

Réservez un échange de 30 minutes pour cadrer le périmètre technique de votre HealthTech avant son premier pilote avec des données réelles.