Il y a dix-huit mois, je ne savais pas ouvrir un terminal sans appeler un développeur. Aujourd'hui, plusieurs apps que j'ai construites tournent pour de vrai. Une facture des abonnements à des vrais clients. D'autres font gagner quelques heures chaque semaine aux équipes chez Guest Suite.
À lire tous les papiers enthousiastes sur le vibe coding depuis six mois, j'ai de plus en plus envie de publier le contre-discours. Le vibe coding est puissant, vraiment. Mais tout le monde raconte la moitié de l'histoire.
Voilà l'autre moitié, vue de l'intérieur.
Les projets
Jour J est mon produit le plus abouti. Une app d'organisation de mariage à paiement unique, 29 € à vie. Elle tourne sur Lovable et Supabase, elle a des clients payants, elle vit en prod depuis des mois, elle a survécu à mes propres expérimentations, et elle a des problèmes bien à elle : SEO bancal, dette technique invisible, et un paquet d'actions manuelles.
LatimApp a eu une vie courte. Une app pour organiser les voyages entre amis, ce moment pénible où il faut coordonner dix personnes, dix budgets, dix envies, et où personne n'a envie de tenir le tableur Excel partagé. Je l'ai construite parce que j'en avais besoin. Je l'ai tuée quelques semaines plus tard, quand j'ai vu qu'une start-up bien financée poussait exactement le même produit. Je n'avais aucune envie de mettre mon temps perso dans un océan rouge naissant. C'est aussi ça, vibe coder : pouvoir enterrer un projet sans avoir brûlé six mois de dev.
Matrices et Cockpit sont plus discrets. Matrices est une app que j'ai construite pour nos clients Guest Suite, aujourd'hui utilisée quotidiennement en dehors de la plateforme principale. Cockpit est le tableau de bord de pilotage que HubSpot ne permettait pas de construire nativement, qu'on a fini par coder maison.
Trois enseignements se dégagent de tout ça.
Ce que le vibe coding accélère vraiment, c'est ta pensée
Le discours dominant dit : « tu peux construire un SaaS en un week-end. » C'est vrai au sens où tu peux avoir un prototype fonctionnel en 48h. C'est faux au sens où ce prototype n'est pas un produit.
Ce que le vibe coding accélère vraiment, c'est la vitesse à laquelle tu peux tester une intuition produit.
Avant, quand j'avais une idée, je la laissais mourir. Je n'allais pas mobiliser un dev pour « voir si ça tient la route ». Aujourd'hui, je la construis moi-même en deux après-midi. Je la montre à cinq personnes. Si ça ne prend pas, je la jette. Si ça prend, je la creuse.
Cockpit est né comme ça. Je me suis dit : « HubSpot ne me donne pas la vue que je veux, Looker c'est une usine à gaz pour ce que j'en ferai, je vais tester un truc moi-même. » Trois après-midi plus tard, on avait la vue dont on avait besoin. Elle n'était pas belle. Elle n'était pas parfaite. Elle nous évite cinq heures d'export Excel hebdomadaire, de fouiller dans HubSpot, et de tordre le CRM dans tous les sens.
Le retour sur investissement n'est pas sur le code livré. Il est sur les idées que tu testes et que tu tues plus vite. Avant, je gardais dix idées moyennes en tête faute de moyens pour les trier. Aujourd'hui, j'en crame neuf en deux semaines et il en reste une qui vaut le coup.
Le vrai gain est dans le tri des idées, beaucoup plus que dans la production de code.
Le vrai changement touche ceux qui ne sont pas développeurs
Le deuxième discours dominant dit : « les développeurs risquent de disparaître. » Ce discours est faux. Ce qui change, c'est le rôle de ceux qui n'en sont pas, précisément :)
Avant, un CMO qui avait une idée produit avait deux options : écrire un doc Notion et attendre que le product team le scope, ou renoncer. Aujourd'hui il a une troisième option : construire lui-même un premier jet. L'objectif n'est pas de remplacer le dev. Il est d'arriver devant le dev avec une conversation plus intelligente.
Quand je montre une app à un développeur, je ne dis plus « est-ce que tu pourrais faire un truc qui… ». Je dis « voilà le truc, il tourne, mais il tient avec du scotch, voilà où ça casse, voilà ce qui mérite d'être refait proprement. » La conversation est radicalement différente. Plus courte. Plus utile. Et au passage, beaucoup plus respectueuse du temps du dev.
La meilleure métaphore que j'ai trouvée : avant, j'envoyais des briefs. Aujourd'hui, j'envoie des prototypes. Un brief est une hypothèse. Un prototype est une donnée.
Ce que ça change pour un profil comme le mien est profond. Je ne suis pas devenu développeur. Je suis devenu un meilleur Marketteux, parce que je comprends enfin ce qu'implique ce que je demande. Quand je dis « il faudrait ajouter une auth email », je sais ce que ça veut dire en pratique. Je sais que c'est trois fois plus long qu'on ne le pense. Je sais pourquoi.
Cette compréhension vaut de l'or dans les conversations produit.
Les pièges sont réels, et les évangélistes les passent sous silence
Piège n°1 : la dette technique invisible.
Quand Lovable te livre un code fonctionnel en quinze minutes, tu ne vois pas ce qu'il y a dessous. Tu ne vois pas les requêtes mal indexées, les composants dupliqués six fois, la logique métier éparpillée dans des hooks qu'aucun humain n'a jamais relus. Invisible, jusqu'au mois six, où tu veux ajouter une feature simple et où tu découvres que le coût n'est pas linéaire. Il est exponentiel. Parce que tu ajoutes sur des fondations que personne n'a pensées pour durer.
Sur Jour J, j'ai découvert au mois 4 que mon schéma Supabase était construit d'une façon qui rendait impossible une fonctionnalité que je voulais ajouter. Il a fallu tout revoir. Ce qui aurait pris deux heures si j'y avais pensé dès le départ m'a pris trois semaines.
Piège n°2 : l'hallucination technique.
Lovable m'a menti plusieurs fois, et c'est inhérent à la façon dont ces outils fonctionnent. La dernière fois, il a modifié silencieusement le title SEO de Jour J, remplaçant le prix de la bonne version par un montant qu'il avait inventé. J'ai mis trois semaines à m'en rendre compte. Trois semaines pendant lesquelles Google indexait un prix qui n'existait pas.
Le plus dérangeant n'est même pas que l'IA se trompe, c'est que tu ne sais pas quand elle se trompe. Un dev humain te dit « je ne suis pas sûr, je vais vérifier. » L'IA te dit toujours la même chose avec la même confiance, qu'elle ait raison ou qu'elle hallucine. La vigilance devient ton métier à plein temps.
Piège n°3 : l'illusion du produit.
Celui-là est le plus traître. Tu construis quelque chose qui marche sur ton écran. Tu le montres à dix amis qui disent « c'est génial ». Tu crois que tu as un produit. En réalité, tu as un prototype qui survit dans des conditions idéales.
Un produit, c'est quelque chose qui tient quand un utilisateur crée 400 items au lieu de 5, quand le réseau lâche à mi-chemin, quand deux personnes modifient la même ressource en même temps, quand un bot essaie de créer 10 000 comptes en une nuit. Un prototype, c'est quelque chose qui marche quand tu fais exactement ce que tu avais prévu de faire.
La distance entre les deux est immense. Le vibe coding te fait franchir la première moitié du chemin en deux jours, mais la deuxième moitié prend toujours autant de temps qu'avant, et elle demande des compétences que le vibe coding n'enseigne pas.
Alors, j'y retourne quand même ?
Tous les jours j'y retourne.
Malgré tout ce qui précède (et c'est probablement la phrase la plus importante de ce papier), j'ai quand même sorti des apps que je n'aurais jamais sorties autrement. Avec des vrais utilisateurs, une vraie utilité, un vrai impact sur mon quotidien et celui des équipes autour de moi.
LatimApp n'existerait pas sans Lovable. Cockpit non plus. Matrices serait encore un fichier Notion à moitié abandonné. Jour J n'aurait jamais quitté le stade de l'idée griffonnée dans les marges d'un carnet.
Voilà, en vrac, ce que ça m'a appris pour quiconque veut s'y mettre sérieusement :
- Ne crois pas les promesses. Le vibe coding reste un outil, rien de plus. Il n'est ni le futur du développement, ni une menace pour les développeurs, ni un raccourci magique vers le produit parfait.
- Sois ton propre contrôleur qualité. Personne ne vérifiera ce que Lovable, Cursor ou Claude te livrent. Relis, teste, casse, doute. Surtout quand c'est trop facile.
- Distingue prototype et produit. Tu as le droit de vivre avec un prototype. La majorité de mes apps internes sont des prototypes assumés, et c'est très bien. Mais quand tu veux passer à autre chose (faire payer, scaler, onboarder des inconnus), prévois un vrai travail de consolidation. Sinon tu le paieras.
- Utilise-le pour ce qu'il est vraiment bon à faire. Tester des idées. Construire des outils internes. Prototyper. Débloquer des conversations. Et surtout pas pour remplacer la rigueur produit, la pensée architecture ou le métier de développeur.
- Continue de parler aux devs. Les miens sont les premiers à me dire « ok c'est sympa ton truc, mais voilà pourquoi on ne mettra jamais ça en prod tel quel. » Et ils ont raison. La vraie valeur du vibe coding, pour un opérateur comme moi, c'est d'arriver plus préparé dans cette conversation, pas de la court-circuiter.
En dix-huit mois, je n'ai pas appris à coder. J'ai appris quelque chose de plus utile pour quelqu'un comme moi : j'ai appris où est la frontière entre ce que je peux faire seul et ce qui demande un vrai savoir-faire. Cette frontière bouge tous les mois. Elle ne disparaîtra pas.
C'est probablement la chose la plus saine qu'on puisse se dire à ce stade du hype cycle : les outils ont changé, le métier de construire un produit solide, lui, est resté aussi difficile. Ce qui a changé, c'est qui a le droit d'essayer.
Moi j'ai essayé. Plusieurs fois. Je recommande, à condition de comprendre ce que ces outils font vraiment, et ce qu'ils ne font pas.
