Assembler des SaaS ou construire son produit : ce qui doit vous appartenir pour être défendable

Un founder qui lance un produit logiciel n’a jamais eu autant de pièces disponibles sur étagère. Le paiement, l’authentification, l’envoi d’e-mails, le support, l’analyse d’usage s’achètent à l’abonnement. Un outil no-code ou un générateur comme Lovable produit un premier parcours en quelques jours. Certains éditeurs vendent même un produit complet en marque blanche, à votre nom et à vos couleurs. Il est donc possible de lancer sans écrire presque aucun code.

La question n’est plus de savoir si l’on peut assembler, mais où placer la ligne : ce qu’on loue, ce qu’on achète une fois, et ce qui doit vous appartenir parce que c’est précisément ce que vos clients paient. Cet article ne compare pas des outils. Il donne une grille pour quatre questions : qu’est-ce qui doit être à vous pour être défendable, que peut-on assembler au départ, quand le sur-mesure devient-il nécessaire, et que coûte la dépendance.

Trois façons d’assembler, trois niveaux de dépendance

Le mot « assembler » recouvre des situations très différentes, et la différence tient à ce que vous contrôlez encore.

Brancher des briques autour de votre propre code. Vous développez le cœur du produit et louez tout le reste : Stripe pour le paiement, un service d’authentification, un outil d’e-mails transactionnels. C’est la configuration normale d’un SaaS aujourd’hui, et personne ne vous reprochera de ne pas avoir réécrit un système de paiement. Chaque brique est une dépendance, mais elle est remplaçable parce que votre code en est le chef d’orchestre.

Construire le produit entier dans un outil no-code ou généré. Le parcours, les données et la logique vivent dans une plateforme (Bubble, Glide, Softr) ou dans un code produit par Lovable, Bolt ou v0 et hébergé sur leurs services. La vitesse est réelle. La dépendance est d’une autre nature : avec une plateforme no-code, la logique de votre produit n’existe que dans cette plateforme et ne s’exporte pas comme du code ; avec un générateur, vous récupérez un code, mais un code que personne n’a conçu et qu’il faut souvent reprendre. Le choix entre ces deux voies et le code écrit à la main est l’objet de notre comparatif MVP no-code ou code : quel choix pour un premier produit.

Revendre un produit en marque blanche. Un éditeur vous fournit une application complète que vous commercialisez sous votre marque. Vous ne gérez ni le code ni l’hébergement. Vous ne contrôlez pas non plus la feuille de route, les prix d’achat ni les conditions de sortie. C’est un modèle de distribution plus qu’un modèle de produit : la valeur que vous construisez est commerciale, pas technique.

Ces trois options ne s’excluent pas. La plupart des produits qui tiennent commencent par un mélange : un cœur réduit, des briques louées, parfois un outil no-code pour l’interne. Le problème n’est pas l’assemblage. C’est d’assembler aussi ce qui aurait dû être à vous.

Ce qui doit être à vous pour être défendable

Posséder du code n’est pas un avantage concurrentiel en soi. Un concurrent peut réécrire votre application ; il ne peut pas réécrire vos clients, vos données ni la compréhension que vous avez de leur problème. Ce qui doit vous appartenir, c’est ce qui rend votre produit difficile à remplacer. Quatre éléments, dans cet ordre.

La logique qui fait la valeur. C’est la règle, le calcul, le parcours ou l’automatisation pour lesquels un client choisit votre produit plutôt qu’un tableur ou un concurrent. Si cette logique vit dans un outil loué, n’importe qui peut la reproduire avec le même outil, et l’éditeur peut la rendre impossible à la prochaine mise à jour. C’est la seule partie qui justifie, dès le départ, du code que vous possédez et que vous comprenez.

Les données et leur structure. Pas seulement le droit de les exporter dans un fichier CSV, mais une base dont la structure reflète votre métier et que vous pouvez interroger, migrer et faire évoluer. Les données accumulées par vos clients sont ce qui rend le départ coûteux pour eux. Elles ne vous protègent que si elles sont réellement à vous. Sur un SaaS B2B, cela inclut la façon dont les données d’un client sont isolées de celles des autres, une décision qu’il vaut mieux prendre tôt, comme nous l’expliquons dans multi-tenant et facturation par abonnement.

