Skip to content
Go To Agency
Go To Agency

Agence Supabase : du Postgres bien tenu, pas juste un SDK

Nous construisons et reprenons des applications Supabase pour de petites équipes techniques : schéma Postgres, politiques RLS, auth, storage, edge functions. Tout se traite par écrit, depuis Dijon, à distance. Quand Supabase n'est pas le bon socle, nous le disons avant le devis.

Décrire mon projet Supabase par écrit →
Migrations SQL versionnées livrées4.9/5 sur 35 avisRéponse sous 24 heures ouvrées

Supabase démarre vite, puis la base devient un angle mort

Supabase donne une base Postgres, une authentification et une API en quelques minutes. Les ennuis arrivent plus tard. Le schéma a été écrit dans l'éditeur du tableau de bord, personne ne sait le rejouer ailleurs. Les politiques RLS ont été activées au fil des besoins, sans un seul test. La clé service_role traîne dans une fonction mal isolée. Rien de cela ne se voit tant que l'application tourne, et tout se voit le jour où un compte lit les lignes d'un autre.

Les migrations versionnées
Ce qui manque presque toujours
Une politique RLS jamais testée
L'erreur la plus fréquente
La clé service_role
Ce qui fuit en premier

Un socle Supabase qui tient quand l'équipe grandit

Un schéma Postgres écrit comme du code

Le schéma ne vit pas dans l'éditeur du tableau de bord mais dans des fichiers de migration versionnés, rejouables sur un projet vierge. Clés étrangères, contraintes, index, valeurs par défaut : tout est déclaré explicitement. Une contrainte en base vaut mieux qu'une validation côté client, parce que la base est le seul endroit que personne ne contourne. Vous récupérez un dépôt qui reconstruit l'environnement en une commande.

Des politiques RLS lisibles et testées

Row Level Security n'est pas une case à cocher. Chaque table reçoit des politiques séparées par opération, écrites autour d'une fonction stable qui exprime l'identité et le rôle du demandeur. Nous évitons les sous-requêtes lourdes, qui s'exécutent sur chaque ligne évaluée et finissent en lenteur inexplicable. Surtout, nous écrivons des tests qui tentent de lire les données d'un autre compte et qui échouent si une politique s'élargit.

Authentification et storage sans zone grise

L'authentification Supabase couvre le mot de passe, le lien magique, les fournisseurs OAuth et le second facteur. Le travail réel est ailleurs : décider ce qui vit dans les métadonnées utilisateur, modifiables par le client, et ce qui reste dans une table protégée, puis régler chaque bucket de storage avec ses propres politiques. Un fichier privé mal exposé se traite comme une ligne de base mal exposée.

Edge functions, et ce que nous n'y mettons pas

Les edge functions conviennent à un webhook à vérifier, une signature, une requête vers une API tierce dont la clé ne doit pas quitter le serveur. Elles sont le mauvais endroit pour un traitement long, un import de plusieurs dizaines de milliers de lignes ou un job qui doit reprendre après un échec. Dans ces cas, le traitement sort vers un worker dédié.

Les points que nous vérifions en premier

Toute la table
Ce qu'une politique RLS trop permissive expose
La clé service_role
Ce qui contourne toutes les règles RLS
Les migrations SQL
Ce que nous livrons avec le code
Par écrit
Format de travail, réponse sous 24 heures ouvrées

Trois façons de travailler ensemble

Démarrage Supabase

Sur devis
  • Modèle de données et migrations versionnées
  • Authentification et rôles applicatifs
  • Politiques RLS par table et par opération
  • Dépôt Git documenté
Décrire mon projet Supabase par écrit →

Reprise et durcissement

Sur devis
  • Revue du schéma et des politiques
  • Tests d'accès entre comptes
  • Séparation des clés et des secrets
  • Passage à des migrations versionnées
Décrire mon projet Supabase par écrit →

Application complète sur Supabase

