Changer le thème

Supabase pour débutants : PostgreSQL + Auth + Storage, backend tout-en-un

Easton editorial illustration: one application card connected to three backend modules

Face à la douzième erreur de connexion à la base de données, une évidence s’impose : pour un développeur frontend, monter un projet full stack, c’est vraiment difficile.

Avant, chaque besoin backend impliquait d’apprendre Node.js, Express, la configuration de base de données, l’authentification, le stockage de fichiers — chaque étape un gouffre. Puis est venu Supabase.

En bref, c’est une alternative open source à Firebase, mais basée sur PostgreSQL, pas sur du NoSQL pénible. Et il regroupe base de données, authentification et stockage de fichiers — un backend tout-en-un.

Cet article vous guide pas à pas avec Supabase, en mettant l’accent sur les trois piliers : Database, Auth et Storage. À la fin, vous devriez pouvoir monter un backend complet rapidement, sans vous noyer dans les fichiers de configuration.


Qu’est-ce que Supabase

Commençons par définir Supabase.

C’est une plateforme BaaS — Backend as a Service. Concrètement : pas besoin de monter un serveur, configurer une base ou écrire des API ; tout est déjà là.

Contrairement à Firebase, Supabase est entièrement open source. Et il s’appuie sur PostgreSQL — point important. PostgreSQL est une base relationnelle : requêtes SQL complexes, relations de données claires — bien plus pratique qu’une base documentaire comme Firestore.

Supabase propose six fonctionnalités clés :

  • Database : base PostgreSQL, requêtes SQL, REST API auto-générée
  • Auth : authentification (email, social Google/GitHub, JWT Token)
  • Storage : stockage de fichiers, type AWS S3 mais plus simple
  • Realtime : synchronisation temps réel, idéal pour le chat
  • Edge Functions : calcul en périphérie, type AWS Lambda
  • Vector Database : base vectorielle pour les applications IA

Cet article ne couvre que les trois premières : Database, Auth et Storage — le cœur du produit. Le reste viendra plus tard.

Vous vous demandez peut-être : open source, PostgreSQL, auth et stockage — Supabase ou Firebase ? On y reviendra en détail ; en résumé : si vous avez besoin de SQL, de relations complexes ou de maîtriser vos données, choisissez Supabase ; pour une app mobile avec sync temps réel très poussée, Firebase peut mieux convenir.


Démarrage rapide

Créer un projet Supabase

Première étape : créer un compte sur supabase.com, puis cliquer sur « New Project ».

À la création, vous renseignez :

  • Nom du projet : au choix, par ex. my-first-app
  • Mot de passe base de données : à conserver, vous en aurez besoin
  • Région : la plus proche ; pour l’Asie, Singapour ou Tokyo

Création en environ trois minutes. Ensuite, le Dashboard : menu à gauche (Table Editor, Authentication, Storage, Edge Functions…). Pas de panique, on détaille tout ici.

Installation et initialisation

Installez Supabase dans votre projet frontend :

npm install @supabase/supabase-js

Récupérez dans le Dashboard Supabase : Project URL et Anon Public Key, dans Settings > API.

Initialisez le client :

import { createClient } from '@supabase/supabase-js';

const supabaseUrl = 'https://your-project-id.supabase.co';
const supabaseAnonKey = 'your-anon-public-key';

export const supabase = createClient(supabaseUrl, supabaseAnonKey);

Ce code est votre point d’entrée vers Supabase. Toutes les opérations — requêtes, connexion, upload — passent par cet objet supabase.

Test de connexion

Après initialisation, vérifiez la connexion. Méthode simple : interroger la base :

const { data, error } = await supabase.from('users').select('*');

if (error) {
  console.error('Échec de connexion:', error.message);
} else {
  console.log('Connexion réussie !', data);
}

Si l’erreur indique que la table users n’existe pas, c’est normal — vous ne l’avez pas encore créée. La section suivante explique comment.

Erreurs fréquentes :

  • URL ou clé mal copiée : vérifiez la copie intégrale
  • Erreur CORS : parfois une config frontend est nécessaire ; Supabase autorise par défaut
  • Problème réseau : réessayez après quelques minutes

