Il y a quelques mois, un fondateur m'a contacte avec une phrase que j'entends de plus en plus : « L'appli, je l'ai deja, elle marche, il ne reste qu'une derniere touche. » J'ai ouvert son ecran, et effectivement, ca tournait. Belle interface, boutons cliquables, donnees qui s'affichent. Le tout monte en quelques jours avec Lovable, quasiment sans une ligne de code ecrite a la main. Le probleme, c'est que cette « derniere touche » representait en realite tout ce qui separe une demo d'un produit. Et ce « tout » pesait plus lourd que l'ensemble du travail deja accompli.
Ce phenomene porte desormais un nom : le vibe coding. Dans cet article, je vous explique de quoi il s'agit, pourquoi il est genial pour un prototype et dangereux pour un produit, ce qui manque concretement a une application vibe codee, quand il suffit largement (oui, parfois il suffit vraiment) et comment transformer un tel prototype en un vrai produit, capable de tenir en production face a de vrais clients.
Qu'est-ce que le vibe coding
Le vibe coding, c'est une facon de developper ou vous ne construisez pas une application en ecrivant du code, mais en decrivant en langage naturel ce que vous voulez a un outil d'IA. « Fais-moi une application de liste de taches avec authentification et mode sombre », et en quelques secondes vous avez un ecran fonctionnel. La couleur ne vous plait pas, vous demandez de la changer. Il manque un bouton, vous demandez de l'ajouter. Vous n'ecrivez pas le code ligne par ligne : vous pilotez au feeling, vous demandez, vous regardez le resultat, vous demandez une correction.
Les outils qui font cela sont desormais bien connus : Lovable et Bolt generent une application entiere, v0 produit l'interface, Cursor, ChatGPT et Claude Code ecrivent du code a partir d'une conversation. C'est une technologie reellement impressionnante, et je ne la denigre pas : j'utilise moi-meme l'IA tous les jours dans mon travail. La question n'a jamais ete « est-ce que l'IA sait ecrire du code ». La vraie question, c'est « est-ce que ce qu'elle a ecrit tiendra dans le monde reel ».
Car le vibe coding a une propriete invisible : il est optimise pour donner l'impression que ca marche. L'IA genere du code qui passe le test evident : vous cliquez sur un bouton, quelque chose se produit. Mais « ca marche sur mon ecran » et « ca tient en production face a de vrais utilisateurs » sont deux choses totalement differentes, et c'est precisement entre les deux que se cache le travail que l'IA ne fait pas d'elle-meme.
Pourquoi c'est genial pour un prototype et dangereux pour un produit
La mission d'un prototype est unique : prouver une idee. Il lui suffit de fonctionner pour vous, une fois, dans le scenario ideal (le chemin ou l'utilisateur fait tout correctement et rien ne casse). Si vous voulez montrer a un investisseur a quoi ressemblera votre service, ou simplement verifier vous-meme si l'idee a du sens, le vibe coding est inegalable. Ce qui demandait hier une semaine et plusieurs milliers d'euros se fait aujourd'hui en une apres-midi. C'est un avantage reel, considerable.
La mission d'un produit est tout autre. Un produit doit fonctionner non pas pour vous, mais pour des inconnus. Avec une connexion internet mediocre. Avec des donnees mal saisies. Avec quelqu'un qui cherche a vous pieger. La nuit, pendant que vous dormez. Six mois plus tard, quand une bibliotheque a change. Avec mille utilisateurs simultanes, pas un seul. C'est la qu'un prototype vibe code commence a se fissurer, et il craque non pas la ou ca se voit, mais la ou ca ne se voit pas, jusqu'a ce qu'il soit trop tard.
L'illusion la plus dangereuse du vibe coding
Quand l'application a l'air finie a 90 %, l'intuition souffle qu'il reste 10 % de travail. En realite, c'est l'inverse : la partie visible (interface, boutons, ecrans) est la partie facile, celle que l'IA fait bien. La partie invisible (securite, donnees, cas limites, deploiement) est a la fois la plus difficile et la plus chere. Ces 30 % difficiles, je les detaille dans mon article « Bloque avec votre application IA ? Que faire concretement ».
7 choses qui manquent a une application vibe codee
Quand je reprends un projet vibe code, il manque presque toujours les memes sept elements. Non pas parce que l'IA serait « mauvaise », mais parce qu'elle genere ce que vous lui demandez, et que personne ne lui demande ces choses-la : on ne sait meme pas qu'elles existent, jusqu'a ce qu'elles deviennent un probleme.
| Ce qui manque | Pourquoi c'est essentiel en production |
|---|---|
| 1. Tests automatises | Sans tests, chaque modification est un pari. Vous corrigez un endroit, un autre casse en silence. Le code vibe code n'a quasiment jamais de tests, donc le projet devient de plus en plus fragile a mesure qu'on y touche. |
| 2. Gestion des erreurs | Que se passe-t-il quand le reseau coupe, que le serveur ne repond pas ou que l'utilisateur saisit n'importe quoi ? Dans un prototype : ecran blanc ou plantage. Dans un produit, il faut un message clair, un chemin de repli et une remontee silencieuse de l'erreur. |
| 3. Securite et RGPD | Cles d'API en clair dans le code, base de donnees non protegee ou n'importe qui recupere les donnees des autres, aucune validation des saisies, ni mentions legales ni bandeau cookies conforme CNIL. C'est la faille la plus frequente et la plus dangereuse, et c'est aussi une non-conformite RGPD qui vous expose. |
| 4. Migrations de donnees | Quand vous ajoutez un champ ou modifiez la structure, les donnees deja presentes des utilisateurs doivent « demenager » sans perte. Dans un prototype, on change le schema en supprimant et recreant : en production, cela signifierait des clients effaces. |
| 5. Monitoring | En production, vous devez decouvrir un probleme avant votre utilisateur. Sans suivi des erreurs ni logs, vous ne voyez pas que la moitie des gens n'arrivent plus a se connecter : vous l'apprenez seulement quand ils cessent de revenir. |
| 6. Mise a l'echelle | Du code qui fonctionne avec un utilisateur peut s'effondrer avec cent. Requetes non optimisees, aucun cache, tout sur un seul fil d'execution : sans importance pour un prototype, fatal pour un produit des sa premiere journee de succes. |
| 7. Maintenance | Les bibliotheques vieillissent, des failles de securite apparaissent, les regles de paiement et d'authentification evoluent. Un produit exige un entretien continu. Un code vibe code que personne ne comprend devient irreparable apres la premiere vraie panne. |
Remarquez bien : aucun de ces sept elements n'est visible par l'utilisateur tant que tout va bien. Ils se revelent tous le jour ou ca tourne mal, et c'est precisement pour eux qu'un produit coute plus cher et prend plus de temps a construire qu'un prototype. Ce n'est pas du « vernis » de finition, c'est la fondation.
Quand le vibe coding suffit vraiment
Maintenant, la partie la plus importante et la plus honnete de cet article. Le vibe coding n'est pas « mauvais ». Il existe de nombreux cas ou il suffit, et meme ou il est le choix le plus intelligent. Si vous tombez dans l'un d'eux, ne me payez pas : economisez votre argent et construisez vous-meme.
Ici, le vibe coding suffit largement
- Un outil interne pour quelques personnes. Un tableur, une mini-base, un petit systeme utilise par votre equipe. S'il ne detient pas de donnees de tiers et ne traite pas d'argent, montez-le avec l'IA sans vous poser de question.
- Une demo pour un investisseur ou un client. Vous devez montrer a quoi ressemble l'idee. Peu importe ce qu'il y a sous le capot si le but est de convaincre, pas de servir des clients.
- La visualisation d'une idee pour vous-meme. Vous voulez voir si votre concept a du sens avant d'investir un vrai budget. Un prototype vibe code repond a cette question pour le prix le plus bas.
- Un projet personnel. Un hobby, un journal personnel, un outil pour vous seul. S'il casse, il casse pour vous tout seul, et vous le supporterez.
La regle generale est simple : si l'application ne detient pas de donnees de tiers et ne traite pas d'argent, le vibe coding vous suffit probablement.
Quand le vibe coding ne suffit plus
Et maintenant l'autre versant. Il existe une limite au-dela de laquelle « on dirait que ca marche » devient un risque qui coute bien plus cher que ce que vous avez economise en le construisant. Vous franchissez cette limite au moment ou des gens que vous ne connaissez pas commencent a utiliser l'application, ou quand de l'argent y transite.
| Le vibe coding suffit | Une reconstruction professionnelle s'impose |
|---|---|
| Seul vous ou un cercle restreint de confiance l'utilisez | De vrais clients inconnus l'utilisent |
| Aucun argent dans le systeme | Paiements (Stripe, PayPlug, CB), abonnements, encaissements |
| Donnees sans importance ou publiques | Donnees personnelles, RGPD, vie privee des clients |
| Une panne ne coute rien | Une indisponibilite signifie des clients ou une reputation perdus |
| Duree de vie de quelques semaines | Doit fonctionner et etre maintenu pendant des annees |
Des qu'apparaissent de vrais clients ou des paiements, chacun de ces sept elements manquants se transforme en responsabilite. Une base de donnees non protegee contenant vos clients n'est plus un detail technique, c'est une violation du RGPD que la CNIL peut sanctionner. Des paiements sans gestion des erreurs, ce sont des sommes qui disparaissent entre vous et la banque. Voila pourquoi ce n'est plus une question de vibe coding, mais une question de produit. Et sur le marche francais, un acheteur serieux ajoutera tres vite : un devis signe, des CGV, une facture conforme et l'hebergement des donnees en Europe.
Comment transformer un prototype vibe code en produit
Bonne nouvelle : un prototype vibe code n'est pas du travail gaspille, c'est souvent un excellent point de depart. Vous avez deja decide ce que l'application fait, a quoi elle ressemble, quelle logique elle suit. C'est la partie la plus precieuse et la plus difficile a coucher dans un cahier des charges, et elle est deja faite. Il reste a combler les 30 % difficiles, ceux qui font qu'un prototype n'est pas un produit.
Quand on me confie un projet vibe code, je commence par auditer le depot et je tranche une chose : continuer sur le code existant ou reconstruire proprement. Ce n'est pas la quantite de code qui decide, c'est sa structure. Si la logique et le modele de donnees sont sains, je continue dessus et j'ajoute la couche manquante. Si le code est chaotique, avec des cles exposees et un etat ingerable, une reconstruction propre est plus rapide et moins chere que le rafistolage. J'explique plus en detail ce qui se passe quand le code IA commence a s'effondrer, et que les « corrections » l'effondrent encore davantage, dans mon article « Lovable, Bolt, v0, Cursor : que faire quand le code IA casse ».
Le chemin du prototype a la production
- Audit. J'examine ce qui fonctionne vraiment et ce qui en a seulement l'air. Je repere les failles de securite, les manques RGPD et les points critiques. Vous repartez avec un compte rendu clair et structure, pas avec du jargon.
- Une fondation solide. Base de donnees securisee, authentification serieuse (Auth0, Clerk, Supabase Auth ou FranceConnect selon le projet), cles cachees, validation des saisies : la base sur laquelle on peut construire.
- Les 30 % difficiles. Paiements, integrations, gestion des erreurs, cas limites. En France, s'y ajoutent souvent des integrations locales que l'IA ne branchera pas : paiement via le reseau CB (Stripe, PayPlug, Lyra/Systempay), signature electronique eIDAS (Yousign, Universign), facturation electronique conforme (Chorus Pro, format Factur-X) en vue de l'obligation B2B de septembre 2026, ou encore la livraison (Mondial Relay, Colissimo, Chronopost via un agregateur comme Sendcloud ou Boxtal).
- Le filet de securite. Tests, monitoring et logs, pour que vous appreniez le probleme avant votre client.
- Deploiement et maintenance. Un vrai domaine, un hebergement serieux (idealement souverain, type OVHcloud, Scaleway ou Clever Cloud), des sauvegardes et un accord clair sur qui assure le suivi ensuite.
Ma proposition n'est jamais « je vais nettoyer ton code ». Elle est « je construis quelque chose qui fonctionne et qui rapporte ». La difference est essentielle : nettoyer du code est cosmetique, alors que construire un produit signifie que vos clients peuvent l'utiliser sereinement, payer et revenir, pendant que vous dormez tranquille.
Les vrais chiffres
Parlons prix concrets, puisque vous allez de toute facon poser la question. Si le prototype vibe code possede deja sa logique et ses ecrans, une reconstruction propre jusqu'a la production, avec authentification, securite, deploiement et integrations de base, coute generalement a partir de 8 000 a 15 000 € HT. Les produits plus complexes, avec paiements, integrations locales et back-office, demarrent a partir de 15 000 € HT. A titre de repere, le TJM d'un developpeur freelance senior (React/Next.js, mobile, IA) se situe en 2026 entre 700 et 1 200 € HT par jour, pour un TJM median tech autour de 500 à 550 € HT. Les delais sont le plus souvent de 3 a 8 semaines, selon ce que le prototype a reellement atteint.
Cela peut sembler beaucoup pour un projet « presque fini ». Mais repensez au tableau des sept elements manquants : vous ne payez pas pour le vernis, vous payez pour cette fondation sans laquelle l'application n'est pas un produit, seulement sa photographie. En France, le reflexe sain est de comparer trois devis : faites-le, et regardez surtout ce que chaque devis inclut en matiere de securite, de conformite RGPD et de mise en production reelle, pas seulement le prix affiche.
Vous avez un prototype vibe code a transformer en vrai produit ?
J'examine votre projet Lovable, Bolt, v0 ou Cursor et je vous dis franchement s'il vaut mieux continuer sur le code existant ou reconstruire proprement, avec un prix et un delai precis. Vous recevez un audit clair, un devis detaille, des CGV et une facture conforme. Premier echange sans engagement.
Discuter de mon projetQuestions frequentes
Qu'est-ce que le vibe coding ?
Le vibe coding est une facon de developper ou vous decrivez en langage naturel a un outil d'IA (Lovable, Bolt, v0, Cursor, ChatGPT, Claude Code) ce que vous voulez, et il genere le code. Vous n'ecrivez pas le code ligne par ligne : vous pilotez au feeling, vous demandez, vous regardez le resultat, vous demandez une correction. C'est ideal pour un prototype rapide, mais le code genere n'a souvent pas ce qu'il faut pour la production : tests, gestion des erreurs, securite, conformite RGPD.
Quelle est la difference entre un prototype et un produit ?
Un prototype doit prouver une idee : il suffit qu'il fonctionne sur votre ecran, dans le scenario ideal. Un produit doit tenir en production, face a de vrais utilisateurs, une connexion mediocre, des saisies erronees et des personnes malveillantes. La difference, ce sont les tests, la gestion des erreurs, la securite, les migrations de donnees, le monitoring, la mise a l'echelle et la maintenance : exactement ce qui manque a un prototype vibe code.
Peut-on mettre un prototype vibe code directement en production ?
Techniquement vous pouvez deployer, mais je le deconseille des qu'il y a de vrais clients ou des paiements. Un prototype vibe code manque presque toujours de securite (cles d'API exposees, base de donnees non protegee), de gestion des erreurs et de monitoring, et il est rarement conforme au RGPD (pas de mentions legales, bandeau cookies non conforme CNIL). La premiere personne mal intentionnee ou la premiere donnee inattendue le fait tomber. Avant la mise en production, il faut combler les 30 % difficiles : securite, donnees, deploiement et cas limites.
Quand le vibe coding suffit-il vraiment ?
Le vibe coding suffit quand l'application ne detient pas de donnees de tiers et ne traite pas d'argent : un outil interne pour quelques personnes, une demo pour un investisseur, la visualisation d'une idee, un projet personnel. Si seuls vous ou un cercle restreint de confiance l'utilisez, une solution vibe codee vous fait gagner beaucoup de temps et d'argent. Dans ce cas, je ne vous conseille pas de payer un developpeur.
Combien coute le passage d'un prototype vibe code a un vrai produit ?
Cela depend de ce que le prototype a deja atteint. Si la logique et les ecrans sont la, une reconstruction propre jusqu'a la production, avec authentification, securite, deploiement et integrations de base, coute generalement a partir de 8 000 a 15 000 € HT. Les produits plus complexes, avec paiements (Stripe, PayPlug, CB), integrations locales et back-office, demarrent a partir de 15 000 € HT. La partie la plus difficile et la plus chere est toujours ce dernier 30 %, pas le debut.
Vaut-il mieux continuer sur le code vibe code ou tout reecrire ?
Ce n'est pas la quantite de code qui decide, c'est sa structure. Si la logique et le modele de donnees du prototype sont sains, je peux souvent continuer dessus et ajouter la couche de production manquante. Si le code est chaotique, avec des cles exposees et un etat ingerable, une reconstruction propre est plus rapide et moins chere que le rafistolage. Je decide apres un audit du depot, et je choisis toujours le chemin qui vous amene le moins cher possible vers un produit fonctionnel et maintenable.