Healthtech sur Supabase : dossier patient et RLS, les pièges qui tiennent
> En bref : Un dossier patient exige une isolation plus stricte qu'un SaaS classique. Les erreurs RLS fréquentes dans les jeunes produits healthtech.
Comment protéger les dossiers patients dans une app Supabase ?
Le dossier patient n'est pas un ticket de support
Dans un produit healthtech, la règle d'accès n'est pas "mon organisation" mais "mon patient, mon praticien, ce soin-là, sur cette période". C'est beaucoup plus fin qu'un SaaS B2B classique.
Ce qui casse souvent
Le bon niveau de rigueur
Un produit de santé doit être capable de répondre : qui a vu quelle donnée, quand, pour quelle raison. Si la réponse dépend d'un log applicatif optionnel, ce n'est pas suffisant pour un hébergeur HDS.
À retenir
Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Supabase et logiciel RH : les erreurs de configuration qui exposent vos fiches de paie
Les erreurs Supabase qui comptent vraiment dans un logiciel RH ou paie : policies RLS incomplètes, buckets trop ouverts et logique d'organisation mal bornée.
Erreurs RLS : le guide 2026 pour Supabase, PostgreSQL et les accès multi-tenant
Les erreurs RLS les plus coûteuses sur Supabase et PostgreSQL : policies incomplètes, rôles trop puissants, JWT mal utilisés, service_role exposé et faux sentiment de sécurité.
Supabase RLS : les 5 erreurs qu'on retrouve dans chaque audit de SaaS RH
Les Row Level Security policies de Supabase sont puissantes mais trompeuses. Voici les erreurs les plus fréquentes qu'on rencontre lors de nos audits d'applications RH.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.