La relation client. Le nom de domaine, les adresses e-mail des utilisateurs, les comptes de paiement, le compte qui envoie les e-mails. Si vos clients s’abonnent sur la plateforme d’un tiers, ce sont ses clients, et vous en êtes l’apporteur. C’est la limite principale de la marque blanche.

La capacité de changer. La possibilité de modifier le produit quand un client important demande quelque chose, sans attendre la feuille de route d’un éditeur. C’est moins visible que les trois premiers éléments, mais c’est ce qui décide si vous pouvez répondre à votre marché à la vitesse d’une startup.

Tout le reste peut être loué sans regret : le paiement, l’authentification, l’envoi d’e-mails, le support, la comptabilité, le CRM interne. Ce ne sont pas vos clients qui vous les paient.

Ce qu’on peut assembler au départ

Avant d’avoir des clients payants, chaque semaine compte plus que chaque ligne de code. Le bon réflexe est de louer tout ce qui n’est pas la logique qui fait la valeur, et parfois même celle-ci, le temps de vérifier qu’elle intéresse quelqu’un.

Deux précisions. D’abord, un kit de départ acheté une fois n’est pas une location : c’est du code que vous possédez et que votre équipe porte. Il fait gagner les premières semaines, et son coût réel apparaît au premier client qui sort du cadre prévu ; c’est ce que nous détaillons dans boilerplate SaaS ou sur-mesure.

Ensuite, assembler la logique de valeur pour valider est légitime, à une condition : savoir que c’est un test, et non la première version du produit. Un prototype no-code qui prouve que des clients paient a rempli sa mission, même s’il faut le jeter. Avant même de construire, d’ailleurs, certains tests engagent davantage un futur client qu’un prototype ; nous les passons en revue dans valider une idée de SaaS avant de coder.

Quand le sur-mesure devient nécessaire

Le passage au code que vous possédez ne se décide pas à une date ou à un chiffre d’affaires. Il se décide quand l’assemblage commence à coûter plus qu’il ne rapporte. Cinq signaux, dont un seul suffit souvent.

Le parcours qui fait vendre se heurte à l’outil. Vous perdez des clients sur une étape que l’outil ne permet pas d’améliorer : un formulaire trop rigide, un calcul impossible, un écran qui ne peut pas afficher ce dont le client a besoin. Quand la limite de l’outil devient la limite de votre conversion, il est temps.

Vos clients auditent leurs fournisseurs. Dès que vous vendez à des entreprises, on vous demandera où sont hébergées les données, qui y a accès, comment elles sont isolées, comment on les supprime. Si la réponse est « chez l’éditeur de la plateforme, selon ses conditions », certaines ventes s’arrêtent là.

Le coût de l’outil croît plus vite que vos revenus. Beaucoup d’outils facturent à l’utilisateur, à l’opération ou au volume. Ce modèle est indolore à dix clients et devient la première ligne de dépense à mille. Le calcul se fait sur votre marge unitaire : si chaque nouveau client vous coûte une part croissante de ce qu’il paie, l’outil mange votre modèle économique.

L’intégration tient avec des automatisations fragiles. Cinq scénarios d’automatisation qui se déclenchent en cascade pour faire ce qu’une fonction de quinze lignes ferait, et que personne n’ose plus modifier : c’est de la dette, simplement placée dans un autre outil.

Quelqu’un regarde le produit de l’extérieur. Un investisseur, un acquéreur ou un gros client qui demande ce que vous possédez réellement. Un produit entièrement construit dans la plateforme d’un tiers, ou revendu en marque blanche, se valorise comme une activité commerciale, pas comme un actif logiciel.

À l’inverse, le sur-mesure est prématuré quand aucun client ne paie encore, quand l’outil n’a encore bloqué personne, ou quand le seul argument est « on finira par en avoir besoin ». Dépenser le budget d’un MVP avant d’avoir une preuve de demande est le moyen le plus sûr de ne pas en avoir de deuxième. Pour savoir ce qu’un premier produit sur-mesure coûte réellement et lire les devis qu’on vous remettra, voir combien coûte vraiment un MVP SaaS.

Ce que coûte la dépendance

Toute dépendance a un prix. La question n’est pas de l’éviter, ce qui est impossible, mais de savoir lequel on paie et s’il est acceptable. Il se paie sous quatre formes.

