Comment créer son SaaS quand on n'est pas développeur

Quelle différence entre un prototype, un MVP et un produit

Avant de choisir comment construire un SaaS, il faut savoir ce que la première version doit prouver, parce que les décisions qui engagent le produit ne sont pas les mêmes à chaque stade. Les trois termes circulent souvent comme des synonymes, alors qu'ils désignent des objectifs différents.

Le prototype pour tester une idée

Un prototype sert à montrer une idée à des utilisateurs potentiels, à un associé ou à un investisseur, et à observer leur réaction. Il peut simuler une partie de ses fonctions, stocker ses données de façon provisoire et ne gérer aucun paiement. Le founder peut le jeter une fois qu'il a obtenu les réponses qu'il cherchait, si bien que les choix techniques faits pour le construire pèsent peu sur la suite du projet.

Le MVP pour vérifier qu'il y a un marché

Une fois l'idée testée, vient le MVP, la plus petite version du produit que de vrais clients utilisent, et qu'idéalement ils paient. Son périmètre reste réduit, mais des personnes y créent un compte, y confient leurs données et parfois leur carte bancaire, ce qui l'oblige à fonctionner de façon fiable. C'est à ce stade que se prennent les premières décisions durables, sur les comptes utilisateurs, la structure des données et les paiements, parce que ces briques resteront en place longtemps après le lancement.

Le produit pour tenir la croissance

Si le MVP trouve son marché, le produit grandit et accueille des centaines puis des milliers d'utilisateurs, reçoit de nouvelles fonctions chaque mois et finit souvent par être repris par une équipe. Les décisions prises pour le MVP montrent alors leurs conséquences. Le founder se demande ce que coûte chaque utilisateur, combien de temps prend une évolution et qui comprend encore la façon dont l'ensemble tient.

Ainsi, une solution rapide et bon marché convient très bien à un prototype lancé en deux mois, et la même solution peut devenir coûteuse pour un produit qui compte dix mille clients. Le calendrier et les fonds disponibles pèsent donc autant que la technique dans le choix d'une architecture.

Combien coûte un SaaS, à développer puis à faire tourner

Chacune de ces décisions a un prix. Une partie se paie au moment du développement, une autre chaque mois pour chaque utilisateur, et une dernière plus tard, quand il faut revenir sur un choix.

Ce qui fait varier le coût de développement

Le premier prix se paie au développement, et deux SaaS d'apparence proche peuvent coûter du simple au quintuple, parce que leur coût dépend du périmètre de la première version, du nombre de rôles et de permissions à gérer, de la présence d'abonnements et de paiements, des intégrations avec d'autres outils comme un CRM ou un logiciel de comptabilité, et du soin apporté au design. Le temps passé à décider de ce qu'il faut construire réduit souvent le reste de la facture, puisqu'une fonction retirée du périmètre ne coûte plus rien. Nous avons détaillé ces mécanismes pour les sites web dans un de nos articles, et la plupart s'appliquent à un SaaS.

Ce que coûte un utilisateur une fois le produit lancé

Le deuxième se paie chaque mois. Chaque utilisateur actif consomme de l'hébergement, de la base de données, du stockage, des emails envoyés, et parfois des appels à des modèles d'IA si le produit en utilise. Les paiements ont aussi leur coût, puisque les prestataires comme Stripe prélèvent une commission sur chaque transaction. Comme une grande partie de ces services facture à l'usage, le démarrage est presque gratuit et la facture grimpe avec le succès. Ce coût par utilisateur dépend en grande partie des services choisis pour le MVP. Estimer ce qu'il deviendrait avec cent, mille puis dix mille utilisateurs, avant de choisir ces services, permet de savoir si le prix de l'abonnement pourra le couvrir.

Les briques techniques difficiles à changer ensuite

Le dernier prix se paie quand une brique doit être remplacée, et c'est ce qu'on peut appeler le coût de sortie. Il varie beaucoup d'une brique à l'autre. L'authentification fait partie des plus élevés, parce que les comptes et les mots de passe des utilisateurs restent liés au système qui les a créés, et en changer oblige parfois à demander à chaque client de réinitialiser son accès. La structure des données et le système d'abonnement présentent le même risque. Nous avons rencontré ce problème en construisant notre plugin Better Auth pour Medusa, et il se pose de la même façon pour un SaaS.

