Application SaaS : comment construire son propre produit, du MVP aux paiements récurrents

Une application SaaS, c’est un logiciel que l’on vend par abonnement plutôt que de livrer au client une fois le projet terminé. Cette seule différence change presque tout : la façon de compter les coûts, ce qui doit figurer dans la première version, la façon d’encaisser l’argent et les documents juridiques à avoir avant que le premier client ne clique sur « Payer ».

Ce texte s’adresse à celles et ceux qui ont une idée de produit et veulent savoir ce qu’implique sa construction pour le marché suisse en 2026. Nous nous appuyons sur le droit suisse en vigueur, la documentation des prestataires de paiement et notre propre expérience : nous exploitons un produit SaaS — DVN Links — et ce site utilise lui-même son API publique. Vous n’y trouverez ni histoires de clients inventées, ni promesses de revenus.

En quoi une application SaaS diffère du logiciel sur mesure

Un logiciel sur mesure se construit pour un seul client : un cahier des charges, un budget, un point de livraison après lequel le projet passe en maintenance. Les applications SaaS fonctionnent différemment sur trois points.

Un seul code, de nombreux clients. Chaque entreprise qui s’inscrit utilise la même application, sur les mêmes serveurs. Les données des clients doivent rester séparées, et une modification faite pour l’un atteint tous les autres. La façon dont cette séparation se fait concrètement — une seule base avec un identifiant client sur chaque enregistrement, ou des bases séparées par client — fait l’objet de notre article sur l’architecture multi-tenant.

Un abonnement plutôt qu’un paiement unique. Le client paie chaque mois ou chaque année, et peut résilier à tout moment. Le revenu dépend donc du nombre de clients qui restent, pas seulement de ceux qui arrivent — et les paiements récurrents, la facturation et la gestion des paiements échoués font partie du produit, pas d’un supplément.

Un développement sans date de fin. Les produits SaaS n’ont pas de « réception ». Après la première version viennent les corrections, de nouvelles fonctionnalités, des changements de tarifs et des mises à jour de sécurité. Le coût de construction n’est qu’un début ; le coût d’exploitation et d’évolution se paie aussi longtemps que le produit existe.

Si vous hésitez encore entre un produit propre et un outil déjà existant, commencez par notre guide du SaaS et la comparaison avec le logiciel sur mesure.

Les cinq briques indispensables à tout produit SaaS

Qu’il s’agisse de facturation, de réservation ou d’un raccourcisseur de liens, tous ces produits partagent, sous le capot, les cinq mêmes briques. Le client ne les achète pas — il achète la fonctionnalité qui résout son problème — mais sans elles, cette fonctionnalité ne se vend pas.

1. Comptes et organisations

Un utilisateur s’inscrit, se connecte, réinitialise son mot de passe. Les produits B2B ajoutent un niveau au-dessus : l’organisation, à laquelle appartiennent plusieurs personnes et qui est propriétaire des données et de l’abonnement. Décidez dès le départ si un compte appartient à une personne ou à une entreprise — changer d’avis plus tard implique de reconstruire le modèle de données.

2. Facturation

Plans, prix, période d’essai, changement de plan en cours de cycle, paiements échoués et nouvelles tentatives, factures. La plupart de ces éléments ne se construisent pas de zéro — on passe par un prestataire de paiement — mais l’intégration reste un vrai travail. Notre propre calculateur de coût d’application le formule ainsi : « L’intégration des paiements nécessite la gestion des webhooks, la logique d’idempotence et les tests de conformité — pas seulement l’intégration d’un widget de paiement. »

3. Droits d’accès

Qui, dans une organisation, peut inviter des personnes, voir les factures, supprimer des données. Deux rôles — propriétaire et membre de l’équipe — suffisent généralement au départ. Un système de rôles plus développé vaut la peine d’être construit une fois que les clients commencent à le demander.

4. Un panneau d’administration

