Vibe Coding

Ajouter une base de données à son projet vibe coding avec Supabase

Branche une base de données Supabase sur ton projet vibe coding : 3 méthodes pas à pas, le code à copier et les erreurs de sécurité à éviter.

Par Jérémie Chiari

29 septembre 2026 10 min de lecture

Tu as créé une app avec Claude Code, elle s'affiche, elle fonctionne, et puis tu rafraîchis la page : tout a disparu. C'est normal, tes données vivaient dans la mémoire du navigateur. Pour qu'une application garde les informations de ses utilisateurs, il lui faut une base de données. Supabase est aujourd'hui l'option la plus accessible quand on débute : une base PostgreSQL hébergée, une API générée automatiquement, la gestion des comptes utilisateurs, et un plan gratuit qui suffit largement pour un premier projet.

Tu vas voir ici trois façons d'ajouter cette base à ton projet : te former dans un cadre guidé où les outils sont déjà prêts, la créer à la main dans le tableau de bord Supabase, ou laisser Claude Code écrire ton schéma lui-même via une connexion encadrée. Tu verras aussi les alternatives sérieuses (Firebase, Airtable, SQLite) et les cinq erreurs qui font fuiter des données chez les débutants. Aucun prérequis : si tu sais installer une application, tu sais suivre ce qui vient.

Ce qu'une base de données change dans ton app, et ce que fait Supabase

Une base de données, c'est l'endroit où ton application écrit ce qui doit survivre à la fermeture de l'onglet : comptes, commandes, messages, fichiers envoyés. Sans elle, tu as une maquette qui réagit joliment mais qui oublie tout.

Le vibe coding consiste à décrire en français ce que tu veux obtenir et à laisser un agent comme Claude Code écrire le code à ta place. Ça marche remarquablement bien pour l'interface : boutons, formulaires, mise en page. Ça coince souvent au moment du stockage, parce qu'il faut prendre de vraies décisions : quelles tables, qui a le droit de lire quoi, comment modifier la structure plus tard sans casser l'existant.

Supabase regroupe ces réponses dans un seul projet. Derrière l'interface, c'est PostgreSQL, une base de données utilisée depuis plus de trente ans en production, avec des couches ajoutées par-dessus.

Brique Supabase	À quoi ça sert	Équivalent que tu connais déjà
Database (PostgreSQL)	stocker tes tables et leurs relations	un classeur Excel, mais avec des règles strictes
Auth	inscription, connexion, mot de passe oublié	le bouton « Se connecter avec Google »
Storage	images, PDF, vidéos	un Drive rattaché à ton app
Realtime	mise à jour instantanée de l'écran	voir le curseur des autres dans un document partagé
API auto-générée	parler à la base depuis ton code	le serveur que tu n'as pas à écrire

Concrètement : tu crées une table taches, et Supabase te fournit immédiatement les adresses pour lire, ajouter, modifier et supprimer des lignes. Tu n'écris pas de serveur. C'est ce qui rend l'outil si adapté au vibe coding. La documentation officielle de Supabase sur les bases de données reste la référence à garder ouverte dans un onglet.

Méthode 1 : construire ta base dans un cadre guidé avec Skilzy

Quand tu débutes, la voie la plus rapide est d'apprendre le schéma et la sécurité pendant que tu construis, avec les outils déjà installés et payés.

Skilzy est une plateforme e-learning française pour apprendre et utiliser l'IA. Elle compte plus de 15 programmes : créer des images, des vidéos (UGC, publicités, chaînes faceless, avatars, voix off), de la musique, automatiser avec n8n, écrire de bons prompts, coder avec l'IA. Le point qui change tout pour un débutant, c'est le Lab IA intégré : tu utilises les vrais outils directement dans la plateforme, crédits inclus, sans multiplier les abonnements à 20 € par mois.

Sur la partie qui t'intéresse ici, le programme pour créer une app avec Claude Code te fait passer d'une page vide à une application qui enregistre de véritables données. Ce que tu en ressors, appliqué à ta base :

un schéma que tu comprends, avec les bons types de colonnes et les relations entre tables, au lieu d'un empilement de colonnes text
les règles de sécurité (Row Level Security) écrites et testées, pour qu'un utilisateur ne puisse pas lire les lignes d'un autre
la gestion propre des clés d'API et des variables d'environnement, sujet numéro un des fuites de données chez les débutants
un fichier d'instructions qui cadre l'agent pour la suite, comme expliqué dans notre guide sur le fichier CLAUDE.md

Deux certifications reconnues par l'État et finançables sont également disponibles : la RS7439, marketing de contenus assisté par IA, et la RS6792 sur l'IA et la vente. Utile si tu veux que ton apprentissage laisse une trace sur ton CV ou soit pris en charge.

Une offre B2B existe pour les organismes de formation qui veulent intégrer ces parcours à leur catalogue.

Méthode 2 : créer ta base à la main dans le tableau de bord Supabase

