Exemples de code Vibe : 6 projets pratiques à découvrir

Le « Vibe coding » permet à presque tout le monde de décrire une idée en langage clair et d’obtenir en retour une première version fonctionnelle, en privilégiant la rapidité plutôt que le long processus d’ingénierie qu’exigerait une version traditionnelle. Savoir par où commencer, cependant, est un tout autre problème, en particulier pour les équipes habituées à soumettre un ticket et à attendre la sortie d’une version.

Le « Vibe coding » peut prendre la forme d’une maquette visuelle rapide, d’un prototype fonctionnel ou d’une petite démonstration de faisabilité, selon ce que vous cherchez à découvrir. Cet article présente six exemples que les professionnels peuvent tester. Il s’agit de projets illustratifs que n’importe qui pourrait réaliser, et non de produits finis ou commerciaux.

6 exemples pratiques de « vibe coding » pour les équipes d’entreprise

L’utilisation d’outils d’IA pour le « vibe coding » permet de générer rapidement du code exécutable et des composants d’application à partir de simples descriptions fournies par l’utilisateur, mais il est important de se familiariser avec le processus avant de se lancer. Ces six exemples, qui correspondent au type de projets que l’on rencontre au travail, vont du plus simple et visuel au plus complexe, se rapprochant davantage de solutions reposant sur des données réelles et une logique de workflow. Chacun commence par un besoin métier, présente un exemple de prompt et un premier résultat possible, et se termine par les points à vérifier avant d’aller plus loin.

1. Visualiser une page d’accueil avant de la créer

Transformer un concept de page en quelque chose sur lequel une équipe peut se pencher implique généralement d’attendre un délai de développement dont personne ne dispose. Le « vibe coding » permet d’éviter cette attente. Une simple consigne peut générer une mise en page fonctionnelle avec une hiérarchie et un flux réels, offrant ainsi à l’équipe un élément concret à discuter plutôt qu’un brief écrit que chacun interprète à sa manière.

Exemple de consigne : « Créez une page d’accueil destinée aux chefs de petites entreprises qui envisagent d’adopter [produit]. Incluez une section « hero » avec un titre et un CTA, trois fiches présentant les avantages, une section de témoignages et un tableau comparatif des tarifs. Rendez le bouton CTA « sticky » (qui reste visible) lorsque le visiteur fait défiler la page. »

Premier résultat possible. Une seule page fonctionnelle avec une mise en page et un espacement réels, même si le texte et les images ne sont que des espaces réservés, suffit pour évaluer la hiérarchie et la fluidité avant même qu’elle ne soit présentée à un premier utilisateur.

Prochaines étapes. La validation du texte, le contrôle de l’accessibilité, le respect des directives de marque et la mise en œuvre effective restent à effectuer. Une maquette cliquable permet de vérifier si la structure fonctionne, mais pas si elle est prête à être publiée.

2. Tester un sélecteur de produits interactif

Les gammes de produits complexes sont difficiles à parcourir. Aider les clients à trouver la bonne option implique généralement une longue liste de filtres ou beaucoup de tâtonnements. Une invite permet de créer en quelques minutes un parcours guidé sous forme de questionnaire, posant quelques questions et orientant les clients vers une recommandation avant même que quiconque ne consulte le véritable catalogue.

Exemple de consigne : « Créez une application web de sélection de produits qui pose trois questions sur le cas d’utilisation, le budget et l’espace disponible, puis recommande l’un des cinq types de produits avec une brève explication pour chaque recommandation. »

Premier résultat possible : un parcours de questionnaire fonctionnel avec une logique de recommandation provisoire, suffisant pour parcourir chaque chemin et voir où mène chaque réponse.

Prochaine étape de vérification. Ce test porte sur l’interaction, et non sur la précision des recommandations. Les questions prêtant à confusion ou les chemins sans issue apparaissent rapidement. Les données réelles sur les produits, la logique de recommandation et la disponibilité des stocks doivent encore faire l’objet d’une vérification distincte avant que l’outil n’accède au catalogue en ligne.

3. Explorer un tableau de bord avec des données d’exemple

Toutes les idées de reporting ne nécessitent pas un pipeline de données complet avant de savoir si la mise en page est réellement utile. Une invite peut permettre de créer un tableau de bord entièrement constitué d’enregistrements fictifs, que les parties prenantes peuvent parcourir et auquel elles peuvent réagir immédiatement.

