Module 3 — Stack moderne

Configurer Supabase

Capsule 11 min Type pratique Modalité e-learning Niveau maîtrise

Objectif opérationnel

À l'issue de cette leçon, le stagiaire dispose d'un projet Supabase opérationnel avec un schéma de base, le Row Level Security activé, et l'application cliente connectée selon les bonnes pratiques.

§ 01

Pourquoi Supabase

Supabase est une plateforme open source qui fournit, sur une base PostgreSQL hébergée, l'ensemble des briques courantes du backend moderne : base de données relationnelle, authentification (e-mail, OAuth, magic link), stockage de fichiers, fonctions serverless, abonnements temps réel sur les changements de données.

L'intérêt pour un projet de formation ou un MVP : on évite d'écrire et de maintenir tout cela soi-même. La couche SQL reste accessible — vous gardez la main sur le schéma et les requêtes — mais les briques transverses sont fournies. C'est, en 2026, le choix par défaut pour les projets nouveaux qui privilégient SQL et l'open source.

Alternative principale

Firebase (Google) reste plus mature sur certains aspects, mais propriétaire, avec un modèle NoSQL qui surprend les développeurs venus du relationnel. Pour des besoins équivalents et un cadre RGPD européen, Supabase l'emporte généralement.

§ 02

Création d'un projet — trois minutes chrono

Sur supabase.com, cliquer Start your project. Créer un compte gratuit (ou se connecter).
Cliquer New project. Renseigner trois champs : un nom de projet, un mot de passe pour la base (à conserver dans un gestionnaire de mots de passe — il vous servira pour les connexions admin), et une région.
Choix de région critique pour le RGPD. Pour des utilisateurs européens, choisir Frankfurt (eu-central-1) ou Paris (eu-west-3). Une base hébergée aux États-Unis pour des utilisateurs européens, ce n'est pas seulement plus lent — c'est aussi un sujet de conformité.
Lancer la création. Comptez 2 à 3 minutes. Une fois prêt, l'interface du projet (Supabase Studio) s'affiche avec sa barre latérale : Table Editor, SQL Editor, Authentication, Storage, Edge Functions, API Docs.

§ 03

Schéma de base — le réflexe Row Level Security

Pour une première application, partez sur un schéma minimal — trois ou quatre tables suffisent à démarrer. Pour la démo, on crée une table simple : posts avec quatre colonnes.

Règle non négociable

Une table sans RLS est ouverte à tous les utilisateurs authentifiés. Ce n'est presque jamais ce que vous voulez. Activez le RLS systématiquement, et écrivez des politiques explicites au lieu de désactiver le RLS « pour aller plus vite ».

# Dans Supabase Studio : Table Editor → New table

Nom     : posts
RLS     : activé  # ← critique, cocher dès la création

Colonnes :
  id            uuid       primary key  default gen_random_uuid()
  created_at    timestamptz             default now()
  title         text       not null
  content       text

Quand vous activez le Row Level Security (RLS) sur une table, par défaut personne ne peut rien y lire ni y écrire. Pas même vous depuis l'application. Il faut ajouter des politiques explicites pour autoriser les lectures et écritures.

§ 04

Politiques RLS — démarrer avec une lecture publique

Une fois la table créée avec RLS activé, ajoutez votre première politique. Pour démarrer, une politique de lecture publique suffit :

# Dans Table Editor → cliquer cadenas → Policies → New policy

Nom          : Public read access
Opération    : SELECT
Target role  : public
Expression   : true

# Pour les écritures, quand l'authentification sera en place :
Expression   : auth.uid() = user_id
# → l'utilisateur ne peut écrire qu'avec son propre user_id

§ 05

Connexion depuis l'application — les deux clés

Côté Supabase, on récupère les identifiants de connexion. Project Settings → API. Deux valeurs nous intéressent : Project URL et la clé anon (pour anonyme).

Clé anon — publique par design

Peut être exposée côté navigateur. C'est son rôle. La sécurité repose sur le RLS qu'on a activé, pas sur le secret de cette clé.

Clé service_role — JAMAIS exposée

Contourne le RLS. Ne doit jamais sortir d'un contexte serveur de confiance (fonctions edge, scripts d'admin).

Côté projet local, on installe la bibliothèque cliente et on initialise le client à partir des variables d'environnement définies dans le .env (vu en leçon 07).

§ 06

Première requête de bout en bout — test critique

Insérer une donnée depuis Supabase. Dans le SQL Editor : INSERT INTO posts (title, content) VALUES ('Premier post', 'Bonjour');. Vérifier dans le Table Editor que la ligne apparaît bien.
Lire la donnée depuis l'application. Dans une page React ou un script de test : const { data } = await supabase.from('posts').select('*'); console.log(data);. Lancer l'application et observer la console du navigateur.
Si le post apparaît dans la console, vous avez une chaîne complète qui fonctionne : base de données, RLS, bibliothèque cliente, application. C'est le socle pour tout ce qui suit.

Exercice — appropriation

Esquisser le schéma de votre projet

Esquissez le schéma de base de votre projet de référence (3 à 5 tables suffisent pour démarrer). Créez-le dans Supabase. Activez le RLS sur toutes. Faites une première requête de lecture depuis votre application. Documentez le schéma dans le CLAUDE.md du projet pour que Claude le connaisse aux sessions suivantes.

Cet exercice est à conserver dans votre dossier de stagiaire. Il n'est pas évalué mais il est tracé.

Sources officielles consultées

supabase.com site officiel, création de projet
supabase.com/docs — Row Level Security documentation officielle des politiques RLS
supabase.com/docs — JS Client documentation de la bibliothèque cliente JavaScript

Vous avez créé un projet Supabase opérationnel avec RLS activé et application cliente connectée ?