Boilerplate SaaS TypeScript : choisir un socle et garder la logique métier chez soi

Un boilerplate SaaS est un dépôt de code de départ qui contient le socle technique commun à la plupart des applications SaaS : l’authentification, la gestion des comptes, la structure du projet, les tests, l’intégration continue et le déploiement. Il fait gagner les premières semaines d’un projet, à condition de bien le choisir. Le critère qui compte le plus est la façon dont votre projet récupère les correctifs du kit une fois que votre code s’en est écarté, bien plus que le nombre de fonctionnalités incluses. Tout ce qui dépend de votre modèle économique doit rester hors du kit. Cet article compare boilerplate, template et développement from scratch, passe en revue les starter kits SaaS TypeScript du marché, donne une grille d’évaluation et montre, code à l’appui, comment Lonestone a construit le sien.

Boilerplate, template ou starter kit : quelle différence ?

On emploie souvent les trois mots comme synonymes. Starter kit et boilerplate désignent bien la même chose, mais le template en désigne une autre, plus étroite.

Un boilerplate (ou starter kit) est un projet complet et fonctionnel que vous copiez pour démarrer : une API, un front, une base de données, la configuration des outils. Vous le lancez en local le premier jour, puis vous le modifiez. Il devient votre code.

Un template fournit seulement une partie du projet, sans application qui tourne : un modèle d’interface (un tableau de bord, une page de prix), un squelette de dossiers, ou un générateur qui crée la structure sans la logique. Un template d’interface SaaS vous donne des écrans, sans le backend qui les fait fonctionner.

Le développement from scratch part d’un dossier vide et des frameworks choisis par l’équipe. Elle fait tous les choix, puis écrit tout le code, y compris ce que tous les SaaS ont en commun.

Les briques à réutiliser depuis un boilerplate SaaS

Réutilisez tout ce qui est identique d’un SaaS à l’autre et long à bien faire. Vos concurrents ont exactement les mêmes briques, mais une erreur sur l’une d’elles coûte cher en production :

• l’authentification : inscription, vérification de l’email, réinitialisation du mot de passe, sessions, limitation des tentatives de connexion
• la structure du code et ses conventions : où vivent les modules, comment une route valide ses entrées, comment le front connaît les types de l’API
• les migrations de base de données, les seeds et les factories de test
• les tests automatisés et l’intégration continue (lint, typage, tests à chaque pull request)
• l’observabilité : remontée des erreurs, logs structurés, traces des requêtes
• l’envoi d’emails transactionnels et le stockage de fichiers
• la gestion des variables d’environnement et des secrets
• le build et le déploiement : images Docker, configuration pour un hébergeur
• pour un produit qui intègre de l’IA, les appels aux modèles, la gestion des prompts et le traçage des appels

Prenez l’authentification. Une bibliothèque comme Better Auth gère les comptes et les sessions en quelques lignes. Pour la câbler proprement à une API, avec les guards, les hooks, l’envoi des emails et les types côté front, comptez plusieurs jours la première fois. Un bon boilerplate vous fait gagner ces jours.

La logique métier à écrire pour votre produit

Seule votre équipe connaît ce qui découle de votre modèle économique ou de votre métier :

• le modèle de prix (abonnement par siège, à l’usage ou par palier, avec ou sans essai gratuit, avec ou sans facturation annuelle)
• les règles qui fixent qui peut lire tel dossier, valider telle commande ou voir les chiffres de tel client
• le découpage multi-tenant : une base partagée avec un identifiant d’organisation sur chaque table, des schémas séparés ou des bases séparées
• l’onboarding, c’est-à-dire ce que voit un nouvel utilisateur, ce qu’il configure et le moment où il est invité à payer
• les workflows, ces séquences d’étapes qui font la valeur du produit, avec leurs états et leurs notifications

La facturation est le piège le plus fréquent. Beaucoup de starter kits du marché arrivent avec Stripe déjà câblé et un modèle par défaut (trois plans, un abonnement mensuel). Ce câblage fait gagner une semaine au lancement. Le jour où vous passez à une facturation à l’usage ou par siège, il faut d’abord comprendre le code de quelqu’un d’autre, puis le défaire. Tant que le produit est jeune, son prix change souvent. Écrivez donc la facturation pour votre modèle, à partir de la documentation du prestataire de paiement.

