Le vibe coding consiste à décrire en langage naturel l’application que l’on veut, à laisser un modèle d’IA générer le code, puis à juger le résultat sur son comportement plutôt que sur les lignes produites. Le terme date de février 2025 et décrit une pratique qui existait déjà, mais qui a changé d’échelle avec l’arrivée des agents capables de modifier plusieurs fichiers seuls.
Cet article explique le fonctionnement réel de cette approche, ce qui la sépare du no-code et du développement classique, les outils disponibles en 2026, les cas où elle tient la route et ceux où elle casse. La dernière partie porte sur le point que la plupart des contenus sur le sujet laissent de côté : comment encadrer cette pratique dans une équipe sans accumuler de dette technique ni de problème de sécurité.
À retenir
- Le vibe coding consiste à décrire une application en langage naturel et à laisser une IA générer le code, sans le relire ligne à ligne.
- Trois familles d’outils coexistent en 2026 : les générateurs d’application complète comme Lovable ou Bolt.new, les éditeurs augmentés comme Cursor, et les agents en ligne de commande comme Claude Code ou Gemini CLI.
- La méthode donne de bons résultats sur les prototypes, les outils internes et les scripts de traitement de données, mais elle est à écarter dès qu’un projet touche au paiement, aux données personnelles ou doit vivre plusieurs années.
- Le code généré présente des failles récurrentes comme les secrets en dur ou les routes sans authentification : une revue humaine avant mise en ligne reste nécessaire, et un prototype ne passe jamais en production sans reprise complète.
Le vibe coding, c’est quoi exactement ?
Le vibe coding est une méthode de développement logiciel où l’utilisateur formule une demande en langage naturel, un LLM génère le code correspondant, et la validation se fait en exécutant le programme plutôt qu’en lisant le résultat. L’humain décrit une intention, la machine produit un code fonctionnel, et la boucle recommence jusqu’à obtenir le comportement attendu.
Définition en une phrase
On parle de vibe coding lorsque l’utilisateur ne relit pas le code ligne à ligne et accepte de ne pas comprendre en détail ce que le programme fait, tant qu’il fait ce qu’on lui demande.
Cette nuance de degré compte. Simon Willison, développeur et auteur, a formulé le critère le plus utile : si vous relisez et validez chaque ligne de code générée, vous faites du développement assisté par IA, pas du vibe coding. La différence n’est pas dans l’outil utilisé, elle est dans le niveau de contrôle que vous exercez sur le résultat.
D’où vient le terme ?
Andrej Karpathy, cofondateur d’OpenAI et ancien responsable de l’IA chez Tesla, publie le terme dans un post en février 2025. Il y décrit une façon de coder où l’on se laisse porter par le ressenti, où l’on oublie que le code existe, où l’on colle les messages d’erreur sans les lire. Le propos était largement ironique. Il a été repris au premier degré par une bonne partie de l’écosystème.
Trois repères pour situer la date :
- 2021 : GitHub Copilot popularise la complétion de code par IA dans l’éditeur.
- Fin 2022 : ChatGPT rend la génération de code accessible à des profils non techniques via un simple chat.
- 2025 : le terme apparaît, et les outils passent du chat au mode agent, capable d’exécuter des commandes et de modifier une arborescence complète.
Le vocabulaire s’est vite installé. Le terme figure désormais sur Wikipédia, dans les modules de formation Microsoft Learn et dans la documentation de Google Cloud.
Décrire une intention plutôt qu’écrire une instruction
C’est le cœur du changement. Un langage de programmation classique exige une précision absolue : chaque instruction décrit une opération, sans ambiguïté possible. Le langage naturel, lui, est ambigu par construction. L’effort ne disparaît pas, il se déplace vers la formulation de la demande.
Même fonctionnalité, trois niveaux de formulation :
| Formulation | Résultat obtenu |
|---|---|
| Code Python explicite | Exactement ce qui est écrit, rien d’autre |
| « Affiche l’heure » | Un affichage minimal, fuseau horaire par défaut du serveur, aucun format défini |
| « Affiche l’heure et le jour de la semaine dans le fuseau horaire du navigateur, format 24h, mise à jour chaque seconde » | Un composant utilisable en production |
Le deuxième cas illustre le problème central du vibe coding : l’IA comble les trous. Elle prend une décision à votre place sur le fuseau horaire, sur le format, sur la fréquence de rafraîchissement. Un prompt vague ne produit pas une erreur, il produit un programme qui tourne et qui fait autre chose que ce que vous vouliez.
À quoi ressemble une conversation avec l’IA ?
Le fonctionnement se comprend mieux par un exemple que par un schéma. Prenons un tableau de bord interne qui affiche des données issues d’une base existante.
Le premier message pose le cadre
Un brief d’ouverture qui tient la route contient quatre éléments : la stack imposée, les contraintes techniques, le périmètre exact, et ce que vous ne voulez pas. Sans ces éléments, l’outil choisit à votre place, généralement la stack la plus représentée dans ses données d’entraînement.
Deux briefs pour le même projet :
Brief faible : « Crée un tableau de bord pour visualiser mes ventes. »
Brief exploitable : « Crée un tableau de bord en React qui lit une table PostgreSQL existante nommée ventes, affiche le chiffre d’affaires par mois sur 12 mois glissants, avec un filtre par région. Pas de nouvelle dépendance graphique, utilise Recharts. Pas d’authentification pour l’instant, l’application tourne derrière un VPN. »
Le premier produit une application générique avec des données de démonstration inventées. Le second produit un programme qui se branche sur l’environnement réel dès la première itération. Le temps gagné sur les échanges suivants dépasse largement les deux minutes passées à écrire le brief.
La boucle réelle
Quatre temps, répétés jusqu’à satisfaction :
- Vous décrivez ce que vous voulez.
- L’IA génère le code et, en mode agent, l’exécute.
- Vous regardez le résultat à l’écran ou l’erreur dans le terminal.
- Vous reformulez à partir de ce que vous voyez, pas à partir du code.
Cette quatrième étape est ce qui distingue le vibe coding du débogage classique. Vous ne cherchez pas la ligne fautive, vous décrivez le symptôme : « le filtre par région ne remonte que trois régions sur douze », ou vous collez le message d’erreur brut sans le lire. L’assistant identifie la cause et corrige.
Ce que l’IA retient, ce qu’elle oublie
La conversation n’a pas de mémoire infinie. Chaque modèle travaille dans une fenêtre de contexte limitée, et au-delà d’un certain volume d’échanges, les premières instructions sortent de cette fenêtre. Le symptôme est reconnaissable : l’IA réintroduit un bug corrigé vingt messages plus tôt, contredit un choix technique validé, ou réécrit une fonctionnalité qui marchait.
La parade consiste à sortir les règles de la conversation et à les écrire dans un fichier versionné, lu automatiquement à chaque session. La plupart des outils lisent aujourd’hui un fichier de ce type, sous des noms différents selon l’éditeur.
# Règles projet
## Stack
– Next.js 15, TypeScript strict, Tailwind
– Base de données : PostgreSQL via Prisma
– Aucune nouvelle dépendance sans validation explicite
## Conventions
– Composants en PascalCase, fichiers en kebab-case
– Aucune requête SQL brute hors des fichiers repository
– Tous les appels réseau passent par le client centralisé lib/api.ts
## Interdits
– Pas de secrets en dur, variables d’environnement uniquement
– Pas de modification du schéma de base sans migration
Ce fichier se partage par git et s’applique à toute l’équipe. C’est le premier geste de collaboration structurée autour du vibe coding.
Du chat à l’agent
La bascule de 2025 tient en une ligne : l’IA a cessé de répondre pour commencer à agir.
| Critère | Mode chat | Mode agent |
|---|---|---|
| Périmètre d’action | Génère un bloc de code, vous copiez | Lit l’arborescence, modifie plusieurs fichiers |
| Autonomie | Un échange, une réponse | Enchaîne les étapes, lance les tests, corrige |
| Contrôle humain | Total, à chaque copier-coller | À la validation du résultat, ou à chaque commande selon la configuration |
| Projet adapté | Fonction isolée, script, apprentissage | Projet existant, refactorisation, fonctionnalité complète |
Le mode agent change la nature du risque. Un chat produit du texte que vous choisissez d’intégrer. Un agent écrit directement sur le disque, installe des dépendances et lance des commandes. Le gain de temps est réel, la surface d’erreur aussi.
En quoi ça diffère du no-code et du développement classique ?
Quatre approches coexistent aujourd’hui pour produire un logiciel. Elles ne s’excluent pas, mais elles n’ont ni le même plafond de complexité ni le même coût de sortie.
| Développement classique | Vibe coding | Low-code | No-code | |
|---|---|---|---|---|
| Mode de production | Écrire le code | Décrire en langage naturel | Assembler + écrire du code | Assembler dans un éditeur visuel |
| Propriété du code | Totale | Totale, code exportable | Partielle | Aucune, ou export limité |
| Plafond de complexité | Aucun | Élevé, dépend du contexte fourni | Moyen à élevé | Bas à moyen |
| Compétences requises | Développeur | Compréhension technique utile, pas indispensable | Développeur ou profil technique | Aucune |
| Maintenabilité | Dépend de l’équipe | Dépend de la qualité de la revue | Correcte | Assurée par l’éditeur |
| Coût de sortie | Nul | Faible | Moyen | Élevé |
Vibe coding et no-code : le code existe ou non
C’est la différence structurante. Un outil no-code produit une configuration, pas des fichiers source. Vous ne pouvez ni versionner sur git, ni héberger ailleurs, ni faire relire par un développeur externe. Le vibe coding produit du code réel, dans un langage identifiable, que vous téléchargez et déployez où vous voulez.
Cette liberté a une contrepartie directe : la responsabilité de la maintenance vous revient. Un outil no-code met à jour son socle technique pour vous, gère la sécurité de son infrastructure et corrige ses propres bugs. Une application générée en vibe coding vieillit comme n’importe quel logiciel : dépendances obsolètes, failles à corriger, environnement à maintenir.
Vibe coding et low-code
Le low-code s’adresse à des développeurs qui accélèrent sur un socle applicatif existant, avec des briques préconstruites et du code personnalisé par-dessus. La cible est technique, le gain porte sur le temps d’implémentation.
Le vibe coding déplace l’effort ailleurs : vers la précision de la demande et la qualité de la relecture. Un profil non technique peut produire un résultat, ce qui n’est pas vrai du low-code.
Vibe coding et développement traditionnel : le temps change de place
L’idée reçue veut que l’IA supprime le travail. Elle le redistribue. Sur un projet mené en vibe coding, le temps d’écriture s’effondre, le temps de spécification et de vérification augmente.
Répartition observée sur un même périmètre fonctionnel, à titre indicatif :
- Développement classique : écriture 50 %, revue et test 25 %, spécification et architecture 25 %.
- Vibe coding : écriture 10 %, revue et test 45 %, spécification et formulation 45 %.
Le total ne descend pas toujours. Ce qui change, c’est le profil capable de faire le travail et la vitesse d’obtention d’un premier résultat exécutable. Sur un prototype, le gain est massif. Sur un système en production avec des exigences de sécurité, il se réduit fortement.
Les combiner sur un même projet
Le choix n’est pas binaire, et la plupart des projets réels mélangent les trois. Un exemple d’architecture rencontrée fréquemment :
- No-code sur le back-office standard : gestion des utilisateurs, formulaires internes, workflows d’approbation. Ce sont des besoins génériques, les réinventer n’apporte rien.
- Vibe coding sur la couche métier spécifique : calculs propres à l’activité, tableau de bord sur-mesure, intégrations avec des outils internes.
- Développement classique sur les parties critiques : authentification, paiement, traitement de données personnelles.
La règle de répartition tient en une question : que se passe-t-il si ce module dysfonctionne pendant une journée entière sans qu’on s’en aperçoive ? Si la réponse implique un risque financier, juridique ou de confidentialité, le module sort du périmètre vibe coding.
Avec quels outils mener cette conversation ?
Les palmarès d’outils vieillissent en trois mois. Le classement par famille tient plus longtemps, parce qu’il décrit des logiques d’usage différentes.
| Outil | Famille | Profil visé | Modèle économique | Export du code |
|---|---|---|---|---|
| Lovable | Générateur d’app | Non technique, produit | Freemium, crédits | Oui, via git |
| Bolt.new | Générateur d’app | Non technique, prototypage | Freemium, crédits | Oui |
| v0 | Générateur d’interface | Designer, front-end | Freemium | Oui |
| Base44 | Générateur d’app | Créateur de SaaS | Payant | Partiel |
| Cursor | Éditeur augmenté | Développeur | Abonnement | Natif, c’est votre projet |
| Windsurf | Éditeur augmenté | Développeur | Abonnement | Natif |
| Claude Code | Agent CLI | Développeur, projet existant | Abonnement ou API | Natif |
| Gemini CLI | Agent CLI | Développeur | Gratuit avec quotas | Natif |
| Aider | Agent CLI open source | Développeur | Gratuit, coût API | Natif |
| GitHub Copilot | Complétion + agent | Développeur | Abonnement | Natif |
Les outils qui produisent une application complète
Lovable, Bolt.new, v0 et Base44 partagent la même promesse : un prompt en entrée, une application déployée en sortie, base de données et authentification comprises. Vous décrivez le produit, l’outil génère l’interface, le back-end et l’hébergement.
Ce qui les distingue réellement, au-delà du discours commercial :
Lovable pousse loin l’application complète, avec base de données intégrée et déploiement en un clic. Bon pour valider une idée auprès d’utilisateurs réels en quelques heures.
Bolt.new travaille entièrement dans le navigateur et convient bien aux prototypes jetables, ceux qu’on montre en réunion puis qu’on abandonne.
v0 se concentre sur l’interface plutôt que sur l’application entière. C’est l’outil le plus pertinent pour un designer qui veut sortir du statique sans monter un projet complet.
Le prix de l’outil se calcule au crédit, pas à l’abonnement affiché. Une correction qui demande quinze allers-retours consomme quinze fois plus qu’une génération réussie du premier coup. Sur un projet de plusieurs semaines, l’écart entre le tarif annoncé et la facture réelle atteint fréquemment un facteur trois.
Les éditeurs de code augmentés
Cursor et Windsurf conservent l’environnement de travail d’un éditeur classique et y greffent la conversation. Vous voyez l’arborescence, vous ouvrez les fichiers, vous gardez la main sur ce qui est modifié.
Ce format convient aux gens capables de lire du code, même sans l’écrire. La conversation sert à générer, l’éditeur sert à vérifier. C’est le meilleur compromis pour un profil technique qui veut accélérer sans perdre le contrôle du résultat.
Les agents en ligne de commande
Claude Code, Gemini CLI, Aider et les équivalents fonctionnent dans le terminal, au cœur du projet. Ils lisent l’arborescence complète, exécutent les tests, lancent les commandes git.
$ claude
> Ajoute un filtre par région au tableau de bord.
La liste des régions vient de la table `regions`.
Écris les tests, puis lance-les.
Ce format s’impose sur les bases de code existantes plutôt que sur les projets neufs. La raison est mécanique : un générateur d’application part d’une page blanche et impose sa structure. Un agent CLI se branche sur une structure déjà là, lit les conventions en place et s’y conforme. Pour reprendre un projet écrit il y a deux ans par quelqu’un d’autre, c’est la seule approche qui fonctionne correctement.
Les options gratuites, et où la limite arrive
| Niveau | Ce qu’on obtient | Le déclencheur de bascule |
|---|---|---|
| Gratuit | Gemini CLI, Google AI Studio, Aider avec sa propre clé API, tiers gratuits des générateurs | Quota journalier atteint, ou projet trop gros pour la fenêtre de contexte |
| Freemium | Quelques dizaines de générations par mois | Le nombre d’itérations nécessaires dépasse le quota dès la deuxième semaine |
| Payant | Modèles les plus récents, contexte étendu, mode agent complet | — |
La limite arrive presque toujours au même endroit : la taille du contexte. Tant que le projet tient en quelques fichiers, les options gratuites suffisent. Dès que l’agent doit tenir compte de vingt fichiers pour modifier correctement une fonctionnalité, la qualité du résultat dépend directement du modèle utilisé, et les modèles les plus capables ne sont pas gratuits.
Choisir selon trois questions
Savez-vous lire du code ?
Non : générateur d’application. Oui : éditeur augmenté ou agent CLI.
Le projet est-il neuf ou existant ?
Neuf : générateur d’application ou éditeur augmenté. Existant : agent CLI, sans hésitation.
Devez-vous exporter et héberger vous-même ?
Oui : vérifiez l’export git avant de commencer, certains générateurs le restreignent aux formules payantes. Non : le générateur le plus simple fera l’affaire.
Ce que cette façon de développer fait gagner
Trois gains mesurables, et un quatrième qui se voit surtout à l’usage.
Tester une idée en heures plutôt qu’en semaines
Un prototype cliquable change la nature des arbitrages produit. Tant qu’une idée reste une maquette ou un document, la discussion porte sur des opinions. Dès qu’elle devient une application qu’on manipule, elle porte sur des observations.
Cas rencontré sur un projet client : un outil interne de qualification de leads, discuté depuis quatre mois en réunion sans décision. Prototype généré en une demi-journée, testé par trois commerciaux la semaine suivante. Résultat : deux fonctionnalités jugées indispensables se sont révélées inutilisées, une troisième absente du cahier des charges est devenue la priorité. Le développement réel a démarré sur un périmètre réduit de 40 %.
Le prototype n’est pas allé en production. Il a servi à écrire les bonnes exigences, ce qui reste son meilleur usage.
Des profils non techniques qui produisent leurs propres outils
Un responsable acquisition qui veut croiser ses exports Search Console avec ses données CRM attend généralement qu’un développeur se libère. Avec un générateur d’application ou un script Python produit par conversation, il obtient son tableau de bord dans la journée.
| Avant | Avec le vibe coding | |
|---|---|---|
| Demande d’un outil interne simple | Ticket, arbitrage, file d’attente | Production directe par le demandeur |
| Délai typique | 3 à 8 semaines | Quelques heures |
| Charge équipe technique | Développement complet | Revue avant mise en ligne |
| Risque | Faible, process maîtrisé | Réel si aucun contrôle en sortie |
La dernière ligne est le point à ne pas perdre de vue. L’autonomie des équipes métier produit de la valeur, et elle produit aussi des applications qui manipulent des données sensibles sans qu’aucun profil technique les ait regardées.
Le gain qui se voit à l’usage : la barrière d’entrée aux petites tâches
Beaucoup de micro-automatisations ne sont jamais faites parce qu’elles ne justifient pas le coût d’ouverture d’un ticket. Renommer trois cents fichiers selon une règle précise, nettoyer un export CSV mal formaté, extraire des données d’une série de PDF. Chacune de ces tâches représente vingt minutes de code et une heure de coordination.
Le vibe coding supprime la coordination. C’est un effet cumulatif, difficile à chiffrer sur un projet isolé, visible sur plusieurs mois à l’échelle d’une équipe.
Cinq projets où la conversation suffit
Prototype à valider auprès d’utilisateurs
Contexte : une idée de fonctionnalité à tester avant d’engager un budget de développement.
Temps : une demi-journée à deux jours.
Résultat : une application manipulable, avec des données réalistes.
Limite : ne jamais la laisser glisser vers la production parce qu’elle « marche déjà ». C’est l’erreur la plus fréquente et la plus coûteuse.
Outil interne à faible criticité
Un tableau de bord de suivi, un formulaire de collecte, un convertisseur de format. Le critère d’éligibilité est simple : si l’outil tombe en panne un lundi matin, personne n’est bloqué et aucune donnée n’est perdue.
Temps : une journée.
Limite : dès que l’outil touche à des données personnelles, il sort de cette catégorie, même s’il reste interne. Le RGPD ne fait pas de distinction entre une application produite en trois heures et une autre développée en six mois.
Script d’automatisation et traitement de données
Le cas où le vibe coding est le plus fiable. Un script Python a un périmètre fermé, une entrée, une sortie, et un résultat vérifiable immédiatement. Vous voyez si le traitement est correct en regardant le fichier produit.
Temps : de quinze minutes à deux heures.
Limite : vérifier le script sur un échantillon avant de le lancer sur l’intégralité des données, et travailler sur une copie. Un script généré qui écrase des fichiers sources est un problème courant.
Landing page ou micro-site événementiel
Contexte : une page à durée de vie limitée, sans back-end, sans authentification.
Temps : deux à quatre heures avec un générateur d’interface.
Résultat : une page déployée, responsive, modifiable par conversation.
Limite : vérifier l’accessibilité et les performances, deux points systématiquement négligés par la génération automatique. Contrastes insuffisants, images non optimisées, structure de titres incohérente, navigation au clavier cassée. Un audit rapide avant mise en ligne évite d’avoir à tout reprendre.
Les cas où il vaut mieux ouvrir un éditeur
Cinq signaux d’alerte. Un seul suffit à sortir du périmètre :
- l’application traite des données personnelles au sens du RGPD ;
- elle manipule un moyen de paiement ou des données bancaires ;
- une indisponibilité de quelques heures a un impact financier ou juridique ;
- le code devra vivre plus de douze mois et être repris par quelqu’un d’autre ;
- l’application est exposée publiquement sur internet sans couche d’authentification déjà éprouvée.
Rien n’interdit d’utiliser un assistant IA sur ces projets. Ce qui change, c’est le mode : relecture ligne à ligne, tests écrits et exécutés, revue par un développeur. On quitte le vibe coding pour du développement assisté.
Quand la conversation atteint ses limites ?
Le problème structurel du vibe coding tient en une phrase : l’IA répond toujours, y compris quand elle a tort, et rien dans le ton de la réponse ne le signale. Un développeur qui bloque le dit. Un modèle génère un code plausible, confiant et faux avec la même fluidité qu’un code correct.
| Risque | Fréquence | Impact | Mesure de réduction |
|---|---|---|---|
| Secrets exposés | Élevée | Critique | Recherche de chaînes sensibles avant tout commit |
| Endpoint sans contrôle d’accès | Élevée | Critique | Test manuel des appels sans session valide |
| Dépendances obsolètes ou vulnérables | Moyenne | Élevé | Audit automatisé des dépendances |
| Code illisible, non maintenable | Très élevée | Moyen à long terme | Revue humaine, documentation générée |
| Perte de cohérence sur projet long | Élevée | Moyen | Fichier de règles, sessions courtes |
| Coût dérivant | Moyenne | Moyen | Suivi de la consommation dès la première semaine |
Le code fonctionne, mais il n’est pas sûr
Les trois problèmes de sécurité récurrents dans le code généré :
Les secrets en dur.
Clés d’API, identifiants de base de données, tokens d’accès écrits directement dans le code, parfois dans un fichier front-end livré au navigateur. L’application fonctionne parfaitement, et la clé est lisible par n’importe quel visiteur via l’inspecteur.
Les endpoints sans vérification.
Une route qui renvoie la liste des utilisateurs, accessible sans authentification parce que personne n’a demandé de contrôle d’accès et que l’IA n’en a pas ajouté spontanément. Le test tient en une commande : appeler l’URL depuis une session vide et regarder ce qui revient.
Les dépendances non maîtrisées.
Un modèle propose les bibliothèques présentes dans ses données d’entraînement, avec des versions parfois antérieures de plusieurs mois et des vulnérabilités connues depuis.
Checklist minimale avant toute mise en ligne :
- Aucun secret dans le code, tout passe par des variables d’environnement
- Chaque route testée sans session valide
- Audit des dépendances exécuté et vulnérabilités critiques traitées
- Entrées utilisateur validées côté serveur, pas seulement côté navigateur
- Messages d’erreur ne révélant ni structure de base ni chemin serveur
- Sauvegarde et procédure de retour arrière en place
Personne ne comprend ce qui a été écrit
Le code produit tourne. Il n’est pas forcément lisible, cohérent d’un fichier à l’autre, ni documenté. La facture arrive six mois plus tard, quand quelqu’un d’autre doit modifier une fonctionnalité.
Le billet de bioinfo-fr sur le sujet rappelle une réalité que les démonstrations d’outils occultent : le métier consiste en grande partie à reprendre du code ancien, comprendre ce qu’un collègue a écrit il y a deux ans et corriger un comportement inattendu. Le vibe coding optimise la phase de création et alourdit celle-là.
Un contrepoids simple : demander à l’IA de documenter ce qu’elle vient de produire, en commentaire dans le code et dans un fichier README. La génération de documentation coûte quelques minutes et reste correcte, parce que le modèle a toujours le contexte en mémoire à cet instant. Six mois plus tard, personne ne l’a.
La conversation perd le fil sur les projets longs
Trois signaux qui indiquent qu’il faut repartir d’une session propre :
- l’IA réintroduit un bug corrigé plus tôt dans la même conversation ;
- elle propose une solution qui contredit un choix technique validé ;
- elle réécrit une fonctionnalité qui fonctionnait sans qu’on l’ait demandé.
Ces trois symptômes ont la même cause : les informations utiles sont sorties de la fenêtre de contexte. La solution n’est pas de répéter les instructions dans le chat, mais de les déplacer dans le fichier de règles versionné, puis de relancer une session.
Dépendance à la plateforme et coût réel
La facturation au crédit rend le coût imprévisible, parce qu’il dépend du nombre d’itérations, donc de la qualité de vos prompts et de la complexité du projet.
Simulation sur un projet type, un outil interne développé sur six semaines :
| Poste | Estimation initiale | Coût réel observé |
|---|---|---|
| Abonnement outil | 25 €/mois × 2 = 50 € | 50 € |
| Crédits supplémentaires | 0 € | 120 à 300 € |
| Hébergement | Inclus | 20 €/mois au-delà du tier gratuit |
| Total sur 12 mois | ~100 € | ~450 à 650 € |
Le montant reste faible comparé à un développement classique. Le point de vigilance est ailleurs : vérifier avant de commencer que l’export du code est possible sur votre formule. Certains générateurs réservent cette fonction aux offres payantes supérieures, ce qui transforme un choix technique en engagement contractuel.
À qui appartient le code généré ?
Trois questions à poser avant de démarrer un projet client :
Propriété. La plupart des éditeurs accordent la propriété du code généré à l’utilisateur. Ce n’est pas universel, et les conditions d’utilisation changent. À vérifier explicitement, pas à supposer.
Licences des dépendances. Le code généré importe des bibliothèques dont les licences s’appliquent à votre projet. Une licence copyleft dans une application commerciale crée une exigence de publication du code que personne n’avait anticipée.
Confidentialité des données. Le code de votre client, ses schémas de base et ses règles métier transitent par l’infrastructure de l’éditeur pendant la génération. Vérifier le traitement des données, la localisation des serveurs et les conditions de réutilisation pour l’entraînement des modèles. Sur un projet sous NDA, c’est un préalable contractuel.
Comment cadrer le vibe coding dans une équipe ?
Le passage de l’usage individuel à la pratique collective est le point que la plupart des contenus sur le sujet laissent de côté. C’est pourtant là que se joue la différence entre une équipe qui gagne du temps et une équipe qui accumule des applications que personne ne maîtrise.
Le circuit type, du prompt à la production :
Demande formulée → génération → revue automatisée (tests, audit des dépendances, recherche de secrets) → revue humaine sur les zones sensibles → mise en préproduction → validation métier → production.
Les deux étapes de revue sont non négociables. Tout le reste peut être allégé selon la criticité du projet.
Écrire les règles une fois plutôt que les répéter à chaque conversation
Un fichier de règles versionné dans le dépôt, lu par l’outil à chaque session, partagé par toute l’équipe. Il évite que chaque développeur reformule les mêmes contraintes et que chaque session reparte de zéro.
Contenu minimal :
# Règles projet — [nom]
## Stack imposée
– Framework, langage, version
– Base de données et ORM
– Bibliothèques autorisées, et interdiction d’en ajouter sans validation
## Conventions de code
– Nommage des fichiers, des composants, des fonctions
– Organisation des dossiers
– Gestion des erreurs et des logs
## Sécurité
– Aucun secret en dur, variables d’environnement uniquement
– Validation systématique des entrées côté serveur
– Contrôle d’accès obligatoire sur toute route exposée
## Interdits
– Modification du schéma de base sans migration
– Suppression de fichiers sans demande explicite
– Commandes git destructives
Le fichier se maintient comme le reste du code. Une règle ajoutée après un incident évite sa répétition sur tous les projets suivants.
Les zones où la relecture humaine reste non négociable
Liste fermée, à afficher quelque part de visible :
- authentification et gestion des sessions ;
- paiement et données bancaires ;
- lecture ou écriture de données personnelles ;
- appels à des services externes avec des identifiants ;
- toute modification du schéma de base de données ;
- droits et permissions utilisateurs.
Sur ces six zones, la revue se fait ligne à ligne, par quelqu’un capable de comprendre le code. Le reste peut passer par une revue de comportement : est-ce que ça fait ce qu’on attend, dans les cas normaux et dans les cas limites.
Tester ailleurs qu’en production
Faire générer les tests par le même outil fonctionne bien, à une condition : les écrire avant de valider la fonctionnalité, pas après. Un test écrit après coup se contente souvent de valider le comportement observé, y compris quand il est faux.
Un pipeline minimal suffit pour la plupart des projets :
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– run: npm ci
– run: npm audit –audit-level=high
– run: npm run lint
– run: npm test
Trois vérifications automatiques, quelques minutes d’exécution, et la majorité des problèmes de dépendances et de régression détectés avant la mise en ligne.
Qui déploie, qui documente, qui gère les secrets
Une charte interne en huit points, à adapter selon la taille de l’équipe :
- Tout projet généré vit dans un dépôt git, sans exception.
- Le fichier de règles est créé avant la première génération.
- Les secrets passent exclusivement par des variables d’environnement, jamais dans le code ni dans un prompt.
- Aucun code client sous NDA n’est envoyé à un outil dont les conditions de confidentialité n’ont pas été validées.
- Le déploiement en production passe par une personne identifiée, différente de celle qui a généré le code sur les projets critiques.
- Chaque projet dispose d’un README indiquant ce qui a été généré, avec quel outil, et ce qui a été relu.
- La checklist de sécurité est cochée avant toute mise en ligne publique.
- Un prototype ne devient jamais une application de production sans une reprise complète du code.
Le point 8 est celui qui coûte le plus cher quand il n’est pas respecté. Un prototype validé produit une pression forte pour le mettre en ligne tel quel, puisqu’il fonctionne déjà. C’est précisément le moment où la dette technique s’installe.
Ce que ça change pour les métiers
| Compétences qui prennent de la valeur | Compétences qui en perdent |
|---|---|
| Spécifier précisément un besoin | Écrire du code répétitif |
| Relire et évaluer du code | Mémoriser une syntaxe |
| Concevoir une architecture | Connaître une bibliothèque par cœur |
| Identifier un risque de sécurité | Configurer un environnement de développement |
| Tester dans les cas limites | Chercher une solution sur les forums |
Pour les développeurs, le temps se déplace vers la revue
Le travail ne disparaît pas, il change de nature. Moins d’écriture, plus d’architecture, de spécification et de relecture critique. Un développeur senior gagne beaucoup à cette bascule : son expérience porte justement sur les décisions structurantes et sur la détection des problèmes que l’IA ne signale pas.
Les profils juniors sont plus exposés. Le raccourci est tentant, et il court-circuite l’apprentissage par l’erreur qui construit la compréhension technique. Un développeur qui n’a jamais débogué seul ne sait pas reconnaître un code généré qui va poser problème dans six mois. La responsabilité est partagée entre l’individu et l’équipe qui l’encadre.
Pour les profils produit, design et marketing
La différence entre une maquette et un prototype fonctionnel :
| Maquette Figma | Prototype généré | |
|---|---|---|
| Ce qu’on teste | La perception visuelle | Le comportement réel |
| Données affichées | Fictives et figées | Réelles ou réalistes |
| Retour utilisateur | Sur l’apparence | Sur l’usage |
Un designer qui arrive en réunion avec une application manipulable change la conversation avec l’équipe technique. La discussion ne porte plus sur ce qu’il faudrait faire, mais sur ce qui manque à ce qui existe déjà.
Se former à quoi, exactement
Deux niveaux à distinguer.
La formation à un outil se périme vite. Un tutoriel sur une interface de 2025 décrit une application qui a changé trois fois depuis. Utile pour démarrer, sans valeur durable.
La compréhension des fondamentaux reste rentable : comment fonctionne une base de données, ce qu’est une requête HTTP, pourquoi un secret ne doit pas se trouver côté client, ce que signifie valider une entrée utilisateur. Ce socle permet de repérer un code généré qui pose problème, ce qu’aucune formation à l’outil n’apprend.
Ressources sérieuses :
| Ressource | Niveau | Durée |
|---|---|---|
| Module d’introduction au vibe coding, Microsoft Learn | Débutant | 1 heure |
| Documentation Google Cloud sur le développement assisté par IA | Intermédiaire | Variable |
| Documentation officielle des éditeurs (Cursor, Claude Code, GitHub Copilot) | Tous niveaux | Variable |
| Fondamentaux du développement web, parcours type MDN ou OpenClassrooms | Débutant à intermédiaire | Plusieurs semaines |
Questions fréquentes sur le vibe coding
Peut-on faire du vibe coding avec ChatGPT ?
Oui, pour des scripts, des fonctions isolées ou des pages simples. Vous décrivez le besoin, vous copiez le code généré, vous l’exécutez. La limite apparaît sur les projets multi-fichiers : sans accès à votre arborescence, l’assistant ne voit pas le contexte et produit du code incohérent avec l’existant.
Quelle est la différence entre vibe coding et no-code ?
Le vibe coding produit du code source que vous pouvez exporter, versionner et héberger où vous voulez. Le no-code produit une configuration dans l’éditeur d’une plateforme, sans code récupérable. Le premier vous laisse la propriété et la responsabilité de la maintenance, le second délègue les deux.
Le vibe coding est-il sécurisé ?
Le code généré présente des failles récurrentes : secrets en dur, routes sans contrôle d’accès, dépendances obsolètes. Rien n’est signalé, puisque l’application fonctionne. Une vérification avant mise en ligne est obligatoire dès que le projet est exposé sur internet ou traite des données personnelles.
Peut-on mettre une application générée en production ?
Oui, à condition de la traiter comme n’importe quelle application : revue du code sur les parties sensibles, tests, audit des dépendances, sauvegardes. Un prototype validé ne devient pas une application de production parce qu’il fonctionne à la démonstration.
Quel outil de vibe coding choisir pour débuter sans savoir coder ?
Un générateur d’application complète comme Lovable ou Bolt.new. Vous décrivez le produit, l’outil génère l’interface, la base de données et l’hébergement. Vérifiez avant de commencer que l’export du code est possible sur votre formule.
Quel est le meilleur outil de vibe coding pour un designer ?
v0 pour générer des interfaces à partir d’une description ou d’une maquette, sans monter un projet complet. Le résultat est du code React exportable, utilisable directement par l’équipe technique.
Le vibe coding remplace-t-il les développeurs ?
Non. Il supprime une partie de l’écriture, pas l’architecture, la revue, la sécurité ni la maintenance. Sur un projet en production, le temps gagné sur la génération se reporte sur la vérification. Le métier se déplace, il ne disparaît pas.
Combien coûte le vibe coding ?
Entre 20 et 40 € par mois pour un abonnement, auxquels s’ajoutent des crédits facturés à l’usage. Sur un projet de plusieurs semaines, la facture réelle atteint fréquemment trois fois le tarif affiché, parce que chaque itération de correction consomme des crédits.
À qui appartient le code généré ?
Dans la plupart des cas, à l’utilisateur, selon les conditions d’utilisation de l’éditeur. À vérifier explicitement projet par projet, notamment pour un travail client. Les licences des bibliothèques importées s’appliquent séparément et peuvent créer des exigences de publication.
Peut-on utiliser le vibe coding sur un projet existant ?
Oui, et c’est même le cas où il est le plus utile. Utilisez un agent en ligne de commande comme Claude Code, Gemini CLI ou Aider : il lit l’arborescence, respecte les conventions en place et modifie plusieurs fichiers de façon cohérente. Les générateurs d’application, eux, partent d’une page blanche et imposent leur structure.