Le prix de l'abonnement et le moment où le produit devient rentable

Ces trois coûts se comparent à ce que rapporte chaque client. Le prix de l'abonnement doit couvrir le coût de chaque utilisateur avec une marge suffisante, et les clients qui partent chaque mois doivent être remplacés pour que le produit puisse grandir. Le moment où les revenus remboursent le développement dépend de ces deux chiffres, et c'est souvent ce calcul qui fixe le budget raisonnable pour construire la première version.

Développer son SaaS soi-même avec l'IA ou le no-code

Comme tous ces coûts découlent des décisions prises sur le périmètre, l'architecture et le prix dès les premières versions du produit, les trois façons de développer un SaaS se distinguent par la personne qui prend ces décisions et par ce qu'elle sait de leurs conséquences. Seul, le founder les prend toutes. Avec un CTO, il confie la partie technique à un associé. Avec un prestataire, il la confie à quelqu'un d'extérieur, qui participe plus ou moins à la réflexion sur le produit.

Ce que les outils d'IA permettent aujourd'hui

Ce premier chemin est devenu une option sérieuse parce que les outils ont changé la nature de l'exercice. Lovable, Bolt, Cursor ou Claude Code produisent en quelques jours une application qui aurait demandé des semaines il y a trois ans. Le changement touche aussi les éditeurs de logiciels les plus exigeants. Quentin Adam, qui dirige l'hébergeur français Clever Cloud, raconte que les agents d'IA produisent parfois une meilleure implémentation que celle qu'il aurait écrite lui-même, et que la valeur du travail des développeurs se déplace vers les spécifications, l'architecture et les tests. Ces outils ont d'ailleurs rapproché le no-code du développement, puisqu'on y décrit ce qu'on veut en langage courant et qu'on obtient malgré tout du code. Écrire le code n'est donc plus l'obstacle principal pour un founder qui n'est pas développeur.

Gérer seul les choix techniques tout en vendant son produit

Reste la question de l'architecture. L'IA peut écrire le code de n'importe quelle architecture, une base Postgres, un cache Redis, un stockage de fichiers, ou un backend prêt à l'emploi comme Supabase ou Firebase. Elle construit ce qu'on lui demande, et quand on ne lui demande rien de précis, elle choisit une solution par défaut. Nous l'avions montré lors de notre atelier sur le vibe coding à l'IA Day de Valenciennes avec l'exemple de Node.js, que l'IA retient souvent parce qu'il domine ses données d'entraînement, sans que ce soit toujours le langage le plus adapté au projet. Le founder qui construit seul prend donc toutes les décisions, ou accepte celles qu'on lui propose sans toujours connaître leur coût de sortie. Il paie cette liberté en temps, au moment où il doit aussi trouver ses premiers clients, parler à des investisseurs et affiner son offre, si bien que chaque heure passée sur l'architecture manque à la vente.

Ce qui change quand le produit grandit

Les conséquences de ces décisions apparaissent rarement au lancement. Elles se manifestent quand le coût par utilisateur grimpe plus vite que les revenus, quand une fonction demandée par les clients ne rentre pas dans l'outil choisi, ou quand personne ne sait vérifier si les règles d'accès aux données protègent bien les informations de chaque client. Beaucoup de produits solides ont commencé ainsi, et les choix du départ les suivent très loin. OpenAI fait encore tourner ChatGPT sur une seule base PostgreSQL principale, épaulée par près de cinquante répliques en lecture. Quand les écritures sont devenues trop lourdes pour cette base, l'équipe a déplacé une partie des traitements vers d'autres systèmes et interdit l'ajout de nouvelles tables sur la base principale. Savoir dès le départ quelles briques auront un coût de sortie élevé permet d'aborder ce genre de moment sans le subir.

S'associer avec un CTO

