En bref — Tes clients sont ta meilleure source d'insights ET ta pire distraction. Guide complet pour passer de freelance à SaaS sans se noyer dans le sur-mesure gratuit.

passer de freelance à SaaS Image : Grant Source — Openverse (by)

En bref — Passer de freelance à SaaS ne se joue pas sur la qualité du code, mais sur la capacité à résister à un piège précis : transformer ses clients existants en commanditaires de fonctionnalités gratuites. Ce guide détaille la méthode pour valider et construire ton produit sans sacrifier ta trésorerie ni ta santé mentale.


Il y a un moment que presque tous les freelances connaissent. Un client dit : « Tu pourrais pas automatiser ce truc qu'on fait à la main ? Je te paie pas plus, mais si tu le fais, je m'en sers tous les jours. » Et toi, tu penses : idée de SaaS. Tu codes le week-end. Tu livres. Le client est content. Il ne paie pas plus. Et toi, tu viens de travailler gratuitement sur un produit que tu n'as pas encore.

C'est comme ça que ça commence. Et c'est exactement là que ça déraille.

Passer de freelance à SaaS, c'est l'une des transitions les plus naturelles du monde maker — et l'une des plus mal exécutées. Pas parce que les freelances manquent de compétences. Parce qu'ils tombent dans des pièges structurels, souvent dès les premières semaines.


Le paradoxe du freelance-maker : tes clients sont ton meilleur insight ET ta pire distraction

Être freelance, c'est un avantage compétitif énorme pour lancer un SaaS. Tu es déjà payé pour résoudre des problèmes réels, dans un secteur précis, pour des gens qui ont un budget. Tu accumules des insights que n'aura jamais un fondateur qui sort de formation ou d'une grande entreprise.

Mais ce même accès crée une dépendance cognitive. Tu commences à confondre ce que tes clients demandent et ce que le marché veut vraiment. Tes cinq clients actuels ne sont pas "le marché". Ce sont cinq échantillons biaisés, avec qui tu as une relation affective et commerciale.

Le danger : tu construis un produit optimisé pour tes clients existants — qui ne deviendront probablement jamais tes premiers abonnés SaaS. Parce qu'ils t'ont déjà, toi, à la demande. Pourquoi payer un outil quand le maker est joignable par SMS ?

C'est le premier niveau du piège. Et il y en a trois autres.


Les 4 pièges qui tuent la transition freelance → SaaS avant même le lancement

Piège n°1 : le sur-mesure gratuit déguisé en MVP

C'est le scénario de l'intro. Tu codes une feature "pour voir". Le client s'en sert. Tu continues. Six mois plus tard, tu as un outil qui tourne en prod chez un seul client, que tu maintiens gratuitement, et qui est trop spécifique pour être vendu à quelqu'un d'autre.

Tu n'as pas fait un MVP. Tu as fait du consulting non facturé.

La règle simple : si tu codes quelque chose pour un client spécifique, facture-le. Si tu codes quelque chose pour un marché, c'est ton produit — et le client ne doit pas dicter les specs.

Piège n°2 : le feature creep client

Tu as une idée de produit générique. Tu en parles à tes clients. Ils adorent. Ils ajoutent des "petites" demandes. Tu intègres, parce qu'ils seront tes premiers utilisateurs. Résultat : ton produit devient une usine à gaz sur-mesure pour trois personnes.

Ce n'est pas de la validation. C'est de la co-construction non payée avec des gens qui ne sont pas représentatifs de ton ICP futur.

Piège n°3 : la dépendance aux revenus services

Tu ne peux pas te permettre de perdre un seul client freelance, donc tu dis oui à tout. Chaque "oui" grignote du temps sur le produit. Quatre mois après avoir "lancé" ton SaaS, tu as 40 heures de code et 400 heures de missions client.

Le produit ne pousse pas. Pas parce que l'idée est mauvaise. Parce que tu n'as jamais vraiment voté avec ton temps.

Piège n°4 : attendre d'avoir un produit parfait pour réduire le freelance

