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 ? CleanIssue réalise des audits de sécurité pour votre produit 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 : les erreurs de configuration qui exposent vos données sensibles
Les erreurs Supabase qui comptent vraiment dans un produit : 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 produit
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.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.