Si tout va bien, vous obtenez des données — éventuellement un tableau vide [] si la table est vide.


Database : opérations sur la base

C’est le cœur de Supabase. Si vous connaissez PostgreSQL, vous serez à l’aise ; si vous venez du frontend, le SQL peut surprendre, mais le Table Editor visuel permet d’opérer sans SQL.

Créer une table

Deux approches : Table Editor (visuel) ou SQL.

Table Editor : dans le Dashboard, « Table Editor », puis « Create a new table ». Nom de table, colonnes, types.

Exemple, table users :

ColonneTypeContrainte
idint8Primary Key, Auto Increment
emailtextUnique, Not Null
nametext-
created_attimestamptzDefault: now()

Cliquez « Save », la table est créée.

Le SQL reste souvent plus rapide, surtout pour des opérations avancées. SQL Editor dans le menu gauche du Dashboard.

SQL pour users et projects :

-- Table utilisateurs
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email TEXT UNIQUE NOT NULL,
  name TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Table projets
CREATE TABLE projects (
  id SERIAL PRIMARY KEY,
  user_id INTEGER REFERENCES users(id),
  title TEXT NOT NULL,
  description TEXT,
  status TEXT DEFAULT 'active',
  created_at TIMESTAMPTZ DEFAULT NOW()
);

Détail : user_id dans projects est une clé étrangère vers users.id. Chaque projet appartient à un utilisateur — l’avantage d’une base relationnelle, relations explicites.

CRUD

Insertion :

// Insérer un utilisateur
const { data, error } = await supabase
  .from('users')
  .insert([
    { email: '[email protected]', name: 'John Doe' }
  ]);

if (error) {
  console.error('Échec insertion:', error.message);
} else {
  console.log('Insertion réussie:', data);
}

Lecture :

// Tous les projets avec infos utilisateur
const { data, error } = await supabase
  .from('projects')
  .select(`
    *,
    users (
      name,
      email
    )
  `)
  .eq('status', 'active')
  .order('created_at', { ascending: false });

console.log(data);

Cette requête lit projects et joint les utilisateurs via la clé étrangère — deux tables en une requête. Avec Firestore, il faudrait plusieurs allers-retours et assembler manuellement.

Mise à jour :

const { data, error } = await supabase
  .from('projects')
  .update({ status: 'completed' })
  .eq('id', 1);

Suppression :

const { data, error } = await supabase
  .from('projects')
  .delete()
  .eq('id', 1);

.eq() filtre sur l’égalité. Supabase propose aussi .gt(), .lt(), .like() — l’essentiel des filtres SQL courants.

Row Level Security (RLS)

Point crucial pour toute fonctionnalité liée aux utilisateurs.

RLS — Row Level Security, sécurité au niveau des lignes : contrôler que chaque utilisateur ne voit que ses données.

Exemple : la table projects contient de nombreux projets ; après connexion, l’utilisateur ne doit voir que les siens.

Activez RLS :

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

Créez une Policy :

-- L'utilisateur ne voit que ses projets
CREATE POLICY "Users can view their own projects"
ON projects FOR SELECT
USING (user_id = auth.uid());

auth.uid() renvoie l’ID de l’utilisateur connecté. Cette Policy ne retourne que les lignes où user_id correspond.

Policies pour insertion, mise à jour et suppression :

-- Insertion de ses propres projets uniquement
CREATE POLICY "Users can insert their own projects"
ON projects FOR INSERT
WITH CHECK (user_id = auth.uid());

-- Mise à jour de ses propres projets uniquement
CREATE POLICY "Users can update their own projects"
ON projects FOR UPDATE
USING (user_id = auth.uid())
WITH CHECK (user_id = auth.uid());

-- Suppression de ses propres projets uniquement
CREATE POLICY "Users can delete their own projects"
ON projects FOR DELETE
USING (user_id = auth.uid());

Même une requête malveillante est bloquée au niveau base — plus sûr qu’une vérification frontend.


Auth : système d’authentification

