La question « comment créer un SaaS » reçoit presque toujours une réponse technique : un framework, une base de données, un hébergeur. C'est la partie la moins déterminante. Ce qui fixe le coût d'un SaaS et sa date de mise en production, ce sont sept décisions que l'on peut prendre avant d'écrire une ligne de code.
Nous exploitons cinq produits en production. Les sept points qui suivent sont ceux sur lesquels nous nous sommes trompés au moins une fois.
1. Le périmètre de la première version
Un SaaS n'a pas besoin d'être complet pour être utile. Il a besoin d'être utile à quelqu'un de précis, pour une tâche précise, dès la première semaine.
La bonne question n'est pas « que devrait faire le produit ». C'est « qu'est-ce qui, retiré, rend le produit inutilisable ». Tout le reste attend la version suivante. Un cadrage écrit qui liste ce qui n'est pas dans la première version vaut mieux qu'un cahier des charges de quarante pages.
2. Le modèle de données
C'est la décision la plus chère à changer plus tard. Une table mal découpée se paie en migrations, en incohérences et en écrans qui contournent le schéma.
Deux questions suffisent à révéler les erreurs : qu'est-ce qui appartient à qui, et qu'est-ce qui doit rester vrai même en cas de panne au milieu d'une opération. Si la réponse est floue, le schéma n'est pas prêt.
3. Les comptes, les rôles et les droits
Beaucoup de projets traitent l'authentification comme une case à cocher, puis découvrent qu'un client veut inviter son comptable en lecture seule, et qu'une entreprise veut cinq utilisateurs sous une seule facture.
Décider tôt si le produit s'adresse à une personne ou à une organisation change l'ensemble du modèle. Rétrofiter la notion d'équipe dans un produit conçu pour des comptes individuels est un chantier, pas un réglage.
4. La facturation
Un SaaS se distingue d'un logiciel par son abonnement. L'abonnement implique des essais, des changements de formule en cours de mois, des impayés, des remboursements et des factures conformes.
Ce n'est pas un module que l'on branche à la fin. C'est un flux qui traverse le produit entier : les droits d'accès dépendent de l'état du paiement, et l'état du paiement arrive par un webhook qui peut se perdre.
5. L'hébergement et la localisation des données
Pour un produit français qui traite des données personnelles, l'hébergement n'est pas une question de préférence. Il conditionne ce que vous pourrez écrire dans vos mentions légales et ce que vos clients accepteront de signer.
Nos produits sont hébergés en France, avec une minimisation prévue dès l'architecture plutôt qu'ajoutée après coup. Le sujet se traite au cadrage, quand il ne coûte encore rien.
6. La supervision
Un produit en ligne tombe. La vraie question est de savoir si vous l'apprendrez par une alerte ou par un client mécontent.
Sauvegardes testées, journaux consultables, alerte sur les erreurs et sur la dépense : quatre éléments qui prennent une journée à mettre en place au démarrage, et une semaine à ajouter ensuite dans l'urgence.
7. Ce que le produit ne fera pas
La liste des refus est le document le plus utile d'un projet. Elle protège le calendrier et elle rend les arbitrages rapides, parce qu'ils ont déjà été rendus.
Si votre SaaS intègre de l'intelligence artificielle, la liste des refus vaut aussi pour elle. Un agent qui engage l'entreprise sans validation humaine est un risque, pas une fonctionnalité. Le coût d'inférence, lui, se plafonne dès le premier jour : nous détaillons comment dans l'article sur le coût réel d'un agent en production.
Combien de temps, combien ça coûte
Avec ces sept points tranchés, une première version utilisable sur un périmètre resserré se construit en deux à trois semaines. Sans eux, le même produit dérive sur plusieurs mois, non pas parce que le code est difficile, mais parce que chaque décision non prise devient une réunion.
C'est la méthode que nous appliquons sur nos propres produits et sur ceux de nos clients. Elle est décrite en détail sur notre page développement SaaS sur mesure.