Les rôles posent le même problème. Un kit qui livre « Owner » et « Member » suffit pour une démo. Un logiciel métier a besoin de rôles qui correspondent à l’organisation de ses clients (comptable, responsable de site, auditeur externe). L’API doit vérifier ces droits dans chaque route. Le Top 10 OWASP des API classe l’oubli de cette vérification en première position.

Les starter kits SaaS TypeScript du marché en 2026

Le marché se partage entre des kits payants, vendus une fois avec un accès à vie au dépôt, et des projets open source gratuits. Les prix cités sont ceux affichés par les éditeurs en novembre 2026.

Ces kits visent deux publics. ShipFast, Supastarter, Makerkit et Open SaaS s’adressent surtout aux développeurs indépendants et aux petites équipes qui veulent vendre un abonnement vite : landing page, page de prix et paiement sont prêts. Le boilerplate de Lonestone part d’une autre hypothèse, celle d’une équipe qui livre des produits sur mesure pour des clients différents. Il fournit le socle technique et laisse la facturation au projet.

La plupart de ces kits reposent sur Next.js, qui mélange front et backend dans le même framework. C’est pratique pour un produit simple. Pour une API qui doit servir un front web, une application mobile et des intégrations clients, un backend séparé sous NestJS garde l’API indépendante du front.

Évaluer un boilerplate SaaS avant de l’adopter

Clonez le kit, lancez-le, puis vérifiez sa sécurité, sa maintenance, ses dépendances, ses mises à jour, son déploiement et la place qu’il laisse au code métier. Une heure d’examen évite des semaines de démontage.

La sécurité et le suivi des failles

Une faille dans une dépendance du kit devient une faille de votre produit. En mars 2025, la faille CVE-2025-29927 de Next.js (score de gravité 9,1 sur 10) permettait de contourner le middleware avec un simple en-tête HTTP, x-middleware-subrequest. Les applications auto-hébergées qui vérifiaient l’authentification uniquement dans le middleware laissaient alors passer des requêtes d’utilisateurs non connectés. En décembre 2025, la faille CVE-2025-55182 des React Server Components, notée 10 sur 10, touchait Next.js 15 et 16 : elle permettait d’exécuter du code sur le serveur sans être connecté.

Vérifiez donc combien de temps le kit a mis à publier une version corrigée après ces failles, si chaque route de l’API vérifie la session en plus du middleware, et quel outil vous alerte sur les dépendances vulnérables (Dependabot, Renovate ou équivalent).

La maintenance

Regardez la date de la dernière version, la fréquence des publications et le changelog. Un changelog qui explique ce qui change et comment migrer vaut mieux qu’une liste de commits. Comptez les contributeurs actifs : un kit maintenu par une seule personne s’arrête souvent le jour où elle change de projet.

Les dépendances

Ouvrez le package.json. Chaque paquet est une mise à jour à suivre et une faille possible. Repérez les services tiers imposés (une base hébergée, un fournisseur d’authentification, un service d’emails) : chacun ajoute un compte à ouvrir, une facture et un sous-traitant à déclarer quand un client B2B demande où sont stockées ses données. Vérifiez qu’ils se remplacent sans réécrire le kit.

Les mises à jour après le démarrage

Votre projet s’éloigne du kit dès le premier jour. Quand le kit publie un correctif six mois plus tard, comment l’intégrer ? Un git merge depuis le dépôt d’origine produit alors des dizaines de conflits, parce que votre code a changé entre-temps. Cherchez un kit qui documente chaque changement assez précisément pour que vous puissiez le rejouer à la main, version par version.

Le déploiement

Le kit doit se construire en images Docker ou se déployer sur un hébergeur standard, avec une documentation des variables d’environnement. Méfiez-vous d’un kit lié à une seule plateforme : vous voudrez peut-être un jour passer chez un hébergeur français ou réduire la facture.

La place laissée au code métier

Un bon kit se laisse alléger. Il sépare les exemples du socle et documente la suppression de chaque brique inutile. Vérifiez qu’on peut retirer la démo, l’IA ou un des fronts en suivant une procédure plutôt qu’en cherchant les fichiers un par un.

Les pièges de dépendance d’un starter kit

Quatre pièges reviennent avec les starter kits :

• le code que le produit n’utilise pas
• l’enfermement dans une plateforme
• la dette héritée
• le kit que l’équipe ne comprend pas