Supabase Auth est complet : email/mot de passe, Magic Link sans mot de passe, OTP, social (Google, GitHub, Apple et 20+ plateformes), téléphone, SSO entreprise.

Vue d’ensemble

Mécanisme central : JWT Token — JSON Web Token. Après connexion, Supabase émet un token ; le frontend l’envoie aux API ; le backend valide l’identité.

Supabase Auth stocke automatiquement les utilisateurs dans auth.users (PostgreSQL) — table auto-créée. ID, email, dates de création et dernière connexion, etc.

Session Persistence : après connexion, le navigateur mémorise la session ; pas de reconnexion à chaque visite. Le SDK frontend gère cela sans code supplémentaire.

Authentification Email/Password

Inscription :

// Inscription
const { data, error } = await supabase.auth.signUp({
  email: '[email protected]',
  password: 'securepassword123',
});

if (error) {
  console.error('Échec inscription:', error.message);
} else {
  console.log('Inscription réussie:', data);
}

Après inscription, Supabase envoie un email de confirmation. Clic sur le lien = compte activé. Comportement par défaut ; désactivable dans le Dashboard, mais déconseillé — la confirmation limite les inscriptions abusives.

Connexion :

// Connexion
const { data, error } = await supabase.auth.signInWithPassword({
  email: '[email protected]',
  password: 'securepassword123',
});

if (error) {
  console.error('Échec connexion:', error.message);
} else {
  console.log('Connexion réussie:', data);
}

Utilisateur courant :

// Utilisateur connecté
const { data: { user } } = await supabase.auth.getUser();

console.log('Utilisateur courant:', user);
// Ex. : { id: 'abc123', email: '[email protected]', ... }

Déconnexion :

await supabase.auth.signOut();

La session est effacée ; nouvelle connexion requise.

Réinitialisation du mot de passe :

// Email de réinitialisation
const { data, error } = await supabase.auth.resetPasswordForEmail(
  '[email protected]'
);

L’utilisateur reçoit un lien par email — pas de logique custom à écrire.

Social Auth

Connexion via Google ou GitHub sans formulaire — meilleure expérience.

Configuration : Dashboard → Authentication > Providers, activez la plateforme voulue.

Étapes typiques :

  1. Créer une OAuth App sur Google/GitHub
  2. Copier Client ID et Client Secret dans Supabase
  3. Configurer l’URL de callback (Redirect URL)

Code frontend :

// Connexion Google
const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'google',
});

// Connexion GitHub
const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'github',
});

Redirection vers la page d’autorisation, consentement, retour dans l’app — utilisateur connecté.

Options avancées :

const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: {
    redirectTo: 'https://your-app.com/dashboard',
    queryParams: {
      access_type: 'offline',
      prompt: 'consent',
    }
  }
});

redirectTo : page après connexion ; queryParams : paramètres OAuth supplémentaires.

RLS et Auth

On relie RLS et auth.uid().

Après connexion, auth.uid() renvoie l’ID utilisateur. Les Policies n’exposent que les données de cet utilisateur.

Exemple : créer un projet lié automatiquement à l’utilisateur courant.

// Créer un projet lié à l'utilisateur courant
const { data: { user } } = await supabase.auth.getUser();

const { data, error } = await supabase
  .from('projects')
  .insert([
    {
      title: 'New Project',
      user_id: user.id  // ID depuis Auth
    }
  ]);

Les Policies RLS garantissent :

  • Lecture : uniquement user_id = auth.uid()
  • Insertion : user_id doit égaler auth.uid()
  • Mise à jour et suppression : idem

Connexion, association des données et contrôle d’accès — une chaîne cohérente.


Storage : stockage de fichiers

Supabase Storage est un stockage d’objets type AWS S3, plus simple. Avatars, images, documents.

Vue d’ensemble

Deux concepts : Bucket et Object.

  • Bucket : conteneur, comme un dossier. Plusieurs buckets possibles : avatars, documents, etc.
  • Object : fichier concret, ex. avatar.jpg, report.pdf

Deux modes de bucket :

  • Public : accès ouvert (images publiques)
  • Private : accès autorisé uniquement (documents privés)

Créer un Bucket

