Quand on commence à construire un SaaS, la question de la stack technique arrive très vite. Tu lis des posts Linkedin, tu regardes ce que font les autres et tu te retrouves avec dix options sur la table sans savoir laquelle choisir.
La stack technique SaaS que tu adoptes au départ a des conséquences concrètes : vitesse de développement, facilité de recrutement quand tu agrandis l'équipe, coût d'hébergement, dette technique accumulée au fil des itérations. C'est pas un détail.
Voici comment on aborde ce sujet chez Ellebay depuis Toulon et pourquoi on revient souvent aux mêmes technos sur nos projets SaaS.
Pourquoi la cohérence de stack est sous-estimée par les fondateurs ?
Beaucoup de fondateurs pensent que le choix de la stack est une décision technique réservée aux devs. Erreur, c'est une décision produit et business.
Une stack trop fragmentée (un bout en Python, un autre en PHP, un micro-service Node.js par-ci) ralentit tout le monde. Pas forcément à cause de la techno en elle-même, mais parce que chaque jonction entre deux systèmes différents est un endroit où les bugs se planquent.
À l'inverse, une stack cohérente et bien choisie te permet de :
- itérer rapidement sur les fonctionnalités
- embarquer un nouveau dev sans trois semaines d'onboarding
- déployer sans peur le vendredi après-midi (bon, presque)
En 2026, l'écosystème JavaScript/TypeScript a clairement gagné la bataille du SaaS fullstack. Plusieurs raisons concrètes derrière : tu partages tes types entre frontend et backend, le tooling est mature, la communauté est massive.
Quelle stack technique SaaS choisir en 2026 ?
Voici les technos qu'on retient le plus souvent sur nos projets SaaS custom, avec la raison derrière chaque choix.
Next.js App Router comme socle fullstack
Next.js avec l'App Router est devenu le standard de facto pour les SaaS en 2026. Ce n'est plus une question de débat.
Ce qui le rend pertinent pour un premier produit : tu as le rendu serveur, les API routes et le frontend dans le même projet. Pas besoin de gérer un backend séparé dès le départ. Quand ton SaaS grandit et que tu dois découpler certaines parties, tu peux le faire. Mais au MVP, c'est du temps gagné.
React reste la base côté composants. La courbe d'apprentissage est bien documentée, les patterns sont connus et si tu dois recruter ou externaliser plus tard, c'est beaucoup plus simple que si tu avais parié sur un framework confidentiel.
TypeScript est non-négociable. Sur un projet qui va durer des mois ou des années, les types t'évitent une catégorie entière de bugs. Et avec les LLMs qui génèrent de plus en plus de code en 2026, avoir un typage fort te protège des hallucinations silencieuses.
PostgreSQL via Neon pour la base de données
PostgreSQL est la base de données relationnelle qui fait consensus dans l'écosystème SaaS. Elle est robuste, elle gère les transactions, les relations complexes et les requêtes analytiques sans broncher.
On utilise Neon comme provider. C'est PostgreSQL serverless : tu paies ce que tu consommes, la base s'adapte à la charge automatiquement et le cold start est devenu très acceptable pour la grande majorité des usages. Pour un MVP, ne pas payer une instance dédiée 24h/24 pour 12 utilisateurs actifs, c'est un vrai avantage.
Pourquoi pas une base NoSQL comme MongoDB ? Parce que la grande majorité des SaaS B2B ont des données structurées avec des relations. Un utilisateur appartient à une organisation, une organisation a plusieurs abonnements, un abonnement a plusieurs factures. PostgreSQL gère ça nativement. Passer à une base documents pour ce type de modèle, c'est souvent se créer des problèmes artificiels.
Drizzle ORM pour rester proche du SQL
Drizzle est notre ORM de choix. Il est typé, léger et te laisse écrire du SQL quand tu en as besoin sans sortir du contexte TypeScript.
La différence avec Prisma (le concurrent principal) : Drizzle est plus explicite. Tu vois ce que tu interroges. Moins de magie, plus de contrôle. Sur des projets avec des requêtes complexes ou des contraintes de performance, c'est une vraie différence.
La migration de schema se fait proprement et l'intégration avec Neon est native. Pas de configuration ésotérique.
Auth.js pour l'authentification
L'auth est l'endroit où beaucoup de fondateurs perdent du temps au mauvais moment. Construire son propre système d'authentification de zéro en 2026, c'est risqué et inutile.
Auth.js (anciennement NextAuth) gère OAuth, magic links, credentials, sessions JWT ou base de données. C'est open source, bien maintenu et compatible nativement avec Next.js.
On ne délègue pas l'auth à un service tiers payant comme Clerk ou Auth0 par défaut. Pas parce que ces services sont mauvais, mais parce qu'Auth.js te donne le contrôle total sur tes données utilisateurs et n'ajoute pas de coût récurrent dès le MVP. Si tu as besoin d'une interface d'admin utilisateur clé en main, Clerk a du sens. Mais on pose toujours la question avant d'ajouter une dépendance externe.
Vercel pour l'hébergement et le déploiement
Vercel est l'hébergeur de référence pour les projets Next.js. Le déploiement est automatisé depuis GitHub, les previews par branche sont instantanées et les Edge Functions permettent de distribuer le code près des utilisateurs.
Pour un fondateur sans équipe DevOps, c'est exactement ce qu'il faut. Tu ne passes pas tes vendredis à débugger une config Nginx. Tu pushe, ça déploie, tu dors.
Le plan Pro Vercel commence à 20 $/mois. Pour un SaaS en production avec quelques centaines d'utilisateurs, le coût reste très raisonnable.
Comment cette stack tient à l'échelle ?
C'est la vraie question. Choisir une stack pour un MVP de 50 utilisateurs, c'est simple. La question, c'est : est-ce que ça tient quand tu passes à 5 000 ?
Réponse courte : oui, pour la grande majorité des SaaS B2B.
Neon monte en charge verticalement et horizontalement. Next.js sur Vercel supporte des millions de requêtes par mois sans reconfiguration. PostgreSQL gère des datasets bien au-delà de ce qu'un SaaS atteint dans ses premières années.
Les vrais problèmes de montée en charge arrivent quand tu as des jobs background complexes, du temps réel à forte fréquence, ou des volumes de données qui se comptent en dizaines de millions de lignes par jour. À ce stade, tu ajoutes des briques spécifiques comme une queue de jobs ou un cache Redis, plutôt que de changer de stack entièrement.
L'idée, c'est de ne pas sur-architécter au démarrage. Un fondateur qui lance un SaaS de gestion de plannings pour artisans du Var n'a pas besoin d'une architecture microservices. Il a besoin que son produit fonctionne, que les bugs soient faciles à tracer et que son dev puisse avancer vite.
Si tu veux comprendre comment on choisit aussi les bons outils gratuits pour gérer un site ou un SaaS au quotidien, on a publié un article dédié.
Ce qu'on ne fait pas et pourquoi
On ne fait pas de no-code pour les SaaS. Pas de Bubble, pas de WeWeb, pas de Glide.
Ça ne veut pas dire que le no-code est inutile. Si tu veux valider une idée en deux semaines avec un prototype cliquable, un outil no-code peut avoir du sens. Mais dès que tu as des règles métier complexes ou une logique d'authentification fine, sans parler des intégrations API sur-mesure, le no-code montre ses limites très vite.
La dette technique du no-code est réelle et souvent invisible au départ. Tu te retrouves bloqué à 80% des fonctionnalités que tu veux construire et migrer vers du code custom à ce stade coûte plus cher que de l'avoir fait dès le début.
C'est notre point de vue honnête. Si tu es au stade "est-ce que mon idée intéresse quelqu'un ?", un prototype no-code peut suffire. Si tu es au stade "je veux construire un vrai produit que je vais commercialiser", le custom s'impose.
Pour creuser ce comparatif, on a publié un article complet sur le choix entre no-code et développement custom pour un MVP SaaS.
Combien ça coûte de construire un SaaS avec cette stack ?
Chez Ellebay, on travaille sur des SaaS custom depuis Toulon avec des fondateurs partout en France.
Un MVP SaaS minimal (fonctionnalité core + auth + déploiement) démarre à 3 500 € HT. Une V1 complète avec dashboard, gestion des utilisateurs et fonctionnalités métier se situe entre 5 000 et 10 000 € HT. Pour des intégrations avancées comme un paiement Stripe, des API tierces ou des webhooks de notifications, on monte jusqu'à 10 000 à 20 000 € HT.
Ce n'est pas un forfait au sens "tu prends ce qu'on te donne". On cadre le périmètre ensemble, on priorise les fonctionnalités et on livre de façon itérative.
Si tu veux d'abord poser les bases côté site web avant de te lancer dans le SaaS, notre article créer un site web professionnel couvre les fondamentaux à connaître avant de démarrer un projet.
Si tu as un projet SaaS en tête et que tu veux en parler, un appel découverte de 30 min offert est disponible. Pas de présentation PowerPoint, pas de promesse vague. On regarde ton cas, on t'explique ce qui est faisable et à quel coût.
Tu peux aussi consulter notre page dédiée au développement SaaS pour avoir une vue d'ensemble de ce qu'on fait.
Marion, co-fondatrice d'Ellebay Digital, accompagne les fondateurs de startups dans le développement de leur SaaS depuis Toulon. Spécialisée Next.js, Drizzle et architectures serverless, elle conçoit des produits qui tiennent dans la durée sans dette technique inutile.
