Launchbase — template monorepo de production pour SaaS

Chaque nouveau produit recommence par les mêmes semaines de travail : authentification, gestion des utilisateurs, rôles, back-office, facturation, pages légales, CI. Launchbase les traite une fois, proprement, pour que le premier jour d'un projet serve à écrire ce qui le distingue.

Ce que fait le template

• Trois applications dans un monorepo pnpm et Turborepo : un site public Next.js (accueil, tarifs, blog, contact, liste d'attente, espace connecté), un back-office Next.js réservé aux rôles ADMIN et SUPER_ADMIN, et une API NestJS sur Fastify.
• Authentification : mots de passe hachés en Argon2id, jeton d'accès court, rotation du jeton de rafraîchissement dans une transaction, cookies httpOnly, limitation de débit sur les routes sensibles, réinitialisation de mot de passe par jeton haché.
• Utilisateurs et RBAC : CRUD avec suppression logique, filtres par rôle et statut, avatar, suspension. Les rôles sont vérifiés dans le routage des fronts et par des guards côté API, qui reste l'autorité finale.
• Quinze modules activables depuis le back-office, chacun avec son schéma de configuration : Stripe (abonnements, portail client, webhooks), blog, liste d'attente, parrainage, formulaire de contact, clés d'API, feature flags, webhooks sortants avec journal de livraison, onboarding, notifications, analytique, journal d'audit.
• Design system partagé : un paquet @repo/ui basé sur shadcn/ui, Radix et Tailwind 4, avec thème clair et sombre, utilisé par les deux fronts sans duplication.

Stack et architecture

• Next.js, React 19, NestJS 11, Prisma 6 sur PostgreSQL, Redis, Zod pour la validation partagée, Biome pour le lint.
• Paquets internes : database, validation, env (variables validées au démarrage, échec immédiat si elles manquent), logger (logs structurés avec champs sensibles masqués), modules (registre des modules), ui.
• Côté API, l'authentification est organisée en CQRS avec une couche domaine, des ports et des adaptateurs ; chaque requête porte un identifiant de corrélation repris dans les logs et dans le format d'erreur uniforme. Un point de santé vérifie la base et Redis, et Swagger documente l'API hors production.
• Docker Compose pour les dépendances et les images, et un workflow GitHub Actions : lint, typecheck, validation Prisma, tests sur base réelle, build et audit de sécurité.

Ce qui a été difficile

La bascule vers Prisma 7 a coûté une série de correctifs : l'adaptateur pg imposé, des erreurs de démarrage en cascade après la montée de NestJS 11, puis un retour à Prisma 6 pour retrouver une base stable. L'historique montre aussi un long travail sur le design system : rayons de bordure non résolus par Tailwind, menus déroulants au fond transparent, classes du paquet UI absentes du CSS généré tant que la directive @source n'était pas ajoutée. Le résultat est un paquet UI dont les défauts ont été corrigés une seule fois, à la source.

État du projet

Le dépôt sert de point de départ interne. Les migrations Prisma ne couvrent pas encore tous les modèles récents (clés d'API, feature flags, blog, webhooks, notifications, parrainage) et la couverture de tests reste mince : un seul fichier de tests, sur le service d'authentification. Ces deux points sont les prochains chantiers avant une publication.