Guide d’introduction au vibe coding en 5 étapes pour les non-développeurs

Ces dernières semaines, j’ai créé avec des connaissances non développeuses (avocats, marketeurs, PM, etc.) cinq ou six petites applications en vibe coding

• Tableau de bord de raid de guilde WoW (web)
• Simulateur de course pour événement de tirage au sort (web + Three.js)
• Un outil de communication entre monteur vidéo et client (extension Chrome)
• Un minuteur automatique qui définit un nombre d’itérations, aide à se concentrer pendant une durée donnée, puis invite à faire une rétrospective à la fin (application desktop Electron)

J’ai résumé ce processus dans un « guide d’introduction au vibe coding pour les non-développeurs » en 5 étapes

1. Se faire une idée de ce que l’IA actuelle peut faire, et jusqu’où
2. Définir clairement le problème à résoudre et le produit à créer
3. Vérifier rapidement et fréquemment par soi-même le fonctionnement du résultat
4. Échanger avec l’IA en la guidant avec des prompts pour qu’elle code bien
5. Repérer les comportements anormaux et les pistes d’amélioration, puis améliorer et finaliser

1) Se faire une idée de ce que l’IA actuelle peut faire, et jusqu’où

Pour les non-développeurs qui découvrent le vibe coding, je recommande de commencer par ce type d’activités

• Faire soi-même l’expérience, dans un LLM ou dans un service de prototypage IA, qu’un simple prompt court peut produire quelque chose de fonctionnel, afin de gagner en confiance
• S’abonner à quelques comptes SNS et newsletters qui synthétisent les dernières informations sur l’IA
• Renoncer à l’idée de tout absorber sur l’IA et ses outils ; se concentrer plutôt sur les outils liés à quelques sujets qui vous intéressent vraiment, et les tester rapidement

2) Définir clairement le problème à résoudre et le produit à créer

• Même si l’on a compris les capacités de l’IA, on ne peut pas créer un produit sans une définition claire du problème
• Il faut donc d’abord devenir plus lucide grâce à des questions qui renforcent la métacognition
• Utiliser cette application de métacognition créée en vibe coding
  1. Qu’est-ce que je veux créer ?
  2. Pourquoi est-ce que je veux le créer ? Quel problème est-ce que j’essaie de résoudre ?
  3. Qui rencontre ce problème ?
  4. Dans quelles situations ces personnes rencontrent-elles ce problème ?
  5. Dans cette situation, quels expédients ou substituts utilisent-elles actuellement ?
  6. Comment vérifier que la solution 1 résout mieux le problème que la solution 5 ?
  7. Comment faire pour qu’elles utilisent volontiers la solution 1 à la place de la solution 5 ?
• Une fois l’idée clarifiée, j’ai pris le « prompt de génération de PRD » produit par l’application et je l’ai donné à un LLM pour lui faire générer un PRD

3) Vérifier rapidement et fréquemment par soi-même le fonctionnement du résultat

• Le plus grand avantage du vibe coding, c’est d’obtenir une « application fonctionnelle » très tôt. C’est aussi extrêmement important pour motiver les non-développeurs
• Dans cette optique, je ne recommande pas vraiment aux non-développeurs de commencer le vibe coding avec Cursor. À mon avis, il y a trop de petits et grands obstacles avant d’arriver à exécuter l’application
• À la place, je pense que des services comme Lovable, qui génèrent un prototype fonctionnel à partir d’un PRD, constituent un bien meilleur point de départ. Ils créent aussi immédiatement un lien public, pratique pour montrer le résultat à des proches et recueillir des retours
• En revanche, si l’application à créer n’est pas basée sur le web, cela devient un peu plus complexe, car les outils de prototypage produisent des web apps
• Dans ce cas, il faut prendre des décisions techniques et configurer un environnement d’exécution, ce qui suppose que l’IA et moi devenions tous les deux plus compétents

4) Échanger avec l’IA en la guidant avec des prompts pour qu’elle code bien

• Moi et l’IA devenons plus compétents <-> j’écris de meilleurs prompts <-> le résultat arrive plus vite et de meilleure qualité
• Plus le prompt est bon, plus le nombre d’allers-retours nécessaires pour atteindre l’objectif diminue (= moins de temps et d’argent)
• Quand on lit différents guides de prompt engineering, on voit toujours revenir la même idée : bien définir dans le prompt le rôle (Role), le contexte (Context) et la tâche (Task)

Rôle, contexte, tâche

• En vibe coding, le « rôle » n’est pas si important
  • Les coding agents ont déjà des rôles adaptés définis en amont, donc cela peut même brouiller les choses
  • Et comme le code est un benchmark important, les LLM codent bien même sans attribution de rôle
  • Bien sûr, si l’application que vous créez a des spécificités, donner un rôle adapté peut être utile
• Si le PRD est bien fait, le « contexte » suffit largement
• La « tâche », c’est surtout bien définir l’objectif et les critères d’achèvement. Ces critères peuvent
  • être explicitement indiqués dans le prompt (few-shot prompting)
  • être définis dans des fichiers externes ou dans le code (TODOs.md ou code de test)
  • n’exister que dans ma tête (ce style n’est pas très heureux)
