Supabase, ce n'est pas qu'une base de données
La plupart des développeurs découvrent Supabase pour son PostgreSQL managé, puis réalisent qu'ils tiennent là 80 % d'un backend complet. Realtime, Storage, Edge Functions et une API générée automatiquement : quatre briques qui remplacent des semaines de code serveur.
Dans cet article, vous allez découvrir :
- •Comment l'API PostgREST vous donne un backend REST complet sans écrire une seule route
- •Pourquoi Realtime remplace votre serveur WebSocket pour le chat et les notifications
- •Comment structurer vos buckets Storage avec des règles d'accès qui tiennent la route
- •Quand basculer une logique métier dans une Edge Function Deno (et quand ne surtout pas le faire)
Sur Wiloq, notre SaaS événementiel en production, ces quatre briques couvrent la quasi-totalité du backend. Aucun serveur à administrer.
L'API auto-générée : un backend REST sans écrire de routes
Dès que vous créez une table dans Supabase, PostgREST expose automatiquement une API REST complète par-dessus. Lecture, insertion, mise à jour, suppression : tout est là, filtres et pagination compris.
Concrètement, une table articles devient interrogeable immédiatement depuis votre front :
const { data } = await supabase
.from('articles')
.select('id, titre, auteur')
.eq('statut', 'publie')
.order('cree_le', { ascending: false })Le vrai gain, c'est la sécurité. Les policies Row Level Security de PostgreSQL s'appliquent directement à l'API. Un utilisateur ne voit que ses propres lignes, sans que vous écriviez la moindre condition côté serveur.
Cette API générée est le socle de tout le reste. Si vous voulez comprendre comment elle s'articule avec l'authentification et la base, notre guide complet sur Supabase détaille l'architecture globale de la plateforme.
Realtime : le temps réel sans gérer de serveur WebSocket
Realtime écoute les changements de votre base et les pousse en direct vers les clients connectés, via WebSockets. Vous n'avez ni serveur de sockets à maintenir, ni file de messages à orchestrer.
Trois modes coexistent :
- •Postgres Changes : réagir aux INSERT, UPDATE et DELETE d'une table
- •Broadcast : envoyer des messages éphémères entre clients (curseurs, frappe en cours)
- •Presence : savoir qui est en ligne dans un salon à l'instant T
Le cas d'usage le plus parlant reste le chat. Un nouveau message inséré en base arrive chez tous les participants sans rafraîchissement :
supabase
.channel('messages')
.on('postgres_changes',
{ event: 'INSERT', schema: 'public', table: 'messages' },
(payload) => afficherMessage(payload.new)
)
.subscribe()Même logique pour un fil de notifications, un tableau de bord temps réel ou un statut de commande qui évolue. C'est exactement le genre de fonctionnalité que nous avons câblée sur nos SaaS avec ce couple front/back moderne, comme expliqué dans notre article sur le combo Supabase et Next.js.
Storage : gérer fichiers et images avec de vraies règles d'accès
Storage est un service de stockage objet (compatible S3) intégré à Supabase. Vous y rangez avatars, documents, exports PDF ou images produits, organisés en buckets.
Un bucket peut être public (URL accessible directement) ou privé (accès contrôlé par policy). Uploader un fichier tient en quelques lignes :
const { data } = await supabase.storage
.from('avatars')
.upload(`public/${userId}.png`, fichier)La force de Storage, c'est que les règles d'accès reposent sur le même moteur RLS que vos tables. Vous écrivez une policy qui dit, par exemple, un utilisateur ne peut téléverser que dans son propre dossier, et Supabase l'applique à chaque requête.
Pour les buckets privés, vous générez des URL signées à durée limitée : le fichier reste protégé, mais reste partageable temporairement. Idéal pour des documents clients sensibles.
Edge Functions : du serverless Deno au plus près de l'utilisateur
Tout ne doit pas vivre dans le front. Dès qu'une opération manipule une clé secrète ou une logique sensible, elle doit tourner côté serveur. C'est le rôle des Edge Functions : des fonctions serverless écrites en TypeScript, exécutées sur le runtime Deno, déployées sur un réseau edge mondial.
Deno.serve(async (req) => {
const { montant } = await req.json()
// logique côté serveur, la clé secrète n'est jamais exposée au navigateur
return new Response(JSON.stringify({ ok: true }))
})Les cas d'usage typiques :
- •Recevoir un webhook de paiement Stripe et mettre à jour la base
- •Envoyer un email transactionnel via un service tiers
- •Exécuter une logique métier qui ne doit jamais fuiter côté client
- •Appeler une API externe avec une clé privée
La règle d'or : gardez les Edge Functions pour ce qui exige le serveur. Une simple lecture filtrée de données passe par l'API PostgREST, pas par une fonction. Trop de fonctions inutiles alourdissent la maintenance sans rien apporter.
Comment ces quatre briques s'assemblent dans une vraie app
Prises séparément, ces fonctionnalités sont utiles. Assemblées, elles forment un backend complet. Voici la répartition que nous appliquons sur nos projets.
| Brique | À quoi ça sert | Cas d'usage typique |
|---|---|---|
| API PostgREST | CRUD sécurisé sur vos tables | listes, fiches, formulaires |
| Realtime | pousser les changements en direct | chat, notifications, présence |
| Storage | stocker et servir des fichiers | avatars, documents, images |
| Edge Functions | exécuter de la logique serveur | webhooks, paiement, clé privée |
Nous avons capitalisé la même approche sur d'autres produits, de Swap&Share (SaaS d'échange de compétences) jusqu'à des applications métier à fort volume comme celle livrée pour Dassault (plus de 90 utilisateurs actifs). Le point commun : moins d'infrastructure à gérer, plus de temps sur la valeur produit.
Si vous voulez partir des fondations, notre guide pour créer une application avec Supabase reprend tout le parcours, du schéma de base au premier écran fonctionnel.
FAQ : Supabase Realtime, Storage et Edge Functions
Faut-il un serveur pour utiliser Supabase Realtime ?
Quelle différence entre l'API PostgREST et une Edge Function ?
Le Storage de Supabase est-il sécurisé pour des documents sensibles ?
Supabase convient-il à une application en production ou seulement aux prototypes ?
Conclusion : quatre briques, un backend complet
API auto-générée, Realtime, Storage et Edge Functions : Supabase vous donne les pièces pour construire un backend robuste sans réinventer l'infrastructure. Le vrai travail n'est plus de tout coder, mais de bien assembler ces briques et de sécuriser chaque accès.
C'est précisément là où une équipe expérimentée fait la différence. Vous avez un projet Supabase en tête, un MVP à lancer ou une application à faire monter en charge ? Parlons de votre projet : on cadre l'architecture et on avance vite, sans dette technique cachée.
