Une agence de développement peut-elle être certifiée HDS ?

Non. La certification HDS (Hébergement de Données de Santé), encadrée par l'article L.1111-8 du Code de la santé publique, s'applique à l'infrastructure d'hébergement elle-même, pas à l'agence qui développe l'application. Une agence peut construire une app sur un hébergeur certifié HDS (OVHcloud, AWS, Azure, Google Cloud en disposent), mais elle ne peut pas être "certifiée HDS" en tant que prestataire de développement. Toute agence qui l'affirme décrit quelque chose qui n'existe pas.

Supabase est-il hébergé HDS ?

Non, Supabase lui-même n'est pas certifié HDS. Pour une app de données de santé destinée à des patients traités en France, il faut soit héberger sur une infrastructure HDS-certifiée directement (OVHcloud, AWS, Azure, Google Cloud), soit vérifier avec Supabase les options disponibles pour ce cas d'usage spécifique. Supabase propose en revanche une conformité HIPAA avec BAA sur son plan Team et au-dessus, ce qui répond au cadre américain, pas au cadre français.

Quelle différence entre RGPD et HDS pour une app santé ?

Le RGPD s'applique à toute donnée personnelle de résidents européens, avec les données de santé classées comme "catégorie particulière" sous l'article 9, nécessitant des conditions renforcées. Le HDS est une exigence française spécifique qui s'applique en plus du RGPD dès que des données de santé de patients pris en charge en France sont hébergées ou traitées, elle certifie l'hébergeur, pas l'éditeur de l'app. Une app RGPD-compliant hébergée hors de France n'a pas besoin du HDS si aucun patient français n'est concerné.

Faut-il du HIPAA si mon app ne vise que le marché français ou européen ?

Non. HIPAA est une loi fédérale américaine qui s'applique aux "covered entities" (professionnels de santé, assureurs, chambres de compensation) américaines et à leurs sous-traitants. Si votre app n'a aucun patient ni client de santé américain, HIPAA ne s'applique pas. Le RGPD (et le HDS si des patients français sont concernés) suffit. HIPAA devient pertinent uniquement si vous servez des patients ou des structures de santé aux États-Unis.

Qui doit signer un contrat d'hébergeur de données de santé ?

Tout hébergeur qui stocke ou traite des données de santé à caractère personnel concernant des patients pris en charge en France doit détenir la certification HDS et signer un contrat d'hébergement conforme avec le responsable de traitement (l'établissement de santé, la clinique, l'assureur). L'agence de développement n'est généralement pas elle-même l'hébergeur, elle choisit et intègre un hébergeur certifié pour le compte du client.

HDS, RGPD, HIPAA : quelle conformité pour une app santé ?

Le HDS certifie l'hébergeur, pas l'agence

Le Code de la santé publique (article L.1111-8) impose que toute personne hébergeant des données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic ou de soins concernant des patients pris en charge en France détienne la certification HDS. Cette certification, basée sur ISO 27001 et délivrée par des organismes accrédités sous la supervision de l'Agence du Numérique en Santé (ANS), s'applique à l'infrastructure d'hébergement elle-même.

Concrètement : OVHcloud, AWS, Microsoft Azure et Google Cloud disposent tous de régions ou d'offres certifiées HDS. Une agence de développement construit son application sur cette infrastructure, elle ne devient pas elle-même "certifiée HDS" en le faisant. C'est exactement la même logique qu'un promoteur immobilier qui construit sur un terrain classé, le terrain a un statut, pas nécessairement le promoteur.

Beaucoup de prestataires no-code et de dev affichent "conforme HDS" ou "certifié HDS" sur leur site. Dans l'immense majorité des cas, ce qu'ils veulent dire c'est "nous savons construire sur un hébergeur certifié HDS", ce qui est très différent de détenir soi-même la certification. La distinction n'est pas cosmétique, elle détermine qui porte réellement la responsabilité légale en cas d'audit ou d'incident.

Qui a vraiment besoin du HDS

Le HDS s'applique dès qu'un patient pris en charge en France est concerné, peu importe où est basée l'entreprise qui développe l'application. Une startup française qui construit une app de suivi médical pour des cliniques françaises a besoin d'un hébergement HDS. Une app de bien-être grand public, sans lien avec un professionnel de santé ni un établissement, où l'utilisateur saisit lui-même ses données, tombe généralement hors du champ HDS, même si les données semblent sensibles, elle reste soumise au RGPD classique avec les protections renforcées de l'article 9 pour les données de santé.

Si votre app sert uniquement des patients hors de France, même en Europe, le HDS ne s'applique pas, seul le RGPD s'applique (avec ses propres exigences renforcées pour les données de santé). Le HDS est une couche additionnelle spécifiquement française, pas une exigence RGPD générale.

Ce que le RGPD exige spécifiquement pour les données de santé

Le RGPD classe les données de santé comme "catégorie particulière" sous l'article 9, ce qui interdit leur traitement sauf exception explicite : consentement explicite de la personne, nécessité pour des motifs d'intérêt public dans le domaine de la santé, ou nécessité pour les soins de santé. Cela va au-delà de la base légale générique ("intérêt légitime") qui suffit pour des données personnelles ordinaires.

