Vibe Coding 101 : Un atelier pratique de zéro à un

Lisez la transcription :

Nous essayons de transcrire nos podcasts à l’aide d’un programme logiciel. Veuillez nous excuser pour d’éventuelles fautes, car le robot n’est pas exact à 100 % du temps.

Hannah Clark : Très bien, tout le monde. Avertissement pour l’épisode : si vous êtes déjà un expert du Vibe coding, cet épisode n’est peut-être pas fait pour vous. Mais si vous avez entendu parler du Vibe Coding et que vous voulez connaître la vérité face aux mythes, et que vous êtes curieux d’apprendre comment utiliser cette technologie pour avancer sur vos propres objectifs, vous allez adorer cet épisode.

Si vous n’avez pas suivi nos newsletters, celles auxquelles vous pouvez vous abonner sur theproductmanager.com/subscribe, je n’arrête pas de parler du fantastique atelier pratique de Vibe Coding que nous avons organisé il y a quelques semaines avec Drew Falkman, Principal de Moves The Needle. Cet épisode du Product Manager Podcast est en fait un enregistrement du séminaire de 30 minutes que nous avons fait avant de passer à la session de prototypage en direct. Vous découvrirez une explication claire de ce qu’est (et n’est pas) le vibe coding, des exemples d’utilisation inspirants et des recommandations d’outils pour commencer à explorer et découvrir vos propres cas d’usage. C’est parti !

Au fait : nous tenons ce type de discussions chaque semaine. Donc si cela vous intéresse, pourquoi ne pas vous abonner ? Bien, on y va.

Je suis Hannah Clark. Si vous ne me connaissez pas, je suis la rédactrice en chef de The CPO Club et l’animatrice du podcast The CPO Club. Et j’ai avec moi ma co-animatrice, Katie.

Katie Sanders : Bonjour à tous, je suis Katie Sanders. Je suis rédactrice en chef chez The CTO Club. Peut-être aussi de The QA Lead. Il y a des gens, car on a fusionné ces sites. Je suis ravie. C’est mon premier atelier et vraiment enthousiaste de le faire avec Hannah, car il y a beaucoup de points communs entre le produit et les CTOs. Donc oui, ravie de faire connaissance avec tout le monde. Bienvenue !

Hannah Clark : Je suis très heureuse de travailler avec Katie. Si vous ne la suivez pas encore sur LinkedIn, Katie Sanders, c’est vraiment une pro. Elle propose du super contenu, je suis ravie que vous fassiez plus ample connaissance.

J’aimerais aussi présenter notre intervenant vedette. Nous avons Drew Falkman avec nous. Drew est un leader produit, conseiller, éducateur, spécialisé dans la stratégie produit de l’amorçage à l’amorçage avancé. Il a optimisé des équipes, il se concentre sur l’adéquation produit-marché.

Il a tout fait. C’est un grand ami du magazine. Il a beaucoup travaillé avec nous. Et avec moi, ce qui démontre qu’il est très patient. Vous êtes donc entre de bonnes mains aujourd’hui. Il a aussi beaucoup d’expérience sur les produits web, mobile, blockchain et IA. On a ici un véritable expert.

Drew, veux-tu dire bonjour à tout le monde ?

Drew Falkman : Salut à tous, super content d’être ici. Ça va être fun.

Hannah Clark : Nous allons commencer par casser quelques mythes et je vais lancer la première question, puis ma super co-animatrice Katie abordera quelques mythes et Drew viendra les démonter pour nous. On va poser le contexte.

On dirait que tout le monde parle de vibe coding et ça revient dans tous les posts LinkedIn en ce moment, y compris beaucoup des miens. Et les gens semblent soit très excités, soit très effrayés, soit très confus. Parlons donc de pourquoi le Vibe coding est si populaire et si important aujourd’hui. Allons sur le mythe autour de ça.

Katie Sanders : Ok, premier mythe, le vibe coding remplace les ingénieurs. Évidemment il y a beaucoup de gens qui disent qu’en général l’IA va supprimer tous les métiers, c’est ce qui se dit. Mais je dirais que c’est un mythe et que cela change peut-être le métier d’ingénieur et cela génère du code prêt à être utilisé, mais ça ne remplace pas totalement l’ingénieur.

Comme toujours avec l’IA, il faut garder un humain dans la boucle, donc rien ne sera déployé sans une validation humaine, je pense qu’on peut vraiment casser ce mythe.

Hannah Clark : Drew, tu veux ajouter quelque chose ?

Drew Falkman : Oui, je dirais que c’est quelque chose à prendre en considération et à anticiper en tant qu’ingénieur, car cela arrive très vite.

Cela peut vraiment accélérer vos processus. Et en tant que designer, product manager ou fondateur non technique, vous pouvez désormais créer des MVP et valider des prototypes, puis les transmettre aux ingénieurs. Mais lorsque vous voulez passer à du code prêt pour la production, en général, au-delà du MVP…

