Création de SaaS et développement de produit
La création d’un SaaS ne se résume pas à une application avec une page de tarifs. C’est un produit qui doit isoler ses clients, encaisser tous les mois, se laisser administrer et rester debout pendant que vous dormez. Ce sont ces quatre points qui décident, pas la page d’accueil.
- Nature
- Produit multi-tenant vendu par abonnement
- Périmètre
- Produit · architecture · facturation · exploitation
- Socle
- TypeScript · PostgreSQL · API documentée
- Preuve
- Stellary, notre propre SaaS en production
Ce qu’un SaaS demande de plus qu’une application
Le développement SaaS se distingue sur un point : une application sert un client, un SaaS en sert des centaines, sur la même base de code, sans qu’aucun ne voie les données d’un autre. Cette contrainte-là traverse tout le produit : le modèle de données, les requêtes, les sauvegardes, les journaux, les exports. Elle se décide au premier jour et se rattrape très mal.
Vient ensuite l’argent. Essais, changements de formule au prorata, échecs de prélèvement, relances, remboursements, TVA selon le pays du client : la facturation d’abonnement est un domaine métier à part entière, pas un bouton de paiement.
Puis l’exploitation. Un SaaS se met à jour pour tout le monde en même temps, sans interruption, avec des migrations de base qui doivent passer sur des données réelles. C’est ce qui distingue un produit d’une application métier déployée pour un seul client.
Ce qu’il faut construire, et dans cet ordre
L’ordre compte : chacune de ces briques est bien plus coûteuse à ajouter après coup qu’à poser au départ.
- 01
Le cloisonnement
Une organisation, ses membres, ses données. L’isolation se pose dans le modèle et se vérifie par des tests : une requête qui oublie le filtre de tenant est la faille la plus banale et la plus grave d’un SaaS.
- 02
Les abonnements
Formules, essais, prorata, changements en cours de période, impayés, relances, remboursements. Le prestataire de paiement encaisse ; c’est votre produit qui doit savoir ce que chaque client a le droit de faire à chaque instant.
- 03
Les rôles
Propriétaire, administrateur, membre, invité. Des permissions explicites plutôt qu’une accumulation de conditions dans les écrans — c’est ce qui permet d’ajouter un rôle plus tard sans tout relire.
- 04
L’arrivée
Inscription, création de l’espace, invitation de l’équipe, premier résultat utile. Le taux d’abandon d’un SaaS se joue dans les dix premières minutes, bien avant la fin de l’essai.
- 05
L’administration
Voir les comptes, dépanner un client, prolonger un essai, rembourser, consulter les journaux. Sans cet outil, chaque demande du support devient une requête SQL écrite à la main en production.
- 06
L’observabilité
Erreurs remontées, métriques d’usage, alertes sur ce qui mérite un réveil. Un produit que des clients paient ne peut pas attendre qu’un utilisateur signale la panne.
Du premier utilisateur au produit qui tient
- 01
Cadrer ce qui se vend
Quel problème justifie un abonnement récurrent, pour qui, et à quel prix. Un SaaS sans réponse claire à ces trois questions devient une application sur mesure déguisée, avec le coût d’un produit et le revenu d’une prestation.
- 02
Construire le noyau, pas le catalogue
Une première version qui fait une chose entièrement, avec le cloisonnement et la facturation en place. Un produit à demi multi-tenant se réécrit ; un produit à une seule fonctionnalité s’étend.
- 03
Confronter à de vrais clients
Les premiers utilisateurs révèlent ce qu’aucune spécification n’avait prévu — souvent une hypothèse de départ sur leur organisation interne. Mieux vaut le découvrir à dix comptes qu’à mille.
- 04
Industrialiser
Déploiements sans interruption, migrations rejouables, sauvegardes restaurées pour de vrai, surveillance et astreinte. C’est le moment où le produit cesse de dépendre de la personne qui l’a écrit.
Ce que vous recevez
- Un produit multi-tenant dont l’isolation est testée, pas seulement affirmée.
- La chaîne d’abonnement complète : formules, essais, prorata, impayés, factures.
- Une administration qui permet de dépanner un client sans toucher à la base.
- Un déploiement automatisé, des migrations rejouables et des sauvegardes vérifiées.
- Le code, la base et la documentation : le produit est le vôtre, y compris si vous changez de prestataire.
Nous opérons nos propres SaaS
Stellary · voir l’étude de casLe studio ne fait pas que vendre du développement SaaS : il en exploite. Stellary est une plateforme multi-tenant avec organisations, workspaces, permissions, facturation, administration et supervision — construite, déployée et maintenue ici.
Ça change deux choses dans une mission. D’abord les arbitrages : nous avons déjà payé le prix des mauvais, sur nos propres produits. Ensuite l’honnêteté sur les délais — quand on exploite ce qu’on vend, on sait ce que coûte réellement la deuxième année.
Le même socle sert nos clients : Créarègle porte du paiement récurrent, des rôles distincts et une infrastructure sauvegardée et supervisée.
Ce qu’on nous demande le plus souvent
Les réponses que nous donnons de toute façon au premier échange.
Combien coûte la création d’un SaaS ?
Une première version vendable — cloisonnement, abonnements et une fonctionnalité aboutie — se situe généralement au-delà d’une application métier classique, parce que la facturation et l’isolation sont du travail incompressible. Le budget se cadre après un premier échange sur ce que vous vendez et à qui.
Faut-il commencer par un MVP ?
Oui, à condition que « minimum » porte sur le périmètre fonctionnel et jamais sur les fondations. Un produit avec une seule fonctionnalité mais un cloisonnement correct s’étend ; un produit riche mal cloisonné se réécrit.
Une base de données par client, ou une base commune ?
Une base commune avec un cloisonnement strict couvre la grande majorité des cas et coûte beaucoup moins cher à exploiter. La base par client se justifie sur des exigences réglementaires ou des clients très volumineux — c’est une décision d’architecture, pas une préférence.
Qui gère les paiements et la TVA ?
Le prestataire de paiement encaisse et gère la TVA selon le pays du client. Votre produit, lui, doit connaître à chaque instant l’état de l’abonnement et les droits qui en découlent — c’est cette partie que nous construisons.
Que se passe-t-il si nous internalisons l’équipe plus tard ?
C’est prévu dès le départ : code versionné et livré, base standard, API documentée, déploiement automatisé et procédures écrites. Un produit qu’on ne peut pas transmettre est un produit qui vous tient en otage.
Un produit SaaS à lancer ?
Dites-nous ce que vous vendez et à qui. Nous cadrons le périmètre de la première version.
Parler de votre projet Réponse sous deux jours ouvrés · contact@anym.fr