L'inverse du piège 3. Tu gardes 100 % de ton activité freelance parce que "le produit n'est pas encore prêt". Mais un produit n'est jamais prêt. Et tant que tu n'as pas de contrainte financière douce pour valider, tu ne sauras jamais si quelqu'un paiera.

Ces quatre pièges ont un point commun : ils repoussent le moment où tu dois confronter ton produit au réel. Et dans le monde indie, seul le réel compte. Pas le feedback client, pas les étoiles sur Product Hunt — les paiements.

Pour comprendre comment valider une idée avant de coder, les mêmes principes s'appliquent : confronte l'hypothèse au portefeuille, pas aux opinions.


La méthode 20/80 : garder 80 % de son CA freelance pendant la phase de validation

La transition idéale n'est pas un grand saut. C'est une bascule progressive avec un filet de sécurité calculé.

Le principe : pendant les 6 à 12 premiers mois, tu réserves 20 % de ton temps (et pas un jour de plus) à ton produit. Le reste, tu continues à facturer normalement. Tu ne "lances" rien publiquement. Tu valides.

Pourquoi 20 % et pas 50 % ?

Parce que 50 %, c'est assez pour te sentir investi, mais pas assez pour ne pas paniquer à la première mauvaise semaine de trésorerie. Tu prendras de mauvaises décisions produit sous stress financier. Un freelance qui a peur de perdre un client ne peut pas pivoter librement.

Les 20 % servent à trois choses uniquement :

  1. Définir le problème à résoudre (pas la solution)
  2. Construire un prototype ou une landing page testable
  3. Trouver 3 personnes extérieures à ton réseau client qui acceptent de payer pour y accéder — même 1 €

Si tu n'arrives pas à trouver ces 3 personnes avec 20 % de ton temps sur 3 mois, le signal est clair : soit le problème n'est pas assez douloureux, soit tu ne t'adresses pas au bon segment. Tu peux utiliser un outil comme GoNoGo pour structurer cette phase de validation avant de coder quoi que ce soit.

Ce que tu ne fais pas pendant cette phase :

  • Tu n'optimises pas l'UX
  • Tu ne travailles pas sur le pricing définitif
  • Tu ne pitches pas à tes clients freelance existants en mode "je vais faire ça pour toi"

Ce dernier point mérite sa propre section.


Comment utiliser tes clients existants pour valider sans les transformer en co-fondateurs gratuits

Tes clients actuels sont une ressource. Pas des cobayes, pas des commanditaires, pas des associés non déclarés.

La bonne posture : l'observation, pas la co-construction.

Concrètement, ça ressemble à quoi ?

Tu observes, tu notes, tu ne demandes pas encore. Pendant tes missions, tu identifies les points de friction récurrents que tu résous manuellement. Pas ceux qu'un client t'a demandé de résoudre — ceux que tu vois toi-même, projet après projet.

Tu poses des questions de problème, pas de solution. "Quel est ton plus gros casse-tête sur ce sujet ?" vaut cent fois mieux que "Est-ce que tu utiliserais un outil qui ferait X ?". La deuxième question appelle toujours "oui" par politesse.

Tu ne leur proposes rien de spécifique. Dès que tu dis "je bosse sur un truc qui pourrait t'aider", tu crées une attente. Et une attente chez un client existant, c'est une demande de sur-mesure gratuit qui arrive dans les trois semaines.

Si tu veux les impliquer dans la bêta, pose un garde-fou simple : accès bêta contre 30 minutes d'appel mensuel structuré ET contre un pré-paiement symbolique. Le pré-paiement n'est pas pour l'argent — c'est pour le signal. Quelqu'un qui paie 19 € pour un accès bêta prend ça au sérieux. Quelqu'un à qui tu offres l'accès te renverra du feedback poli et inutile.

La distribution de ton produit commencera probablement en dehors de ton réseau freelance. C'est contre-intuitif, mais c'est souvent là que se trouvent tes vrais premiers clients payants — des gens qui n'ont pas de relation affective avec toi, juste un problème à résoudre.

Pour cette phase de distribution, des outils de planification et de publication sur les réseaux sociaux comme PurrPlan peuvent t'aider à maintenir une présence build-in-public sans y passer trois heures par jour — il existe aussi des alternatives comme Buffer ou Typefully si tu préfères un outil généraliste.