De nos jours, il faut toujours faire des revues de code pour s’assurer que tout est resserré, en particulier s’il y a des questions de conformité ou autres à surveiller.

Hannah Clark : Passons au mythe numéro deux. Certains disent que le vibe coding se fait en dehors du cycle dev.

En d’autres termes, si on construit quelque chose dans une app de vibe coding, que ce n’est pas vraiment utilisable et qu’il faut tout refaire à zéro avec un développeur qui code tout à la main. Drew, est-ce vraiment le cas ?

Drew Falkman : Les outils ont tellement évolué et c’est littéralement en train de changer tous les jours.

Claude vient de sortir une nouvelle itération de génération de code il y a environ un mois et c’est bien meilleur qu’avant. Donc ça progresse constamment. Comme tous les outils génératifs, l’IA peut « halluciner », faire des choses inattendues. Donc cela peut s’intégrer au cycle, on peut créer ces bouts de code.

Les transmettre aux ingénieurs, mais il faut garder à l’esprit qu’il faudra probablement retravailler certaines choses. Peut-être réutiliser des composants, et certains ingénieurs pourraient être surpris par la qualité du code généré.

Hannah Clark : Ok, un autre mythe que j’ai beaucoup entendu est que vous n’avez pas besoin de PRD ou d’une stratégie produit pour créer un outil avec du vibe code.

Drew, Katie, un avis là-dessus ?

Drew Falkman : Il faut toujours réfléchir en amont. Je pense que parfois les gens se disent que s’ils font du vibe coding, ils peuvent juste se lancer, ouvrir l’outil et avoir une app le lendemain. Mais comme pour tout, si vous ne préparez rien, le résultat ne sera pas à la hauteur. Il faut penser à qui est votre public, votre marché cible.

Il faut réfléchir à la proposition de valeur, aux fonctionnalités principales et aux parcours dans l’application. Ça vaut vraiment le coup de préparer un quelque chose. Mais l’avantage, c’est que vous n’êtes pas obligé d’établir un PRD de 5 à 10 pages détaillant la technologie, les diagrammes de flux, etc.

Ce n’est pas ça, il suffit de poser votre vision, ce que vous construisez. J’ai mis au point un petit « vibe PRD », c’est une ou deux pages, juste pour vous et vos éventuels collaborateurs pour être alignés et travailler de façon organisée.

Et ainsi, votre code sera plus propre sur le long terme.

Hannah Clark : Bon à savoir. Passons au mythe suivant à propos des industries fortement réglementées. Katie représente The CTO Club, tu veux prendre cette question ?

Katie Sanders : Oui, je voulais aussi aborder un autre point. Ce n’est pas vraiment nouveau : on fait du vibe coding depuis des années.

On n’appelait pas ça comme ça, mais copier-coller depuis GitHub, Reddit ou Hacker News, peu importe : les bons ingénieurs résolvent des problèmes. Ils recherchent, repèrent des patterns, adaptent et construisent. Donc ce prompt n’est que l’évolution logique de cela. Ensuite, Hannah, c’était quoi l’autre mythe que tu voulais casser ?

Hannah Clark : Justement, que si tu travailles dans une industrie très réglementée tu ne peux pas faire de vibe coding. Que ce n’est pas sécurisé.

Katie Sanders : Oui, évidemment si on pense à la santé ou à la finance, ces secteurs sont très réglementés. Comme partout ailleurs, il faut s’assurer d’être conforme HIPAA et tout ça.

Je sais que les LLMs peuvent parfois piocher n’importe où. Voilà, il faut être attentif à la conformité selon le secteur. Mais je crois qu’il y a juste une vigilance supplémentaire à garder en tête pour la santé ou la finance par exemple.

Hannah Clark : Oui, c’est un peu comme d’autres process de développement où les outils de vibe coding ne remplacent pas votre équipe.

C’est juste un complément pour accélérer le cycle de développement. Mais un bon processus de revue de code, c’est sans doute encore plus essentiel maintenant qu’on externalise une partie du travail. Passons à quelques cas d’usage, ce serait intéressant d’explorer différentes façons dont le vibe coding est utilisé efficacement aujourd’hui.

Katie va animer cette section et citer quelques cas d’utilisation sympas.

Katie Sanders : En fait, beaucoup de ces exemples je les ai trouvés sur Reddit au tout début du Vibe Coding. Je cherchais des exemples concrets, alors que tout le monde en parlait. Mais je ne voyais rien de vraiment concret.

J’ai donc écrit un article là-dessus et l’un des cas évoqués était un passionné qui a créé, je crois, une appli d’organisation de jeux de foot amateur, juste pour son loisir. Il n’était pas développeur, mais il comprenait le fonctionnement des apps full stack, et il avait toujours dû embaucher des développeurs pour concrétiser ses idées.