• Le but ultime du vibe coding est de donner à l’IA les bonnes instructions pour qu’elle code bien et produise rapidement une application qui fonctionne conformément au PRD. Pour y parvenir, il est préférable de viser 3 objectifs intermédiaires
  • Je deviens plus compétent
  • L’IA devient plus compétente
  • Les fonctionnalités se comportent conformément aux spécifications

Je deviens plus compétent ?

• Si l’on n’est pas développeur, ou si le domaine ou la stack technique sont peu familiers, il est difficile de donner des instructions avec une terminologie précise
• Dans ce cas, il suffit de signaler ses lacunes au LLM et d’apprendre avec lui
  • « (en montrant une capture) Ce type de jeu est généralement développé avec quoi ? »
  • « Je veux créer quelque chose comme ça ; toi, comment ferais-tu pour obtenir les données ? »
  • « Si je veux vérifier au plus vite le comportement clé d’une application native, quelles technologies devrais-je utiliser ? »
• À travers ce type de questions, observez si vous évoluez ainsi
  • Mots-clés techniques : j’utilise désormais les bons termes techniques et métiers
  • Flux de données : je peux expliquer comment les données nécessaires aux fonctions clés de mon application sont obtenues, traitées et affichées
  • Environnement d’exécution : j’ai mis en place un environnement où je peux lancer le code écrit par l’IA et vérifier de mes propres yeux s’il fonctionne
• Dans l’idéal, il vaut mieux lever tous les unknown unknown avant d’écrire le PRD puis de commencer à coder, mais ce n’est pas indispensable
• On apprend aussi beaucoup une fois qu’on entre dans le code, et au pire on peut toujours repartir de zéro. (Cela peut même être plus rapide que de corriger quelque chose d’existant.)

L’IA devient plus compétente ?

• Il s’agit d’indiquer à l’IA, via un system prompt (Cursor Rules, etc.), les mots-clés techniques et les flux de données identifiés
• Pour réduire le nombre de mes interventions et obtenir un code plus conforme à mes attentes, il faut surtout deux choses : des contraintes et des consignes de documentation
• Les consignes de contrainte aident l’IA à écrire un code plus cohérent. Par exemple :
  • Stack technique : utilise NextJS app router, stylise avec Tailwind et ShadCN, n’utilise que des icônes Lucid, utilise Stripe pour les paiements, etc.
  • Structure et patterns : organise les dossiers ainsi, nomme les fichiers comme ceci, adopte un style UI de type Material, etc.
  • Format de sortie (selon l’environnement d’exécution) : je vais utiliser Electron Fiddle, donc donne-moi les 4 fichiers correspondants ; je vais utiliser CodePen, donc donne-moi un fichier HTML, un CSS et un JS, etc.
• Les consignes de documentation aident à améliorer la concentration et la mémoire de l’IA. Deux idées se sont révélées particulièrement utiles
  • Memory Bank de Cline : définir un workflow où l’on travaille en consignant dans des fichiers ce qui a été fait et ce qu’il reste à faire
  • Le prompt context de Dongyoon Kang : au lieu de laisser de longues consignes sur tout le projet à la racine, créer des consignes par dossier
• Le Memory Bank facilite particulièrement l’observation de ce qui se passe et l’apprentissage, donc je le recommande tout spécialement aux non-développeurs

Les fonctionnalités se comportent conformément aux spécifications ?

• Ici, il ne s’agit pas de stratégies de prompt au niveau projet, mais au moment d’échanger dans le chat avec un coding agent
• À mon avis, la meilleure stratégie pour faire en sorte qu’une fonctionnalité se comporte selon les spécifications, c’est commit si les tests passent
  • « Implémente X. Écris d’abord les tests, puis code, exécute les tests, et continue à corriger le code jusqu’à ce qu’ils passent. »
• C’est possible parce que les coding agents ont l’autorisation et la capacité d’écrire du code de test, de l’exécuter dans le terminal et d’en lire le résultat
• Une fois les tests passés, il suffit de recevoir une proposition de message de commit et de valider ensemble le code de test et le code fonctionnel. Personnellement, je fais les commits moi-même, mais l’agent peut aussi les faire automatiquement
• L’IA peut aussi écrire, exécuter et corriger d’elle-même non seulement des tests unitaires, mais aussi des tests d’intégration et des tests E2E (voir : automatisation des tests avec Cursor + Playwright)
• Tout cela constitue une stratégie qui aide à vérifier plus facilement, côté vibe coder comme côté IA, si chaque fonctionnalité est implémentée selon les spécifications et si l’ensemble de l’application fonctionne conformément au PRD

5) Repérer les comportements anormaux et les pistes d’amélioration, puis améliorer et finaliser

• Pour moi, le vibe coding est très loin du simple « clic » magique, et il y a beaucoup à apprendre
• Parmi ces apprentissages, je vois 3 compétences comme essentielles si l’on veut dépasser le stade du « petit prototype personnel » et construire, en tant que fondateur solo, une application au niveau d’un produit commercial : les capacités d’analyse, les compétences de code et les compétences de product engineering

