Vibe coding et site pro : le mariage impossible

Le vibe coding est génial pour explorer. Pour livrer, c’est un piège

Je vais être direct : j’adore le vibe coding. Pour tester une idée un dimanche soir, pour maquetter une interface en quinze minutes, pour vérifier qu’un flux a du sens avant de l’écrire proprement, c’est un outil que j’utilise sans complexe. Le problème n’est pas là. Le problème, c’est le moment où on décide de mettre ce prototype en production et de facturer des clients dessus.

Le vibe coding désigne une façon de programmer où l’on décrit une intention en langage naturel, où l’IA génère tout le code, et où, c’est le point clé, on accepte les modifications sans relire les diffs. Le terme a été inventé par Andrej Karpathy en février 2025 (Wikipedia). Karpathy lui-même décrivait sa méthode comme « copier-coller les messages d’erreur sans les analyser » (Studeria). Ça marche merveilleusement pour un prototype. Ça se retourne contre vous dès qu’il y a de vrais utilisateurs et de l’argent en jeu.

Un site pro, ce n’est pas une vibe, c’est une spec

Une « vibe » est en réalité une exigence non écrite qui change constamment. C’est la formulation d’InfoWorld et elle est parfaite (InfoWorld). Un site professionnel, lui, repose sur des contraintes explicites : le tunnel de paiement doit gérer un échec de carte bancaire, un panier abandonné, une TVA à trois taux, un stock à zéro, un utilisateur qui appuie deux fois sur « Valider ». Les edge cases désignent ces cas limites, rares mais bien réels, qu’un système doit gérer sans broncher. L’IA ne les invente pas si vous ne les nommez pas.

Et c’est exactement là que ça casse. Une étude 2025 montre 84-89 % de réussite sur des benchmarks synthétiques mais 25-34 % sur des tâches réelles issues de vrais dépôts (bioinfo-fr). Les agents IA passent les failles génériques mais ratent systématiquement la logique métier et l’autorisation des API (The Intelligence Academy), précisément ce qui sépare une démo d’un produit qui encaisse des paiements.

Le cadrage n’est pas une lourdeur d’ancien monde. C’est ce qui transforme une intention floue en système qui tient. Je l’ai déjà écrit à propos du brief créatif face au prompt : l’humain qui définit les contraintes change tout. Le vibe coding supprime précisément cette étape.

La dette technique n’est pas une opinion, elle est chiffrée

Le rapport Veracode 2025, sur plus de 100 modèles de langage testés, est brutal : 45 % des échantillons de code générés échouent aux tests de sécurité et introduisent des vulnérabilités du OWASP Top 10 (source : Veracode, 2025). Le OWASP Top 10 désigne la liste de référence des dix risques de sécurité les plus critiques pour une application web, tenue par la fondation OWASP (source : OWASP). Les taux de réussite s’effondrent en particulier sur les failles d’injection dans les pages et dans les journaux, celles que rien ne signale à l’écran.

Le pire, c’est que les tests qui passent vous donnent une fausse sécurité. Un test ne prouve pas qu’un code est bon en général, seulement qu’il fonctionne dans les cas vérifiés. Vous croyez le problème réglé ; en réalité, la dette s’accumule sous la surface.

Le cycle est documenté et il est régulier : 6 à 12 mois pendant lesquels les incohérences architecturales et les failles atteignent la production, les bugs explosent, la vélocité s’effondre, et le coût de démêlage dépasse souvent la valeur créée (Kyros). La conséquence est visible sur le marché : reprendre un produit vibe-codé pour le rendre exploitable est devenu une prestation à part entière, le « rescue engineering » (Getcreatr).

Un cas typique (représentatif, pas nominatif)

Prenons un scénario que je vois revenir souvent, je le donne comme exemple hypothétique, pas comme un vrai client identifiable. Un fondateur monte sa boutique en deux semaines de vibe coding. La démo est superbe. Puis les vrais clients arrivent : les emails de confirmation ne partent pas, le formulaire de contact avale les messages, et une clé API traîne en dur dans le code front. À 5 visiteurs, ça tenait. À 50, le château de cartes s’effondre, c’est exactement le mécanisme décrit par Jayd : clés en dur, permissions OAuth trop larges, données clients dans des prompts sans filtrage. L’ANSSI classe précisément ces usages non maîtrisés de l’IA générative parmi les risques à encadrer côté développement (source : ANSSI, 2026).

Quand on reprend un projet dans cet état, la moitié du travail consiste à comprendre du code que personne n’a jamais relu. C’est le même genre de reprise que quand un prestataire web disparaît : sauf qu’ici, le prestataire fantôme, c’est l’IA.

« Mais les outils s’améliorent » : oui, et ça ne change rien

L’objection revient à chaque conversation : les modèles progressent, dans un an ce sera résolu. Non. La limite décisive n’est pas l’outil, c’est le cadrage humain, revue, architecture, validation. Le vibe coding, par définition, retire l’humain de la boucle de décision. Un modèle deux fois meilleur produira une dette deux fois plus propre en apparence, tout aussi invisible.

D’ailleurs, l’IA bien utilisée est redoutable. Chez Peechy, on s’appuie sur Claude et GitHub Copilot au quotidien, mais avec un humain qui relit, cadre et refuse. C’est toute la différence entre utiliser l’IA et la laisser conduire. Le vibe coding, c’est lâcher le volant.

Le vibe coding n’est pas mauvais. Il est mal placé. Utilisez-le pour explorer, jamais pour livrer. Et si votre site pro tourne déjà sur une vibe : faites-le auditer avant que le château de cartes ne tombe tout seul, un vendredi soir, en plein pic de commandes.