TL;DR

• SvelteKit compile la reactivite au build : moins de JS envoye, DX superieure, courbe d'apprentissage de 2 jours.
• FastAPI combine la rapidite de prototypage de Python avec la rigueur de Pydantic et une doc Swagger auto-generee.
• Supabase offre un vrai PostgreSQL avec auth, storage et realtime integres -- sans le vendor lock-in de Firebase.
• Ce stack a des limites : ecosysteme Svelte plus petit, FastAPI moins battle-tested que Spring en enterprise, dependance a Supabase.
• Le meilleur stack n'existe pas. Celui-ci convient a mon contexte : SaaS MVP, prototypage rapide, un dev solo qui veut aller vite sans sacrifier la qualite.

Chaque dev a une opinion sur le "meilleur stack". Voici le mien, pourquoi je l'ai choisi, et surtout -- ce que j'aurais perdu avec les alternatives.

Le contexte

Je construis un SaaS. Les besoins sont concrets : prototypage rapide, type safety, authentification, stockage de fichiers, generation de PDF, et une DX qui ne me donne pas envie de fermer mon editeur toutes les 30 minutes.

Mon background, c'est 8 ans de Java et Spring Boot. Je connais l'ecosysteme enterprise. Je sais ce que ca apporte. Je sais aussi ce que ca coute en temps quand tu veux juste valider une idee.

J'avais besoin d'un stack qui me permette de passer de l'idee au prototype deployable en quelques jours. Pas en quelques sprints. Et surtout, un stack ou chaque couche justifie sa presence.

Frontend : SvelteKit vs Next.js vs Nuxt

Le choix du framework frontend, c'est souvent le premier debat. Et le plus emotionnel. Tout le monde a son avis. Voici le mien, base sur l'usage reel.

Pourquoi SvelteKit a gagne

SvelteKit ne fonctionne pas comme React ou Vue. Il n'embarque pas de runtime dans le navigateur. Le compilateur Svelte transforme tes composants en JavaScript vanilla au moment du build. Le resultat : moins de code envoye, des interactions plus rapides, et un modele de reactivite natif qui elimine une categorie entiere de bugs.

Concretement :

• Pas de virtual DOM. La reactivite est resolue a la compilation. Quand tu ecris let count = 0, c'est reactif. Pas besoin de useState, pas de hooks, pas de regles a memoriser.
• Moins de boilerplate. Un composant Svelte, c'est du HTML, du CSS scope, et du JavaScript. Pas de JSX, pas de className, pas de useEffect pour gerer les side effects.
• Builds plus rapides. Vite sous le capot, HMR quasi-instantane, et un bundle final plus leger.
• Routing filesystem. Comme Next.js, mais avec une syntaxe plus directe pour les layouts, les server-side loads, et les form actions.

Ce que Next.js fait mieux

Soyons honnetes. Next.js a des avantages reels :

• L'ecosysteme. React a le plus grand ecosysteme de composants, de librairies, et de solutions de l'univers frontend. Tu trouveras une librairie React pour tout. En Svelte, tu trouveras une librairie pour presque tout -- mais "presque" peut couter cher sur un projet specifique.
• La communaute. Quand tu as un probleme avec Next.js, il y a 47 threads Stack Overflow et 12 videos YouTube qui t'attendent. Avec SvelteKit, tu vas parfois lire le code source. C'est formateur, mais c'est pas toujours ce que tu veux a 23h.
• Vercel. L'integration Next.js + Vercel est lisse. Deployment en un push, preview branches, analytics integrees. SvelteKit se deploie aussi sur Vercel, mais c'est pas le meme niveau de polish.

L'avis honnete