Un kit « tout compris » embarque un blog, une page de prix, trois fournisseurs de paiement et un panneau d’administration. Chaque brique inutile reste dans le dépôt, alourdit les mises à jour et élargit la surface d’attaque. Supprimez dès la première semaine ce que le produit n’utilisera pas dans les six prochains mois.

Un kit construit autour d’un backend hébergé (base, authentification et stockage chez le même fournisseur) démarre très vite. Le jour où le volume grossit, où un client exige un hébergement en France ou où la facture dépasse le budget, la migration touche toutes les couches de l’application en même temps.

Un kit fige aussi des choix faits par son auteur, à une date donnée : une version de framework, un ORM, une façon d’organiser les dossiers. Si ce framework ou cet ORM ne sont plus maintenus, la dette technique commence avant la première ligne de votre code.

Une équipe qui adopte le code d’un kit sans le lire découvre son fonctionnement en production, lors du premier incident. Prévoyez une journée pour lire l’authentification, la gestion des erreurs et le déploiement du kit avant d’écrire la première fonctionnalité.

Comment Lonestone a construit son boilerplate open source

Lonestone démarre ses projets web sur un boilerplate open source maintenu par ses ingénieurs. C’est un socle technique : il accélère la livraison des premières semaines, puis l’équipe du projet construit la logique métier de chaque client par-dessus. Passons-le à la même grille d’évaluation.

La structure du projet

Le boilerplate est un monorepo TypeScript : une API NestJS, deux fronts React (une application monopage et une application rendue côté serveur), une documentation et des paquets partagés.

mon-projet/
├── apps/
│   ├── api/               # API NestJS : auth, IA, emails, base de données
│   ├── web-spa/           # Application React monopage
│   ├── web-ssr/           # Application React rendue côté serveur
│   └── documentation/     # Documentation du projet
├── packages/
│   ├── ui/                # Composants d’interface partagés (shadcn/ui)
│   ├── i18n/              # Traductions partagées
│   └── openapi-generator/ # Client d’API typé généré depuis l’OpenAPI
└── .boilerstone/          # Suivi de la version du boilerplate

Côté backend, le boilerplate utilise PostgreSQL avec MikroORM, Zod pour la validation des données et Better Auth pour l’authentification. Le front utilise Tailwind CSS, shadcn/ui, React Router, TanStack Query et React Hook Form. L’API publie un contrat OpenAPI, dont le paquet openapi-generator tire un client typé : si une route change côté API, la compilation du front échoue tout de suite, avant toute mise en production.

Un projet créé à partir d’une version publiée

Une seule commande crée un nouveau projet à partir de la dernière version publiée du boilerplate, plutôt que de sa branche de développement :

# Crée le projet à partir de la dernière version publiée
pnpm dlx @lonestone/boilerstone-cli init mon-projet

# Garde uniquement l’application monopage
pnpm dlx @lonestone/boilerstone-cli init mon-projet --apps web-spa

# Fixe une version précise du boilerplate
pnpm dlx @lonestone/boilerstone-cli@1.2.0 init mon-projet

L’option --apps retire les fronts inutiles, ainsi que les paquets partagés dont aucune application restante ne se sert.

Les mises à jour rejouées plutôt que fusionnées

Le boilerplate a son propre mécanisme de mise à jour. Chaque version est livrée avec des « intentions de migration » : de courts fichiers Markdown qui décrivent le changement, sa raison et la façon de savoir si le projet est concerné. La commande pnpm boilerplate upgrade prépare une branche dédiée sans toucher au code de l’application. Un développeur, éventuellement aidé d’un agent IA qu’il supervise, applique ou écarte les intentions une par une. La version 1.3.0, publiée le 13 octobre 2026, a par exemple remplacé le code d’intégration de Better Auth dans NestJS par un paquet dédié et fait passer l’API sur Express 5. Un projet existant récupère ces changements sans fusionner un diff qui ne correspond plus à son code.

La règle des 80 %

Une fonctionnalité n’entre dans le boilerplate que si 80 % des projets de Lonestone s’en servent. Les autres fonctionnalités deviennent des guides pas à pas dans la documentation. Les organisations, les équipes et l’administration des comptes s’activent ainsi au cas par cas, parce qu’un outil interne à une seule entreprise n’en a pas besoin. Chaque brique du socle a aussi une procédure de suppression documentée. Les exemples (un système d’articles et de commentaires, un chat IA) sont rangés dans des dossiers séparés, qu’on retire en cinq étapes.

L’IA déjà câblée

