Pendant longtemps, ma façon de gagner ma vie était simple : quelqu'un avait une idée, je la codais, on me payait, et on passait au suivant.
C'est un bon modèle. Honnêtement. Ça m'a appris énormément, ça m'a payé mes factures et ça m'a mis face à des vrais clients avec des vrais problèmes. Mais un jour, en livrant un projet, je me suis posé une question qui ne m'a plus quitté :
Si je m'arrête demain, il reste quoi ?
La réponse était : rien. Le code appartenait au client. La relation s'arrêtait à la livraison. Et le mois suivant, je repartais de zéro.
Le piège invisible du « je suis payé à l'heure »
Quand tu vends ton temps, ton revenu a un plafond, et ce plafond, c'est le nombre d'heures dans une journée. Tu peux augmenter ton tarif, tu peux travailler plus vite, mais tu restes la pièce centrale. Si tu tombes malade, tout s'arrête.
Le pire, c'est que ce modèle est confortable. Il y a toujours un client qui attend, toujours une urgence, toujours une bonne raison de remettre à plus tard « ton » projet. J'ai passé des mois à dire « je lancerai mon produit quand j'aurai le temps ».
On n'a jamais le temps. On le prend.
Le déclic : un produit travaille pendant que tu dors
Ce qui m'a fait basculer, c'est de voir la différence entre un service et un produit :
- Un service, tu le revends à chaque fois, et chaque vente te coûte du temps.
- Un produit, tu le construis une fois, puis tu l'améliores. Chaque nouvel utilisateur ne te coûte presque rien de plus.
Avec Sellify, puis Biolinko, puis Motriks et EVP, j'ai commencé à construire des choses qui m'appartiennent. Des choses qui continuent d'exister quand je ferme mon ordinateur.
Ce que j'ai dû désapprendre
Passer de développeur à entrepreneur, ce n'est pas juste « coder pour soi ». C'est changer de cerveau. Voilà ce que j'ai dû laisser tomber :
1. Vouloir que tout soit parfait avant de montrer.
En tant que dev, j'aimais le code propre, l'architecture bien pensée. C'est toujours important. Mais un produit parfait que personne n'utilise ne vaut rien. Aujourd'hui je préfère sortir une version simple qui résout un vrai problème, puis l'améliorer avec les retours.
2. Penser que la technique est la partie difficile.
Elle ne l'est pas. La partie difficile, c'est de trouver qui a vraiment le problème, de lui parler, de le convaincre d'essayer, et de le garder. Le code, c'est peut-être 30 % du travail.
3. Attendre qu'on me donne le cahier des charges.
Quand tu es freelance, le client te dit quoi faire. Quand tu construis ton produit, personne ne te dit rien. C'est à toi d'aller sur le terrain, d'écouter, et de décider.
Ce que je garde du freelance
Je ne crache pas sur mes années de prestation. Elles m'ont donné trois choses que j'utilise chaque jour :
- La rigueur de livraison : un client qui paie veut une date. Je m'impose la même discipline sur mes produits.
- L'écoute : j'ai appris à comprendre ce que les gens veulent dire derrière ce qu'ils demandent.
- La polyvalence : backend, frontend, serveur, base de données. Quand tu lances un produit seul, tu ne peux pas attendre quelqu'un d'autre.
Si tu es dev et que tu hésites
Tu n'as pas besoin de tout quitter du jour au lendemain. Moi-même je ne l'ai pas fait. Commence petit :
- Garde une source de revenu stable.
- Bloque quelques heures par semaine, vraiment bloquées, pour ton produit.
- Choisis un problème que tu as vu de tes yeux, pas une idée que tu trouves « cool ».
- Sors une première version en semaines, pas en mois.
- Montre-la à de vraies personnes, même si elle est moche.
Le jour où ton produit t'apporte son premier utilisateur qui n'est ni ta mère ni ton pote, tu comprends pourquoi ça vaut le coup.
Moi, je n'ai pas fini d'apprendre. Mais je sais une chose : je préfère construire quelque chose qui m'appartient, même lentement, que de passer ma vie à construire celles des autres.
