Depuis quelques années maintenant, je développe et maintiens Nomisora, un SaaS destiné aux professionnels de la santé et du bien-être. Pas de levée de fonds, pas d’équipe, pas de bureau design. Juste moi, mon ordinateur, et l’envie de construire quelque chose qui serve vraiment.
Ce n’était pas ma première tentative de side project. J’en ai déjà abandonné avant. Mais celle-ci a tenu. Elle génère du revenu, elle a des utilisateurs actifs, et surtout, elle m’a appris plus que toutes mes années de freelance réunies.
Cet article, c’est le retour d’expérience que j’aurais aimé lire avant de me lancer. Pas de success story romancée, pas de chiffres gonflés. Juste ce qui a marché, ce qui a foiré, et ce que je referais différemment.
Pourquoi j’ai voulu créer un SaaS
La raison principale était simple : sortir du modèle temps contre argent. En freelance, même bien payé, tu restes limité par le nombre d’heures dans une journée. Tu pars en vacances, tu ne factures pas. Tu es malade, pas de revenu. Le SaaS, c’est l’inverse : tu construis une fois, tu vends plusieurs fois.
Mais il y avait aussi une dimension plus personnelle. Après dix ans à coder pour les projets des autres, je voulais prendre mes propres décisions techniques. Choisir ma stack sans négocier avec un CTO. Refactorer quand ça me semblait nécessaire, pas quand le planning le permettait.
Et puis, il y avait cette frustration récurrente : voir mes clients faire des choix produit que je savais mauvais, mais ne pas avoir le dernier mot. Avec mon propre SaaS, les erreurs seraient les miennes. Les réussites aussi.
La phase d’idée : trouver le bon problème
J’ai passé presque un an à chercher “la bonne idée”. C’était une erreur.
La vérité, c’est qu’il n’y a pas d’idée parfaite qui attend d’être trouvée. Il y a des problèmes réels, vécus par des gens réels, qui ont besoin de solutions. Le reste, c’est de l’exécution.
Nomisora est née d’une conversation avec un ami praticien. Il me racontait son enfer administratif : gestion de patients, prises de rendez-vous, facturation, suivi de dossiers. Il utilisait plusieurs outils différents, aucun n’était pensé pour son métier. Il payait des abonnements pour des fonctionnalités dont il n’avait pas besoin, et devait bricoler pour celles qui lui manquaient.
Ce qui m’a convaincu, ce n’était pas l’originalité de l’idée. Des logiciels de gestion de cabinet, il en existe des dizaines. C’était sa réaction quand je lui ai proposé de lui montrer une maquette : “Si tu fais ça, je paye tout de suite.”
Cette phrase a tout changé. Je ne cherchais plus une idée géniale. Je cherchais quelqu’un prêt à sortir sa carte bleue.
Avant d’écrire la moindre ligne de code, il en a parlé à une plusieurs confrères. Même problème partout : des outils généralistes qui ne collent pas à leur réalité métier, ou des solutions sur-mesure hors de prix.
La validation, ce n’était pas qu’ils trouvent l’idée intéressante. C’était qu’ils me demandent quand ce serait prêt.
Les choix techniques : pragmatisme avant purisme
J’ai choisi ma stack avec un seul critère : la vitesse de développement. Pas la hype, pas ce qui ferait bien sur mon CV, pas ce qui impressionnerait sur Linkedin. Ce qui me permettrait d’expédier le plus vite.
Nuxt.js : J’ai hésité avec Next.js. L’écosystème React est plus gros, mais Nuxt avait tout ce qu’il me fallait out of the box. File-based routing, server-side rendering, modules officiels pour tout (auth, i18n, SEO). Moins de décisions à prendre, moins de temps perdu à configurer.
Avec le recul, c’était le bon choix. La convention over configuration de Nuxt m’a fait gagner des semaines. Quand tu es seul, chaque heure compte.
TypeScript : Non négociable. TypeScript, c’est ton deuxième cerveau. Il te rattrape avant que tu déploies une connerie en production. Quand tu codes seul, sans code review, c’est ton filet de sécurité.
Drizzle ORM : J’ai choisi Drizzle plutôt que Prisma pour une raison simple : le contrôle. Drizzle reste proche du SQL, il ne cache rien. Pas de magie noire, pas de requêtes générées que tu ne comprends pas. Et surtout, Drizzle est léger. Prisma ajoute un runtime, une couche d’abstraction, des megabytes au bundle. Drizzle, c’est juste du TypeScript qui génère du SQL propre.
PostgreSQL : Base relationnelle classique. J’ai regardé du côté des bases serverless. Mais au final, Postgres fait le job depuis longtemps. C’est stable, c’est rapide, c’est documenté partout. Et si je veux migrer, mes données restent portables.
Hébergement : J’ai commencé sur un VPS chez Ikoula. Pas de serverless, pas de cloud fancy. Un serveur basique avec Docker Compose. Ça m’a coûté vingt fois moins cher que AWS pour les mêmes performances. Aujourd’hui, je pourrais migrer vers du cloud managé si le scale l’exigeait. Mais pour démarrer, c’était largement suffisant.
L’approche MVP : ce que j’ai construit en premier
Le piège classique du développeur qui lance un SaaS, c’est de vouloir tout construire avant de montrer quoi que ce soit. J’ai failli tomber dedans.
Mon premier MVP, c’était le strict minimum pour qu’un professionnel puisse gérer son cabinet au quotidien : connexion, dashboard basique, gestion de patients, envoi et export PDF des factures.
C’est tout. Pas de paiement en ligne, pas d’API publique, pas de système de notifications push, pas de dark mode, pas d’onboarding interactif.
Ça m’a pris un mois, en parallèle de mes missions freelance. Un mois à coder sur mon temps libre.
La tentation de rajouter des features était constante. “Ce serait cool si…”, “Il faudrait aussi…”, “Les utilisateurs vont vouloir…”. À chaque fois, je me forçais à poser la question : est-ce que quelqu’un ne peut PAS utiliser le produit sans ça ?
Si la réponse était non, ça attendrait.
Ce qui m’a sauvé, c’est d’avoir montré cette première version très tôt à mes premiers utilisateurs potentiels. Leur feedback était clair : c’est déjà utilisable, on veut tester. Ils se fichaient qu’il n’y ait pas de dark mode. Ils voulaient juste arrêter de jongler entre Excel et leurs agendas papier.
Les plus grosses erreurs
Ne pas structurer la prospection (alors que le produit est prêt)
J’ai fait un truc bien : j’en ai parlé dès le début. Mon premier client est arrivé presque immédiatement. Le produit plaît, le bouche-à-oreille fonctionne à petite échelle. Quand quelqu’un teste, il reste.
Le problème, c’est ce qui vient après. Le site est en ligne depuis six mois. Le produit tourne. Mais je n’ai toujours pas mis en place une vraie stratégie d’acquisition. Pas de process de prospection structuré. Pas de contenu régulier. Pas de tunnel clair.
Pourquoi ? Parce que je suis développeur. Coder une feature, c’est confortable. Écrire un email de prospection, créer du contenu marketing, définir un tunnel d’acquisition, c’est un autre métier. Et comme c’est inconfortable, je procrastine. Je me dis “je ferai ça la semaine prochaine” et je retourne coder une feature dont personne n’a encore besoin.
Le marketing, ce n’est pas juste “parler du produit”. C’est comprendre ton audience, créer du contenu qui résonne, tester des canaux, analyser ce qui marche. C’est technique, c’est itératif, c’est mesurable. Exactement comme le code. Mais ça demande une discipline différente, et c’est là que je pêche.
La leçon est claire : avoir un bon produit ne suffit pas. Si tu n’investis pas autant d’énergie dans l’acquisition que dans le développement, tu te retrouves avec un outil solide que personne ne connaît. C’est exactement là où j’en suis, et c’est le prochain chantier.
Ce qui a vraiment marché
La niche ultra-précise
Nomisora ne s’adresse pas à “tous les professionnels de santé”. Elle vise un segment très spécifique : les praticiens en médecines alternatives et complémentaires, en exercice libéral, seuls ou en petit cabinet.
Cette précision, c’est ce qui a fait la différence. Mon message marketing est clair. Mes features sont pensées pour eux. Mon pricing correspond à leur réalité économique.
Le pricing simple et transparent
Un seul plan. Un prix fixe par mois. Pas de freemium, pas de tiers complexes. Plus simple à gérer. Et pour mes utilisateurs aussi. Ils savent exactement ce qu’ils payent, et pourquoi.
Le support direct
Chaque utilisateur a mon email. Ils peuvent m’écrire directement. Pas de chatbot, pas de ticket system.
C’est chronophage ? Pas encore. Ça scale mal ? Probablement. Mais c’est ce qui a créé la confiance. Et c’est comme ça que j’ai découvert les vrais problèmes à résoudre. Les meilleures features de Nomisora viennent de conversations par email avec des utilisateurs.
Leçons pour les développeurs qui veulent se lancer
Commence petit, vraiment petit. Ton MVP est probablement trop gros. Divise-le par deux. Puis encore par deux. Garde uniquement ce sans quoi le produit ne fonctionne pas. Tu ajouteras le reste quand tu auras des utilisateurs qui te le demanderont.
Choisis une stack que tu maîtrises. Ce n’est pas le moment d’apprendre Rust ou d’essayer le dernier framework hype. Prends les outils avec lesquels tu es le plus productif. La stack parfaite n’existe pas. La stack qui te fait expédier vite, oui.
Parle à tes utilisateurs, tout le temps. Pas des utilisateurs imaginaires. Des vraies personnes, avec des vrais problèmes, qui sortiraient leur carte bancaire si tu résolvais leur douleur. Dix conversations valent mieux que mille heures de réflexion dans ton coin.
Lance avant d’être prêt. Tu ne seras jamais prêt. Il y aura toujours un bug à corriger, une feature à ajouter, un pixel à aligner. Lance quand c’est utilisable, pas quand c’est parfait. Le feedback réel vaut mille fois plus que ton intuition.
Accepte la solitude. Créer un SaaS en solo, c’est solitaire. Il n’y a personne pour te dire si tu vas dans la bonne direction. Trouve une communauté. Un groupe de makers, un slack de fondateurs, un ami qui fait la même chose. N’importe quoi, mais ne reste pas seul dans ta tête.
Gère ton énergie, pas ton temps. Tu ne peux pas coder efficacement douze heures par jour. Trouve ton rythme. Pour moi, c’était deux heures le matin avant mes missions freelance, et quelques heures le week-end. Moins que ce que je voulais, mais soutenable sur la durée. Mieux vaut avancer lentement pendant deux ans que sprinter pendant trois mois et abandonner.
FAQ
Combien de temps avant les premiers revenus ?
Dès le lancement de la première version utilisable. Mais j’avais pré-vendu à quelques personnes pendant le développement. Si tu attends d’avoir un produit fini pour chercher des clients, tu vas attendre longtemps.
Faut-il arrêter son job pour lancer un SaaS ?
Non. Vraiment, non. Garde ton revenu stable. Lance ton SaaS à côté. Quand il génère suffisamment pour réduire tes missions, là tu pourras ajuster. L’argent, c’est de la liberté. La liberté, c’est ce qui te permet de construire sans pression, sans compromis. Ne la sacrifie pas trop tôt.
Comment tu gères la motivation quand personne n’utilise ton produit ?
Je me concentre sur les métriques que je contrôle. Je ne peux pas forcer les gens à s’inscrire. Mais je peux envoyer dix emails par semaine. Je peux publier du contenu. Je peux améliorer l’onboarding. Et je célèbre les petites victoires. Un nouvel inscrit, un utilisateur qui revient, un email de remerciement.
Si tu devais recommencer, tu changerais quoi ?
Je mettrais en place un process de prospection dès le premier mois, en parallèle du développement. Pas “quand le produit sera prêt”, pas “quand j’aurai le temps”. Dès le début, 50/50 : une journée sur le produit, une journée sur l’acquisition. Créer du contenu, tester des canaux, structurer un tunnel. Le code, c’est la partie facile. Trouver des clients de manière régulière et prévisible, c’est le vrai boulot.