Sur devis
  • Front Next.js connecté à Supabase
  • Edge functions et intégrations tierces
  • Environnements séparés et déploiement
  • Restauration de sauvegarde testée
Décrire mon projet Supabase par écrit →

Supabase depuis Dijon, en travail à distance : ce qui va vite et ce qui pique

Supabase est d'abord une base Postgres, avec des services autour. Cette phrase évite la plupart des mauvaises surprises : ce qui relève de Postgres se traite comme du Postgres, le reste a ses propres règles. Voici ce qui fait gagner du temps, ce qui coûte cher, et quand nous disons non.

Postgres au centre, une couche de services autour

Sous le tableau de bord, il y a une base Postgres classique. L'API que vous consommez depuis le navigateur n'est pas un serveur métier écrit à la main : elle est générée à partir de votre schéma, ce qui explique pourquoi une table renommée change immédiatement le contrat vu par le client. L'authentification vit dans un schéma dédié, avec sa propre table utilisateurs à laquelle vos tables se rattachent par clé étrangère. Le temps réel écoute le journal de réplication. Le stockage de fichiers décrit les droits de ses objets dans des tables, comme le reste. Conséquence pratique : la qualité de votre schéma détermine la qualité de votre API. Un modèle mal normalisé produit des requêtes clientes tordues, des jointures imbriquées et des règles d'accès impossibles à écrire proprement. Nous passons donc plus de temps sur le modèle de données que sur le code client, parce que tout le reste en découle.

Row Level Security : ce qui va vite, ce qui pique

Ce qui va vite : exprimer qu'un utilisateur ne voit que ses propres lignes tient en une politique de quelques lignes, et le navigateur interroge alors la base directement, sans écrire le moindre endpoint. Pour une application où chaque enregistrement appartient à une personne, le gain est réel. Ce qui pique arrive avec les organisations, les invitations et les rôles. Dès qu'un utilisateur appartient à plusieurs espaces avec des droits différents, la politique doit consulter une table d'appartenance, et cette lecture s'exécute pour chaque ligne évaluée. Nous stabilisons cela avec des fonctions déclarées stables, des index sur les colonnes de jointure et, quand c'est justifié, en portant l'appartenance dans le jeton d'authentification. Le piège suivant est plus sournois. Activer RLS sans écrire de politique bloque tout, et cela se voit en cinq minutes. Écrire une politique trop large n'affiche aucune erreur, et cela peut vivre des mois. D'où les tests d'accès croisés, systématiquement.

Auth, storage, edge functions : les arbitrages qui reviennent

Sur l'authentification, la question récurrente est celle des informations de profil. Les métadonnées utilisateur sont modifiables par le client, donc rien qui décide d'un droit ne doit y vivre. Le rôle applicatif appartient à une table protégée par ses propres politiques, jamais à un champ que le navigateur peut écrire. C'est une des reprises les plus fréquentes que nous faisons sur des projets existants. Sur le stockage, marquer un bucket comme privé ne suffit pas : ce sont les politiques attachées aux objets qui décident réellement de l'accès. Les liens signés ont une durée de vie, et cette durée doit correspondre à l'usage réel. Pour les fichiers volumineux, l'envoi passe par une URL signée générée côté serveur. Sur les edge functions, le bon usage est court et déclenché : un webhook de paiement à vérifier, une intégration tierce, une transformation ponctuelle. Un traitement long, reprenable ou planifié n'y a pas sa place.

Quand Supabase n'est pas le bon choix