Dashboard → Storage → « New Bucket ».

Exemple bucket avatars :

  • Nom : avatars
  • Public bucket : coché (avatars souvent publics)
  • File size limit : ex. 2 Mo

Ensuite, upload possible.

Upload et téléchargement

Upload :

// Upload avatar
const file = document.getElementById('avatar-input').files[0];

const { data, error } = await supabase.storage
  .from('avatars')
  .upload('user-id/avatar.jpg', file, {
    cacheControl: '3600',
    upsert: false
  });

if (error) {
  console.error('Échec upload:', error.message);
} else {
  console.log('Upload réussi:', data);
}

Détails :

  • Premier argument de upload() : chemin 'user-id/avatar.jpg'
  • cacheControl : durée de cache, 3600 secondes
  • upsert : écraser si existant. false = erreur si doublon ; true = écrasement

Téléchargement :

// Télécharger un fichier
const { data, error } = await supabase.storage
  .from('avatars')
  .download('user-id/avatar.jpg');

if (error) {
  console.error('Échec téléchargement:', error.message);
} else {
  // data est un Blob, convertible en URL
  const url = URL.createObjectURL(data);
  document.getElementById('avatar-img').src = url;
}

Bucket public — URL directe :

// URL publique
const { data } = supabase.storage
  .from('avatars')
  .getPublicUrl('user-id/avatar.jpg');

console.log('URL publique:', data.publicUrl);
// Ex. : https://your-project.supabase.co/storage/v1/object/public/avatars/user-id/avatar.jpg

Bucket privé — URL signée temporaire :

// URL temporaire (1 heure)
const { data, error } = await supabase.storage
  .from('documents')
  .createSignedUrl('private-file.pdf', 3600);

console.log('URL temporaire:', data.signedUrl);

Suppression :

const { data, error } = await supabase.storage
  .from('avatars')
  .remove(['user-id/avatar.jpg']);

Contrôle d’accès

Storage supporte aussi les RLS Policies.

Exemple : upload et accès uniquement dans son propre dossier.

-- Upload dans son dossier uniquement
CREATE POLICY 'Users can upload to their own folder'
ON storage.objects FOR INSERT
WITH CHECK (
  bucket_id = 'avatars' AND
  (storage.foldername(name))[1] = auth.uid()::text
);

-- Accès à son dossier uniquement
CREATE POLICY 'Users can access their own files'
ON storage.objects FOR SELECT
USING (
  bucket_id = 'avatars' AND
  (storage.foldername(name))[1] = auth.uid()::text
);

storage.foldername(name) extrait le dossier du chemin. [1] = premier segment, l’ID utilisateur.

Le chemin doit être user-id/filename — RLS vérifie que user-id = utilisateur courant, sinon refus.


Cas pratique : application de gestion de tâches

Récapitulons avec un exemple complet.

Fonctionnalités :

  • Inscription et connexion
  • Créer et lister des tâches
  • Joindre des fichiers aux tâches

Conception de la base

Schéma :

-- Table utilisateurs (créée par Auth, pas besoin de la créer)
-- Table tasks
CREATE TABLE tasks (
  id SERIAL PRIMARY KEY,
  user_id UUID REFERENCES auth.users(id) NOT NULL,
  title TEXT NOT NULL,
  description TEXT,
  status TEXT DEFAULT 'pending' CHECK (status IN ('pending', 'completed')),
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW()
);

-- Activer RLS
ALTER TABLE tasks ENABLE ROW LEVEL SECURITY;

-- Policy : l'utilisateur gère uniquement ses tâches
CREATE POLICY 'Users can manage their own tasks'
ON tasks FOR ALL
USING (user_id = auth.uid())
WITH CHECK (user_id = auth.uid());

