Créer un SaaS en 2026 : ce que les guides ne vous disent pas (par un développeur qui en a construit un)
Les guides sur la création de SaaS sont presque tous écrits par des agences qui veulent vendre leurs services, ou par des marketeurs qui n’ont jamais touché une ligne de code. Voici ce que j’ai appris en construisant SpringBoot Generator — les vraies difficultés, les bons arbitrages, et ce que je referais différemment.
MVP ou SaaS complet : la décision que personne ne prend bien
La première erreur des porteurs de projet SaaS, c’est de vouloir construire le produit complet dès le départ. La deuxième erreur, c’est de construire un MVP si minimaliste qu’il ne démontre rien à personne.
La vraie question n’est pas « MVP ou SaaS complet ? » — c’est « quelle est la fonctionnalité centrale qui crée de la valeur pour votre premier utilisateur, et tout le reste peut-il attendre ? »
Les offres MVP Starter et SaaS Business.
Les 5 décisions d’architecture qui déterminent le coût à long terme
L’architecture d’un SaaS se décide dans les premières semaines. Ce qu’on construit à ce moment-là, on le porte pendant des années. Voici les cinq décisions qui ont le plus d’impact sur le coût total de possession.
Pour aller plus loin
MVP vs produit complet : comment décider ?
Les 4 signaux pour aider à choisir, FAQ.
Multi-tenant : pourquoi c’est critique et comment le concevoir dès le départ
Le multi-tenant, c’est la capacité d’un SaaS à servir plusieurs clients (tenants) dans la même instance applicative, chacun voyant uniquement ses propres données.
Il existe trois approches principales :
- Base de données partagée, schéma partagé — un champ
tenant_idsur chaque table. Moins coûteux à l’échelle, plus risqué en termes d’isolation des données. Adapté aux SaaS grand public avec peu de sensibilité des données. - Base de données partagée, schéma séparé — un schéma PostgreSQL par client dans la même instance. Bon équilibre entre coût et isolation. Recommandé pour la plupart des SaaS B2B.
- Base de données dédiée par client — isolation totale, coût élevé à l’échelle. Réservé aux clients enterprise avec exigences réglementaires fortes (santé, finance).
J’ai opté pour une approche schéma séparé par tenant avec PostgreSQL. Cela m’a permis d’isoler les données sans multiplier les instances, et d’automatiser la création de schéma à l’onboarding d’un nouveau client. C’est l’approche que je recommande pour les SaaS B2B avec des données sensibles.
Stripe vs alternatives : ce qui change vraiment dans la facturation SaaS
Stripe est devenu le standard de facto pour la facturation SaaS, et à raison. Mais l’intégration va bien au-delà du simple formulaire de paiement.
Ce que Stripe Billing gère pour vous
- Abonnements récurrents avec gestion des échecs de paiement (retry logic)
- Périodes d’essai, coupons, codes promo
- Facturation pro-rata lors des changements de plan
- Portail client pour la gestion des abonnements en libre-service
- Webhooks pour synchroniser l’état des abonnements avec votre base
Ce que Stripe ne fait pas à votre place
- La logique de provisioning — activer/désactiver les fonctionnalités selon le plan souscrit, c’est votre code
- La gestion des impayés côté métier — que faire si un client ne paie pas ? Bloquer l’accès ? Après combien de jours ? Ces règles sont les vôtres
- La conformité fiscale avancée — TVA intracommunautaire, taxe américaine par état, etc.
Ce que j’ai appris en construisant SpringBoot Generator
SpringBoot Generator est un SaaS qui permet de générer des projets Spring Boot préconfigurés avec une stack opinionated : architecture hexagonale, sécurité JWT, multi-tenant, Stripe billing, Docker-compose prêt à l’emploi.
Ce que je n’avais pas anticipé au départ :
- Le temps de l’onboarding UX. La génération technique était prête bien avant que l’expérience d’onboarding soit acceptable. Un utilisateur qui ne comprend pas ce qu’il obtient en 30 secondes repart.
- La documentation. Générer du code est une chose. Générer du code que l’utilisateur peut comprendre, modifier et maintenir en est une autre. La documentation des projets générés représente autant de travail que leur génération.
- Le support utilisateur dès la v1. Les premiers utilisateurs vous remontent des cas limites auxquels vous n’avez pas pensé — et ils le font souvent de manière peu structurée. Prévoir du temps de support dès le lancement.
Les signaux qui indiquent que votre idée de SaaS est viable (ou non)
Le planning réaliste d’un SaaS de A à Z
Je passerais plus de temps en phase de validation avant de toucher au code. Et je mettrais en place la facturation dès la phase 2, pas après. Repousser la monétisation repousse la validation réelle du produit — quelqu’un qui paie donne un feedback bien plus honnête que quelqu’un qui teste gratuitement.
Services
Créer votre SaaS sur mesure.
SaaS sur mesure, SaaS complet, MVP, stack technique, FAQ.
Vous avez un projet SaaS ?
Discutons de l’architecture dès maintenant
Un échange de 30 minutes pour valider votre approche technique avant d’investir dans le développement.