Créer un SaaS : les cinq décisions à prendre avant de coder

Mon terrain, pour ce guide, est ekyde : une place de marché de l’équitation doublée d’un outil de réservation pour les établissements et les coachs, qui m’a obligée à trancher chacune de ces questions avant d’écrire du code. L’étude de cas en détaille la construction ; ce guide en tire les décisions, utiles pour tout produit vendu par abonnement.

Le modèle économique conditionne le produit lui-même. Trois formes dominent : l’abonnement, la commission sur les transactions qui passent par la plateforme, et l’usage gratuit financé autrement. Aucune n’est meilleure dans l’absolu ; elles demandent des produits différents.

Une commission suppose que l’argent des clients transite par vous : paiements, remboursements, reversements, litiges. Un abonnement fixe ne demande que de facturer. ekyde est parti d’un modèle où la plateforme encaissait le cavalier, puis a basculé vers un abonnement seul : un prix fixe par établissement, aucune commission, et plus aucun paiement de cavalier qui passe par la plateforme. Le code de l’ancien modèle a été supprimé, pas désactivé, et les vérifications juridiques et bancaires liées à l’encaissement pour des tiers sont devenues sans objet.

Reste à choisir le moment où le client paie. Chez ekyde, un établissement prépare tout gratuitement, sa fiche, ses offres et ses stages ; l’abonnement n’est demandé qu’au moment de publier, c’est-à-dire quand le produit sert à d’autres personnes. Ce choix de moment compte autant que le prix : on ne demande l’engagement qu’une fois la valeur visible.

Un SaaS métier applique les règles d’un métier : qui peut réserver quoi, dans quelles conditions, avec quelles exceptions. Ces règles vivent dans la tête de celles et ceux qui exercent le métier, rarement par écrit. Les mettre sur le papier avant le code est le travail le moins visible et le plus rentable du projet.

Pour chaque règle, je cherche une phrase, un exemple chiffré et l’exception. Chez ekyde, la règle de base est que la disponibilité se compte par offre et par nuit. Les cas limites viennent ensuite : plusieurs offres qui partagent les mêmes places, une nuit fermée par l’établissement, une demande en attente de réponse. Quand une règle manque, je l’écris comme question ouverte plutôt que de la deviner, et quand elle change, la modification est consignée dans un registre de demandes de changement.

Un contrôle placé dans un écran se contourne, se déclenche deux fois ou se joue en parallèle. Toute règle dont la violation coûte cher, comme une place vendue deux fois, un droit d’accès mal attribué ou un doublon de facture, doit être garantie là où les données vivent.

Chez ekyde, la capacité de chaque nuit est protégée par des contraintes de la base : elle refuse toute écriture qui ferait dépasser les places déclarées, même si deux demandes arrivent en même temps. L’interface affiche le restant sans l’imposer. C’est la différence entre une survente improbable et une survente impossible.

La contrepartie est un peu de travail au départ : écrire ces contraintes et les tester directement sur la base, hors de l’application. Elle se rembourse le jour où une erreur de code aurait, sinon, laissé passer une double réservation.

Certaines obligations légales imposent des champs, des statuts ou des fonctions dans le produit : conservation et suppression des données personnelles, répartition des responsabilités entre vous et vos clients, déclaration fiscale des revenus des vendeurs pour une place de marché, règles de contact et de modération pour une plateforme en ligne. Les ajouter après coup suppose de les rétro-collecter auprès de clients déjà inscrits, ce qui coûte très cher.

Chez ekyde, ces décisions ont été écrites avant le schéma : la base prévoit les champs dès le départ, et l’export comme la suppression des données y sont prévus comme des fonctions du produit, pas comme des opérations manuelles.

Ces obligations dépendent de votre activité et de votre pays, et se vérifient auprès d’un juriste ou d’un expert-comptable. Le travail de conception consiste à savoir quelles questions lui poser avant d’écrire le schéma, et à ne pas dire d’un produit qu’il est conforme sans cette vérification.

On conseille souvent de commencer par le plus petit produit possible. Le bon critère est plus exigeant : le plus petit produit qu’un client acceptera de payer. Pour ekyde, j’ai élargi la première version. Les petites structures visées n’ont souvent pas d’outil de réservation : elle devait donc être à la fois une place de marché et un outil de réservation, avec les cours, les stages et les coachs.

Ce périmètre est plus large qu’un produit minimal, et il faut le dire : il coûte plus de travail avant la première vente. Le cadrage sert autant à décider ce qui n’entre pas dans la première version qu’à décider ce qui y entre. Ici, l’application mobile, les services liés au cheval et la demi-pension sont renvoyés à des versions suivantes.

Il n’existe pas de délai ni de prix valables pour tous les SaaS : ils dépendent du nombre de parcours, des rôles, des intégrations et des règles à écrire. Pour un produit construit avec un client, une première version utile demande généralement plusieurs semaines à quelques mois ; le cadrage en isole un premier périmètre réellement testable.

À titre de repère, ekyde compte moins de cinq semaines entre le premier commit du dépôt (9 septembre 2026) et la mise en ligne du site (12 octobre). Ce repère décrit un produit dont je suis la seule décisionnaire, construit avec un assistant de programmation IA et des règles écrites avant le code. Il ne vaut pas devis : la page tarifs donne les repères de prix.

C’est le cœur de la prestation application web métier. Si vous connaissez un métier de l’intérieur et qu’il manque l’outil qui le sert, la première étape est un échange pour décrire le besoin : écrivez-moi en quelques lignes. Pour voir ce que donnent ces décisions sur un produit réel, lisez l’étude de cas ekyde.