-- Table attachments (liée aux tâches)
CREATE TABLE task_attachments (
  id SERIAL PRIMARY KEY,
  task_id INTEGER REFERENCES tasks(id) ON DELETE CASCADE,
  file_name TEXT NOT NULL,
  file_path TEXT NOT NULL,
  file_size INTEGER,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Activer RLS
ALTER TABLE task_attachments ENABLE ROW LEVEL SECURITY;

-- Policy : droits via la tâche parente
CREATE POLICY 'Users can manage attachments of their tasks'
ON task_attachments FOR ALL
USING (
  EXISTS (
    SELECT 1 FROM tasks
    WHERE tasks.id = task_attachments.task_id
    AND tasks.user_id = auth.uid()
  )
);

Pour task_attachments, la Policy ne teste pas user_id directement : elle remonte via task_id vers tasks.user_id. Seul le propriétaire de la tâche gère les pièces jointes.

Créer le Storage Bucket

Bucket task-files, privé :

-- Dans le Dashboard ou en SQL
INSERT INTO storage.buckets (name, public)
VALUES ('task-files', false);

-- Policy : upload dans son dossier
CREATE POLICY 'Users can upload task files'
ON storage.objects FOR INSERT
WITH CHECK (
  bucket_id = 'task-files' AND
  (storage.foldername(name))[1] = auth.uid()::text
);

CREATE POLICY 'Users can access task files'
ON storage.objects FOR SELECT
USING (
  bucket_id = 'task-files' AND
  (storage.foldername(name))[1] = auth.uid()::text
);

Code principal

Ensemble des fonctionnalités :

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  'https://your-project.supabase.co',
  'your-anon-key'
);

// 1. Inscription
async function register(email: string, password: string) {
  const { data, error } = await supabase.auth.signUp({
    email,
    password,
  });

  if (error) throw error;
  return data;
}

// 2. Connexion
async function login(email: string, password: string) {
  const { data, error } = await supabase.auth.signInWithPassword({
    email,
    password,
  });

  if (error) throw error;
  return data;
}

// 3. Créer une tâche
async function createTask(title: string, description?: string) {
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) throw new Error('Non connecté');

  const { data, error } = await supabase
    .from('tasks')
    .insert([
      {
        title,
        description,
        user_id: user.id,
      }
    ])
    .select();

  if (error) throw error;
  return data[0];
}

// 4. Liste des tâches
async function getTasks() {
  const { data, error } = await supabase
    .from('tasks')
    .select('*')
    .order('created_at', { ascending: false });

  if (error) throw error;
  return data;
}

// 5. Upload pièce jointe
async function uploadAttachment(taskId: number, file: File) {
  const { data: { user } } = await supabase.auth.getUser();

  if (!user) throw new Error('Non connecté');

  const filePath = user.id + '/' + taskId + '/' + file.name;

  const { data, error } = await supabase.storage
    .from('task-files')
    .upload(filePath, file);

  if (error) throw error;

  // Enregistrer dans task_attachments
  const { data: attachment, error: dbError } = await supabase
    .from('task_attachments')
    .insert([
      {
        task_id: taskId,
        file_name: file.name,
        file_path: filePath,
        file_size: file.size,
      }
    ])
    .select();

  if (dbError) throw dbError;

  return attachment[0];
}

// 6. Pièces jointes d'une tâche
async function getTaskAttachments(taskId: number) {
  const { data, error } = await supabase
    .from('task_attachments')
    .select('*')
    .eq('task_id', taskId);

  if (error) throw error;

  // URLs temporaires
  const attachmentsWithURLs = data.map(async (attachment) => {
    const { data: urlData } = await supabase.storage
      .from('task-files')
      .createSignedUrl(attachment.file_path, 3600);

    return {
      ...attachment,
      url: urlData.signedUrl,
    };
  });

  return Promise.all(attachmentsWithURLs);
}

// 7. Marquer une tâche terminée
async function completeTask(taskId: number) {
  const { data, error } = await supabase
    .from('tasks')
    .update({ status: 'completed', updated_at: new Date() })
    .eq('id', taskId)
    .select();

  if (error) throw error;
  return data[0];
}

// 8. Déconnexion
async function logout() {
  await supabase.auth.signOut();
}

Inscription, connexion, CRUD tâches, upload — le squelette d’une app complète. Ajoutez catégories, tags, commentaires, notifications…


Supabase vs Firebase

Quel choix ? Comparatif détaillé.

Différences clés

