J’ai construit ce produit entièrement seul, surtout le soir, le week-end et pendant plus de jours fériés que je ne voudrais l’admettre. Pendant longtemps, cela a malgré tout gardé l’allure d’un projet personnel qui se trouvait simplement être accessible sur le Web.
L’activation des paiements a immédiatement changé cette impression. Le code n’est pas devenu soudainement plus sophistiqué, mais ma responsabilité vis-à-vis du produit, elle, a changé. À partir du moment où quelqu’un peut payer, un parcours cassé n’est plus seulement un edge case inachevé. L’onboarding, la modération, la rétention, la confiance et la fiabilité cessent d’être des sujets pour plus tard. Ils font partie de ce que le produit promet maintenant.
C’est la principale leçon que je retiens du lancement : construire seul un projet riche en fonctionnalités et exploiter un vrai produit sont deux métiers différents.
En solo, l’attention est devenue le vrai goulot d’étranglement
Pendant que je construisais le produit, j’ai presque disparu des réseaux sociaux. Ce n’était pas une stratégie de lancement. Les décisions produit, l’implémentation, les edge cases, les tests de parcours et la préparation de la release se disputaient tous les mêmes heures limitées.
Je comprends beaucoup mieux aujourd’hui cette partie du développement en solo. Le goulot d’étranglement n’est pas toujours la vitesse à laquelle j’écris du code. C’est la quantité d’attention que je peux consacrer à un nombre croissant d’états, de transitions et de modes de défaillance dans le produit.
Un build réussi ne répond pas à ces questions. Un paiement réussi non plus.
Les paiements ont changé ma définition d’un bug
Avant les paiements, je pouvais encore considérer certaines imperfections comme des choses que je corrigerais plus tard. Une fois les paiements activés, ce modèle mental ne fonctionnait plus pour moi. Un produit payant n’a pas besoin d’être exempt de bugs ; ce ne serait pas réaliste. Mais le coût d’un problème connu laissé sans solution change quand quelqu’un a déjà confié son argent au produit.
Il en va de même pour l’onboarding et la modération. Pendant le développement, ils peuvent sembler être des systèmes de soutien autour de la « vraie » fonctionnalité. En production, ils font partie de cette fonctionnalité parce que les utilisateurs les vivent directement. La rétention suit la même logique : une bonne première session ne prouve pas que le produit donne une raison de revenir.
Les paiements n’ont pas prouvé que le produit était terminé. Ils ont révélé tout le travail que le mot « terminé » cachait.
Le lancement m’a donné un autre type d’information
Après la mise en ligne est arrivé le travail moins photogénique : les bugs visibles seulement après publication, les parcours cassés, les problèmes de modération qui deviennent concrets quand les utilisateurs arrivent, et les questions de rétention bien plus difficiles que la création d’une bonne première impression.
J’essaie de ne pas surinterpréter ces signaux. Un bug après la release ne signifie pas automatiquement que l’architecture est mauvaise. Un problème de rétention n’est pas, à lui seul, un diagnostic de product-market fit. Un problème de modération ne prouve pas que tout le système est dangereux. Un symptôme me dit où chercher ; il ne m’explique pas automatiquement la cause.
Ce qui change, c’est la qualité des preuves. Avant le lancement, je peux tester ce que je m’attends à voir faire par les utilisateurs. Après le lancement, je dois composer avec ce qu’ils font réellement. Une release n’est pas le moment où l’incertitude disparaît. C’est le moment où une partie de l’incertitude la plus importante devient enfin observable.
La boucle post-lancement que j’utilise maintenant
Je m’intéresse davantage aujourd’hui au travail après le lancement qu’à la mise en scène du lancement lui-même : enseignements sur les paiements, parcours cassés, défis de modération, comportement des utilisateurs, surprises de rétention et petites corrections qui rendent progressivement le produit plus fiable.
- Observer le vrai parcours. Ne pas supposer que le chemin que j’ai conçu est celui que les utilisateurs suivent réellement.
- Séparer symptômes et causes. Une étape qui échoue indique où quelque chose s’est mal passé, pas automatiquement pourquoi.
- Prioriser les défaillances qui touchent à la confiance. Paiements, accès, onboarding et modération sont plus urgents pour moi que les imperfections cosmétiques, car leur coût d’échec est plus élevé.
- Corriger d’abord le plus petit problème confirmé. Je préfère supprimer une source de friction vérifiée plutôt que redesign un système autour d’une hypothèse.
- Revalider l’expérience utilisateur après le correctif. Une modification de code peut être correcte et pourtant ne pas résoudre le problème vécu par l’utilisateur.
Ce n’est pas un framework universel. C’est simplement la discipline qui me paraît la plus logique depuis que je suis passé de la construction du produit à son exploitation.
Le lancement a changé ma source de vérité
La distinction qui compte le plus pour moi aujourd’hui est celle entre avoir construit le produit et être prêt à l’exploiter. Construire revient à demander si le système fait ce pour quoi je l’ai conçu. Exploiter revient à demander ce qui se passe lorsque de vraies personnes l’utilisent, le comprennent mal, le quittent, y reviennent, paient ou empruntent un chemin que je n’avais pas prévu.
C’est pour cela que je ne vois plus le lancement comme une ligne d’arrivée. Avant, la plupart des preuves viennent de mes propres hypothèses et de mes tests. Après, le produit commence à répondre par des comportements réels, des échecs et des usages répétés.