Guide de création d’applications

Comment créer une application en vibe coding à partir d’une idée claire

Si vous voulez apprendre à créer une application en vibe coding, partez d’une tâche qu’une personne doit accomplir, pas d’une liste d’écrans. Ce guide distingue la création d’une première version simple de la modification d’un projet existant, puis indique où les tests humains sont essentiels.

Commencez avec des données d’exemple
Visuel de la page d’accueil de Vibe Code

déterminez votre situation (tableau d’aide à la décision)

Choisissez selon ce que vous avez déjà. Une nouvelle idée demande une première version ciblée ; un projet existant demande une modification qui préserve le fonctionnement actuel.

6 min de lecture

approche A

Suivez cette approche si vous avez une idée, mais pas encore de projet. Gardez la première version assez simple pour pouvoir l’examiner en une seule séance.

  1. 1

    Décrivez la tâche et ses limites

    Rédigez une instruction qui précise qui est l’utilisateur, l’action qu’il doit accomplir et le résultat visible. Pour un outil de suivi des habitudes, demandez un pointage quotidien, un court historique et un état vide. Précisez qu’il faut utiliser des données d’exemple pour éviter de prendre un écran convaincant pour un service de données fonctionnel.

  2. 2

    Créez une interaction complète

    Demandez à Vibe Code le parcours utilisable le plus simple : ouvrir l’écran, ajouter un pointage et le voir apparaître. Demandez des libellés lisibles, des commandes utilisables au clavier et une mise en page adaptée aux mobiles. Si le résultat comporte des écrans supplémentaires ou des fonctionnalités sans rapport, demandez de les supprimer plutôt que de construire autour de ces éléments superflus.

  3. 3

    Exécutez l’application et décrivez ce qui ne fonctionne pas

    Essayez vous-même le parcours avant de demander une refonte. Signalez un problème observable, par exemple un pointage qui disparaît après l’actualisation de la page, et précisez le comportement attendu. Modifiez une seule chose à la fois, testez de nouveau le parcours et conservez une copie de la dernière version qui fonctionnait.

parcours B

Utilisez ce parcours lorsqu’un projet fonctionne déjà. Donnez à l’assistant suffisamment de contexte pour qu’il apporte une modification ciblée sans remplacer discrètement un comportement qui fonctionne.

Obligatoire Facultatif

  • Une copie fonctionnelle du projet et un moyen de l’exécuter localement — Vérifiez d’abord que le projet non modifié démarre et que son interaction principale fonctionne.

  • Une demande de modification précise, accompagnée du résultat attendu — Par exemple : ajouter un message lorsque la liste des tâches est vide.

  • Une liste des comportements qui doivent rester inchangés — Précisez les écrans concernés, le format des données existant et les interactions qu’il faut absolument préserver.

  • Un environnement de test sûr avec des données d’exemple non sensibles — N’incluez pas de mots de passe, de dossiers privés ou de clés de services actifs dans un prompt.

  • Un point de sauvegarde dans le système de gestion de versions avant toute modificationfacultatif — Un commit facilite l’examen des différences et l’annulation d’une modification indésirable.

  • Des captures d’écran ou une courte description de l’interface actuellefacultatif — Le contexte visuel aide lorsque la demande concerne l’espacement, le texte ou une mise en page défectueuse.

Parcours associés

Si vous avez besoin d’une introduction plus générale, d’une présentation axée sur la création d’applications ou d’une analyse de sécurité plus approfondie, choisissez le parcours qui correspond à votre prochaine question.

vérification finale

Une interface qui semble terminée n’est pas nécessairement un produit fiable. Testez ce qui se passe lorsqu’une personne l’utilise autrement que dans votre exemple de prompt.

1

Un aperçu ne prouve pas que les données sont conservées

Un élément peut sembler enregistré alors qu’il n’existe que dans la session actuelle du navigateur. Actualisez la page, rouvrez-la et faites un test sur un second appareil si votre conception promet des données partagées ou persistantes.

Que faire à la place

Précisez si les données sont temporaires, puis vérifiez comment elles sont réellement stockées avant d’affirmer que les enregistrements sont conservés.

2

Le code généré ne remplace pas un audit de sécurité

Un formulaire fonctionnel peut malgré tout exposer des informations sensibles, accepter des entrées dangereuses ou permettre d’accéder aux données d’une autre personne. Le code produit par le vibe coding doit être examiné avant d’utiliser de vraies données ou d’ouvrir l’accès au public.

Que faire à la place

Utilisez des données fictives pendant les itérations et faites examiner et tester les parcours sensibles avant la mise en ligne.

