Comment choisir une stack SaaS en 2026 : monorepo, Next.js, NestJS, MongoDB

La question « quelle stack dois-je utiliser » est devenue plus difficile, pas plus facile, parce que la réponse dépend de ce que votre équipe sait déjà et de ce que votre acheteur est prêt à intégrer. Il n'y a pas de stack objectivement meilleure. Il y a une stack qui est la meilleure pour votre combinaison spécifique d'équipe, d'acheteur et de timeline.

Monorepo vs polyrepo

Deux ans à faire tourner un monorepo pnpm chez 2Run donnent une réponse claire pour notre cas : monorepo.

Les gains sont concrets : types TypeScript partagés entre le backend NestJS et le frontend Next.js (fini le devinette de « l'API retourne X »), un pipeline CI, un jeu de règles linting, un endroit pour appliquer une baseline de sécurité sur les deux apps.

Les pertes sont aussi concrètes : dérive de config partagée, une CI qui construit les deux apps à chaque merge même si une seule a changé, une mise en place d'outillage qui coûte une semaine à atterrir correctement. Pour une équipe d'un ou deux ingénieurs, un polyrepo est plus simple.

La règle de décision :

• Monorepo si vous avez deux ou plusieurs apps frontend/backend qui partagent des types, partagent l'auth et partagent une cadence de release.
• Polyrepo si vous avez une app et une API, ou si vous avez plusieurs apps qui ne partagent rien. Les coûts de mise en place d'un monorepo sont réels et vous ne les récupérez pas à cette échelle.

Next.js (App Router) — quand il s'adapte

Next.js est un choix standard pour nos webapps B2B pour trois raisons :

• Routage i18n intégré. Le pattern de segments (routes)/[locale] est exactement ce dont nous avons besoin pour un produit en cinq langues. L'histoire middleware pour la détection de locale et les rewrites est mature.
• Server components pour les surfaces marketing. Une landing page qui combine du contenu MDX, des données CMS-driven et un petit widget interactif est un fichier avec trois composants. Les patterns React standard nécessitent plus de colle.
• Une baseline de sécurité qui est largement correcte out-of-the-box. HSTS, frameguard, referrer-policy et standards CSP sont réglables via middleware et config headers. Nous écrivons encore un middleware durci (voir l'article security-hardening), mais nous ne construisons pas à partir de zéro.

Les coûts : taille de bundle, la frontière serveur/client de l'App Router est une vraie courbe d'apprentissage, et la sémantique de cache de données dans Next 16 demande une gestion intentionnelle pour éviter les stale reads.

NestJS — quand vous voulez de la structure

NestJS n'est pas le framework backend le plus simple. C'est dans notre expérience celui qui scale le mieux. La raison : la structure module/provider/controller vous force tôt à définir des bounded contexts, l'injection de dépendances et un cycle de vie de requête. Le pattern se transfère dans n'importe quel framework que vous utiliserez ensuite.

Trois gains concrets :

• L'auth est un module, pas une route. Remplacez le module auth sans toucher aux routes qui le consomment.
• Guards et interceptors sont first-class. Le contrôle d'accès basé sur les rôles, le rate limiting et le logging de requête composent tous proprement.
• La génération Swagger est une ligne de config. La doc API reste en lockstep avec le code.

Les coûts : le nombre de fichiers est plus élevé qu'Express, la courbe d'apprentissage est plus raide que Fastify, et la metadata basée sur les décorateurs a des arêtes vives autour des types génériques.

MongoDB — pour les documents, pas pour les jointures

MongoDB est le bon choix quand le modèle de données est naturellement document-shaped : articles de blog, pages de contenu avec métadonnées mixtes, contenu généré par l'utilisateur avec schéma flexible, données catalogue avec des attributs qui varient par catégorie.

MongoDB est le mauvais choix quand le modèle de données est fortement relationnel : un ledger financier, un warehouse analytics multi-tenant, un système de permissions avec des arêtes many-to-many. Nous utilisons Postgres pour ceux-là.

Le piège : chaque équipe commence par MongoDB et réalise à mi-chemin qu'elle veut des jointures. Soyez honnête sur le modèle de données avant de vous engager. Si vous ne savez pas encore, commencez par Postgres — il est plus difficile de migrer depuis MongoDB que depuis Postgres plus tard.

Ce que nous choisissons pour un SaaS B2B en 2026

Pour un SaaS B2B avec support de cinq langues, surfaces produit basées navigateur et intégration aux régimes de conformité UE :

• Monorepo pnpm avec apps/web et apps/backend.
• Next.js (App Router) côté frontend avec next-intl pour les locales.
• NestJS côté backend avec des modules auth, content et translation modulaires.
• MongoDB pour le contenu, les jobs et les données product-shaped, Postgres pour la facturation et le ledger.
• Redis pour le cache, pub/sub et le state de rate-limit.
• MinIO (compatible S3) pour le stockage de fichiers avec un endpoint proxy qui n'expose jamais les URLs de bucket.

Ce n'est pas la seule combinaison valide. C'en est une que nous avons livrée deux fois, payée deux fois, et sur laquelle nous remettrions.