Architecture d'un SaaS Next.js : nos choix

L'architecture d'un SaaS en production, ce n'est pas empiler les technologies à la mode : c'est choisir une base stable, maintenable et prête à évoluer. Sur nos projets, cette base s'articule autour de Next.js, d'une couche de données claire et de Stripe. On détaille ici les choix qu'on applique, et les raisons derrière chacun. Cet article s'adresse aux porteurs de projet qui veulent vérifier le sérieux technique avant de se lancer.

Next.js comme socle applicatif#

Pour la majorité des SaaS, séparer un front et un back dès le départ ajoute de la complexité sans bénéfice. Next.js réunit le rendu serveur, les routes API et l'interface dans une seule base de code. Résultat : on développe et on déploie un MVP plus vite, et les pages publiques (accueil, fonctionnalités, pricing) profitent d'un rendu serveur favorable au SEO dès le premier jour.

Ce choix sert aussi la performance : avec une approche orientée composants serveur, on n'envoie au navigateur que le JavaScript réellement nécessaire, ce qui aide à tenir les Core Web Vitals au vert sur les pages publiques.

La couche de données et les frontières#

Le cœur d'un SaaS, ce sont ses données : comptes, abonnements, contenu métier. On s'appuie sur une base relationnelle et un modèle clair, avec une règle simple : la logique métier ne se disperse pas dans les composants d'interface. Chaque couche a sa responsabilité.

Une frontière compte particulièrement : toute donnée venue de l'extérieur (formulaire, API, webhook) est validée avant d'entrer dans le système. Le typage statique ne protège pas du runtime, d'où l'intérêt d'une validation explicite à l'entrée, dans l'esprit de nos règles TypeScript strict.

// Toute entrée externe est validée avant usage
const schema = z.object({ email: z.string().email(), plan: z.enum(['starter', 'pro']) })
const data = schema.parse(await request.json())

Les paiements : Stripe comme source de vérité#

C'est le point où une architecture se juge. Le principe directeur : la base de données locale est un miroir de Stripe, jamais une source de vérité concurrente. Tout changement d'état (paiement, changement de plan, échec) arrive par webhook et met à jour le modèle local.

Deux exigences rendent ce miroir fiable :

• Des webhooks idempotents : Stripe peut livrer le même événement plusieurs fois. Un handler non idempotent peut appliquer deux fois un changement de plan ou suspendre un compte à tort.
• Le rejeu testé avant le go-live : on vérifie systématiquement qu'un même événement traité deux fois ne casse rien.

// On ignore un événement déjà traité
if (await alreadyProcessed(event.id)) return ok()
await applyChange(event)
await markProcessed(event.id)

Cette rigueur sur les paiements est ce qui sépare un SaaS qui encaisse proprement d'un produit qui perd des revenus en silence. C'est aussi pour ça que les trois briques (auth, paiements, dashboard) font partie de ce qu'on livre dans chaque SaaS.

Déploiement et mise en production#

Une architecture n'est complète que si la mise en production est fiable. On automatise les vérifications (types, lint, tests, build) à chaque modification, et on bloque la mise en ligne si l'une échoue. Les secrets vivent hors du code, et chaque déploiement est reproductible.

L'objectif n'est pas la sophistication, mais la confiance : pouvoir livrer une correction le jour même sans craindre de casser la production. C'est cette fiabilité, posée dès le départ, qui permet de tenir le rythme d'un SaaS livré en 6 à 8 semaines.

Ce que cette architecture garantit#

Aucune architecture ne garantit le succès commercial, qui dépend du marché. Mais celle-ci garantit des choses concrètes et vérifiables :

• une stack maîtrisée et documentée, pas un assemblage fragile,
• des paiements fiables, parce que Stripe reste la source de vérité,
• une base maintenable, que votre équipe peut reprendre, puisque le code vous appartient,
• une mise en production sûre, qui permet d'itérer sans casser l'existant.

C'est le niveau d'exigence technique qu'on applique dans notre offre de création de SaaS : un produit solide sous le capot, livré sur votre dépôt, prêt à grandir.