600 millions de dollars. C’est le revenu annualisé que Lovable vient de franchir, selon TechCrunch le 24 septembre, contre environ 500 millions en juin, et après une levée de 400 millions en août à 13,3 milliards de valorisation. Des gens dans deux tiers des entreprises du Fortune 500 utiliseraient déjà l’outil. Et le cofondateur, Fabian Hedin, résume le tout d’une phrase qui devrait empêcher de dormir pas mal de designers et d’agences : Lovable ne vend pas du code, il vend des produits, et de plus en plus, des business. Alors je pose la question qui fâche : et vous, vous vendez quoi ?

La phrase qui vaut 13 milliards

Voici la citation complète, traduite au plus près :

« Vous pouvez utiliser ces outils [comme Codex ou Claude Code] pour produire du code. La différence, c’est que Lovable ne produit pas du code. Le résultat est un produit, et de plus en plus, une activité. » — Fabian Hedin, cofondateur de Lovable, cité par TechCrunch

On peut trouver ça gonflé. Moi je trouve ça lucide. Parce que Lovable a compris un truc que la moitié de notre métier refuse encore de regarder en face : personne ne veut acheter du code. Personne ne veut acheter des écrans non plus. Les gens achètent un résultat. Un truc qui marche, qui se vend, qui fait gagner du temps ou de l’argent.

Et attention, je ne vais pas refaire le procès du vibe coding. Je l’ai déjà fait dans L’Empire du Paraître, et je n’ai pas changé d’avis sur l’utilisabilité des interfaces générées à la chaîne. Cet article-là est un article business. Parce que les chiffres de Lovable ne disent pas « le code IA est génial ». Ils disent « le marché paie pour des résultats ». Nuance énorme.

Quand l’app ne coûte plus rien, l’app ne vaut plus rien

C’est de l’économie de base. Quand le coût de production d’un bien tend vers zéro, sa valeur marchande suit. Une app CRUD avec login, dashboard et formulaire ? Il y a quelques années, c’était plusieurs semaines de dev. Aujourd’hui, c’est un après-midi et quelques prompts. Donc ce n’est plus là que se joue la valeur.

Elle se déplace vers trois endroits :

• Le problème choisi. Construire vite la mauvaise chose, c’est juste se planter plus vite. Le vrai travail, c’est de savoir quel problème mérite qu’on le résolve, pour qui, et combien il coûte à ceux qui le subissent.
• La distribution. Un produit que personne ne trouve n’existe pas. Si tout le monde peut sortir une app en un week-end, l’avantage revient à celui qui a déjà l’audience, le canal, la confiance.
• L’usage réel. Pas la démo sur LinkedIn. Le mardi matin, quand un utilisateur pressé essaie de faire sa tâche et que ça coince. C’est là que le produit tient ou s’effondre.

Combien de fois j’ai vu des fondateurs arriver avec un prototype très propre visuellement, et incapables de me dire qui allait payer, pourquoi, et combien. Le prototype n’était pas le problème. Le problème, c’est qu’il avait donné l’illusion que le travail était fait.

Le marché paie Lovable au résultat. Pourquoi vous facturez au jour ?

C’est là que ça pique pour nous, designers et agences. Lovable ne se vend pas « au prompt ». Son discours, c’est le produit livré, et même le business qu’il y a derrière. Pendant ce temps, combien de prestataires facturent encore au jour, à l’écran, à la maquette ?

Facturer à l’écran en 2026, c’est vendre exactement ce que l’IA est en train de transformer en commodité. C’est se positionner pile sur la courbe qui s’effondre. Quand un client peut générer vingt écrans dans l’après-midi, il ne comprendra plus pourquoi vous en facturez trois à la journée. Et honnêtement, il aura raison.

Mon opinion, assumée : le designer qui veut survivre à cette vague doit vendre ce que Lovable ne sait pas garantir.

• Un taux de conversion qui monte, pas un Figma bien rangé.
• Un onboarding qui réduit le churn, pas un parcours « joli ».
• Une décision produit prise avec des preuves, pas une intuition validée par un prompt.

C’est la même logique que j’ai déjà décrite pour les éditeurs eux-mêmes dans la réinvention des business models SaaS : on passe de la vente de fonctionnalités à la vente de résultats. Si vos clients basculent vers ce modèle, il serait temps que vous, prestataires, fassiez pareil. Le pricing à la valeur, ce n’est pas du marketing, c’est une question de survie.