C'est gratuit, ça prend une quinzaine de minutes, et c'est la méthode à connaître même si tu délègues ensuite le travail à l'IA. Tu ne peux pas vérifier ce que fait un agent sur une base dont tu ignores le fonctionnement.

Crée ton projet. Sur supabase.com, connecte-toi avec GitHub, puis « New project ». Choisis une région proche de tes utilisateurs (Paris ou Francfort pour un public français, ça se joue en dizaines de millisecondes sur chaque requête). Note le mot de passe de la base dans ton gestionnaire de mots de passe : il ne s'affichera plus.
Crée ta première table. Deux chemins : le « Table Editor », qui ressemble à un tableur, ou le « SQL Editor », qui va plus vite dès que tu sais quoi écrire. Exemple pour une liste de tâches liée à des utilisateurs :

create table public.taches (
  id uuid primary key default gen_random_uuid(),
  created_at timestamptz not null default now(),
  user_id uuid not null references auth.users (id) on delete cascade,
  titre text not null,
  terminee boolean not null default false
);

Active la sécurité par ligne. Sans cette étape, n'importe qui disposant de ta clé publique peut lire toute la table. Supabase active RLS par défaut sur les tables créées depuis l'interface, mais pas toujours sur celles créées en SQL. Vérifie, puis écris ta règle :

alter table public.taches enable row level security;

create policy "chacun voit ses taches"
  on public.taches for select
  using (auth.uid() = user_id);

Traduction en français : un utilisateur connecté ne voit que les lignes dont le user_id correspond à son propre identifiant. Il te faudra une règle équivalente pour l'insertion, la modification et la suppression.

Récupère tes clés. Dans « Project Settings », puis « API », tu trouves l'URL du projet et deux clés. La clé publique (anon) peut vivre dans le code de ton interface. La clé service_role contourne toutes les règles de sécurité : elle ne doit jamais quitter ton serveur, ni apparaître dans un dépôt Git.
Branche ton code. Installe la bibliothèque officielle avec npm install @supabase/supabase-js, place tes clés dans un fichier .env.local ignoré par Git, puis :

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

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
)

const { data, error } = await supabase
  .from('taches')
  .select('*')
  .order('created_at', { ascending: false })

Côté budget : le plan gratuit de Supabase couvre deux projets actifs, environ 500 Mo de base de données et 50 000 utilisateurs actifs par mois au moment où ces lignes sont écrites. Les projets gratuits sont mis en pause après une semaine d'inactivité, ce qui surprend beaucoup de débutants : il suffit de les relancer depuis le tableau de bord. Vérifie la page tarifs avant de bâtir un business dessus, ces seuils évoluent.

Méthode 3 : laisser Claude Code écrire ton schéma avec le serveur MCP Supabase

Claude Code peut lire la structure de ta base, proposer les tables manquantes et écrire les fichiers de migration lui-même, à condition de lui donner un accès encadré.

MCP (Model Context Protocol) est le standard qui permet à un agent de dialoguer avec un outil extérieur. Supabase publie un serveur MCP officiel. L'installation tient en une commande :

claude mcp add supabase -e SUPABASE_ACCESS_TOKEN=ton_token -- npx -y @supabase/mcp-server-supabase@latest --read-only --project-ref=ton_ref

Le --read-only est volontaire : tu commences en lecture seule, le temps de vérifier que l'agent comprend ta base. Tu l'enlèves plus tard si tu en as besoin. Si cette partie est nouvelle pour toi, notre tutoriel sur la connexion de Claude Code à tes outils avec MCP détaille chaque étape, y compris la création du jeton d'accès personnel.

Ensuite, tu travailles en langage naturel : « Regarde la table taches dans Supabase, ajoute une table projets avec un titre et une couleur, relie chaque tâche à un projet, et écris la migration. » L'agent lit la structure existante, propose le SQL, et tu valides.

Pour les modifications, utilise le CLI Supabase plutôt que de taper du SQL à la main dans l'interface. Tes changements deviennent des fichiers versionnés, donc réversibles :

npx supabase init
npx supabase link --project-ref ton_ref
npx supabase migration new ajout_table_projets
npx supabase db push

Un fichier CLAUDE.md à la racine du projet évite 80 % des accidents. Trois lignes suffisent : « Toute modification du schéma passe par une migration dans supabase/migrations. RLS obligatoire sur chaque nouvelle table. Interdiction d'utiliser la clé service_role côté client. » Pour le reste des réflexes de terrain, garde sous la main les commandes Claude Code essentielles.

Les cinq erreurs à corriger avant de publier ton app

RLS désactivé sur une table publique. Ta clé anon est visible dans le code du navigateur. Sans RLS, toute la table est lisible par n'importe qui.
La clé service_role dans le front-end. Elle ignore toutes tes règles. Elle reste côté serveur, point.
Le fichier .env envoyé sur GitHub. Vérifie ton .gitignore avant le premier commit. Une clé publiée doit être révoquée, pas simplement supprimée du dépôt.
Des modifications de schéma faites uniquement à la main. Sans migration, tu ne peux plus revenir en arrière ni reproduire ta base ailleurs.
Valider le SQL de l'agent sans le lire. Un drop table glissé dans une migration est irréversible sur le plan gratuit, qui n'inclut pas la restauration à un instant précis.