Exemple de demande : « Créez un tableau de bord à partir de données d’exemple correspondant à 50 demandes d’assistance. Incluez des fiches récapitulatives indiquant le nombre de demandes en attente, en cours de traitement et résolues, un filtre par priorité et par équipe assignée, ainsi qu’un tableau présentant le délai de traitement moyen par catégorie. »

Premier résultat possible. Un tableau de bord fonctionnel que les parties prenantes peuvent filtrer et sur lequel elles peuvent réagir immédiatement, en utilisant des enregistrements fictifs plutôt que des données extraites d’un système en production.

Ce qu’il faut vérifier ensuite. Un tableau de bord convaincant construit à partir d’exemples de données ne répond pas aux questions suivantes : d’où proviendront les données réelles ? Seront-elles issues d’une véritable base de données ? À quelle fréquence seront-elles mises à jour ? Et ces chiffres correspondent-ils réellement à ce que les utilisateurs supposent ?

4. Prototyper un workflow d’intégration des fournisseurs

L’intégration des fournisseurs se fait souvent à travers des fils de discussion par e-mail, des feuilles de calcul et la mémoire de celui ou celle qui se souvient de la dernière étape. Personne ne se rend vraiment compte à quel point ce processus est défaillant jusqu’à ce que quelqu’un en dresse un schéma. Une consigne peut générer des écrans interactifs couvrant l’enregistrement, le suivi du statut et la validation, permettant ainsi aux équipes des achats et des opérations de parcourir ensemble l’ensemble du processus pour la première fois.

Exemple de consigne : « Créez un flux d’intégration des fournisseurs comprenant un formulaire de soumission pour les informations sur l’entreprise et les documents requis, un aperçu du statut indiquant où en est chaque soumission, et un écran de validation permettant aux responsables de valider ou de rejeter une demande en ajoutant des commentaires. »

Premier résultat possible : des écrans que les équipes des achats et des opérations peuvent parcourir ensemble afin d’identifier les étapes manquantes ou les transferts de responsabilité peu clairs avant de s’engager dans une mise en œuvre concrète.

Prochaines étapes. Une version définitive nécessite des structures de données convenues, des règles d’accès réelles pour chaque rôle, une gestion des documents conforme aux exigences réglementaires applicables, ainsi que des connexions aux systèmes qui assurent déjà le suivi des fournisseurs et des paiements.

5. Créer une maquette d’expérience de compte en libre-service

Les clients ne devraient pas avoir à appeler quelqu’un simplement pour consulter une commande ou mettre à jour un paramètre de compte. Mettre en place une véritable infrastructure de gestion des comptes pour tester cette hypothèse représente un engagement trop important dès le départ. Un ensemble d’écrans navigables, construit à partir de données d’exemple, permet de déterminer si les utilisateurs peuvent réellement trouver ce dont ils ont besoin bien avant que cette infrastructure n’existe.

Exemple de consigne : « Créez une expérience de compte client comprenant un tableau de bord affichant les commandes récentes, une page permettant de mettre à jour les coordonnées et les préférences de paiement, ainsi qu’un formulaire de demande d’assistance avec suivi du statut, en utilisant cinq comptes clients fictifs. »

Premier résultat possible : des écrans sur lesquels un utilisateur réel peut naviguer à l’aide de données de compte fictives, ce qui suffit pour vérifier si la mise en page et les libellés sont cohérents.

Prochaines étapes de vérification. Ce test permet de vérifier si les clients peuvent trouver des informations et accomplir une tâche sans aide. La vérification d’identité réelle, les autorisations et les connexions au système de comptes réel, ainsi que tout ce qui touche aux données sensibles, constituent un ensemble de travaux distinct que le prototype ne couvre pas.

6. Vérifier une idée d’intégration à l’aide d’une petite preuve de concept

Il est rare que deux systèmes s’accordent sur la manière dont les données doivent être structurées. S’en rendre compte en cours d’intégration coûte cher. Grâce à une preuve de concept à portée restreinte, un développeur peut créer une petite fonction qui transforme des données d’exemple provenant d’un système dans le format attendu par un autre système, répondant ainsi à la question en un après-midi plutôt qu’en une semaine.

Exemple de consigne : « À partir de cet exemple de réponse JSON provenant du [système A], écrivez une fonction qui la transforme selon la structure de champs attendue par le [système B]. Traitez les champs manquants en les laissant vides et signalez tout champ dont le type ne correspond pas à celui attendu. »

