Début 2025, j'ai lancé mon premier produit auprès du public. Pas un projet client, pas un prototype qui vivait sur mon ordinateur : un produit à nous, construit de zéro, avec de vraies personnes qui s'inscrivaient. À la fin de la même année, on l'a mis au placard.
Ce n'était pas un produit mal fait, ni une équipe qui s'est défaite, ni une idée à laquelle personne ne croyait. On avait presque tout ce qui est censé compter. Et pourtant, ça n'a pas avancé. Cet article est une tentative d'expliquer pourquoi, aussi honnêtement que possible, du point de vue de celui qui était responsable de le construire.
Ce qu'on avait
Le produit était une plateforme web et mobile pour nutritionnistes et coachs sportifs : un endroit pour prescrire des plans alimentaires et des entraînements, suivre la progression de chaque client et gérer les rendez-vous, le tout dans une seule app.
On formait un bon groupe d'associés, chacun avec un rôle bien défini. J'étais le « CTO », entre guillemets, parce que le titre est généreux pour une entreprise de cette taille. On avait des contacts dans le marché qu'on visait. On l'a construit de zéro, on l'a lancé, et on a enchaîné les réunions qui suivent un lancement. On s'est même assis avec des investisseurs : des discussions et des négociations, pas d'argent au final, mais un vrai intérêt pour ce qu'on avait construit.
Si vous m'aviez montré cette liste avant qu'on commence, j'aurais dit que c'était une bonne position. Produit, équipe, réseau, lancement, intérêt d'investisseurs. La plupart des projets que j'avais vus mourir n'en avaient pas la moitié.
Là où je pensais que se trouvait le risque
En tant que celui qui le construisait, je pensais que le risque était surtout technique. L'app sera-t-elle stable ? Les paiements vont-ils fonctionner ? Est-ce que ça tiendra quand les gens l'utiliseront vraiment ? C'étaient les questions sur lesquelles je dépensais le plus d'énergie, et c'étaient celles auxquelles je savais répondre.
Avec le recul, c'était l'endroit le plus confortable où placer le risque. C'était la partie que je contrôlais. Si le problème était technique, je pouvais le régler avec plus de travail. Je n'avais pas de plan pour le cas où le produit fonctionnerait et où les gens ne viendraient quand même pas.
Là où ça a bloqué
Certaines personnes sont venues. Quelques professionnels ont utilisé la plateforme avec leurs propres clients dessus. Ce n'est donc pas vrai que le produit n'a marché pour personne. Il n'a simplement jamais atteint le point où il pouvait grandir tout seul.
On a essayé les canaux habituels : Meta Ads, Google et le contact direct avec des gens du secteur. Le problème n'était pas d'avoir choisi le mauvais canal. C'était ce que le client trouvait de l'autre côté de chaque canal : un marché avec des concurrents installés, qui se démarquaient plus que nous.
Et quand les gens nous essayaient, on se heurtait à deux choses que j'avais sous-estimées. La première, c'était le support. Un professionnel qui fait tourner une partie de son activité sur votre app a besoin de réponses rapides, et on était en défaut là-dessus. La seconde, c'étaient des features auxquelles on n'avait tout simplement pas pensé : les edge cases de l'usage réel, les choses qui n'apparaissent que quand la vraie routine de quelqu'un rencontre votre produit. Chacune était petite. Ensemble, elles faisaient la différence entre essayer le produit et y rester.
Rien de tout ça n'est un problème de code. J'aurais pu écrire un meilleur code, et rien sur cette liste n'aurait changé.
Comment ça s'est terminé
Il n'y a pas eu de jour où il est mort. Le produit s'est éteint petit à petit, et à un moment, une conversation entre associés a rendu officiel ce qui était déjà vrai. Fin 2025, on l'a mis au placard.
Être le « CTO » de quelque chose qui n'a clairement pas marché est une sensation étrange. La partie dont vous étiez responsable a tenu. L'entreprise, non. Et on commence à voir que la frontière entre les deux n'a jamais été aussi nette qu'on le croyait.
Ce que je ferais aujourd'hui
Si je recommençais aujourd'hui, je sais par où je commencerais, et ce ne serait pas par le code.
- Valider la thèse avant de construire. Pas savoir si les gens aiment l'idée, mais si le marché a vraiment besoin de ce produit, venant de nous, au point de quitter ce qu'il utilise déjà.
- La distribution dès le premier jour. Pas comme une phase qui commence quand le produit est prêt, mais comme une partie du produit. Qui va en entendre parler, et pourquoi nous croirait-on ?
- Le positionnement. Dans un marché avec des concurrents installés, « on fait ça aussi » n'est pas une raison de changer. Savoir exactement pour qui c'est, et pourquoi c'est mieux pour ces personnes, est un travail qui doit se faire avant la première pub.
- Build in public. Montrer le travail pendant qu'il se fait, pour que les gens voient qu'il est bon. La confiance dans un produit commence souvent comme une confiance dans ceux qui le construisent, et cette confiance prend plus de temps à bâtir que n'importe quelle feature.
- Le support comme partie du produit. Pour quelqu'un qui fait tourner son propre travail sur votre plateforme, la rapidité de votre réponse fait partie de ce qu'il paie.
Ce que j'en ai retenu
Dans mon dernier article, j'écrivais qu'à un moment donné, écrire du code cesse d'être la partie difficile. C'est ici que je l'ai appris, et ça m'a coûté cher. On a construit le produit. Ce qu'on n'a pas construit, c'est une raison pour que quelqu'un le choisisse.
Je porte encore ça dans ma façon de travailler sur des produits aujourd'hui. Pas comme « les ingénieurs doivent faire du marketing », mais comme des questions que je pose bien plus tôt qu'avant : pour qui c'est, comment ces personnes vont le trouver, et pourquoi elles lui feraient confiance ? Le code répond à beaucoup de questions. Pas à celles-là.
On a construit le produit. La distribution, c'était le produit.