Mais après avoir testé Lovable, Cursor et d’autres outils, il a développé cette appli de jeux de foot pour organiser ses parties hebdo, et il l’a lancée avec succès. Oui, une appli entièrement générée par IA en 100 lignes de code, rentable en quelques semaines, et il gagnait environ, c’était Michael non ?

C’était environ 700 $ par semaine je crois. Un autre exemple, Work Aid : gestion de tâches gamifiée par IA. Donc : révolutionner sa to-do list avec des applis qui rendent le travail ludique. Voilà quelques cas trouvés sur Reddit et on pourra vous mettre le lien du post.

Il y en avait d’autres, et je pense que beaucoup vont juste jouer avec, mais que certains réussiront vraiment, ce qui est cool à voir.

Hannah Clark : Oui très chouette exemple ! Je voulais juste intervenir car on a une bonne question de Katya.

Katya demande : en tant que PM, devrai-je encore faire des wireframes et maquettes pour le front-end ? Je pourrais juste utiliser le vibe coding pour créer l’interface, et les devs prennent ce front-end comme base pour leur développement ?

Drew Falkman : Oui, à 100 %. En fait, je pense même que ce serait plus compliqué avec le vibe coding et la plupart de ces outils de partir d’un design préexistant.

Il est difficile d’importer des écrans, etc. Il est plus simple de définir et de travailler avec l’IA générative pour obtenir le look and feel, puis de le passer aux autres pour s’assurer de la cohérence avec le design system ou les autres contraintes.

Hannah Clark : Merci Drew ! Désolée Katie, je t’ai coupée. Tu veux reprendre sur les cas d’usage ? Tu en as encore quelques-uns sous le coude.

Katie Sanders : Michael, tu veux partager cet exemple d’impact social ? Quelqu’un chez nous a créé un outil d’analyse d’impact des licenciements. Michael, tu veux expliquer ?

Michael Mordak : Avec plaisir. Donc voilà un superbe exemple utilisé par un collègue sur son site, pour un magazine RH, qui voulait construire un outil permettant d’analyser l’impact d’un licenciement. Et il a codé, ou plutôt le bot a codé, pour que les utilisateurs remplissent un questionnaire avant d’y accéder.

Cela lui permettait de collecter les données des utilisateurs, ce qui était son objectif. Une fois le questionnaire rempli, l’application vous amène sur un calculateur. Plusieurs exemples sont intégrés : si vous travaillez dans une usine et cherchez à licencier 200 salariés, vous pouvez tester ce scénario. En fait, il faut saisir des détails, comme le niveau de connaissance des employés, le temps pour en former de nouveaux, etc. et le calculateur vous montre l’impact du plan.

Voilà un super outil pour les RH qui doivent préparer un plan social, et il l’a offert gratuitement pour obtenir des retours. C’est un cas d’usage interne. Un deuxième cas : l’outil de sondage qu’on a utilisé tout à l’heure, que j’ai codé moi-même.

Je n’ai pas ou très peu d’expérience en code. J’ai donc créé cette appli sondage pour collecter les votes en direct et afficher les résultats sans payer pour une solution complète qui inclut plein de fonctions inutiles.

Je voulais juste le sondage, donc j’ai tout développé pour pouvoir créer mes propres sondages, leur donner un nom, ajouter des options, les prévisualiser avant publication, puis les lancer ou les supprimer. Voilà comment ils apparaissent à l’écran.

Donc vous votez sur l’appli que j’ai créée. Je ne collecte aucune donnée. Tout reste ici. Les résultats s’affichent en direct. J’ai terminé ce dev 30 minutes avant l’appel, mais au total, cela m’a pris une à deux heures pour tout finir, avec un branding qui me plaisait.

Mais je ne suis pas designer, donc ne suivez pas mon style !

Katie Sanders : Oui, on a vu beaucoup d’avantages. Évidemment, certains pensent qu’ils n’auront plus jamais besoin de gens techniques. Mais il y a l’exemple de Leo Junior.

Son post est devenu viral sur X : il est fondateur d’Enrich Lead, un outil qui collecte des adresses IP et utilise un LLM pour générer des leads commerciaux. Il a construit l’appli entière avec Cursor et annonçait fièrement : zéro ligne de code écrit à la main, tout IA. On peut râler ou se mettre à construire avec ! Pas de modestie.

Bien sûr, la toile ne lui a pas pardonné : en 48 h, des hackers ont pris le contrôle, les abonnements ont été contournés, ses coûts ont explosé et le LLM inventait des leads de toutes pièces. Leo a dû poster un SOS sur Twitter : je suis attaqué, tout part en vrille.

Il n’est pas technique et galère à réparer. Il apprend donc à coder « à la dure » ! Encore une fois : il faut toujours un humain pour valider le code, même si on s’amuse avec ces outils sans expérience technique.