Si tu viens de React, SvelteKit va te faire mal pendant 2 jours. Tu vas chercher useEffect, tu vas essayer de passer des props comme en React, tu vas ecrire {#if} pour la premiere fois et trouver ca bizarre.

Puis le troisieme jour, tu vas ecrire un composant complet en 15 lignes, te demander ou est passe le boilerplate, et ne plus vouloir revenir. C'est systematiquement ce que je vois chez les devs qui font la transition.

Nuxt, je l'ai teste. C'est solide. Mais Vue n'a jamais ete mon langage naturel, et Nuxt 3 avait encore des rough edges quand j'ai fait mon choix. Si tu es a l'aise avec Vue, c'est un excellent choix.

Backend : FastAPI vs Express vs Spring Boot

Le backend, c'est la ou mon choix surprend le plus vu mon parcours. 8 ans de Spring Boot, et je choisis Python. Voici pourquoi.

Pourquoi FastAPI

FastAPI reunit trois choses que je n'ai jamais trouvees ensemble ailleurs :

• Prototypage ultra-rapide. Un endpoint CRUD complet avec validation, documentation, et gestion d'erreurs se fait en quelques lignes. Pas en quelques classes avec annotations, injection de dependances, et configuration XML heritee de 2014.
• Pydantic. La validation de donnees par type hints. Tu definis ton modele, FastAPI valide automatiquement les inputs, genere la doc, et te donne des messages d'erreur clairs. C'est la meilleure DX de validation que j'ai utilisee.
• Async natif. Python 3.12+ avec async/await gere tres bien les I/O concurrentes. Pour un SaaS qui fait beaucoup d'appels API et de requetes DB, c'est exactement ce qu'il faut.
• Swagger auto-genere. Tu ecris ton code, tu as ta doc. Pas un fichier OpenAPI a maintenir a cote. Pas un Postman collection a synchroniser.

Voici un endpoint FastAPI vs son equivalent Spring Boot :

# FastAPI — 12 lignes
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()

class Invoice(BaseModel):
    client_id: int
    amount: float
    description: str

@app.post("/invoices", status_code=201)
async def create_invoice(invoice: Invoice):
    result = await db.invoices.insert(invoice.model_dump())
    return {"id": result.id, **invoice.model_dump()}

// Spring Boot — meme fonctionnalite, plus de ceremony
@RestController
@RequestMapping("/invoices")
public class InvoiceController {

    @Autowired
    private InvoiceService invoiceService;

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public InvoiceResponse createInvoice(
            @Valid @RequestBody InvoiceRequest request) {
        Invoice invoice = invoiceService.create(
            request.getClientId(),
            request.getAmount(),
            request.getDescription()
        );
        return InvoiceResponse.from(invoice);
    }
}

// + InvoiceRequest.java (DTO)
// + InvoiceResponse.java (DTO)
// + InvoiceService.java (service layer)
// + Invoice.java (entity)

La difference n'est pas juste cosmetique. C'est du temps. Sur un MVP, chaque fichier en plus est une friction en plus.

Pourquoi pas Express

Express a un probleme fondamental : il ne structure rien. Tu pars d'un fichier vide et tu dois tout decider -- validation, architecture, middleware, gestion d'erreurs. C'est de la liberte, mais c'est aussi de la fatigue decisionnelle.

Avec FastAPI, les opinions sont deja la. Pydantic pour la validation, les type hints pour la doc, les dependency injections pour les middlewares. Tu peux diverger, mais le chemin par defaut est solide.

Pourquoi pas Spring Boot

Spring Boot, c'est mon outil de predilection en enterprise. Pour un systeme SIRH multi-tenant avec 200 utilisateurs et des contraintes de conformite, c'est imbattable. Les transactions distribuees, la securite, l'ecosysteme -- tout est la.

Mais pour un MVP SaaS ou je suis le seul dev, Spring Boot est de l'artillerie lourde pour une cible legere. Le temps de setup, les annotations en cascade, la configuration, le cycle de feedback -- tout est plus lent. Et en solo, la vitesse d'iteration est la metrique qui compte.

Database et BaaS : Supabase vs Firebase vs PostgreSQL auto-heberge

C'est le choix qui m'a le plus convaincu a l'usage.

Pourquoi Supabase

Supabase, c'est comme avoir un DBA PostgreSQL gratuit qui gere aussi ton auth, ton stockage, et ton realtime. Sauf que c'est pas une metaphore -- c'est litteralement un PostgreSQL manage avec des services integres autour.

Les avantages concrets :

• Un vrai PostgreSQL. Pas un datastore NoSQL avec des regles de securite fragiles. Des vraies tables, des vraies relations, des vraies requetes SQL. Quand tu veux faire un JOIN ou une sous-requete, tu le fais. Tu ne contournes pas les limites de ton modele de donnees.
• Row Level Security (RLS). La securite au niveau des lignes, directement dans PostgreSQL. Tu definis des politiques en SQL, et le moteur les applique. Pas de logique de securite dans ton code applicatif. C'est elegant et fiable.
• Auth integree. Email/password, magic links, OAuth providers -- tout est integre. L'auth Supabase genere des JWT qui s'integrent avec RLS. Un seul systeme de securite du frontend jusqu'a la base de donnees.
• Storage. Upload de fichiers avec gestion de buckets et politiques de securite. Pour la generation de PDF et le stockage de documents dans mon SaaS, c'est exactement ce qu'il faut.
• Realtime. Les subscriptions PostgreSQL exposees en WebSocket. Les changements dans la base se propagent automatiquement aux clients connectes. Pas besoin d'un systeme de pub/sub separe.

Pourquoi pas Firebase

Firebase est un excellent produit pour certains cas. Les applications mobiles simples, les prototypes rapides avec Firestore, les projets ou le modele de donnees est hierarchique et previsible. Mais pour un SaaS avec des relations complexes, Firebase montre ses limites :

• NoSQL. Firestore est un document store. Si ton modele de donnees a des relations many-to-many, des aggregations complexes, ou des besoins de reporting, tu vas passer ton temps a denormaliser, dupliquer, et maintenir la coherence manuellement.
• Vendor lock-in. Firebase, c'est Google Cloud avec une couche d'abstraction. Migrer hors de Firebase, c'est reecrire. Supabase est du PostgreSQL standard -- si tu veux partir, tu exportes ta base et tu la montes ailleurs.
• Pricing imprevisible. Firebase facture a la lecture de document. Quand ton application commence a scaler, la facture peut exploser sans prevenir. Supabase a un pricing plus lineaire et previsible.

Pourquoi pas PostgreSQL auto-heberge

J'aurais pu monter un PostgreSQL sur un VPS, gerer les backups, le monitoring, les mises a jour de securite, la haute disponibilite. Mais en solo sur un MVP, chaque heure passee en ops est une heure pas passee sur le produit. Supabase me donne un PostgreSQL manage avec des services integres, et un tier gratuit genereux pour demarrer.

Les compromis

Aucun stack n'est parfait. Voici ce que celui-ci fait moins bien.

L'ecosysteme SvelteKit est plus petit. Quand tu as besoin d'un composant specifique -- un editeur rich text, un date picker avance, une librairie de charts complexe -- tu as moins d'options qu'en React. Parfois, il faut wrapper une librairie JS vanille toi-meme. C'est faisable, mais c'est du temps.

FastAPI n'est pas battle-tested en enterprise. Spring Boot tourne dans des banques, des compagnies d'assurance, des systemes critiques depuis des annees. FastAPI est plus jeune. Pour un MVP et un SaaS en croissance, c'est suffisant. Pour remplacer le backend d'un systeme critique en production, je reflechirais a deux fois.

La dependance a Supabase. Meme si c'est du PostgreSQL standard, les services autour (auth, storage, realtime) creent une dependance. Si Supabase ferme demain, tu gardes ta base, mais tu perds la couche de services. C'est un risque mesure -- Supabase est open source et auto-hebergeable, ce qui limite le lock-in.

Python en backend web. Le typage de Python est optionnel et runtime. Meme avec Pydantic et mypy, tu n'as pas la meme garantie compile-time que TypeScript ou Java. Pour un dev seul, c'est gerable avec de la discipline. Pour une equipe, la question se pose.

Le vrai test : la prod

La theorie, c'est bien. La production, c'est la verite.

Ce qui a fonctionne exactement comme prevu :

• Le cycle de dev. SvelteKit + FastAPI, c'est un HMR instantane cote front et un reload rapide cote API. Le feedback loop est court, et ca change tout quand tu iteres vite.
• L'auth Supabase. De l'inscription au JWT dans les headers API, tout s'imbrique sans friction. RLS fait le reste cote donnees.
• La generation de PDF. Python + WeasyPrint cote FastAPI, stockage dans Supabase Storage. Simple, fiable.

Ce qui a ete plus dur que prevu :

• Le SSR SvelteKit avec l'auth. Gerer les cookies de session, le refresh de token, et l'hydratation cote client a demande plus de plomberie que je ne l'anticipais. La documentation officielle couvre le cas de base, mais les edge cases demandent de la patience.
• Les migrations Supabase en prod. L'outil CLI est fonctionnel mais encore jeune. J'ai eu quelques sueurs froides sur des migrations avec des foreign keys et des politiques RLS imbriquees. Un pg_dump regulier est ton meilleur ami.
• Le deploiement FastAPI. Docker + Fly.io, ca fonctionne. Mais configurer les health checks, les variables d'environnement, et le cold start a demande quelques iterations.

Le bilan : le stack tient en production. Les problemes rencontres sont des problemes de plomberie, pas des problemes d'architecture. Et c'est exactement ce que tu veux.

Ressources

Pour aller plus loin sur chaque technologie :

• SvelteKit Documentation -- la doc officielle, excellente et bien structuree
• FastAPI Documentation -- le tutoriel officiel est un des meilleurs de l'ecosysteme Python
• Supabase Documentation -- guides, references API, et exemples concrets
• Supabase vs Firebase -- comparaison detaillee par Supabase
• Svelte Society -- packages, templates, et composants communautaires
• Pydantic V2 Documentation -- le coeur de la validation FastAPI

Pour aller plus loin

Si tu t'interesses a la facon dont j'utilise l'IA dans mon workflow de dev, j'ai ecrit une serie sur le sujet :

• RAG, MCP, function calling -- le kit du dev en 2026 -- les patterns concrets pour integrer des LLM dans tes projets
• Les agents IA ne sont pas du hype -- comment fonctionnent les agents et pourquoi ca change le quotidien des devs

Le stack que tu choisis compte. Mais ce qui compte encore plus, c'est de le choisir en connaissance de cause -- pas parce que c'est le trend du moment sur Twitter.