Healthtech sur Supabase : dossier patient et RLS, les pièges qui tiennent
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.
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 vs Firebase : comparaison sécurité pour SaaS français
Quel backend est le plus sécurisé ? Supabase RLS vs Firebase rules : forces, faiblesses et pièges de chaque approche.
Sources
Analyse éditoriale fondée sur la documentation officielle des éditeurs, projets et autorités concernées.
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.