Un prix à l’usage. C’est la forme la plus visible et souvent la plus saine. Stripe facture par exemple 1,5 % + 0,25 € par transaction sur une carte standard de l’Espace économique européen, et 3,15 % + 0,25 € sur une carte internationale, selon sa page tarifaire consultée le 14 octobre 2026. Pour un paiement, c’est un prix qu’on accepte sans hésiter : refaire l’équivalent coûterait infiniment plus. Le même mécanisme appliqué à la logique qui fait votre valeur est un impôt permanent sur votre marge.

Un changement de conditions. Un éditeur peut modifier ses prix, ses limites ou son offre, et vous ne pouvez que suivre. L’exemple le plus cité reste Heroku, qui a annoncé le 25 août 2022 l’arrêt de ses offres gratuites à partir du 28 novembre 2022, d’après son propre billet : trois mois pour migrer ou payer. Les projets dont le code était standard ont déménagé en quelques jours. Les autres ont payé.

Un retrait. Une fonctionnalité, une API ou un modèle disparaît. C’est devenu courant avec les modèles de langage : chez OpenAI, le retrait de gpt-4.5-preview a été annoncé le 14 avril 2025 pour un arrêt le 14 juillet 2025, selon la page des dépréciations consultée le 14 octobre 2026. Un produit qui a bâti sa fonctionnalité principale sur un modèle précis doit pouvoir en changer en quelques semaines.

Un coût de sortie. C’est le coût le moins visible et le plus élevé : ce qu’il faudra dépenser le jour où vous voudrez partir. Il se mesure à ce que l’export ne contient pas. Les données brutes sortent souvent ; la logique, les automatisations, les paramétrages et l’historique sortent rarement. Pour un produit construit dans une plateforme no-code, la sortie veut presque toujours dire une reconstruction.

Quatre précautions réduisent ces coûts sans renoncer à assembler :

• tous les comptes à votre nom, dès le premier jour : hébergement, base, domaine, paiement, e-mails ;
• un export régulier et testé des données, dans un format que vous pourriez recharger ailleurs ;
• un point d’entrée unique dans votre code pour chaque service loué, afin de pouvoir changer de fournisseur sans toucher tout le produit ;
• une liste écrite des dépendances, avec pour chacune son coût à dix fois votre volume actuel et ce que coûterait d’en partir.

La grille quand le logiciel est votre produit

Les comparatifs habituels entre SaaS et sur-mesure supposent un logiciel qui sert une activité. Quand le logiciel est l’activité, trois règles changent.

Vous ne pouvez pas louer votre différenciation. Louez tout le périmètre support, jamais le cœur de ce que vos clients paient. Si un concurrent peut obtenir votre produit en s’abonnant au même outil que vous, vous n’avez pas de produit, vous avez une configuration.

Le coût total n’est pas la bonne métrique, le coût d’opportunité l’est. Trois mois de retard sur un marché qui se referme coûtent plus cher que n’importe quelle facture d’outil. À l’inverse, un budget de développement dépensé avant d’avoir un seul utilisateur payant est rarement récupérable. Assembler pour aller vite, puis construire ce qui s’est révélé décisif, est un ordre raisonnable ; l’inverse l’est rarement.

La dette n’est pas symétrique. Une partie de ce que vous assemblez est une dette choisie, qu’on remplacera le jour où elle gênera. Une autre, comme des données mal structurées ou une isolation entre clients absente, coûte une réécriture si on la découvre tard. La distinction entre les deux est détaillée dans dette technique d’un MVP.

En pratique, la grille tient en trois colonnes, à remplir brique par brique avant de choisir un outil ou de signer un devis : louer (tout ce que vos clients ne paient pas), acheter une fois (le socle technique commun à tous les SaaS) et construire (la logique qui fait la valeur, les données qui la portent). Un devis de développement qui ne distingue pas ces trois colonnes vous fait payer au prix du sur-mesure ce qui se loue ou s’achète.

C’est cette séparation qui structure notre offre de développement de MVP SaaS : construire le cœur que vous devez posséder, sur des briques éprouvées pour le reste. Et si votre produit a commencé dans Lovable, Bolt ou v0 et touche aujourd’hui l’un des cinq signaux décrits plus haut, la question n’est pas forcément de tout refaire ; c’est l’objet de la reprise de projet Lovable.