Lovable, Bolt, v0

Comment ça marche

On ouvre l’outil, on décrit l’application en français : « un outil pour que mes commerciaux saisissent leurs visites, avec une liste par client et un tableau de bord par mois ». Quelques minutes plus tard, l’application existe, avec son interface, sa base de données et une adresse web. On la teste, on demande des changements en langage courant, on ajoute une fonction, on change une couleur. Le code est récupérable, et peut être repris par un développeur ou par un agent de code.

Ces outils ont rendu la création d’applications accessible à tous, et c’est une rupture réelle. Leur bon usage tient en une règle : ce qu’ils produisent est un prototype, parfois un outil interne simple, jamais directement un produit. Avant d’exposer l’application à des clients ou d’y mettre des données sensibles, le code se relit, se teste et se sécurise, par un développeur ou par un agent de code supervisé. La valeur est dans la vitesse de la première version, et dans ce qu’elle permet de valider.

Un exemple concret

1. Heure 1, Lovable : la dirigeante décrit un portail où ses clients voient leurs locations en cours, téléchargent leurs factures et demandent une prolongation. Un prototype fonctionnel, avec des données fictives, existe à midi.
2. Semaine 1 : le prototype est montré à huit clients. Trois fonctions jugées inutiles sont retirées, une demandée par tous est ajoutée (l’état du matériel en photo). En parlant, en direct.
3. Semaine 2, la consolidation : le code est récupéré et repris avec un agent de code supervisé par un développeur indépendant : revue de sécurité (deux failles d’accès aux données trouvées et corrigées), tests, connexion à la vraie base de clients, hébergement choisi.
4. Semaine 4 : mise en ligne pour les clients. Le prototype a servi de spécification vivante ; le développeur n’a pas eu à deviner ce qu’il fallait construire.
5. Ce qui aurait mal tourné : mettre en ligne le prototype de la semaine 1 avec les vraies données. Les deux failles auraient exposé les factures de tous les clients.

Une heure pour avoir quelque chose à montrer, trois semaines pour le rendre sûr. Les deux étapes étaient nécessaires, dans cet ordre.

Ce que ça change pour une équipe

• Les idées se testent en une heure. Un prototype qu’on manipule vaut mieux que dix pages de spécification.
• Les clients participent à la conception. On montre, on modifie en direct, on valide avant d’investir.
• Le prototype devient la spécification. Le développeur ou l’agent qui consolide sait exactement quoi construire.
• Les outils internes simples sont à portée. Pour un usage interne sans données sensibles, le prototype peut suffire.

Les limites et les erreurs fréquentes

• Mettre le prototype en production. Avec de vraies données et de vrais clients. Les failles d’accès sont le risque numéro un, et il est documenté.
• Ne pas faire relire le code. Par un développeur ou un agent de code supervisé, avec une revue de sécurité. Avant toute exposition.
• Ignorer les coûts d’hébergement. Les plans montent avec l’usage et les fonctions. Une estimation avant de dépendre de l’outil.
• Confondre la vitesse et la fin. La première version en une heure donne l’impression que tout est fait. Il reste le plus important : la rendre fiable.