Le module IA de l’API utilise le Vercel AI SDK pour appeler les modèles de plusieurs fournisseurs (OpenAI, Anthropic, Google, Mistral), avec des sorties structurées validées par Zod, des outils que le modèle peut appeler, le streaming et les outils MCP. Langfuse gère les prompts et leurs versions. OpenTelemetry trace chaque appel à la fois dans Langfuse et dans Sentry. Une fonctionnalité IA s’écrit donc comme n’importe quel service :

import { z } from 'zod'

const ticketSchema = z.object({
  categorie: z.enum(['facturation', 'bug', 'question']),
  urgence: z.number().min(1).max(5),
})

const { result } = await this.aiService.generateObject({
  prompt: `Classe ce ticket de support : ${ticket.contenu}`,
  schema: ticketSchema,
  options: {
    telemetry: { traceName: 'support.classement', spanName: 'ai.classer-ticket' },
  },
})
// result est typé : { categorie: 'facturation' | 'bug' | 'question', urgence: number }

Le choix des catégories et ce que l’application fait du résultat restent du code métier. Le boilerplate fournit l’appel au modèle, la validation et la trace qui aidera à comprendre une mauvaise réponse en production.

La logique métier, écrite pour chaque client

La facturation, les règles d’accès propres à un produit, la logique de marketplace, les workflows CRM et le tunnel de paiement restent hors du boilerplate, par choix : ces briques changent d’un client à l’autre. Les ingénieurs de Lonestone, qui ont pour la plupart entre 10 et 25 ans d’expérience, les écrivent pour chaque produit, avec des outils d’IA pour la partie répétitive.

Boilerplate, template ou from scratch : choisir selon votre contexte

Quatre questions suffisent à trancher dans la plupart des cas.

• La stack du kit est-elle celle que votre équipe maîtrise ? Un boilerplate dans une stack inconnue fait perdre plus de temps qu’il n’en fait gagner, parce que l’équipe apprend le framework et le kit en même temps.
• Votre produit ressemble-t-il à ce que le kit suppose ? Un abonnement mensuel vendu à des indépendants correspond aux kits payants du marché. Un logiciel B2B avec des rôles métier, des intégrations et un hébergement imposé par les clients part mieux d’un socle technique seul.
• Qui maintiendra le code dans deux ans ? Si c’est votre équipe, elle doit pouvoir lire et faire évoluer chaque brique du kit. Quand l’équipe qui livre le produit maintient aussi le socle, elle en connaît déjà tout le code.
• Le produit doit-il d’abord prouver qu’il intéresse quelqu’un ? Pour tester une idée en quelques semaines, un template d’interface ou un MVP réduit au parcours principal suffit souvent. Le choix du socle vient après.

graph TD
    A[Nouveau projet SaaS] --> B{L’équipe maîtrise-t-elle la stack du kit ?}
    B -- Non --> C[Choisir un kit dans la stack de l’équipe, ou partir from scratch]
    B -- Oui --> D{Faut-il d’abord tester l’idée ?}
    D -- Oui --> E[Template d’interface ou MVP réduit au parcours principal]
    D -- Non --> F{Le modèle de prix et les rôles sont-ils standards ?}
    F -- Oui --> G[Starter kit avec facturation incluse]
    F -- Non --> H[Socle technique seul, logique métier écrite pour le produit]

Le développement from scratch reste pertinent quand l’architecture sort vraiment du commun (temps réel massif, calcul intensif, contraintes de certification) ou quand l’équipe a déjà son propre socle. Dans les autres cas, l’équipe qui part de zéro réécrit l’authentification et le déploiement, au risque d’y laisser des failles qu’un socle éprouvé a déjà corrigées.

Lancer votre SaaS sur un socle solide

Un boilerplate fait gagner les premières semaines d’un projet SaaS. La suite dépend des choix faits pendant ces semaines : le découpage multi-tenant, le modèle de droits, la façon dont les mises à jour de sécurité arriveront dans le code.

Lonestone a travaillé pour plus de 200 clients depuis 2014 et démarre ses projets web sur son boilerplate open source. Une équipe senior de Lonestone peut développer votre produit en sprints de deux semaines, du MVP à la V1. Si vous avez déjà démarré sur un kit et voulez savoir s’il tiendra, un audit applicatif passe en revue le code, les dépendances et la sécurité. Vous êtes éditeur logiciel ou startup et voulez créer votre SaaS ? Contactez-nous pour en parler.