Votre propre écran, où vous voyez les clients, leurs plans et leurs paiements, où vous pouvez prolonger un essai, suspendre un compte ou comprendre pourquoi un client signale un bug. Sans lui, chaque demande de support se termine par une requête manuelle dans la base de données.

5. E-mails transactionnels

Confirmation d’inscription, réinitialisation de mot de passe, invitation d’équipe, confirmation de paiement, notification de paiement échoué. Ce n’est pas du marketing : ce sont les messages dont le client a besoin pour savoir ce qui se passe sur son compte.

Ce qui peut attendre

Trois éléments qui finissent souvent dans le plan de la première version alors qu’ils sont rarement nécessaires dès le premier jour :

• une application mobile — une application web bien construite fonctionne très bien dans le navigateur d’un téléphone ; une application dédiée vaut la peine d’être construite une fois que l’on sait que les clients en ont réellement besoin sur le terrain ;
• une API publique — elle a du sens une fois que les clients veulent connecter votre produit à leurs propres systèmes ; avant cela, c’est une surface supplémentaire à construire et à sécuriser ;
• une deuxième langue — traduire l’interface, les e-mails, les conditions générales et le support, ce sont plusieurs tâches distinctes ; si vos premiers clients partagent une même langue, livrez-en une seule.

MVP d’une application SaaS — ce qui doit figurer dans la première version

Un MVP, produit minimum viable, doit répondre à une seule question : quelqu’un va-t-il payer pour que ce problème soit résolu. Nous détaillons comment en planifier un dans notre article sur le MVP. Pour un SaaS, la règle est simple : les cinq briques ci-dessus, plus la fonctionnalité pour laquelle le client vient réellement. Tout le reste attend que des clients payants disent ce qui manque.

L’erreur la plus fréquente sur un MVP consiste à construire toutes les fonctionnalités de l’idée avant que quiconque n’en ait utilisé une seule. La deuxième consiste à sauter la facturation « parce qu’on offrira gratuitement pour l’instant ». Si le produit doit gagner de l’argent par abonnement, le paiement est le test le plus important du MVP.

Plan gratuit et limites comme mécanisme de vente

Dans de nombreux produits SaaS, le tarif n’est pas une liste de fonctionnalités, mais une liste de limites. Notre propre produit, DVN Links, une plateforme européenne de gestion de liens avec analytique et codes QR, l’illustre bien. Son échelle de plans (consultée le 2026-10-02) va de Free à Starter, Pro, Business et Enterprise, avec 50 / 500 / 2 000 / 10 000 liens par mois, 1 000 / 10 000 / 50 000 / 250 000 clics par mois, un historique de statistiques de 7 / 30 / 90 / 365 jours, un accès API à partir du plan Starter, des limites de 10 000 et 50 000 requêtes par heure sur les plans supérieurs, un essai de 7 jours sur le plan Pro, une remise de 20 % en facturation annuelle, et un SLA contractuel sur Enterprise. L’interface elle-même n’existe qu’en anglais et en polonais.

Chaque plan est la même application — seuls les chiffres changent. Le plan gratuit permet d’essayer le produit sans carte, et les limites (nombre de liens, durée de conservation des statistiques, accès API) marquent le moment où passer à l’étage supérieur devient rentable. Pour un MVP, cela veut dire une chose : concevez le mécanisme de limites dès le premier jour, même si vous lancez avec un seul plan payant. Nous détaillons quand un plan gratuit aide, et quand il ne fait que coûter de l’argent, dans notre article sur le modèle freemium.

Paiements récurrents en Suisse : Stripe, TWINT et PostFinance

Les paiements récurrents sont des prélèvements automatiques effectués chaque mois ou chaque année auprès d’un client, une fois son consentement obtenu. Sur le marché suisse, plusieurs prestataires sont disponibles, qui se distinguent non seulement par le prix mais aussi par les moyens de paiement qui gèrent réellement la récurrence.

Stripe et TWINT