Le Fortune 500 s’y met : bienvenue dans la jungle des outils internes

Deux tiers du Fortune 500, ça veut dire quoi concrètement ? Que dans des grands groupes, des gens qui ne sont ni devs ni designers sont en train de fabriquer leurs propres outils. Un tableau de suivi ici, un portail fournisseur là, un mini-CRM pour l’équipe commerciale. Sur le papier, c’est génial : le métier se débrouille, l’IT respire.

Dans la vraie vie, je vois venir des milliers d’outils internes non gouvernés. Et trois questions que personne ne pose au moment du « regarde ce que j’ai fait en deux heures » :

• Qui garantit la cohérence ? Quinze outils, quinze logiques de navigation, quinze façons de nommer la même donnée. Les collaborateurs passent d’un outil à l’autre et réapprennent tout à chaque fois.
• Qui garantit la sécurité ? Là, ce n’est pas une opinion. L’étude publiée par Veracode en juillet 2025, qui a testé plus de 100 modèles de langage sur 80 tâches de code, conclut que le code généré par IA introduit des failles de sécurité dans 45 % des cas. Et Lovable lui-même a eu sa vulnérabilité référencée : la CVE-2025-48757, liée à des politiques de Row Level Security insuffisantes, qui pouvait exposer des données personnelles, des clés d’API ou des données de transaction de projets générés.
• Qui garantit l’utilisabilité ? Un outil interne mal conçu ne fait pas de bruit. Il ne perd pas de clients, il perd du temps. Des heures, tous les jours, dans toute l’organisation. C’est une taxe invisible.

Je ne dis pas qu’il faut interdire. Je dis qu’il va falloir des adultes dans la pièce. Des gens capables de poser un design system, des règles, des garde-fous, et de dire « celui-là, on le passe en production, celui-là, on le jette ». Ce rôle-là, il est à prendre. Et il ne sera pas pris par un prompt.

Designer-builder, la version adulte

Qu’on soit clair : je ne suis pas contre Lovable. Je suis contre l’idée que Lovable remplace le travail qui décide si un produit tient. Le designer-builder version adolescente, c’est celui qui poste sa démo générée en vingt minutes et croit avoir livré un produit. Le designer-builder version adulte, c’est celui qui s’en sert comme d’un accélérateur, puis qui fait le vrai boulot.

Concrètement, voici comment je vois l’usage intelligent :

• Valider vite. Utiliser Lovable pour mettre un prototype cliquable devant de vrais utilisateurs en quelques jours au lieu de quelques semaines. Là, l’outil est imbattable.
• Observer froidement. Regarder où les gens bloquent, ce qu’ils ne comprennent pas, ce qu’ils ignorent. Le prototype sert à apprendre, pas à se rassurer.
• Reprendre la main. Architecture de l’information, parcours critiques, états d’erreur, accessibilité, sécurité des données. Tout ce que la démo ne montre jamais et que l’usage réel exige.
• Mesurer. Brancher des KPI dès le départ : activation, rétention, conversion. Sinon on ne saura jamais si le produit tient, on saura juste qu’il existe.

C’est exactement ce que je disais dans l’IA et la crise tech redéfinissent la valeur du design UX : l’exécution devient une commodité, le jugement devient le produit. Lovable vient juste de mettre un chiffre dessus. 600 millions, pour être précis.

Vendez un résultat, ou préparez-vous à être remplacé par un prompt

Le message de Lovable est brutal et je le prends comme un cadeau. Le marché ne paie plus pour la fabrication. Il paie pour le résultat. Si votre offre se résume à « je fais des écrans » ou « je fais des sites », vous êtes en concurrence directe avec un outil valorisé 13,3 milliards qui fait ça plus vite que vous. Bon courage.

Si votre offre, c’est « je vous aide à choisir le bon problème, à le résoudre pour de vrai, et à prouver que ça marche », alors Lovable n’est pas votre concurrent. C’est votre meilleur outil de prototypage.

Donc je repose la question : vous vendez quoi ?

Si vous êtes fondateur et que vous avez un prototype vibe codé qui tourne mais dont vous ne savez pas s’il tiendra face à de vrais utilisateurs, c’est typiquement là que j’interviens. Soit avec un audit produit de votre prototype (utilisabilité, parcours, cohérence, points de fragilité), soit avec un design sprint MVP pour repartir du problème et valider vite, avant d’investir dans le build. Écrivez-moi, on regarde ensemble ce que votre produit vend vraiment.