← Tous les articles

Construire

Supabase + Next.js : pourquoi c'est mon combo par défaut

Pour chaque nouveau projet, je repars sur la même base. Pas par paresse — parce que ça marche. Voici pourquoi ce duo est devenu mon standard.

8 min de lecture

Le piège du choix technologique

Chaque fois qu'un nouveau projet commence, la même tentation revient : "Et si je testais ce nouveau framework ?" "Et si je passais à telle base de données ?" "Et si je prenais cette nouvelle lib d'auth ?"

J'y ai cédé. Plusieurs fois. Et à chaque fois, j'ai perdu du temps. Pas parce que le nouveau truc était mauvais — mais parce que je n'avais pas la maîtrise. Les bugs mystérieux à 2h du matin, la doc incomplète, les edge cases non documentés. Tout ça ralentit. Et quand tu es seul, chaque heure perdue compte.

Aujourd'hui, je ne change plus de stack. Pour chaque nouveau projet — Kala, MafateRésa, Zinfluence — je repars sur la même base. Exactement la même. Ce n'est pas de la paresse. C'est de la discipline.

Ma stack, pièce par pièce

Supabase — le backend que je ne gère pas

Supabase, c'est une base PostgreSQL managée, avec auth, storage, real-time et edge functions intégrés. Un backend complet, accessible via une API REST ou un SDK JavaScript, sans avoir à gérer un serveur.

Pourquoi Supabase et pas Firebase ? Parce que PostgreSQL. Les requêtes relationnelles, les jointures, les contraintes d'intégrité — tout ce qu'un vrai backend de production a besoin. Firebase c'est du NoSQL, et dès que ton modèle de données devient complexe (et il le devient toujours), tu te retrouves à dénormaliser dans tous les sens.

Pourquoi Supabase et pas un backend custom (Express, Fastify, NestJS) ? Parce que je suis seul. Maintenir un serveur, gérer les mises à jour de sécurité, configurer le monitoring, scaler les instances — c'est un job à plein temps. Supabase me libère de tout ça. Je me concentre sur le produit.

Ce que j'utilise concrètement :

  • Auth. Inscription, connexion, mot de passe oublié, OAuth (Google, Apple). Tout est géré nativement. Pour Kala, l'auth prend en charge les comptes propriétaires et locataires avec des rôles différents. Pour MafateRésa, les gérants ont un accès spécifique à leur tableau de bord. Zéro code d'auth custom.

  • PostgreSQL. Les tables, les relations, les RLS (Row Level Security). Le RLS est crucial : chaque utilisateur ne voit que ses propres données, directement au niveau de la base. Pas besoin de filtrer côté API. C'est plus sûr et plus simple.

  • Storage. Les photos de matos sur Kala, les images de gîtes sur MafateRésa, les photos de profil sur Zinfluence. Tout est stocké dans Supabase Storage avec des politiques d'accès granulaires. Upload direct depuis le client, pas besoin de passer par le backend.

  • Real-time. Pour MafateRésa, les disponibilités se mettent à jour en temps réel. Quand un randonneur réserve un gîte, les autres voient la place disparaître instantanément. Sans WebSockets custom — juste la souscription real-time de Supabase.

Next.js — le framework qui fait tout

Next.js, c'est React avec du SSR (Server-Side Rendering), du SSG (Static Site Generation), des API Routes, et un système de routing intuitif. En une phrase : tout ce qu'il faut pour construire une web app complète.

Pourquoi Next.js et pas un SPA pur (Create React App, Vite + React) ? Parce que le SEO. Kala a besoin d'être indexé sur Google pour que les gens trouvent du matériel à louer. MafateRésa doit apparaître quand quelqu'un cherche "réserver gîte Mafate". Le SSR garantit que les pages sont indexables.

Pourquoi Next.js et pas Nuxt (Vue), SvelteKit, ou Remix ? Parce que l'écosystème React est le plus large. Plus de composants disponibles, plus de documentation, plus de réponses sur Stack Overflow. Et Claude maîtrise React mieux que n'importe quel autre framework — ce qui compte quand l'IA est ton copilote de dev.

Ce que j'utilise concrètement :

  • App Router. La dernière version du routing Next.js. Les layouts partagés, les loading states, les error boundaries — tout est géré par la structure de fichiers. Plus de configuration de routes, plus de boilerplate.

  • Server Components. Les composants qui n'ont pas besoin d'interactivité sont rendus côté serveur. Moins de JavaScript envoyé au client, meilleure performance. Pour les pages de listing (gîtes, matériel), c'est un gain significatif.

  • API Routes. Les webhooks Stripe, les endpoints internes, les tâches CRON — tout passe par les API Routes de Next.js. Pas besoin d'un serveur séparé.

TypeScript — la sécurité du typage

Je ne code plus en JavaScript vanilla. TypeScript attrape les bugs avant le runtime. Les types Supabase sont générés automatiquement depuis le schéma de la base — ce qui signifie que quand je change une colonne dans la DB, le compilateur me dit exactement quels fichiers sont cassés.

Sur un projet solo, c'est inestimable. Pas de collègue pour review ton code. Pas de QA team pour tester les régressions. TypeScript est mon filet de sécurité.