La page de tarifs suisse de Stripe indique « 2,9 % + 0,30 CHF pour les cartes émises en Suisse » et 3,25 % + 0,30 CHF pour les cartes internationales. TWINT, l’application de paiement suisse, est disponible via Stripe à 1,9 % + 0,30 CHF, et la documentation de Stripe consacrée à TWINT (en anglais) indique « Recurring payments: Yes » — les paiements récurrents sont pris en charge —, avec le franc suisse comme devise de présentation et la Suisse comme pays des clients. La page de tarifs Billing suisse de Stripe précise : « 0,7 % du volume traité via Billing… Inclut les transactions Billing traitées dans ou hors Stripe. Exclut les factures ponctuelles. »

PostFinance Checkout

PostFinance Checkout est une alternative suisse pour l’acquisition des paiements. Son offre All-in-One coûte CHF 199 de mise en place plus CHF 14,90 par mois, avec des frais de 2,5 % (minimum CHF 0,20) pour un chiffre d’affaires jusqu’à CHF 200 000 ; l’offre E-Com Bundle est à CHF 19,90 par mois, avec TWINT/PostFinance Pay à 1,3 %, les cartes à 1,55 %, plus des frais PSP de CHF 0,18 par transaction. Nous n’avons pas pu confirmer si PostFinance Checkout gère les abonnements récurrents de la même façon que Stripe — vérifiez ce point directement auprès de PostFinance avant de vous y fier pour un produit par abonnement.

Factures et TVA pour une activité par abonnement

Le prestataire de paiement encaisse l’argent, mais vous devez malgré tout émettre une facture conforme au droit suisse pour un client professionnel. En vertu de l’art. 26 de la loi sur la TVA (LTVA), le fournisseur assujetti doit établir une facture sur demande, avec les éléments qu’énumère cet article (dont votre numéro de TVA) ; les tickets de caisse jusqu’à CHF 400 peuvent ne pas indiquer le destinataire (OTVA, art. 57). La partie paiement d’une facture suisse, c’est la QR-facture : en circulation depuis juin 2020, elle a définitivement remplacé les anciens bulletins de versement le 1er octobre 2022, de nouvelles exigences s’appliquent depuis le 22 novembre 2025, et à partir de novembre 2026, seules les adresses structurées (type S) seront acceptées. Nous ne pouvons pas confirmer l’existence d’une obligation suisse de facturation électronique B2B — si votre outil de facturation l’affirme, vérifiez-le directement avant de vous y fier.

Si vous vendez votre application SaaS à des consommateurs suisses depuis l’étranger, vous n’êtes plus libéré de l’assujettissement à la TVA suisse dès que votre chiffre d’affaires mondial atteint CHF 100 000 (LTVA, art. 10, al. 2, let. a et let. b, ch. 2) ; le taux normal est de 8,1 %. Ne présumez pas qu’un guichet unique à l’européenne (OSS) existe pour ces ventes : inscrivez-vous et déclarez selon les règles suisses.

Minimum légal : conditions générales, protection des données et règles consommateurs

Ce qui suit est une carte des obligations, pas un conseil juridique. Faites vérifier vos conditions générales et vos documents sur la protection des données par un avocat avant d’accepter un premier paiement.

Conditions générales pour un service en ligne

La Suisse n’a pas de loi spécifique sur les conditions générales du commerce électronique, équivalente à la directive européenne sur le commerce électronique. C’est la loi contre la concurrence déloyale (LCD) qui fixe le cadre : l’art. 3, al. 1, let. s, exige une information claire sur l’identité du vendeur en ligne (y compris une adresse e-mail), les étapes techniques pour conclure le contrat, la façon de corriger les erreurs de saisie et une confirmation de commande électronique immédiate ; l’art. 8 interdit les conditions générales créant un déséquilibre important et injustifié au détriment du consommateur. Il n’existe pas d’équivalent suisse à la règle européenne imposant de fournir les conditions générales sous une forme que le client peut conserver et reproduire — mais en proposer une copie téléchargeable ne coûte rien et évite des litiges.

Protection des données dans les deux sens : responsable et sous-traitant