Quand le founder ne veut plus porter seul ces décisions, ou ne se sent pas capable d'en anticiper le coût de sortie, il peut les confier à un associé technique. Le CTO reprend alors la partie technique des décisions. Il choisit l'architecture, construit le produit et en connaît les conséquences, ce qui laisse au founder le temps de se concentrer sur le business, et beaucoup de startups ont été construites de cette façon. Le founder paie cette connaissance en capital plutôt qu'en argent, avec une part qui peut aller jusqu'à la moitié quand le CTO arrive au tout début du projet. Cette connaissance reste attachée à une personne, si bien que le coût de sortie prend ici la forme d'un départ. Si le CTO quitte l'entreprise ou si l'association se passe mal, la compréhension du produit part avec lui, et c'est pour limiter ce risque qu'un pacte d'associés prévoit les conditions de départ et l'acquisition progressive des parts. Comme tout repose sur cette personne, la choisir prend du temps, souvent plusieurs mois pendant lesquels le produit n'avance pas.

Faire développer son SaaS par une agence ou un studio

Le founder qui ne veut ni céder une part de son capital ni faire reposer son produit sur une seule personne peut confier ces décisions à un prestataire, contre de l'argent cette fois, avec un budget plus important au départ et un peu plus de temps de préparation. Cet investissement évite une partie des difficultés décrites plus haut, à condition que les choix techniques tiennent compte du calendrier, des fonds et de l'ambition du projet.

Exécuter un cahier des charges ou réfléchir au produit

Tous les prestataires ne prennent cependant pas la même part de ces décisions. Certains développent ce que décrit un cahier des charges, avec rigueur, et laissent au founder toutes les décisions sur le produit. D'autres commencent par discuter du marché, du modèle économique et de ce qu'il faut construire en premier, puis proposent une architecture adaptée à ces réponses. Les deux approches existent chez les agences comme chez les studios. Pour un founder qui a une idée solide sans savoir encore comment l'exécuter, la seconde change la nature de la collaboration.

Payer en argent ou en parts

Quant à la rémunération, un prestataire se paie le plus souvent en argent, ce qui laisse au founder la totalité de son capital. Certains acceptent une rémunération en parts, seule ou combinée à un forfait réduit, ce qui préserve la trésorerie du projet et fait du prestataire un associé, avec les mêmes questions de dépendance qu'un CTO. Dans les deux cas, le coût de sortie dépend de ce que le founder récupère à la fin de la mission. Quand il repart avec le code, les accès à l'hébergement et la documentation, il peut continuer avec un autre prestataire ou reprendre le produit en interne. De plus en plus de prestataires travaillent d'ailleurs de cette façon.

Choisir selon son objectif, son calendrier et ses fonds

En somme, le choix revient à croiser ce que le projet doit prouver avec la personne à qui le founder veut confier les décisions. Un founder qui veut tester une idée en quelques semaines avec peu de moyens a intérêt à construire seul, puisque les décisions d'un prototype engagent peu. Celui qui prépare un MVP pour ses premiers clients payants gagne à faire valider ses décisions durables par quelqu'un qui en connaît le coût de sortie. Celui qui vise un produit durable avec des fonds pour le financer peut confier une part plus large des décisions à un prestataire ou à un associé.

Commencer seul puis changer de façon de faire

Ce choix n'est d'ailleurs pas définitif. Beaucoup de SaaS changent de façon de faire en cours de route, et ce passage fait partie de la vie normale d'un produit. Changer de façon de faire revient à changer la personne qui prend les décisions. Un founder qui a validé son idée avec un prototype construit seul garde l'essentiel de ce qu'il a obtenu, ses premiers utilisateurs, leurs données, ce qu'il a appris sur son marché et souvent une bonne partie du design, et le prototype devient la description la plus précise possible de ce qu'il faut construire. L'architecture peut être conservée et consolidée, ou reconstruite sur des bases prévues pour la croissance, selon le coût de sortie des décisions prises au départ.

Chez Nualt

Nous intervenons à chacun de ces moments de la vie d'un SaaS. Certains projets commencent avant toute ligne de code, par une discussion sur le marché, le modèle économique et le périmètre de la première version. D'autres arrivent avec un prototype qui a trouvé ses premiers utilisateurs et qu'il s'agit de transformer en produit. D'autres encore ont besoin de mettre en ligne un MVP dans un délai précis. Dans tous les cas, les décisions d'architecture sont prises avec le founder, en fonction du calendrier et des fonds du projet, et le code, l'hébergement et la documentation appartiennent au client, qui peut continuer avec nous ou sans nous.