Premier résultat possible : une logique de transformation côté client fonctionnelle qui traite correctement l’exemple d’entrée, testée sur quelques enregistrements types plutôt que sur une connexion en production.

Ce qu’il faut vérifier ensuite. Un exemple réussi ne permet pas de vérifier le comportement réel des API en production, la manière dont les identifiants (tels que les clés API) sont stockés et renouvelés, ce qui se passe en cas d’échec d’une requête, ni qui gère le mappage lorsque les systèmes sources changent.

Que pouvez-vous apprendre en testant les exemples de code Vibe ?

Chacun de ces exemples vous apprend quelque chose de différent, mais la leçon sous-jacente reste la même. Vous découvrez si une idée tient la route une fois qu’elle existe concrètement, et non pas seulement sous forme de description lors d’une réunion. Pour y parvenir, il faut décrire ce que vous souhaitez en langage naturel à un agent IA, examiner ce qu’il renvoie, puis lui donner de nouvelles instructions jusqu’à ce que cela fonctionne.

La véritable valeur va au-delà de la première instruction. Vous voyez l’interface ou le comportement réel qu’elle produit. Vous apprenez également ce qui doit être modifié une fois que quelqu’un y réagit. Parfois, cette réaction met en évidence l’outil lui-même. On commence souvent par un outil permettant un premier aperçu visuel rapide, puis on passe à un outil tel que Cursor ou Claude Code dès que le code sous-jacent nécessite une attention particulière. Les outils de « vibe coding » et les plateformes « low-code » adoptent ici des approches véritablement différentes : l’une s’articule autour des requêtes et du code, l’autre autour de la configuration visuelle.

Aucun des exemples ci-dessus n’est achevé ni prêt pour la production. Ils constituent un point de départ. Ce que vous tirez de la première version détermine s’il vaut la peine d’aller plus loin.

Comment choisir un projet de Vibe Coding à tester ?

Avec six orientations différentes, le choix est vaste. Le projet qui vous convient dépend de ce que vous cherchez réellement à apprendre. Quelques questions vous aideront à affiner votre choix :

• Qu’essayez-vous d’apprendre ? La mise en page, le parcours utilisateur, la vue de rapport, le workflow ou une connexion technique : chacun de ces éléments nécessite un type de prototype différent, car des tâches différentes exigent des types de validation différents.
• Pouvez-vous commencer avec des données fictives ? Utilisez des informations qui permettent aux personnes concernées d’évaluer l’idée sans accéder aux données réelles de l’entreprise, afin que l’expérience reste sans risque.
• Qui doit réagir au résultat ? Selon que l’exemple s’adresse à des clients, à des parties prenantes de l’entreprise, à des concepteurs ou à des développeurs, la notion d’« utilité » prend une signification différente.
• Qu’est-ce qui rendrait l’expérience utile ? Identifiez une décision spécifique sur laquelle elle devrait s’appuyer, par exemple pour déterminer si un workflow mérite d’être développé davantage.

Il ne s’agit pas ici de mener un audit de sécurité complet. Il convient toutefois de prendre cette étape au sérieux. Une étude de Veracode a révélé que 45 % des exemples de code générés par l’IA contiennent des failles de sécurité. Mieux vaut effectuer une vérification rapide maintenant plutôt qu’une vérification coûteuse plus tard.

Que se passe-t-il lorsqu’un exemple devient une application durable ?

Choisir le bon prototype à développer n’est que la première décision. Ce qui se passe ensuite est tout aussi important. Certains prototypes répondent à la question posée et peuvent être mis au rebut immédiatement. D’autres révèlent un workflow que l’entreprise souhaite réellement continuer à utiliser.

Prenons l’exemple de l’intégration des fournisseurs évoqué précédemment. Une fois que les utilisateurs commencent à s’en servir régulièrement, l’équipe a besoin d’enregistrements fiables, d’autorisations clairement définies, d’un véritable processus de validation, d’intégrations fonctionnelles et d’une personne chargée de la gestion à long terme. Ce sont là les mêmes exigences que tout workflow opérationnel, que la première version ait été écrite ou non par l’un des modèles d’IA actuels.