Dans une application SaaS B2B, vous occupez deux rôles à la fois.

Envers vos propres utilisateurs, la nouvelle loi fédérale sur la protection des données (nLPD) impose, à l’art. 19, un devoir d’information lors de la collecte, portant au minimum sur : « a. l’identité et les coordonnées du responsable du traitement; b. la finalité du traitement; c. le cas échéant, les destinataires ou les catégories de destinataires… ».

Envers les données que vos clients importent dans l’application, vous êtes normalement sous-traitant. L’art. 9 de la nLPD couvre cette relation mais — contrairement à l’art. 28, al. 3, du RGPD — ne fixe aucune liste obligatoire de clauses qu’un contrat de sous-traitance doit contenir. En pratique, vous préparez malgré tout un contrat type que le client accepte avec vos conditions générales, couvrant le même terrain que le RGPD exigerait, même si le droit suisse n’impose pas les clauses précises. Si votre produit propose lui-même son service à des personnes dans l’Union européenne, le RGPD peut aussi s’appliquer à cette partie de l’activité (art. 3, al. 2), même si votre société est suisse.

Clients consommateurs : pas de droit de rétractation légal

Si vous vendez aussi à des particuliers, la position suisse diverge nettement de celle de l’Union européenne. L’art. 40b du Code des obligations (CO) ne prévoit un droit de rétractation que pour le démarchage à domicile et par téléphone — et le portail PME du SECO le dit sans détour : « In e-commerce, Swiss law does not provide for any withdrawal period or other right of return once the order has been placed » — traduction libre : « Dans le commerce en ligne, le droit suisse ne prévoit aucun délai de rétractation ni aucun autre droit de retour une fois la commande passée. » Il n’existe pas d’équivalent suisse à la règle européenne permettant à un consommateur de résilier gratuitement dans les 30 jours en cas de modification défavorable du produit.

En pratique, cela signifie que vos conditions d’annulation et de remboursement relèvent d’un choix contractuel, et non d’un droit légal que vous mettez en œuvre. Énoncez-les clairement, comme l’exige la LCD (art. 3, al. 1, let. s), et veillez à leur équité au sens de l’art. 8 — une politique d’annulation généreuse est ici un choix concurrentiel, pas une obligation légale. Si l’application sert aussi des consommateurs dans l’Union européenne, les règles européennes de rétractation et de contenu numérique (et le RGPD, en vertu de son art. 3, al. 2) s’appliquent à cette partie de votre activité, même si rien de tout cela ne s’applique au volet suisse.

Ce que coûte la construction d’une application SaaS

Le prix d’une telle application dépend fortement du périmètre, et nous n’avons trouvé aucun référentiel suisse avec un échantillon publié pour la construction de SaaS ou d’applications web. Ce qui pèse sur le coût, c’est le mécanisme, pas un chiffre unique : les cinq briques ci-dessus, la profondeur nécessaire du système de droits, le nombre de moyens de paiement et de devises pris en charge, et la part des cas particuliers de facturation (paiements échoués, prorata, gestion de la TVA suisse) que vous gérez vous-même plutôt que de la confier au prestataire. Chaque projet que nous chiffrons est évalué individuellement pour cette raison précise — un « SaaS simple » et « le même SaaS avec paiements récurrents, droits d’accès et facturation suisse » sont des projets très différents.

Vous pouvez obtenir une estimation approximative pour votre propre périmètre avec notre calculateur de coût d’application web. Pour le contexte général de ce qui influence le prix d’une application, voir combien coûte la création d’une application ; nous avons aussi publié un rapport sur le coût des applications web, mais cette étude porte spécifiquement sur le marché polonais et ses chiffres ne se transposent pas à la Suisse.

Coûts après le lancement