Hannah Clark : Michael, tu veux donner un aperçu de l’apprentissage pour toi la première fois que tu as testé ces outils ?

Michael Mordak : Oui, comme je disais, j’ai très peu d’expérience en code. Je fais partie de ceux qui ont souvent des idées sans avoir jamais rien construit, je l’admets, car je réfléchis toujours à la façon d’améliorer les process internes sans payer pour des apps tierces, mais réaliser un outil c’est autre chose !

Pour répondre à Grand qui demandait quel est l’apprentissage en pratique — avec l’outil du jour, Lovable, et c’est pareil sur les autres — l’entrée en matière a été très simple. C’est du prompt textuel : vous décrivez exactement ce que vous voulez, le but de l’application, les résultats attendus.

L’outil propose des exemples de ce qu’il pourrait bâtir, et vous pouvez ajouter des détails. Par exemple, pour la mienne, j’ai dit que je voulais une interface semblable à slido.com, un service de sondage bien connu.

Il s’inspire donc d’exemples réels, puis vous pouvez personnaliser la marque et toutes les exigences. Après la première version, ce n’est pas terminé — vous pouvez continuer la discussion.

Il y a un mode chat pour poser des questions à l’outil avant qu’il ne change quoi que ce soit. Ensuite, dès que j’étais bloqué, je copiais les réponses dans ChatGPT en disant « explique-moi comme si j’avais 5 ans », et il me vulgarisait la technique. Donc c’était extrêmement fluide et ça m’a facilité la prise en main.

Hannah Clark : Génial ! J’espère que cela rassure tous ceux dont moi, qui débutent de zéro.

Je prends aussi une question de Tal pour Drew : quel workflow recommandes-tu pour une entreprise avec produit existant ? Je suis PM dans une start-up qui a un design system et un vrai produit avec des utilisateurs. Où le vibe coding peut-il être utile — pour de nouvelles fonctionnalités, idées ?

Et à quel moment repasser par la partie design ou aller direct au dev ?

Drew Falkman : Franchement, tout ce workflow est en pleine évolution. Il n’y a pas encore de « meilleures pratiques », c’est un peu le far west pour l’instant. Mais si j’étais en entreprise, je ne sauterais pas l’étape design, je collaborerais avec le designer.

Je ferais — je vais vous montrer — un vibe PRD qui décrit les écrans et éléments. Assurez-vous de demander l’accord des designers, ils peuvent aussi collaborer. On n’est pas obligé d’être en silo, il faut rester ensemble dans le projet.

Ensuite, je construirais. À ma connaissance, il n’existe pas encore — du moins sur Lovable — d’intégration directe des design systems. D’autres outils comme Cursor sont plus bas niveau : vous pouvez brancher vos chats dans le code, c’est plus technique (ligne de commande), mais ça permet plus d’intégration et d’interaction avec le code, donc mieux pour ce genre d’usages. Lovable permet en tout cas une synchronisation bidirectionnelle avec GitHub, ce que j’essaierai de montrer aujourd’hui.

Vous pouvez faire une itération d’écran, la pousser sur GitHub, et vos devs la récupèrent, intègrent les composants/reviennent sur le design system et la « poussent » à nouveau. Vous devriez alors retrouver tous les changements, idéalement sans problème.

Hannah Clark : Super. Question de Donald pour Drew : quelle est ton expérience du vibe coding quand il s’agit de quelque chose de très « cloney » (par ex : un gestionnaire de tâches classique) versus une idée totalement inédite (ex : « sonification » des données Google Trends) ? Autrement dit, est-ce plus simple de faire du vibe coding sur une adaptation existante ou du neuf de chez neuf ?

Drew Falkman : Très bonne question. Globalement, quand on prototype avec ces outils, tout ce qui existe déjà, c’est très simple. L’outil reconnaît, par exemple : créer une app de voyage, il saura faire à chaque fois. Mais sonifier des Google Trends, ce sera plus compliqué.

D’ailleurs, dès qu’on sort des éléments UI standard (liste déroulante, boutons, etc.) — pour des visualisations très personnalisées — ces outils, notamment Lovable (à date), sont plus limités. D’autres outils faciliteront ces cas à l’avenir, mais pour l’instant il faudra impliquer les devs sur des besoins très innovants ou hors norme.

Hannah Clark : Voilà, il est temps de conclure. Un immense merci à Katie pour sa participation, et évidemment à Drew pour ta générosité et ton expertise.

Merci pour votre écoute. Pour encore plus de conseils, guides pratiques et tests d’outils, abonnez-vous à notre newsletter sur theproductmanager.com/subscribe. Vous pouvez retrouver plus de conversations comme celle-ci en vous abonnant au CPO Club, là où vous écoutez vos podcasts.