DimensionSupabaseFirebase
Type de basePostgreSQL (relationnelle)Firestore (NoSQL documentaire)
Open sourceEntièrement open sourceProduit propriétaire Google
TarificationFixe 25 $/mois (Pro Plan)À l’usage (lectures/écritures/stockage)
Propriété des données100 % chez vous, export facileDonnées chez Google, export pénible
RequêtesSQL puissant, jointures complexesLimitées, jointures en plusieurs requêtes
Temps réelWebSocket, abonnement manuelTemps réel Firestore natif
Hors ligneCache à implémenterSupport natif, sync auto
MigrationPostgreSQL standard, facileFormat propriétaire, coût élevé

Quand choisir quoi

Supabase :

  • Relations complexes, SQL et jointures
  • Projet long terme, contrôle total des données
  • Équipe à l’aise avec SQL et PostgreSQL
  • Budget serré (tarif fixe plus prévisible)
  • Priorité open source

Firebase :

  • Prototype rapide, délais serrés
  • App mobile, offline crucial
  • Sync temps réel centrale (chat, etc.)
  • Écosystème Google Cloud déjà en place
  • Données simples, requêtes basiques

Personnellement, après des projets Firebase et une facture à plus de 800 $/mois, la migration vers Supabase — mêmes fonctionnalités, environ 25 $/mois — a fait une grande différence.

L’export Firebase est laborieux : format Firestore propriétaire, conversion nécessaire. Supabase : export SQL ou CSV via outils PostgreSQL, migration vers une autre base possible.

Firebase reste fort sur le temps réel mobile — sync et offline Firestore excellents. Chat, coédition : Firebase peut être plus adapté.


Synthèse et recommandations

En résumé, la valeur de Supabase :

  • Base PostgreSQL — requêtes puissantes, relations claires
  • Auth entreprise — plusieurs modes de connexion, JWT, RLS
  • Stockage d’objets — simple, contrôle d’accès
  • Realtime, Edge Functions — à explorer ensuite

Open source, données sous contrôle, coût stable — important pour un projet durable.

Si vous êtes développeur frontend et voulez une app full stack sans vous noyer dans la config backend, Supabase est un bon choix. Database, Auth, Storage en quelques heures — bien plus vite qu’un backend traditionnel.

Pistes d’apprentissage :

  • Maîtriser d’abord Database, Auth, Storage
  • Tester les RLS Policies pour lier auth et permissions
  • Un projet réel from scratch reste la meilleure école
  • Puis Realtime, Edge Functions, Vector Database

Documentation officielle : supabase.com/docs. La communauté propose de nombreux tutoriels ; sur GitHub, la liste awesome-supabase recense de bonnes ressources.

En une phrase : si vous voulez PostgreSQL en backend sans tout configurer vous-même, Supabase a déjà tracé le chemin — il suffit de suivre.

Prise en main des trois fonctionnalités clés de Supabase

Créer un projet Supabase from scratch et maîtriser Database, Auth et Storage