Capacités d’analyse

• Il faut savoir repérer avec précision les écrans ou fonctionnalités qui ne se comportent pas comme le PRD (ou l’intention initiale) le prévoit
• Sans cela, il devient très difficile d’identifier ce que l’IA a mal fait et de lui demander de corriger
  • Les « tests » de l’étape 4 réduisent d’emblée les erreurs de l’IA tout en développant mes propres compétences
  • En effet, lire le processus par lequel l’IA transforme les spécifications en code de test permet d’apprendre non pas seulement « cette fonctionnalité est nécessaire », mais aussi « telles conditions sont nécessaires pour considérer l’implémentation comme terminée »
• Mais « l’application est conforme aux spécifications » et « l’application est bonne » sont deux choses différentes. C’est pourquoi le sens produit est important pour identifier les améliorations possibles (voir la newsletter de Lenny en lien pour plus de détails)

Compétences de code

• Au moins pour l’instant, même si l’on découpe très bien le travail pour le confier à l’IA, il faut malgré tout intervenir soi-même sur le code à hauteur d’au moins 5 % pour finaliser
  • Sur les SNS, il y a énormément d’applications bloquées à 80 % et jamais lancées parce que leurs créateurs n’y arrivent pas
• Bien sûr, ce pourcentage peut varier selon l’application visée, et il n’est pas totalement impossible de tout réaliser jusqu’au bout uniquement avec l’IA, mais ce serait très inefficace
• Plutôt que de s’abandonner complètement à la vibe, je recommande d’étudier aussi le code lui-même en lisant la documentation générée par l’IA (Memory Bank, code de test, etc.). Et de se faire coacher par des développeurs si possible
• Il est particulièrement utile d’apprendre les parties backend, moins visibles à l’œil nu (authentification des utilisateurs, intégration d’API externes, entrées/sorties de données, paiements, etc.) ainsi que les stratégies de déploiement (branche principale et branches de fonctionnalité, gestion des variables d’environnement, etc.)

Compétences de product engineering

• Le lancement d’une application n’est pas la fin, mais le début. Pour bien faire, il faut comprendre l’ensemble du cycle de vie du développement produit
  • identification du problème, génération d’idées de solution, conception, design, implémentation, tests, déploiement, promotion, monitoring des erreurs, collecte de feedback, opérations...
• Il n’est pas nécessaire de maîtriser chaque étape en profondeur, mais il est au moins utile de savoir ce qu’on y fait et quels mots-clés y sont employés
• C’est ainsi que l’on peut apprendre ce qu’on ignore et reconnaître les compétences des collègues avec lesquels collaborer quand on ne peut pas tout assumer seul

Pour conclure

• Transformer une application créée en vibe coding en produit de niveau commercial n’a rien de facile. En revanche, personne ne peut nier qu’il n’a jamais été aussi simple de « commencer »
• Voir des proches s’émerveiller et s’amuser sincèrement en découvrant leur petite idée prendre vie (« Waouh, moi aussi je code ! ») m’a rendu moi aussi extrêmement heureux
• J’encourage aussi les autres non-développeurs qui lisent cet article à profiter de cette occasion pour devenir, avec plaisir, des « makers »
• En mettant à profit votre propre expertise métier, si vous créez en vibe coding un outil petit, rapide et utile qui résout remarquablement bien un problème précis, je pense que vous pourrez tout à fait rester compétitif à l’ère de l’IA

[jk34011]

Waouh, je pensais que le vibe coding relevait du mirage.
Ça faisait longtemps que je n’avais pas lu un article écrit avec un tel niveau d’expertise.
Je l’ai lu avec beaucoup de plaisir.

[spilist2]

Merci ! Je vois un énorme potentiel haha

[jk34011]

Ah ;; maintenant que je le relis, mon commentaire est un peu maladroit.
Plutôt que de parler d’illusion, c’est davantage le sentiment que ce n’est pas encore mûr.
Au final, j’ai le sentiment que le vibe coding a ses limites et que c’est difficile sans connaissances en développement.
Bien sûr, je pense qu’avec les progrès de l’IA, ce sera bien meilleur plus tard.

J’ai l’impression que mon commentaire pouvait donner l’idée que le vibe coding ne sert à rien, donc je rajoute cette réponse un peu en vrac.
Moi aussi, j’utilise beaucoup le vibe coding haha

[spilist2]

Ah non, pas du tout. Haha, moi aussi j’avais bien saisi la nuance que vous évoquiez.

C’est pourquoi, comme je l’ai écrit dans le corps de l’article, le vibe coding dont je parle est assez éloigné du simple « clic », et je pense que pour élever le niveau, les ingénieurs doivent fournir beaucoup d’efforts.

[bbulbum]

Je vous lis toujours avec beaucoup d’intérêt.

[spilist2]

Merci !

[spilist2]

J’ai aussi fait une vidéo YouTube haha https://www.youtube.com/watch?v=ecY5VBpruOA