J'ai construit deux produits seule avec cette combinaison : Wavestay, une plateforme de réservation d'hébergements pour riders de kitesurf et de surf, et Pulse Outdoor Training Club, de la réservation de sessions de sport en plein air. Même stack dans les deux cas : Lovable pour le build, Claude pour la conception, les arbitrages et les itérations. Ce qui suit n'est pas une démonstration de ce que ces outils savent faire — c'est le partage de la répartition réelle du travail, y compris la part que l'outillage n'a pas réduite d'une minute.
Ce que l'outillage accélère franchement
Le passage de l'intention à l'écran. C'est le gain le plus spectaculaire, et il est réel. Décrire un parcours de réservation et voir une version cliquable dans la foulée change la nature du travail de conception. Tu n'argumentes plus sur une maquette : tu regardes le truc et tu vois immédiatement ce qui cloche. Les allers-retours qui prenaient une semaine tiennent dans une session.
Le contenu. Les libellés, les textes d'aide, les messages d'erreur, les pages légales, les mails transactionnels. Sur un produit construit seule, cette masse de micro-rédaction est un des vrais coûts cachés. La déléguer, en gardant la main sur le ton, libère un temps considérable.
Les itérations de forme. Changer une hiérarchie visuelle, tester deux organisations d'un formulaire, reprendre un enchaînement d'écrans. Le coût de l'essai s'effondre, et ça modifie ton comportement : tu essaies des choses que tu n'aurais pas essayées si chaque test coûtait deux jours.
Le déblocage technique. Quand quelque chose ne fonctionne pas et que je n'ai pas la compétence pour diagnostiquer seule, expliquer le symptôme à Claude et remonter la piste ensemble m'a évité des impasses. Ce n'est pas magique, mais ça remplace des heures de recherche à l'aveugle.
Ce qui n'a pas bougé d'un pouce
Voici la partie que les démonstrations en ligne ne montrent jamais.
Le choix du périmètre. Aucun outil ne décide à ta place ce qui entre dans la V1 et ce qui attend. Et cette décision est de loin la plus structurante du projet. Sur les deux produits, la tentation permanente a été d'ajouter — parce que ça ne coûtait presque rien de le générer. C'est précisément le piège : le coût n'est pas dans la génération, il est dans tout ce qu'il faudra ensuite maintenir, expliquer et corriger. Un écran généré en dix minutes se paie pendant des mois.
La discovery. Comprendre à qui tu t'adresses, ce qu'ils font aujourd'hui à la place, ce qui les bloque réellement. Ça se fait en parlant à des gens. Sur Wavestay, mon avantage n'est pas technique : je suis instructrice de kitesurf, je connais le contexte de l'intérieur, je sais ce qu'un rider regarde avant de réserver. Cette connaissance-là ne se génère pas.
L'exploitation. Une fois en ligne, il y a des utilisateurs qui écrivent, des cas non prévus, des choses à corriger, des décisions à prendre. Personne ne fait ça à ta place. C'est du travail continu, et il commence le jour de la mise en ligne, pas avant.
La responsabilité de ce que tu livres. Si une réservation part de travers, l'explication « c'est l'outil qui l'a écrit » n'existe pas. Tu dois comprendre ce que tu as mis en ligne — pas ligne à ligne, mais dans sa logique.
Six règles de méthode que j'applique maintenant
-
Écrire le périmètre avant d'ouvrir l'outil. Une page. Le problème, l'utilisateur, le parcours principal, et surtout la liste explicite de ce qui n'est pas dans la V1. Sans ce document, la génération assistée devient une machine à élargir le périmètre.
-
Un seul parcours nominal d'abord, complet et propre. De l'arrivée jusqu'à la confirmation. Pas de branches, pas de cas particuliers. Tant que le chemin principal n'est pas irréprochable, ajouter des variantes ne fait qu'épaissir le problème.
-
Séparer la session de conception de la session de build. J'utilise Claude en amont pour arbitrer, challenger le périmètre, dérouler les cas limites, écrire les spécifications d'écran. Puis je passe au build avec une intention claire. Mélanger les deux produit des produits mous, qui dérivent au fil des prompts.
-
Relire la structure de données tôt. C'est le seul endroit où une erreur se paie cher plus tard. Ce qui est bâclé sur un écran se refait ; ce qui est mal modélisé se traîne.
-
Traiter les cas d'erreur explicitement. Ce que voit l'utilisateur quand un paiement échoue, quand une date n'est plus disponible, quand il ferme l'onglet au milieu. Ces cas ne se génèrent pas spontanément — il faut les demander, un par un.
-
Garder une trace des décisions. Pourquoi ce champ est obligatoire, pourquoi ce parcours a été simplifié. Trois semaines plus tard, tu ne t'en souviens plus, et tu défais tes propres arbitrages.
Pour qui c'est le bon choix
Cette approche est très adaptée à un produit dont la valeur tient au parcours et à la connaissance du domaine, pas à une prouesse technique. Une place de marché de niche, un outil interne, un service de réservation : oui. Quelque chose qui exige une architecture de données lourde ou des intégrations profondes avec un système existant : le sujet devient différent, et j'en parle ailleurs.
Le point à retenir
L'assistance déplace l'effort, elle ne le supprime pas. Ce qui coûtait de la fabrication coûte maintenant de la décision. Si tu construis avec cette stack, l'endroit où tu dois investir ton attention n'est plus l'écran : c'est la page où tu écris ce que tu ne feras pas.