⏱️ Estimated time: 2 hr

  1. 1

    Step 1: Créer un projet Supabase

    Rendez-vous sur supabase.com, créez un compte et un nouveau projet :

    • Nom du projet : my-first-app
    • Mot de passe base de données : notez-le bien
    • Région : la plus proche de vous (Singapour ou Tokyo pour l'Asie)

    Une fois créé, récupérez Project URL et Anon Public Key dans Settings > API
  2. 2

    Step 2: Installer et initialiser le client

    Dans votre projet frontend, installez la dépendance :

    npm install @supabase/supabase-js

    Initialisez le client Supabase :

    import { createClient } from '@supabase/supabase-js';

    const supabase = createClient(
    'https://your-project.supabase.co',
    'your-anon-key'
    );
  3. 3

    Step 3: Créer une table et configurer RLS

    Utilisez le SQL Editor pour créer une table :

    CREATE TABLE tasks (
    id SERIAL PRIMARY KEY,
    user_id UUID REFERENCES auth.users(id),
    title TEXT NOT NULL,
    status TEXT DEFAULT 'pending'
    );

    ALTER TABLE tasks ENABLE ROW LEVEL SECURITY;

    CREATE POLICY 'Users can manage their own tasks'
    ON tasks FOR ALL
    USING (user_id = auth.uid());

    La RLS Policy garantit que chaque utilisateur n'accède qu'à ses propres données
  4. 4

    Step 4: Implémenter l'authentification

    Exemple Email/Password :

    // Inscription
    await supabase.auth.signUp({
    email: '[email protected]',
    password: 'password123'
    });

    // Connexion
    await supabase.auth.signInWithPassword({
    email: '[email protected]',
    password: 'password123'
    });

    // Utilisateur courant
    const { data: { user } } = await supabase.auth.getUser();

    Prise en charge de Google, GitHub et 20+ plateformes pour la connexion sociale
  5. 5

    Step 5: Configurer le stockage de fichiers

    Créez un Storage Bucket (public ou privé) :

    // Upload
    await supabase.storage
    .from('avatars')
    .upload('user-id/avatar.jpg', file);

    // URL publique
    const { data } = supabase.storage
    .from('avatars')
    .getPublicUrl('user-id/avatar.jpg');

    Pour les fichiers privés, utilisez createSignedUrl pour générer un lien temporaire

FAQ

Quelles sont les différences clés entre Supabase et Firebase ?
Supabase utilise PostgreSQL (base relationnelle) avec requêtes SQL complexes et jointures ; Firebase utilise Firestore (NoSQL documentaire) avec des capacités de requête limitées. Supabase est entièrement open source, tarif fixe à 25 $/mois, données 100 % sous votre contrôle ; Firebase est propriétaire, facturation à l'usage (jusqu'à 800 $+/mois), export de données fastidieux.
Pour quels types de projets Supabase convient-il ?
Convient aux scénarios suivants :

• Relations de données complexes nécessitant SQL et jointures
• Projets long terme avec contrôle total des données
• Budget serré (tarif fixe plus prévisible)
• Développeurs frontend construisant rapidement une app full stack
• Priorité open source et stack maîtrisable
Qu'est-ce que Row Level Security (RLS) et à quoi sert-il ?
RLS est une fonctionnalité PostgreSQL de sécurité au niveau des lignes : elle contrôle au niveau base de données que chaque utilisateur n'accède qu'à ses propres données. Combinée à auth.uid() de Supabase Auth, l'utilisateur connecté ne voit et ne modifie que ses enregistrements — plus sûr qu'une vérification côté frontend.
Quelles méthodes de connexion Supabase Auth prend-il en charge ?
Plusieurs méthodes :

• Email/Password
• Magic Link (sans mot de passe)
• OTP (mot de passe à usage unique)
• Social Auth (Google, GitHub, Apple et 20+ plateformes)
• Phone Auth (Twilio, MessageBird)
• SSO (authentification unique entreprise)
Quelle différence entre bucket public et bucket privé dans Supabase Storage ?
Un bucket public (Public Bucket) : tout le monde peut accéder aux fichiers — idéal pour images publiques, avatars. Un bucket privé (Private Bucket) : accès sur autorisation, via createSignedUrl pour un lien temporaire (durée configurable) — idéal pour documents privés et fichiers uploadés par les utilisateurs.
Combien de temps faut-il pour migrer de Firebase vers Supabase ?
Une app simple : 2 à 3 jours — conversion Firestore en schéma PostgreSQL, export utilisateurs Firebase Auth vers Supabase Auth, migration Cloud Storage vers Supabase Storage. Une app complexe : 1 à 2 semaines, surtout pour la conversion du modèle de données et la réécriture des requêtes.
Que comprend le plan gratuit de Supabase ?
Le plan gratuit inclut : requêtes API illimitées, 50 000 utilisateurs actifs mensuels, 500 Mo de stockage base de données, 1 Go de stockage fichiers, 5 Go de bande passante. Idéal pour un MVP personnel ; au-delà des limites, passez au Pro Plan (25 $/mois).

14 min de lecture · Publié le: 3 avr. 2026 · Mis à jour le: 27 juil. 2026

Commentaires

Connectez-vous avec GitHub pour laisser un commentaire

Easton BlogEaston Blog