Les fonctionnalités « low-code » de Liferay DXP peuvent prendre en charge une grande partie de ces besoins. Les objets gèrent les données structurées, les formulaires gèrent la saisie, les workflows gèrent les étapes de validation, tandis que les autorisations et les intégrations relient le tout aux systèmes déjà en place, formant ainsi une véritable couche de gouvernance autour de ce qui n’était au départ qu’un prototype rapide. Certaines fonctionnalités spécialisées peuvent toutefois nécessiter un développement sur mesure et un examen spécifique, notamment lorsqu’une équipe doit ajouter des fonctionnalités non couvertes par les capacités prêtes à l’emploi ou souhaite exercer un contrôle plus précis sur le comportement exact d’un élément. L’important n’est pas que Liferay DXP ait servi à créer le prototype initial. Il s’agit plutôt de choisir la bonne base dès lors qu’un prototype devient un élément dont l’entreprise dépend réellement.

Commencez par l’idée que vous souhaitez tester

Commencez par une question clairement définie, et non par une demande vague de création d’une application. Les outils d’IA traitent rapidement le code standard, ce qui explique en partie pourquoi le premier résultat, aussi brut soit-il, vous donne matière à réagir et à affiner immédiatement. Cette réaction est généralement plus utile que le prototype lui-même. Partagez-le sous forme de publication rapide pour recueillir des retours, ou gardez-le privé, selon ce qui vous permettra d’obtenir le plus rapidement une réaction sincère.

La véritable valeur d’un exemple réside dans le fait de rendre une idée testable, qu’elle devienne ou non une application permanente. Si l’une de ces expériences se transforme en un workflow que votre organisation doit exploiter et maintenir, explorez les capacités « low-code » de Liferay DXP pour découvrir à quoi pourrait ressembler une base régie par des règles.

Foire aux questions sur les exemples de « vibe coding »

D'où vient le terme « vibe coding » ?

C'est le chercheur en IA Andrej Karpathy qui a popularisé ce terme en 2025, pour décrire une méthode de développement logiciel consistant à partir de ce que l'on souhaite obtenir plutôt que d'écrire le code ligne par ligne. Ce nom s'est imposé car il rendait bien compte de la rapidité avec laquelle une idée peut se transformer en une première version fonctionnelle.

Quels sont quelques exemples simples de « vibe coding » pour les débutants ?

Une maquette de page d’accueil, une calculatrice basique, des jeux simples sur navigateur ou un tableau de bord utilisant des données d’exemple constituent tous de bons points de départ. Aucun d’entre eux ne nécessite de connaissances préalables en programmation. Chacun a un objectif précis et vous offre un résultat concret à examiner et à peaufiner, plutôt qu’une idée abstraite. Commencez par une seule fonctionnalité plutôt que de chercher à créer une application complète.

Peut-on créer un outil interne à l’entreprise en « vibe coding » ?

Oui, et il est souvent préférable de commencer par là, car les outils internes tolèrent mieux les imperfections. Un outil interne de suivi des demandes ou un tableau de bord de reporting pourrait facilement voir le jour sous la forme d’un projet parallèle ou d’un prototype développé en « vibe coding ». Cependant, « interne » ne signifie pas automatiquement « faible risque » dès lors que l’outil traite des données de l’entreprise ou s’intègre à un flux de travail régulier. L’équipe doit tout de même examiner les questions d’accès, de fiabilité et de responsabilité avant de s’en servir au quotidien. Les lacunes identifiées lors de cet examen devront être corrigées.

Que faut-il inclure dans une consigne de « vibe coding » ?

Précisez qui utilisera le projet, quelle tâche il doit faciliter, les informations ou exemples de données dont il a besoin, et ce qui doit se passer lorsque les utilisateurs interagissent avec lui, le tout en langage clair plutôt qu’en termes techniques. Incluez les règles importantes ou les cas limites le cas échéant. Vous pouvez toujours affiner le résultat grâce à des consignes complémentaires après avoir testé la première version.

Les exemples de code « vibe » sont-ils prêts à être utilisés avec de vraies données clients ?

Non. Le code généré par l’IA nécessite souvent une révision par des professionnels avant son lancement. Un prototype fonctionnel ne garantit pas que l’authentification, les autorisations, le traitement des données ou les intégrations soient prêts pour une utilisation par les clients. Commencez par des données synthétiques, puis procédez à une révision technique et de sécurité appropriée avant de connecter quoi que ce soit à des enregistrements en production.