Combien coûte un SaaS ?

Le prix d'un SaaS n'est pas un prix de lancement

Un site vitrine se construit, se paye, et vit sa vie. Un SaaS non : c'est un produit qui tourne, qui encaisse, qui stocke des données clients et qui doit continuer à fonctionner pendant que vous dormez. Le devis de départ ne dit donc que la moitié de l'histoire. L'autre moitié est un coût mensuel, faible au lancement, qui grandit avec vos clients.

C'est la première chose à intégrer avant de comparer deux devis : celui qui annonce le montant le plus bas a parfois simplement repoussé des postes que vous payerez plus tard, et plus cher.

Où se situe le budget de départ

Les paliers que nous publions pour un produit de départ donnent le bon repère, et nous les détaillons dans combien coûte un MVP : un périmètre très resserré démarre à partir de 1 500 à 4 000 €, un produit standard avec plusieurs parcours et un back-office léger se situe entre 4 000 et 10 000 €, et au-delà de 10 000 € on parle de logique métier riche, de temps réel ou de multi-plateforme.

Un SaaS atteint le palier du haut plus vite que les autres produits, pour une raison simple : il a presque toujours besoin des comptes, des rôles et de la facturation avant même d'avoir une seule fonctionnalité intéressante. C'est le ticket d'entrée, pas l'ambition.

Les postes qui font le prix, dans l'ordre

À idée égale, le devis se joue sur ces cinq points bien plus que sur la fonctionnalité dont vous parlez à vos proches.

• Les comptes, les équipes et les rôles. Un utilisateur seul coûte peu. Des équipes, des invitations, des droits différents par rôle et une séparation stricte des données entre clients : c'est un chantier à part entière, et il conditionne tout le reste.
• La facturation récurrente. Ce n'est pas « brancher Stripe ». Ce sont les essais gratuits, les changements de plan en cours de mois, les impayés, les remboursements, les accès qui doivent se couper au bon moment. Les cas limites sont nombreux et ils touchent votre argent.
• Le back-office. Vous aurez besoin de voir les comptes, de dépanner un client, de corriger une donnée. Sans outil d'administration, chaque demande de support devient une intervention technique payante.
• Les intégrations et le temps réel. Connexion à des outils existants, imports de données, notifications, collaboration à plusieurs sur le même écran. Chaque brique ajoute du développement et surtout du test.
• La donnée. Reprise de l'existant, exports, historique des modifications, obligations RGPD. Rarement dans le premier devis, presque toujours dans la première facture complémentaire.

La ligne que personne ne chiffre

Une fois en ligne, un SaaS consomme en continu, et ces postes sont récurrents par nature.

• L'hébergement et la base de données, proportionnels à l'usage.
• Les services tiers : envoi d'e-mails, stockage de fichiers, suivi des erreurs.
• La commission du prestataire de paiement, prélevée sur chaque encaissement.
• La maintenance : mises à jour de sécurité, correctifs, montées de version.
• Le support, qui est du temps humain dès le premier client.

Pris isolément, rien d'effrayant. Ensemble, cela justifie de raisonner en coût annuel plutôt qu'en prix de livraison, et de vérifier que votre tarif d'abonnement le couvre avec de la marge.

Comment payer moins sans livrer moins

Le meilleur levier n'est pas de négocier le taux journalier : c'est de repousser tout ce qui n'est pas nécessaire au premier client payant. Trois décisions font l'essentiel de l'économie.

D'abord, encaisser simplement au début. Un lien de paiement et une facture manuelle vous emmènent plus loin qu'on ne le croit, et vous évitent de construire une machine à facturer avant d'avoir des abonnés. Ensuite, remplacer le back-office sur mesure par un outil existant tant que les volumes sont faibles. Enfin, réduire le nombre de rôles à ce que vos premiers clients utilisent vraiment, quitte à en ajouter quand ils le demandent.

Cette discipline est exactement celle de la création de MVP : valider d'abord, empiler ensuite. Elle s'applique aussi bien à une plateforme qu'à une application.

Un prix ferme, et un périmètre écrit

Pour une première version, préférez un forfait à prix ferme annoncé après un appel de cadrage plutôt qu'une régie ouverte. Vous savez ce que vous dépensez, le périmètre est écrit avant la première ligne de code, et les arbitrages se font au bon moment, c'est-à-dire avant de développer. C'est la façon dont nous travaillons sur le développement SaaS : un appel, un périmètre, un prix, puis on construit.