Tailwind CSS — le style sans prise de tête

Tailwind, c'est des classes utilitaires. Pas de fichiers CSS séparés, pas de naming conventions à maintenir, pas de cascade qui te joue des tours. Tu écris le style directement dans le HTML/JSX.

Les puristes détestent. Je comprends. Mais quand tu es seul et que tu dois sortir un MVP vite, Tailwind est imbattable. Le design system est cohérent par défaut (spacing, couleurs, typographie), le responsive est simple, et la maintenance est minimale.

Stripe — le paiement qui fonctionne

Stripe pour les paiements, Stripe Connect pour les marketplaces. Pour Kala, Stripe Connect gère les paiements entre locataires et propriétaires avec la commission automatique. Pour MafateRésa, les paiements de réservation transitent par Stripe avec la commission prélevée au passage.

La documentation Stripe est la meilleure du marché. Les webhooks sont fiables. Le dashboard est clair. Et le support répond vite quand tu as un problème. Après avoir testé Mollie, PayPlug et d'autres, je ne reviens pas.

Un point d'attention à La Réunion : la caution bloquée. Pour Kala, il faut bloquer une caution sur la carte du locataire sans la débiter, et la libérer quand le matos est rendu en bon état. Stripe le gère via les "payment intents" avec capture différée. C'est technique mais bien documenté.

Vercel — le déploiement en un push

Vercel héberge Next.js (c'est le même créateur). Un git push et l'app est en ligne en 60 secondes. Preview deployments pour chaque PR, analytics intégrés, et un CDN global. Le plan gratuit suffit largement pour un MVP.

Sentry — les erreurs avant les utilisateurs

Sentry capture les erreurs JavaScript côté client et serveur. Quand un bug se produit en production, je le sais avant que l'utilisateur me contacte. Avec le stack trace, le contexte, le navigateur, l'appareil. Indispensable quand tu n'as pas de QA.

Comment cette stack s'applique à mes projets

Kala

Marketplace P2P de location de matériel outdoor. Les défis techniques : gestion des annonces avec photos multiples, recherche géolocalisée, système de réservation avec calendrier de disponibilités, paiement avec caution bloquée, messagerie entre propriétaire et locataire.

Supabase gère les données (annonces, réservations, utilisateurs), le storage (photos), le real-time (messagerie). Next.js sert le frontend avec SSR pour le SEO. Stripe Connect gère les paiements et la caution. Le tout déployé sur Vercel.

MafateRésa

Plateforme de réservation de gîtes dans le cirque de Mafate. Les défis : carte interactive des îlets, calendrier de disponibilités par gîte, paiement en ligne avec commission, tableau de bord pour les gérants (accessible en mobile, réseau limité).

Même stack. Supabase pour les données et le real-time (disponibilités en temps réel). Next.js pour le frontend avec des pages optimisées pour le mobile. Stripe pour les paiements avec commission 10% CB / 7% sur place.

Zinfluence

Marketplace influenceurs × entreprises. Les défis : profils créateurs avec portfolio, recherche par catégorie et audience, système de missions, messagerie.

Même stack. La même base de code, les mêmes patterns, les mêmes outils. Le temps gagné est considérable.

Ce que je ne change pas

Le socle ne bouge pas. C'est une décision consciente. Chaque nouvelle technologie a un coût d'apprentissage et un risque d'instabilité. Tant que ma stack fait le job — et elle fait le job — je ne change rien.

Quand une nouvelle version de Next.js sort, je mets à jour. Quand Supabase ajoute une feature, je l'évalue. Mais je ne remplace pas un outil qui fonctionne par un outil qui brille.

Ce principe a un nom dans l'industrie : "boring technology". La technologie ennuyeuse, c'est celle qui marche. Pas de surprises, pas de bugs mystérieux, pas de breaking changes. Juste du code qui tourne.

Ce que je changerais si c'était à refaire

Rien de fondamental. Mais quelques détails :

Tailwind → Tailwind. Je ne changerais pas. Mais si je devais recommencer de zéro en 2027, je regarderais de plus près les CSS Variables natives avec un design system custom. Tailwind est pratique mais génère du HTML verbeux.

Supabase Edge Functions. Je les utilise peu, mais elles deviennent de plus en plus puissantes. Pour les tâches backend complexes (calculs, agrégations, CRON jobs), elles pourraient remplacer les API Routes de Next.js.

Mobile. Kala a une dimension mobile forte. Pour l'instant, c'est une PWA. Si je devais refaire le choix, j'évaluerais React Native ou Expo plus sérieusement pour une app native. La PWA a ses limites — notifications push, accès caméra, performance perçue.

Le conseil

Si tu démarres un projet solo, ne perds pas de temps à choisir la stack parfaite. Prends une stack que tu connais (ou que tu peux apprendre vite), et tiens-toi-y. La valeur est dans le produit, pas dans la technologie. Tes utilisateurs se fichent que tu utilises Supabase ou Firebase, Next.js ou Nuxt. Ils veulent que ça marche.

Ma stack n'est pas la meilleure objectivement. C'est la meilleure pour moi, parce que je la maîtrise. Trouve la tienne, et construis.