Comment construit-on un produit SaaS en 2026 ?
Cela dépend du produit, mais la voie fiable part du plus petit produit qu'un client paierait pour utiliser, puis ne construisez que l'infrastructure sans laquelle il ne fonctionne pas : authentification, modèle de données conscient du tenant, facturation à webhooks idempotents, e-mails transactionnels et tâches de fond. En 2026, la plupart des équipes sautent des mois de plomberie indifférenciée en partant d'un boilerplate de production comme supastack, qui livre auth, espaces d'organisation, huit prestataires de paiement, contrôles de coûts IA et clients web, mobile et desktop dans une seule base testée. Construisez vous-même vos fonctionnalités différenciantes ; achetez ou réutilisez la plomberie.
Étape 1 : cadrer le plus petit produit vendable
Tout SaaS raté partage la même première erreur : construire pour le produit qu'il pourrait devenir plutôt que pour le client qu'il pourrait gagner ce mois-ci. Écrivez une phrase — « {customer} paie {price} pour {outcome} » — et supprimez toute fonctionnalité qui ne délivre pas ce résultat. La page de connexion, la grille tarifaire, le sélecteur d'espace ne sont pas le produit ; ce sont le prix d'entrée.
Décidez tôt des surfaces dont le produit a vraiment besoin : une app web suffit à la plupart des outils ; n'ajoutez le mobile que si le travail se fait loin d'un bureau, et le desktop s'il touche aux fichiers ou au système. Choisir les surfaces maintenant façonne toute l'architecture — greffer un second client sur une base à une seule app est le changement le plus coûteux qu'un jeune produit fasse.
- Écrivez la phrase « {customer} / {price} / {outcome} » avant toute ligne de code.
- Listez les trois écrans qu'un utilisateur payant ouvre chaque semaine ; c'est le MVP.
- Choisissez les surfaces délibérément : web seul, ou web plus mobile/desktop.
Étape 2 : authentification et comptes
La connexion représente quinze pour cent de l'auth. Les quatre-vingt-cinq autres sont la révocation de sessions, la liaison de comptes OAuth, la double authentification et les passkeys, la réinitialisation de mot de passe, l'impersonation admin et les flux d'e-mails autour de tout cela. Choisissez une bibliothèque qui couvre tout — Better Auth ou Auth.js — plutôt que de bricoler la crypto vous-même, et gardez la table utilisateurs dans votre propre base pour que la tarification par MAU ne devienne jamais une prise d'otage.
Si un client sera une entreprise, modélisez les organisations dès maintenant : espaces personnels et d'équipe, invitations et rôles owner/admin/member. Visser la multi-tenance plus tard, c'est migrer chaque requête. La liste complète de ce qui vit après l'écran de connexion est dans l'authentification au-delà du formulaire de connexion.
Étape 3 : un modèle de données conscient du tenant
Votre schéma est la mémoire du produit. Utilisez un ORM proche du SQL — Drizzle ou Prisma — et donnez à chaque ligne du tenant un workspace_id dès le premier jour. Appliquez la portée deux fois : dans le code applicatif et dans la sécurité au niveau ligne de Postgres, pour qu'une clause WHERE oubliée dégénère en « accès refusé » plutôt qu'en fuite de données.
Le motif complet — clés à portée espace, politiques RLS et les tests qui les prouvent — est couvert dans Postgres RLS et auth d'espace de travail. Pour le choix de l'ORM lui-même, voir Prisma vs Drizzle pour le SaaS.
Étape 4 : une facturation qui survit au réseau
La facturation est un problème de systèmes distribués déguisé en page de prix. Le prestataire retente les webhooks ; votre gestionnaire doit être idempotent : stocker l'événement, dédupliquer sur son ID, puis honorer. Modélisez une seule primitive — un droit (entitlement) — et faites que Stripe, Lemon Squeezy, Polar, Paddle ou RevenueCat s'y résolvent tous ; un second prestataire devient un changement de config, pas une réécriture.
Lisez webhooks de facturation idempotents pour le motif du registre, et prestataires de paiement SaaS comparés avant de choisir entre un Merchant of Record et Stripe.
Étape 5 : e-mail, tâches de fond et observabilité
L'e-mail transactionnel fait partie de l'auth et de la facturation ; la délivrabilité (SPF, DKIM, DMARC) n'est pas optionnelle. Les tâches de fond exigent une file qui retente : provisionnement, génération de rapports, appels IA et tout ce qu'un portable fermé ne doit pas tuer. Et on n'opère pas ce qu'on ne voit pas : logs structurés, suivi d'erreurs et enregistrements d'audit relèvent de la première semaine, pas de l'après-premier-incident.
Étape 6 : des fonctionnalités IA sous contrôle des coûts
Ajouter une boîte de chat est facile ; la rendre soutenable est le vrai problème de design. Routez les appels aux modèles derrière un adaptateur pour garder les fournisseurs interchangeables, laissez les espaces apporter leurs propres clés (chiffrées au repos) et imposez des budgets d'usage par espace adossés à un catalogue de prix : ainsi, le mois intense d'un client lui est facturé à lui, pas à vous.
Le raccourci honnête : construisez le produit, pas la plomberie
Tout ce qui précède est résolu, à répétition. Un boilerplate de production comme supastack livre tout le stack déjà intégré : Better Auth, espaces d'organisation, huit prestataires de facturation web derrière un registre idempotent, e-mails transactionnels, jobs Trigger.dev, routeur IA à budgets BYOK et clients Expo + Tauri partageant les paquets typés de l'app web — vérifié par plus de 144 fichiers de tests.
Le calcul construire-ou-acheter est détaillé dans starter kit ou from scratch ; en résumé, vos clients paient pour les fonctionnalités que vous seul pouvez construire. Sur la voie du boilerplate, la checklist de lancement SaaS couvre la suite.