Les alternatives à Supabase, et quand elles sont plus adaptées

Supabase n'est pas le seul choix, et sur certains projets il n'est même pas le meilleur. Voici les options qui tiennent la route.

Option	Son point fort	Sa limite	Pour qui
Supabase	PostgreSQL standard, SQL classique, plan gratuit généreux	il faut comprendre RLS	app web ou mobile avec des comptes utilisateurs
Firebase (Google)	mise en route très rapide, excellent sur mobile	base non relationnelle, requêtes complexes pénibles, facture difficile à prévoir	prototype mobile, notifications push
Airtable	interface tableur immédiate, parfait avec n8n	lent au-delà de quelques milliers de lignes, coûteux par utilisateur	outil interne, gestion de contenu, automatisations
SQLite ou Turso	fichier unique, aucune latence réseau, zéro configuration	pas d'authentification intégrée, sauvegardes à ta charge	projet solo, outil local, app de bureau
Google Sheets	tu sais déjà t'en servir	ce n'est pas une base de données, ça cède vite	maquette jetable, test d'idée sur une semaine

Une règle simple pour trancher : si ton app a des comptes utilisateurs et des données qui se croisent (un utilisateur, ses projets, ses tâches), prends Supabase. Si tu construis un outil interne piloté par des automatisations, Airtable te fera gagner des heures. Si tu fabriques un petit utilitaire local, SQLite suffit et ne te coûtera jamais un centime.

Ton prochain pas

Ouvre un projet Supabase, crée une seule table avec quatre colonnes, active RLS, écris une règle de lecture, branche-la à ton app. Une heure, pas plus. C'est cette première boucle complète qui débloque tout le reste : à partir de là, chaque nouvelle table n'est qu'une répétition du même geste.

Si tu hésites encore sur l'ordre dans lequel apprendre, notre guide pour savoir par où commencer avec l'IA te donne un chemin clair.

Questions fréquentes

Supabase est-il vraiment gratuit pour un premier projet ?

Oui. Le plan gratuit permet de faire tourner deux projets actifs, avec environ 500 Mo de base de données, 1 Go de stockage de fichiers et 50 000 utilisateurs actifs par mois. C'est largement suffisant pour apprendre et pour lancer une première application. Deux points à connaître : un projet gratuit inactif pendant environ une semaine est mis en pause (tu le relances en un clic), et la restauration de la base à un instant précis n'est pas incluse. Vérifie la page tarifs officielle avant de t'engager, ces limites évoluent régulièrement.

Faut-il savoir écrire du SQL pour utiliser Supabase ?

Non pour démarrer, oui pour durer. Le « Table Editor » de Supabase ressemble à un tableur : tu crées tes tables et tes colonnes à la souris, sans écrire une ligne de code. Et Claude Code peut générer le SQL à ta place. Mais tu as besoin de lire ce SQL pour vérifier ce qui part en production, surtout sur les règles de sécurité. Le vocabulaire utile tient en cinq mots : select (lire), insert (ajouter), update (modifier), delete (supprimer), policy (règle d'accès). Une heure d'apprentissage suffit à couvrir 90 % des cas.

Claude Code peut-il modifier ma base de données tout seul ?

Oui, via le serveur MCP officiel de Supabase, mais commence en lecture seule avec l'option --read-only. L'agent lit alors ta structure, comprend tes tables et propose du SQL que tu valides avant exécution. Quand tu ouvres l'écriture, impose deux règles dans ton fichier CLAUDE.md : toute modification de schéma passe par un fichier de migration versionné, et aucune suppression de table sans confirmation explicite. Relis systématiquement le SQL avant de le lancer sur une base contenant de vraies données.

Quelle est la différence entre la clé anon et la clé service_role ?

La clé anon est publique : elle est faite pour vivre dans le code de ton interface, et elle est soumise à tes règles de sécurité par ligne (RLS). La clé service_role, elle, contourne toutes ces règles et donne un accès total à la base. Elle ne doit apparaître que dans du code serveur, jamais dans le navigateur, jamais dans un dépôt Git. Si tu as publié une clé service_role par erreur, révoque-la immédiatement depuis les réglages du projet : la supprimer du code ne suffit pas, elle reste dans l'historique.

Supabase ou Firebase pour une app créée en vibe coding ?

Supabase dans la majorité des cas, parce que c'est du PostgreSQL standard : tes données ont une structure claire, les requêtes qui croisent plusieurs tables sont simples, et tu peux partir ailleurs avec ta base si besoin. Firebase reste pertinent pour une app mobile avec notifications push, où son écosystème Google fait gagner du temps. Sa base non relationnelle complique en revanche les requêtes un peu élaborées, et la facture est plus difficile à anticiper puisqu'elle dépend du nombre de lectures.