Qu’est-ce que le vibe coding ? De l’instruction à l’app testée

Décrire, essayer, réviser : pensez en boucle

Au lieu d’écrire chaque ligne, vous décrivez un comportement et laissez un outil proposer une implémentation. Vous l’exécutez, repérez ce qui manque et formulez une instruction plus précise. L’introduction de Replit présente cette approche itérative et ses limites lors du passage en production.

Le terme recouvre différents degrés de revue du code. Pour votre projet, dites ce que vous avez réellement fait : générer un prototype, relire un changement ou tester une publication. L’étiquette seule renseigne peu sur la fiabilité, la sécurité ou la personne responsable de la maintenance.

Référence: Replit Learn: What is vibe coding?

Un petit exemple rend la différence visible

Supposons que vous demandiez une liste de tâches ménagères. Le premier résultat peut afficher de jolies cartes et un bouton Ajouter fonctionnel. Rechargez la page : les tâches sont-elles toujours là ? Saisissez un nom long : la carte reste-t-elle lisible ? Supprimez une tâche : peut-on se remettre d’une erreur ?

Chaque question devient une exigence concrète. « Enregistrer localement et prévenir en cas d’échec » est plus utile que « rendre prêt pour la production ». Demandez à l’assistant d’expliquer le modèle de données, de réaliser un comportement et d’en montrer la vérification. Examinez le résultat avant de demander une autre fonction.

Un prototype répond à moins de questions qu’un produit

Un prototype aide à décider si une interaction a du sens. Il peut utiliser des données temporaires et supposer une seule personne, une connexion rapide et des requêtes réussies. C’est utile si ces hypothèses sont visibles.

Un produit public doit gérer les retours ultérieurs, les appareils inconnus et les actions échouées. Une liste partagée ajoute l’identité et les autorisations. Un paiement ajoute un fournisseur et un enregistrement du montant payé. Ces sujets changent le travail, même lorsque générer l’écran suivant semble rapide.

Les décisions importantes vous appartiennent toujours

Vous choisissez le problème à résoudre, le résultat qui vaut réussite et les fonctions qui peuvent attendre. Vous décidez aussi des informations nécessaires, des ressources que vous avez le droit d’utiliser et du niveau de confiance requis pour le résultat.

Demandez des explications vérifiables. Où sont stockées les données ? Quelle dépendance réalise cette tâche ? Que se passe-t-il si la requête échoue ? Si la réponse reste floue, réduisez le périmètre ou faites intervenir quelqu’un capable de l’examiner. Faites-le avant toute suppression irréversible, utilisation de données sensibles ou paiement réel.

• Gardez une description lisible du comportement attendu.
• Sauvegardez une version fonctionnelle avant un changement important.
• Relisez les changements et testez le résultat, au-delà de son apparence.
• Identifiez comme non vérifié ce qui reste à vérifier.

Prenez de vraies apps comme références, avec les bonnes limites

Le catalogue LaunchVibe donne des interactions concrètes à examiner : planifier une tâche, pratiquer le morse ou organiser un récit photo. Nous n’avons pas vérifié que les apps présentées ont été créées en vibe coding. Leur présence ici ne constitue pas une affirmation sur leur méthode de développement.

Étudiez le problème et l’interaction plutôt que de copier une marque, une capture ou une implémentation. Notre Village propose une autre façon de découvrir le même catalogue ; les liens habituels fonctionnent toujours sans devoir marcher jusqu’à un bâtiment. C’est une décision d’accès au produit, distincte de l’outil qui a généré du code.

Commencez par un comportement que vous pouvez expliquer

Choisissez une petite expérience réversible. Écrivez la saisie, l’action, le résultat et deux façons dont elle peut échouer. Demandez une première version, essayez ces cas et prenez des notes. Recommencez seulement lorsque vous comprenez assez la version actuelle pour la modifier.

Le guide d’idées propose des exemples limités et un brief réutilisable. Lorsque vous voudrez partager le projet, la checklist de lancement vous aidera à réunir des preuves sur le parcours, les données et la version publiée. Une première version utile est une version dont vous pouvez décrire honnêtement le comportement et les limites.