Démarrer un projet sans perdre la première semaine : Next.js, Supabase, GitHub et Vercel

01L’hésitation coûte plus cher que le code

Au début d’un projet, on veut tout choisir avec soin : le framework, la base de données, l’hébergement, la gestion des comptes. On compare, on lit des avis, on écrit une API et un système de connexion avant d’avoir montré un seul écran à quelqu’un. Une semaine passe, et le projet n’est toujours pas en ligne.

Mon avis : ces choix se font une seule fois, puis se réutilisent à chaque nouveau projet. J’utilise la même pile partout où je peux :

Les quatre ont une offre gratuite suffisante pour lancer un projet, et aucun ne vous oblige à tout réécrire le jour où les utilisateurs arrivent.

02Ce site est construit comme ça

ossama.ma tourne sur cette pile. Le premier commit date du 6 octobre 2026 à 22 h 50 : Next.js, les trois langues (anglais, français, arabe), le schéma Supabase et des données de test. Quinze minutes plus tard, le README avait sa section de déploiement GitHub + Vercel. Le lendemain à 8 h 39, le site public suivait.

Depuis, la base compte 14 migrations, et un backoffice avec double authentification tourne sur son propre sous-domaine, admin.ossama.ma. Je n’ai pas eu à écrire de serveur d’API séparé.

03Le backend : Supabase

Supabase est une base PostgreSQL entourée de ce qu’un backend fait d’habitude : l’inscription et la connexion (email, Google, GitHub…), le stockage des fichiers et une API REST générée à partir de vos tables. Vous créez une table projects, et le frontend la lit en quelques lignes :

const { data, error } = await supabase
  .from("projects")
  .select("id, title, published_at")
  .eq("status", "published");

Le point à comprendre dès le premier jour est la sécurité. Le frontend utilise une clé publique, visible par n’importe qui dans le navigateur. Vos données sont protégées par les règles Row Level Security (RLS), écrites en SQL sur chaque table : qui peut lire quelles lignes, qui peut écrire.

alter table projects enable row level security;
 
create policy "public read of published projects"
  on projects for select
  using (status = 'published');

Gardez le schéma dans des fichiers de migration SQL, dans le dépôt, plutôt que de cliquer dans le tableau de bord. La base est alors versionnée comme le code, et vous pouvez la recréer à l’identique sur un deuxième projet : un environnement de test, un client, une autre région.

04Le frontend : Next.js

Next.js gère les pages, le routage et le rendu côté serveur, ce qui donne des pages rapides et bien indexées par Google. Il apporte aussi un petit côté serveur avec les Server Actions et les Route Handlers. C’est là que va la logique qui ne doit pas tourner dans le navigateur, par exemple un appel avec la clé secrète de Supabase ou l’envoi d’un email.

Un seul dépôt et un seul langage, TypeScript, couvrent donc l’interface et le peu de serveur dont un projet a besoin au début. La commande supabase gen types typescript génère les types de vos tables, et l’éditeur signale une colonne mal nommée avant même que vous lanciez le site.

05Versionning et publication : GitHub et Vercel

GitHub garde l’historique. Vercel se branche sur le dépôt et publie à chaque push, sans serveur à configurer. Mon flux tient en deux branches :

• develop : chaque push crée une URL de prévisualisation sur Vercel. Je vérifie le résultat sur un vrai lien, téléphone compris.
• main : la production. On y arrive par une pull request depuis develop, et le merge déclenche la mise en ligne. Si une mise en ligne casse quelque chose, Vercel permet de revenir au déploiement précédent le temps de corriger.

06Le premier soir, commande par commande

# 1. Le frontend (create-next-app crée aussi le dépôt Git et un premier commit)
npx create-next-app@latest mon-projet
cd mon-projet
 
# 2. Le client Supabase
npm install @supabase/supabase-js @supabase/ssr
 
# 3. Le schéma versionné
npx supabase init
npx supabase migration new init
 
# 4. Le dépôt GitHub
git add . && git commit -m "Supabase setup"
gh repo create mon-projet --private --source=. --push

Ensuite :

1. Créez un projet sur Supabase et copiez son URL et sa clé publique.
2. Écrivez vos tables dans le fichier de migration, puis appliquez-le avec npx supabase link et npx supabase db push.
3. Sur Vercel, importez le dépôt GitHub.
4. Ajoutez les variables d’environnement NEXT_PUBLIC_SUPABASE_URL et NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY, puis déployez. Le site est en ligne avec HTTPS, une base de données et une authentification prête à brancher. Le reste du temps va à la première fonctionnalité.

07Ce que permet le gratuit, et ses limites

Chiffres relevés en octobre 2026 sur les pages officielles de Supabase et de Vercel :

08Grandir sans tout réécrire

Quand le projet décolle, la pile reste la même et seuls les plans changent : Supabase Pro puis une instance de calcul plus grande, Vercel Pro, un nom de domaine. Le code ne bouge pas. La même base Supabase peut aussi servir une application mobile React Native, avec le même client supabase-js.

Le risque d’enfermement est plus faible qu’il n’y paraît. Supabase est du PostgreSQL standard : un pg_dump exporte toute la base vers n’importe quel autre hébergeur Postgres. Next.js tourne aussi sur votre propre serveur Node.js ou dans un conteneur Docker si Vercel ne convient plus. Le dépôt GitHub reste à vous quoi qu’il arrive.

La pile a aussi une limite nette. Une fonction Vercel s’arrête après 300 secondes sur le plan gratuit, donc un traitement long (import de gros fichiers, génération de rapports, file de tâches) demandera un worker séparé. Pour un MVP, un site, un outil interne ou une application à quelques milliers d’utilisateurs, cette limite arrive tard.