3

Un seul clic réussi ne révèle pas les cas limites

Des champs vides, un texte long, des appuis répétés, une connexion lente ou un écran étroit peuvent compromettre un parcours qui fonctionnait lors d’une unique démonstration.

Que faire à la place

Testez chaque cas, décrivez le problème observé et refaites les vérifications précédentes après chaque correction.

4

Un prompt ne peut pas définir les règles de votre produit à votre place

L’assistant peut proposer des choix par défaut, mais il ne peut pas savoir quels utilisateurs doivent avoir accès au produit, quelles données conserver ni quelles erreurs auraient de graves conséquences.

Que faire à la place

Rédigez ces règles en langage clair et vérifiez que le comportement obtenu y correspond.

Comment cette méthode de travail a pris forme

La création guidée par des prompts s’appuie sur plusieurs évolutions, mais la nécessité d’examiner et de tester les logiciels n’a pas disparu.

  1. Les suggestions de code arrivent dans l’éditeur

    La préversion technique de GitHub Copilot a introduit les suggestions générées par l’IA dans un environnement de développement familier. Une suggestion pouvait accélérer une petite modification, mais il revenait toujours au développeur de déterminer si elle convenait au projet dans son ensemble.

  2. Les instructions deviennent conversationnelles

    Le lancement public de ChatGPT a permis de décrire une fonctionnalité, d’examiner une réponse et d’affiner sa demande en langage courant. Ce dialogue est utile aussi bien pour concevoir une interaction que pour produire du code.

  3. Il devient plus facile de demander des modifications plus importantes

    À mesure que les outils d’IA capables de coder se sont développés, les utilisateurs ont commencé à demander des écrans et des fonctionnalités reliés entre eux plutôt que des extraits de code isolés. Il est alors devenu plus important de définir clairement le périmètre : une demande trop large peut produire un résultat soigné en apparence, mais fondé sur des hypothèses non vérifiées.

  4. Le vibe coding trouve son nom

    Andrej Karpathy a popularisé l’expression vibe coding pour désigner une approche de la création de logiciels guidée par des prompts. Pour un projet d’application, la bonne habitude n’est pas d’accepter chaque modification générée, mais de créer un petit parcours, de l’observer et de le corriger à plusieurs reprises.

Commencez par une petite réalisation

Donnez à Vibe Code une tâche utilisateur précise, le résultat qui doit apparaître à l’écran et une limite, comme l’utilisation exclusive de données d’exemple. Après la première version, essayez vous-même l’interaction et demandez une correction précise plutôt qu’une refonte générale.

Transformez une tâche en une première version testable

  • Commencez par une interaction complète
  • Examinez le résultat avant d’ajouter des fonctionnalités
  • Ne mettez pas de données sensibles dans vos premiers prompts
Créer mon application

FAQ du tutoriel

Précisez à qui s’adresse l’application, une tâche à accomplir, l’action à effectuer et le résultat attendu. Ajoutez des limites, comme une mise en page adaptée aux mobiles et l’utilisation exclusive de données d’exemple. Demandez un petit parcours fonctionnel plutôt que toutes les fonctionnalités que vous pourriez souhaiter à terme.

Partez de zéro si vous souhaitez explorer une nouvelle idée et n’avez pas de code à conserver. Utilisez votre projet existant si votre demande porte sur une modification précise de quelque chose qui fonctionne déjà. Dans ce cas, vérifiez d’abord son comportement actuel et expliquez ce qui doit rester inchangé.

Effectuez la tâche principale sans vous appuyer sur l’exemple fourni dans votre prompt. Essayez ensuite une saisie vide, des actions répétées, un rafraîchissement de la page et un écran étroit. Si les données doivent être conservées ou partagées, testez ces points séparément au lieu de supposer qu’un aperçu réussi les prouve.

Décrivez ce que vous avez fait, ce qui s’est passé et ce que vous attendiez à la place. Demandez une seule correction ciblée, puis testez à la fois cette correction et le parcours qui fonctionnait auparavant. Si une modification crée de nouveaux problèmes, revenez à la dernière version fonctionnelle avant d’essayer une autre instruction.

Vous pouvez partager un prototype après avoir vérifié son fonctionnement et clairement indiqué ses limites. Avant que de vrais utilisateurs y saisissent des informations personnelles, examinez le stockage des données, les règles d’accès, la gestion des erreurs et les secrets éventuellement exposés. Une interface qui semble fonctionner ne prouve pas à elle seule que ces protections sont en place.

Commencer à créer
Commencer à créer