Tout le monde parle de vibe coding : guide pour générer rapidement une application avec les modèles d'instructions génératives exacts, par Jay GordonÀ l'approche de Microsoft Ignite, j'ai voulu tester quelque chose dont la communauté ne cesse de parler : le « vibe coding ». Il s'agit d'un style de développement assisté par l'IA dans lequel vous décrivez les résultats en langage naturel et votre assistant se charge de la plupart des tâches de structuration, de refactorisation et d'assemblage. Vous maintenez votre élan en discutant du travail et vous ne passez au code brut que lorsque vous avez besoin de peaufiner les détails.
Si vous avez déjà composé de la musique, la métaphore est pertinente : vous recherchez un riff, sans trop théoriser les gammes. Un partenaire d'écriture est assis à côté de vous, vous suggérant des phrasés, raccourcissant les mesures et vous aidant à passer le cap. Après quelques boucles, vous obtenez une démo qui mérite d'être partagée. C'est l'objectif ici : prouver que je peux obtenir une démo en une heure environ. Cela inclut la création et le dépannage, uniquement via une conversation avec l'assistant.
Voici le guide que j'ai utilisé pour générer rapidement l'application, les modèles d'instructions génératives exacts qui m'ont aidé et la manière dont j'ai validé le résultat dans VS Code sans quitter l'éditeur.
Outils que j'ai utilisés (et comment ils s'intègrent dans le flux)
- Visual Studio Code — édition, terminal et chat en ligne.
- Émulateur Azure Cosmos DB basé sur Linux (vNext Preview) — un conteneur Docker local qui me permet d'itérer rapidement sans rien provisionner.
- Azure Databases (extension VS Code) — se connecte à l'émulateur local et permet de parcourir les bases de données/conteneurs/documents directement dans la barre latérale.
- GitHub Copilot Chat (VS Code) — le « partenaire d'écriture » qui transforme l'intention en code, puis m'aide à itérer.
Qu'est-ce que le « vibe coding » dans la pratique ?
- L'intention d'abord. Vous décrivez le résultat (« Ajouter un flux de suppression numéroté avec une confirmation ») plutôt que de donner des directives ligne par ligne.
- Boucle serrée. Demandez une modification → exécutez-la → validez-la immédiatement → demandez une version plus précise ou plus sûre.
- Jugement humain. Vous restez responsable des tests, de la sécurité et de la maintenabilité ; l'assistant accélère la mise en place et les modifications.
Mon objectif : prouver qu'une véritable démo peut être réalisée rapidement lorsque vous travaillez de cette manière, et documenter les étapes conversationnelles qui permettent d'y parvenir.
Le guide de génération de code que j'ai utilisé
Vous trouverez ci-dessous les types de instructions génératives qui ont permis de faire avancer le travail. N'hésitez pas à les copier/coller dans votre propre flux.
- 1) Kickstart : « Planifier → coder » en deux étapes
Demandez d'abord un plan, puis demandez-lui de le mettre en œuvre.
| Code : | Sélectionner tout |
1 2 3 | « Décrivez une application console Python minimale qui utilise le SDK Python Azure Cosmos DB sur un émulateur local. Fonctionnalités : ajouter/lister/supprimer des « vibes ». La clé de partition est /id. Utilisez une sortie console conviviale et colorée. Proposez ensuite une structure de fichiers et toutes les variables d'environnement que vous attendez dans un fichier .env. » |
Poursuivez avec :
| Code : | Sélectionner tout |
« Parfait, générez maintenant une implémentation en un seul fichier dans vibes_manager.py en utilisant votre plan. »
Pourquoi cela fonctionne : l'assistant révèle ses hypothèses et ses dépendances avant d'écrire le code. Vous détectez les problèmes à un stade précoce (choix du SDK, clé de partition, chemins d'erreur).
- 2) Limitez les différences
Ne demandez pas « une série de modifications ». Demandez une seule modification.
| Code : | Sélectionner tout |
1 2 3 4 5 6 | « Ajoutez un workflow de suppression par numéro : - listez les vibes existantes avec leurs numéros - invitez l'utilisateur à en choisir une - affichez un aperçu détaillé - confirmez avant la suppression Conservez le reste du fichier intact. Ne renvoyez que les fonctions nouvelles/modifiées et les modifications apportées à main(). » |
Pourquoi cela fonctionne : les différences minimes sont faciles à examiner et l'assistant reste concentré.
- 3) Décrivez l'expérience utilisateur, pas le code
Décrivez l'expérience que vous souhaitez, pas la mise en œuvre que vous imaginez.
| Code : | Sélectionner tout |
1 2 3 | « Lorsque je supprime une vibe, je devrais pouvoir les faire défiler et les supprimer une par une. Utilisez un menu numéroté et une confirmation finale « Êtes-vous sûr ? ». S'il n'y a pas de vibes, revenez au menu principal avec un message convivial. » |
Pourquoi cela fonctionne : vous obtenez un comportement qui semble correct, et l'assistant choisit des API idiomatiques pour y parvenir.
- 4) Indiquez les faits d'exécution dès le départ
Donnez à l'assistant le contexte d'exploitation pour éviter les impasses.
| Code : | Sélectionner tout |
1 2 3 | « Informations sur l'exécution : Python 3.10, VS Code sur Windows (WSL disponible), émulateur Cosmos fonctionnant localement. Nous utilisons un fichier .env pour COSMOS_ENDPOINT, COSMOS_KEY, COSMOS_DATABASE_NAME=vibes, COSMOS_CONTAINER_NAME=items. Ajoutez un indicateur DISABLE_SSL_VERIFICATION facultatif pour le développement local. » |
Pourquoi cela fonctionne : élimine les conjectures concernant les certificats, les ports et la configuration.
- 5) Demandez des garde-fous
Intégrez dès le début la fiabilité et la lisibilité.
| Code : | Sélectionner tout |
1 2 3 | « Enveloppez les appels Cosmos avec une gestion claire des exceptions (pas de murs de traces). Renvoyez des messages conviviaux et conservez des journaux concis. Ajoutez des indications de type et de petites chaînes de documentation aux méthodes publiques. » |
Pourquoi cela fonctionne : vous n'aurez pas à modifier la gestion des erreurs ultérieurement.
- 6) Déboguer par symptôme, pas par spéculation
Lorsque quelque chose est « rouge dans VS Code », ne devinez pas. Décrivez ce que vous voyez.
| Code : | Sélectionner tout |
1 2 | « vibes_manager.py est rouge dans VS Code et ne fonctionne pas. Recherchez les causes possibles (balisage des chaînes de documentation, importations, valeurs d'environnement manquantes). Proposer des corrections minimales et afficher uniquement les résultats diff. » |
Pourquoi cela fonctionne : l'assistant prend en compte l'environnement, la syntaxe et les importations, et pas seulement un numéro de ligne.
- 7) Refactorisez avec des critères d'acceptation explicites.
Lorsque les changements deviennent plus importants, définissez des tests/vérifications comme objectif.
| Code : | Sélectionner tout |
1 2 3 4 5 | « Refactoriser le menu principal pour utiliser une seule boucle avec un répartiteur de choix. Accepter si : - ajouter/lister/supprimer tout le travail - une entrée non valide renvoie au menu sans lancer d'exception - le chemin de sortie affiche un message d'adieu convivial. » |
Pourquoi cela fonctionne : « Terminé » devient testable, et non subjectif.
- 8) Documentation à la demande
Assurez la cohérence de votre référentiel grâce à des invites qui maintiennent la documentation au fur et à mesure.
| Code : | Sélectionner tout |
1 2 | « Mettre à jour README.md pour refléter le flux de suppression numéroté et l'exigence .env. Mettre à jour copilot-instructions.md avec les informations d'exécution et les modèles d'invite que nous avons utilisés. » |
Pourquoi cela fonctionne : votre futur vous-même, ainsi que vos collaborateurs, obtenez le contexte sans avoir à fouiller dans les commits.
Configuration minimale (sans approfondissement)
- Python venv : créer/activer, pip install -r requirements.txt.
- .env : point de terminaison, clé, base de données, conteneur, indicateur SSL facultatif.
- Émulateur : exécutez le script de démarrage (Docker requis).
- Exécution : lancez l'application (ou utilisez le script d'aide qui la configure et l'exécute).
C'est tout ce dont vous avez besoin pour commencer à demander et à itérer.
Une boucle de validation rapide, dans VS Code
J'ai effectué une vérification claire et reproductible pour confirmer le flux de bout en bout sans quitter l'éditeur :
- Ajoutez une nouvelle ambiance dans l'application console ; notez l'ID imprimé (UID).
- Dans le panneau Azure : Comptes Cosmos DB → Émulateurs locaux → Émulateur NoSQL : 8081 → vibes → items → Items.
- Ouvrez le document dont l'ID correspond à l'UID imprimé et confirmez les champs. Aucun navigateur n'est nécessaire ; l'extension Azure Databases vous permet de rester dans le flux.
Guide de dépannage (instructions génératives que j'ai réellement utilisées)
- Environnement et syntaxe « C'est rouge dans VS Code. Recherchez les chaînes de documentation mal formées, les importations et les valeurs d'environnement manquantes. Proposez des corrections ; affichez uniquement les différences. »
- Régression des fonctionnalités « La fonctionnalité de suppression par numéro a disparu. Réintroduisez-la, en l'intégrant à la boucle principale et aux invites de confirmation. Ne renvoyez que les sections qui ont changé. »
- Problèmes de connexion « Lors de la connexion, affichez un bref message « Assurez-vous que l'émulateur est en cours d'exécution » si nous ne pouvons pas atteindre la passerelle. N'imprimez pas les traces de pile par défaut. »
- Peaufiner « Renforcez les messages utilisateur : des coches de réussite conviviales, des lignes d'erreur courtes et une note « aucune vibration pour l'instant » lorsque la liste est vide. »
Modèles à conserver
- Planifiez → codez en deux messages.
- Une modification par invite (limitez la différence).
- L'expérience utilisateur d'abord (« comment ça se passe » prime sur « comment implémenter »).
- Indiquez tôt les faits relatifs à l'exécution.
- Critères d'acceptation pour les modifications plus importantes.
- Documentation des instructions génératives pour garder le dépôt à jour.
Ce qui importait moins (et pourquoi)
- Déverser de gros blocs de code dans le chat. Il est plus rapide de sélectionner une région dans l'éditeur et de dire « fais faire X à ceci », ou de coller de courts extraits avec la modification exacte que vous souhaitez.
- Architecture prématurée. Pour une démonstration d'une heure, le « bon » échafaudage de l'assistant est exactement ce qu'il vous faut : gardez les grands projets pour plus tard.
Conclusion
Vous pouvez trouver le résultat complet de mon travail dans ce référentiel GitHub. N'hésitez pas à le dupliquer et à l'améliorer ! Vous avez apporté d'autres améliorations avec Vibes ? Soumettez une PR ! Le vibe coding ne remplace pas l'ingénierie, il accélère la compréhension. En traitant l'assistant comme un partenaire d'écriture compétent et en lui donnant des instructions claires et progressives, vous pouvez rapidement mettre en place une démonstration crédible, résoudre les problèmes de manière conversationnelle et tout valider sans quitter VS Code. À partir de là, vous pouvez renforcer la fiabilité, la sécurité et la structure à votre rythme.
Si vous essayez cette approche, utilisez le guide ci-dessus. Commencez modestement, décrivez l'expérience, limitez chaque changement et maintenez une boucle serrée. Vous serez peut-être surpris de la rapidité avec laquelle cette improvisation se transformera en un morceau que vous serez fier de partager.
À propos d'Azure Cosmos DB
Azure Cosmos DB est une base de données distribuée entièrement gérée et sans serveur pour le développement d'applications modernes, avec une vitesse et une disponibilité garanties par un SLA, une évolutivité automatique et instantanée, et la prise en charge des bases de données open source PostgreSQL, MongoDB et Apache Cassandra. Pour rester informé des mises à jour d'Azure Cosmos DB, suivez-nous sur X, YouTube et LinkedIn.
Source : "Everyone is talkin’ bout vibes"
Et vous ?
Pensez-vous que ce guide est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
Mon guide d'ingénierie des prompts ou instructions génératives d'IA pour les développeurs, par Namanyay Goel "Vibe Coding" vs Réalité, par Cendyne L'IA aurait radicalement transformé le codage au point de remplacer bientôt tous les développeurs ? Il n'y a pas de "Vibe Engineering", par Sergey Tselovalnikov Pourquoi le « Vibe Coding » me donne envie de vomir, par Kush Creates
Vous avez lu gratuitement 202 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.