En pratique, pour une app de santé conforme RGPD : base légale documentée et explicite pour chaque traitement de donnée de santé, hébergement en UE, DPA signé avec chaque sous-traitant, chiffrement au repos et en transit, et un registre des traitements à jour. Les sanctions RGPD ne sont pas symboliques : les autorités européennes ont infligé 7,1 milliards d'euros d'amendes cumulées depuis 2018, avec 1,2 milliard rien qu'en 2025 sur plus de 330 actions, de plus en plus souvent contre des éditeurs SaaS ordinaires et non plus seulement les géants du numérique. Sources : Kiteworks GDPR Enforcement 2026, CMS GDPR Enforcement Tracker.

HIPAA : le cadre américain, si vous avez des patients aux États-Unis

HIPAA ne s'applique que si votre app touche des "covered entities" américaines (professionnels de santé, assureurs, chambres de compensation) ou leurs sous-traitants directs. Comme pour le HDS, il n'existe aucune "certification HIPAA" officielle pour les agences ou les éditeurs de logiciel, seulement des obligations contractuelles (le Business Associate Agreement, ou BAA) et des exigences techniques précises : contrôle d'accès avec identifiant unique par utilisateur, déconnexion automatique, journal d'audit de chaque accès, chiffrement des données en transit.

L'application concrète de ces règles reste sérieuse : sur les cinq premiers mois de 2025 seulement, l'Office for Civil Rights américain (HHS OCR) a conclu 10 accords de résolution avec des pénalités allant de 25 000 à 3 000 000 dollars. La cause la plus fréquemment citée n'est jamais un défaut de certification, c'est une analyse de risque absente ou insuffisante. Sources : HHS.gov, HIPAA Journal.

Les trois cadres, comparés

HDS (France)

Certifie l'infrastructure d'hébergement, article L.1111-8. Requis dès qu'un patient pris en charge en France est concerné. OVHcloud, AWS, Azure et Google Cloud disposent d'offres certifiées.

RGPD (Union Européenne)

S'applique à toute donnée personnelle de résidents UE, données de santé en "catégorie particulière" (article 9). DPA requis, hébergement UE recommandé, base légale explicite obligatoire.

HIPAA (États-Unis)

S'applique aux covered entities américaines et leurs sous-traitants. Aucune certification d'agence, uniquement un BAA signé et des garde-fous techniques audités a posteriori par le HHS OCR.

L'erreur récurrente est identique dans les trois cas : croire que la certification s'applique à celui qui écrit le code. Ce n'est jamais le cas. Le vrai travail de l'agence, c'est de choisir une infrastructure qui détient le bon statut, puis de construire l'application correctement par-dessus, contrôle d'accès, journal d'audit, chiffrement, isolation des données par tenant.

Comment on architecture les apps de données de santé

App Studio n'affirme jamais être "certifié HDS" ni "certifié HIPAA", parce qu'aucune des deux affirmations ne serait exacte. Ce qu'on fait sur chaque projet touchant des données de santé : sélectionner un hébergeur certifié HDS ou éligible HIPAA selon la localisation des patients concernés, faire signer les contrats requis (contrat d'hébergement HDS ou BAA) avant que la moindre donnée réelle n'entre dans l'environnement, et construire le Row-Level Security, le journal d'audit et le contrôle d'accès par rôle comme des fondations du projet, pas comme des options.

Notre expérience concrète sur des données personnelles sensibles, hors contexte clinique HIPAA ou HDS strict, est réelle et directement pertinente : nous avons construit le CRM de gestion des remboursements et litiges de Nostrum Care, filiale technique d'un groupe mutualiste français, qui traite des données personnelles et financières sensibles sous RGPD avec WeWeb, Supabase et n8n. Ce sont des données d'assurance santé en back-office, pas des dossiers cliniques de patients, et on le formule ainsi délibérément : ça démontre une vraie expérience de traitement de données sous RGPD, sans la présenter comme un déploiement HDS ou HIPAA clinique qu'elle n'est pas.

Checklist avant de lancer une app de données de santé

Hébergement : certification HDS confirmée si un patient français est concerné ; hébergement UE confirmé pour tout utilisateur européen ; hébergement HIPAA-éligible avec BAA signé si un patient ou client de santé américain est concerné.

Contrats : contrat d'hébergement HDS conforme signé avec le responsable de traitement ; DPA signé avec chaque sous-traitant ; BAA signé si HIPAA s'applique.

Contrôle d'accès : identifiant unique par utilisateur, jamais de compte partagé ; Row-Level Security appliqué au niveau base de données, pas seulement caché dans l'interface ; déconnexion automatique après inactivité.

Journal d'audit : table de log enregistrant qui a consulté ou modifié quelle donnée et quand ; ce journal lui-même protégé contre toute altération.

Chiffrement : AES-256 au repos sur toute base et toute sauvegarde ; TLS 1.2 minimum sur chaque connexion, interne comme externe ; aucune donnée de santé en clair dans les logs applicatifs.

Analyse de risque : une analyse documentée couvrant où vivent les données sensibles, qui peut y accéder, et ce qui pourrait mal se passer, la faille la plus fréquemment citée dans les vraies actions d'enforcement américaines, et la moins coûteuse à corriger avant le lancement.

HDS, RGPD, HIPAA : quelle conformité pour une app de données de santé ?