Le seuil de bascule : quand couper le cordon avec le freelance ?

C'est la question que tout le monde pose. Et il n'y a pas de réponse universelle — mais il y a des indicateurs précis.

Seuil minimum recommandé avant de réduire sérieusement le freelance :

  • Ton MRR couvre au moins 50 % de ton coût de vie réel (pas de ta vie de rêve — ta vie réelle avec loyer, charges, impôts)
  • Ce MRR est stable depuis 3 mois consécutifs (pas une spike de lancement)
  • Tu as au moins 10 clients payants non issus de ton réseau direct
  • Ton churn mensuel est inférieur à 5 % sur les deux derniers mois

Ces quatre conditions ensemble — pas une seule — te donnent un signal réel. Un MRR de 2 000 € avec 80 % de churn le deuxième mois, c'est une illusion.

Deux scénarios de bascule :

Bascule progressive : tu réduis le freelance à 60 %, puis 40 %, puis 20 % sur 12 à 18 mois, en parallèle de la montée du MRR. Moins risqué, plus long, psychologiquement plus sain.

Bascule franche : tu fixes une date limite. "Dans 6 mois, je coupe le freelance, que le produit soit là ou pas." Ça crée une contrainte réelle qui force les décisions. Certains makers ont besoin de cette pression pour arrêter de procrastiner sous couverture de "garder un filet". Mais elle demande une épargne de sécurité équivalente à 6 mois de charges fixes minimum.

Les deux fonctionnent. Ce qui ne fonctionne pas : rester indéfiniment dans le "je garde le freelance pour financer le produit" sans jamais poser de seuil. C'est le statu quo habillé en stratégie.

Pour suivre tes premiers deals et leads produit quand tu commences à closer — sans CRM surdimensionné — un outil léger comme Fennec peut suffire au début. Simple, fait pour les indépendants qui débutent leur pipeline commercial.


Ce que la transition révèle sur toi (et c'est utile)

La phase de chevauchement freelance / SaaS est révélatrice. Elle te force à répondre à des questions que la posture freelance permettait d'esquiver :

  • Est-ce que tu construis quelque chose que tu veux vraiment, ou est-ce que tu fuis le freelancing ?
  • Est-ce que tu sais dire non à un client existant ?
  • Est-ce que tu peux tenir une roadmap sans que quelqu'un te dicte les priorités ?

Ce ne sont pas des questions philosophiques. Ce sont des compétences opérationnelles. Un indie maker est quelqu'un qui sait arbitrer son propre temps sans manager externe. Si tu n'arrives pas à protéger tes 20 % de temps produit contre les demandes client, tu ne protégeras pas non plus ton produit contre le feature creep une fois lancé.

C'est pour ça que la transition freelance → SaaS est autant une question de posture que de mécanique. Tu trouveras d'autres guides sur la mécanique du bootstrapping. Mais la posture, tu la travailles en shippant.


À retenir

  • Tes clients freelance sont des sources d'observation, pas des co-fondateurs. Observe, ne co-construis pas.
  • Le sur-mesure gratuit est du consulting non facturé. Si tu codes pour un seul client, facture-le.
  • La méthode 20/80 : 20 % de ton temps sur le produit, 80 % sur le freelance pendant la validation. Pas de grand saut avant les premiers signaux payants réels.
  • Le seuil de bascule : MRR stable à 50 % du coût de vie sur 3 mois, 10+ clients hors réseau direct, churn < 5 %.
  • Le feedback poli ne vaut rien. Le pré-paiement, même symbolique, est le seul signal qui compte.
  • Fixe une date ou un seuil de bascule explicite. "Je verrai bien" n'est pas une stratégie.
  • Distribue hors de ton réseau existant dès la phase de validation. C'est là que vivent tes vrais premiers clients.

Ce guide fait partie de la collection guides bootstrapping de graine de startup. Si tu veux creuser la mécanique de productisation, commence par valider ton idée avant de coder — le piège du sur-mesure gratuit commence souvent là.

Le studio derrière ce média : Sébastien De Bollivier — produits bootstrappés, zéro VC.