Premier cas, le plus fréquent : personne dans l'équipe ne veut tenir les politiques RLS. Ce n'est pas un jugement, c'est un constat de charge. Ces politiques sont du SQL, elles évoluent à chaque fonctionnalité, et une équipe qui n'a ni l'envie ni le temps de les relire finira par les élargir jusqu'à ce qu'elles ne protègent plus rien. Dans ce cas, un backend classique, avec la logique d'accès dans du code que l'équipe sait tester, vaut mieux qu'un socle élégant que personne ne maintient. Deuxième cas : une charge analytique lourde, des agrégations permanentes sur de gros volumes. Postgres encaisse beaucoup, mais une base transactionnelle n'est pas un entrepôt, et RLS n'aide pas là. Troisième cas : une exigence contractuelle d'hébergement sur votre infrastructure. L'auto-hébergement existe, mais il vous rend responsable de ce que le service gérait. Nous sommes basés à Dijon et travaillons à distance, par écrit, réponse sous vingt-quatre heures ouvrées. Le rendu se juge sur nos réalisations, LB Athletic notamment.

Nous regardons qui va tenir le code dans six mois. Supabase fait gagner du temps sur l'authentification, le stockage de fichiers et l'API de lecture, à condition d'accepter que la logique d'accès descende dans la base sous forme de politiques SQL. Un backend classique garde cette logique dans du code applicatif, plus familier pour une équipe venue de Node ou de Django. Si votre équipe est à l'aise en SQL, Supabase raccourcit vraiment le chemin. Sinon, le gain initial se paie plus tard.

Elle couvre la couche que personne ne peut contourner depuis le navigateur, mais elle ne fait pas tout. RLS dit seulement quelles lignes un compte peut lire ou écrire. Elle ne valide pas le contenu d'un champ, ne remplace pas les contraintes en base, et ne protège plus rien si la clé service_role sort du serveur, puisqu'elle passe outre les politiques par conception. Nous complétons donc avec des contraintes, une validation côté serveur, une séparation stricte des clés et des tests d'accès entre comptes.

Moins qu'avec un service propriétaire, plus que ne le suggère l'argument du logiciel libre. Votre schéma, vos données et vos politiques RLS sont du Postgres standard, transférables vers un autre hébergeur Postgres. Le reste est spécifique : l'authentification et sa table utilisateurs, l'API générée à partir du schéma, le stockage de fichiers, les fonctions écrites pour leur environnement d'exécution. Une sortie se prépare, elle ne s'improvise pas. C'est pour cela que nous gardons les migrations en fichiers versionnés et la logique métier en SQL standard.

Chaque changement de schéma est un fichier de migration commité, jamais une manipulation directe en production. Un projet de développement reste séparé de la production, et les migrations sont rejouées dans le même ordre sur les deux. Les données de test ne viennent pas de la production telle quelle : nous écrivons un jeu de démarrage, ce qui évite de promener des données personnelles ailleurs qu'en production. Avant toute mise en ligne, nous vérifions la restauration d'une sauvegarde, parce qu'une sauvegarde jamais restaurée n'est qu'une hypothèse.

Souvent oui, en commençant par un périmètre restreint, le stockage de fichiers ou l'authentification par exemple, ajoutés à côté de l'existant. Le cas délicat est la reprise d'une base déjà en service : activer RLS sur une table bloque immédiatement tous les accès qu'aucune politique ne couvre, donc l'ordre des étapes compte autant que leur contenu. Si votre application se connecte à sa base avec un compte administrateur unique, passer à un modèle par utilisateur demande de revoir la façon dont l'identité circule.

Nos autres expertises près de chez vous

Site Internet pour Artisan en BourgogneSite Internet pour Avocat à DijonSite Internet pour Agence Immobilière à DijonSite Internet pour Coach Sportif

Services associés

Site vitrineRefonte de siteApplication web
Voir tous nos services
4.9/5 sur 35 avis clientsDécouvrez les avis de nos clients

Un projet Supabase à cadrer sérieusement ?

Décrivez votre schéma actuel, vos besoins d'accès et ce qui vous inquiète. Réponse écrite sous vingt-quatre heures ouvrées, avec un avis franc, y compris quand Supabase n'est pas le bon socle.

Décrire mon besoin par écrit →
Devis gratuit →
Agence Supabase : Postgres, RLS et auth | Go To Agency | Go To Agency