Pulse Outdoor Training Club permet de réserver des sessions de sport en plein air. Le produit est en ligne depuis mars. Je l'ai conçu, construit et mis en production seule, avec Lovable pour le build et Claude pour la conception et les itérations. Je raconte ici le déroulé réel, dans l'ordre, y compris les endroits où je me suis trompée — parce que c'est la seule partie qui a une valeur transposable.
Pourquoi je construis mes propres produits
Autant commencer par là, parce que la question m'est posée souvent. J'accompagne des dirigeants sur des sujets IA et produit. Je leur demande de faire des choses inconfortables : couper un périmètre, sortir une version incomplète, décider sans avoir toutes les informations.
Je ne veux pas leur demander ça depuis un tableau blanc. Construire mes propres produits, avec les mêmes contraintes de temps et d'arbitrage, me maintient dans la position de celle qui décide et qui assume. Ça change ce que je peux dire en mission, et ça change surtout ce que je ne dis plus — quantité de conseils propres sur le papier ne survivent pas à leur première confrontation avec un vrai produit à sortir.
Le cadrage : deux semaines à écrire, pas à construire
Je n'ai rien ouvert pendant les premiers jours. J'ai écrit.
Le document tenait en une page et demie : à qui ça s'adresse, ce que ces personnes font aujourd'hui à la place, quel est le parcours principal — trouver une session, la réserver, la payer, la retrouver. Puis, en dessous, la partie la plus utile du document : la liste de ce qui ne serait pas dans la première version.
Cette liste a été plus difficile à écrire que le reste. J'y ai mis des choses que j'avais très envie de faire. Le fait qu'elles soient devenues faciles à produire techniquement n'a rien changé au raisonnement : chaque élément ajouté est un élément à maintenir, à expliquer et à corriger pendant des mois.
Le design et le build : rapide, et pas là où je croyais
Le premier parcours cliquable est arrivé vite. C'est la partie de l'histoire qui impressionne, et elle est vraie : passer d'une intention écrite à un enchaînement d'écrans qu'on peut réellement parcourir prend des heures, pas des semaines.
Ma méthode s'est stabilisée en deux temps. D'abord une session de conception avec Claude : je déroule les cas limites, je me fais contredire sur des choix de parcours, j'écris les spécifications d'écran. Ensuite seulement, le build. Quand j'ai mélangé les deux — prompter en construisant, au fil de l'idée — j'ai produit des enchaînements mous qu'il a fallu défaire.
Le point que je n'avais pas anticipé : le gain de vitesse sur la fabrication rend la dérive de périmètre beaucoup plus facile. Ajouter un écran ne coûte plus rien sur le moment. La discipline doit donc venir d'ailleurs que du coût — d'un document écrit avant, qu'on relit quand on est tenté.
Ce qui a pris plus de temps que prévu
Trois choses, très nettement.
Les cas d'erreur. Le chemin nominal a été fini rapidement. Puis est venu tout le reste : le paiement qui échoue, le créneau réservé par quelqu'un d'autre pendant que tu remplis le formulaire, l'utilisateur qui revient sur une page expirée, l'annulation. Ces cas ne se produisent pas spontanément — il faut les lister et les demander un par un. Ils ont représenté une part du travail bien supérieure à ce que j'avais estimé.
Les mails transactionnels et le contenu de service. Confirmation, rappel, annulation, remboursement. Chacun est court. Ensemble, ils forment un système à écrire, à tester, à faire partir au bon moment. C'est un chantier à part entière, et je l'avais rangé mentalement dans les « détails de fin ».
Le passage en production. Le nom de domaine, le paiement réel, les conditions, la conformité de base sur les données, les tests avec de vrais moyens de paiement. Rien de difficile individuellement. Mais c'est une longue série de petites choses dont aucune ne se génère, et pendant laquelle le produit n'avance pas visuellement — ce qui est démoralisant quand on travaille seule.
Depuis la mise en ligne
Ce qui change une fois en ligne, c'est la nature du travail. Avant, je décidais. Maintenant, j'observe et je corrige.
Je ne publierai pas de chiffres ici : ce n'est pas le sujet de l'article, et un ordre de grandeur sorti de son contexte ne t'apprendrait rien d'utile. Ce que je peux dire, c'est que les ajustements post-lancement ont porté sur des choses que je n'avais pas vues venir en conception — des formulations ambiguës, un moment du parcours où les gens hésitent, des questions qui reviennent et qui signalent une information mal placée.
C'est aussi la partie que la vitesse de construction ne réduit pas. Sortir vite ne fait pas gagner de temps sur l'exploitation ; ça la fait juste commencer plus tôt.
Ce que j'en tire pour les projets que j'accompagne
Trois convictions renforcées, et une nuancée.
- Le document de périmètre écrit avant d'ouvrir l'outil est le meilleur investissement du projet.
- Le chemin nominal d'abord, complet et propre, avant toute variante.
- Les cas d'erreur et le contenu de service sont du travail à part entière : ils doivent être dans le plan, pas dans la marge.
La nuance : je croyais que l'assistance permettrait de sauter des étapes de conception. Elle permet de les faire plus vite, ce qui n'est pas la même chose. Là où j'ai voulu en sauter, j'ai payé plus tard, avec intérêts.
Ce que je ferais différemment demain
Je bloquerais une journée entière, dès le cadrage, sur la seule question des cas d'erreur et des messages qui les accompagnent. C'est le poste de travail le plus sous-estimé d'un produit construit seul, et c'est celui qui détermine ce que ressent la personne qui l'utilise le jour où quelque chose ne se passe pas comme prévu.