Next.js est devenu le choix par défaut pour les SaaS modernes — et pour de bonnes raisons. Mais c'est aussi un framework qui évolue vite, qui impose des contraintes particulières, et qui n'est pas la bonne réponse à tous les problèmes. Voici ce qu'on a appris après plusieurs projets SaaS construits avec.
Pourquoi Next.js s'est imposé
Un seul codebase pour tout. Avant Next.js, un SaaS nécessitait deux projets séparés : un backend (Node/Express) et un frontend (React). Next.js unifie ça. Le même projet gère les pages, les API routes, les Server Components et le déploiement. Pour une équipe de 1 à 5 développeurs, c'est un gain de productivité significatif.
Le SEO sans configuration. Un SaaS a une landing page, un blog, des pages de fonctionnalités qui doivent être indexées. Avec un SPA React classique, le SEO nécessite des configurations complexes. Avec Next.js, le rendu serveur est le comportement par défaut.
Vercel et le déploiement sans friction. La combinaison Next.js + Vercel est probablement la meilleure DX du marché actuellement : git push → preview automatique → production en un clic.
L'écosystème React. Next.js hérite de tout l'écosystème React : composants UI (shadcn, Radix), animations (Framer Motion), formulaires (React Hook Form), state management (Zustand). Le catalogue disponible est imbattable.
Les avantages concrets pour un SaaS
Server Components. Les Server Components permettent de charger les données directement dans le composant côté serveur, sans useEffect ni loading state côté client. Pour les dashboards qui affichent des données, c'est une réduction significative du code et une amélioration des performances perçues.
Route Handlers comme backend léger. Les API routes de Next.js suffisent pour la plupart des besoins SaaS : authentification, mutations, webhooks Stripe, intégrations tierces. Pas besoin d'un backend séparé pour la majorité des projets.
Middleware pour l'authentification. Le middleware Next.js s'exécute à la périphérie, avant que la requête atteigne le serveur — idéal pour protéger les routes authentifiées sans round-trip supplémentaire.
Les vraies limites
L'App Router a une courbe d'apprentissage réelle. Server Components vs Client Components, le cache, les Server Actions — des développeurs React expérimentés prennent 2 à 4 semaines pour être vraiment à l'aise. Les erreurs courantes : mettre "use client" sur tout par réflexe, mal comprendre le cache.
Pas adapté pour les backends complexes. Next.js Route Handlers fonctionnent bien pour des APIs simples. Pour des queues de jobs, des WebSockets, ou des logiques métier lourdes, il vaut mieux séparer : Next.js pour le frontend + SSR, et un backend dédié pour la logique complexe.
Le cold start sur Vercel. Les fonctions serverless ont des cold starts — 500ms à 2s quand la fonction n'a pas été appelée récemment. Pour des webhooks ou des opérations rares, ça peut causer des timeouts.
La facture Vercel peut surprendre. Gratuit pour les petits projets, mais les coûts montent rapidement avec la bandwidth élevée ou beaucoup d'invocations de fonctions. Pour un SaaS à fort trafic, prévoir le budget ou envisager l'auto-hébergement.
Ce qu'on utilise chez Araylab
Notre stack standard pour les projets SaaS :
Next.js 15 (App Router)
MongoDB + Mongoose — schéma flexible pour itérer vite au départ. PostgreSQL + Prisma pour les données très relationnelles.
Auth.js — couvre 95% des besoins d'authentification
Stripe — pas de discussion, meilleure API du marché
Resend — emails transactionnels modernes
Vercel — jusqu'à un certain niveau de trafic. Au-delà, Railway ou un VPS Hetzner.
Shadcn/ui — composants copiés dans le projet, pas de lock-in
Quand ne pas utiliser Next.js
Application très interactive type éditeur. Pour des applications très interactives avec un état local complexe (Figma, Notion), le modèle SPA React classique peut être plus adapté.
Backend avec workers et queues. Next.js n'est pas un runtime Node persistant. Pour des traitements en arrière-plan, un serveur séparé est nécessaire.
Application mobile. Next.js = web. React Native si vous avez besoin d'une app mobile.
Next.js reste notre choix par défaut pour les SaaS. La productivité qu'il offre à une petite équipe est difficile à battre. Mais c'est un choix qui doit être fait en connaissance de ses limites — pas par défaut parce que "tout le monde le fait".
Vous démarrez un SaaS et hésitez sur votre stack ? Parlons-en. Le choix technique initial est important, mais ce qui compte plus, c'est la qualité du cadrage et la cohérence de l'équipe.