Un produit SaaS paie des factures chaque mois : hébergement et base de données, service d’envoi d’e-mails, frais du prestataire de paiement (chez Stripe, une commission par transaction plus 0,7 % pour Billing), supervision et sauvegardes. S’ajoute à cela le temps de développement pour les corrections, les mises à jour de dépendances et les nouvelles fonctionnalités. Nous expliquons comment organiser cela après le lancement dans nos articles sur la maintenance technique et l’auto-hébergement sur Coolify — ce dernier peut réduire la facture d’infrastructure tant que le produit reste petit.

Exemple : DVN Links et son API publique

DVN Links est notre propre produit SaaS — son propre site le décrit comme « a European link management platform with analytics and QR codes » (une plateforme européenne de gestion de liens avec analytique et codes QR). Nous avons décrit ses tarifs plus haut : un produit où le plan gratuit et ses limites constituent le principal mécanisme de vente.

Une API publique en pratique

DVN Links expose aux clients une API REST, documentée selon la norme OpenAPI 3.1. Chaque requête nécessite une clé API transmise en jeton Bearer dans l’en-tête Authorization. Les limites de débit dépendent du plan, et l’API les indique dans les en-têtes de réponse X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset, afin qu’un programme client sache toujours combien de requêtes il lui reste et quand le compteur se réinitialise. L’accès à l’API est inclus à partir du plan Starter.

C’est un bon exemple d’élément qui peut attendre : l’API n’était pas nécessaire pour vérifier si quelqu’un était prêt à payer pour des liens courts. Elle est devenue nécessaire lorsque le produit a eu des clients voulant créer des liens automatiquement depuis leurs propres systèmes — et elle est alors devenue, elle aussi, une limite distinguant les plans.

Ce que notre propre site fait de cette API

Le meilleur test d’une API, c’est de l’utiliser soi-même. Ce site — celui que vous lisez — dialogue avec DVN Links via la même API REST publique que les clients payants :

• crée un lien court à la publication d’un article ou d’une page, et l’enregistre sur le document ;
• vérifie à chaque publication suivante que le lien existe toujours ;
• recrée le lien si quelqu’un l’a supprimé dans le panneau DVN Links ;
• met à jour l’adresse de destination quand l’adresse d’une page change — l’ancien lien court continue de fonctionner et pointe désormais vers la nouvelle adresse ;
• récupère les liens créés avant que le site ne commence à enregistrer leurs identifiants : il recherche un lien par son adresse de destination et l’attache au document plutôt que d’en créer un doublon.

Un appel API en échec ne bloque jamais l’enregistrement de l’article — il est simplement journalisé. C’est une règle à adopter pour toute intégration avec un service tiers : votre application doit continuer à fonctionner même quand l’autre service est momentanément indisponible. Nous expliquons ce qu’est une API, comment fonctionne un webhook et comment sécuriser une intégration dans notre article sur les API.

Construire soi-même, avec une agence, ou avec nous

Il n’y a pas de bonne réponse unique — seulement quelques critères à examiner honnêtement.

Construisez vous-même si vous êtes développeur, ou en avez un dans l’équipe fondatrice, et que le temps coûte moins cher que l’argent. Le risque : les cinq briques prennent plus de temps que la fonctionnalité principale, et les paiements ainsi que les documents juridiques sont remis « à plus tard ».

Commencez par des outils no-code ou low-code si vous voulez tester la demande en quelques semaines et acceptez de probablement reconstruire la première version. Nous détaillons quand cela a du sens, et quand cela bloque la croissance, dans notre article sur le low-code.

Choisissez une agence si vous avez un périmètre bien défini, un budget pour une construction complète et une personne côté métier pour porter le produit par la suite.

Parlez-nous si vous voulez démarrer avec la plus petite version capable d’encaisser des paiements et la faire grandir par étapes. Nous exploitons notre propre produit SaaS, donc les paiements récurrents, les limites de plan, l’API et les obligations légales, nous les connaissons en tant que propriétaire, pas seulement en tant que prestataire. Voir nos pages MVP pour startups et création d’applications web pour notre façon de travailler, ou faites notre quiz SaaS ou sur mesure si vous hésitez encore à construire votre propre produit.