Le vibe coding consiste à décrire en langage naturel ce que l'on veut et à accepter ce que produit le modèle, sans le lire attentivement. Pour un prototype, un script, un outil bricolé en une soirée, c'est une très bonne façon de travailler. Je l'utilise ainsi moi-même.
Les ennuis commencent quand la chose ainsi produite passe en production et se met à détenir les données d'autrui. Non pas parce que le code est mauvais — il est souvent propre, idiomatique, bien nommé. Le problème, c'est ce que personne n'a écrit.
Un modèle répond à la question posée
Vous demandez un formulaire de réservation, vous obtenez un formulaire de réservation. Il validera l'adresse e-mail. Il sera sans doute plus élégant que celui que j'aurais écrit à la main.
Ce qu'il ne fera pas, c'est vous poser les questions qui déterminent si la chose survit au contact d'utilisateurs réels. Que se passe-t-il si deux personnes réservent le dernier créneau à la même seconde ? Si le prestataire de paiement expire après avoir encaissé mais avant que votre code n'en soit informé ? Qui a le droit de voir cette réservation : le client, tout utilisateur connecté, quiconque possède le lien ? Quand le client demande la suppression de ses données, que faut-il supprimer avec, et que faut-il légalement conserver ?
Ce ne sont pas des questions de programmation. Ce sont des décisions concernant votre entreprise, et le modèle ne peut pas les prendre : on ne lui a jamais donné les faits nécessaires. Il produit quelque chose de plausible pour chacune, en silence, et poursuit. Le code compile. Le formulaire fonctionne quand vous le testez. La décision, elle, n'a été prise par personne.
La démo fonctionne toujours
C'est le piège précis, et il attrape aussi les gens expérimentés.
Une fonctionnalité issue du vibe coding est testée comme elle a été construite : une personne, un navigateur, un seul chemin heureux, sans charge et sans adversaire. Dans ces conditions, presque tout passe. Les défaillances vivent exactement dans les conditions que vous n'avez pas songé à créer : concurrence, panne partielle, entrée hostile, le deuxième client, la dix-millième ligne, l'utilisateur déconnecté dont le jeton fonctionne encore.
La boucle de retour vous ment donc. Vous livrez, ça marche, vous livrez de nouveau plus vite. La confiance grandit exactement pendant que grandit la surface non examinée. Rien ne vous détrompe jusqu'à ce que quelque chose le fasse, publiquement.
Six choses qui manquent systématiquement
L'autorisation, par opposition à l'authentification. Les modèles sont bons pour la connexion. Ils sont bien plus faibles sur « cet utilisateur a le droit de lire précisément cette ligne ». La vulnérabilité la plus fréquente du vibe coding, et de loin, est un point d'entrée qui vérifie que vous êtes connecté et ne vérifie jamais qui vous êtes.
Tout ce qui doit rester juste en concurrence. Stocks, réservations de places, numéros de facture, soldes. Un code manifestement correct lu de haut en bas est fréquemment faux quand deux copies s'exécutent en même temps.
Le mode de défaillance de chaque appel externe. Tout tiers dont vous dépendez sera indisponible un jour. Savoir si cela doit arrêter votre client est une décision d'entreprise. Le code généré la prend par accident, en général en plantant.
Les données que vous ne pouvez pas perdre. Migrations qui suppriment des colonnes, suppressions sans corbeille, aucune sauvegarde que vous ayez réellement restaurée. Personne ne le remarque avant le jour où cela compte, et ce jour-là c'est irrécupérable, pas simplement gênant.
Le back-office. Le vibe coding produit les écrans que vous avez décrits. Vous avez décrit ceux destinés aux clients, parce que ce sont ceux que vous imaginez. Vos équipes vivent ensuite huit heures par jour dans ce qui restait.
La cohérence entre fonctionnalités. Chaque session repart de zéro. Dix fonctionnalités construites en dix sessions donnent dix conventions, trois façons de traiter les dates, deux schémas d'authentification et aucun vocabulaire commun. Individuellement, correct. En tant que système, impossible à maintenir — y compris par le modèle suivant.
Ce que cela coûte réellement
L'argument du vibe coding, c'est la vitesse, et la vitesse est réelle. Ce qu'il repousse, c'est le coût de la compréhension, et ce coût ne disparaît pas : il est payé plus tard, par celui qui devra modifier le système.
Modifier un logiciel sans danger exige quelqu'un capable de prédire ce qu'un changement va casser. Cette personne se construit son modèle du système en prenant les décisions. Si personne n'a pris les décisions, personne n'a le modèle, et chaque modification ultérieure est une supposition assortie d'un déploiement.
On m'appelle régulièrement sur ces projets. Le sauvetage n'est presque jamais une réécriture : le code est généralement récupérable. Ce qui prend du temps, c'est de reconstituer l'intention — lire chaque chemin pour déduire ce que le système était censé faire, parce que personne ne peut me le dire, y compris celui qui l'a mis en ligne.
Ce que je pense vraiment
L'IA est le plus grand gain de productivité qu'ait connu mon métier et je ne travaillerais pas sans elle. C'est un excellent instrument entre les mains de quelqu'un qui sait en lire le résultat d'un œil critique et sait quelles questions n'ont pas été posées.
Elle ne remplace pas cette personne. Elle la rend plus rapide. Le jugement sur ce que votre système n'a jamais le droit de rater n'est pas une tâche de programmation, et c'est précisément la partie que vous payez.
Utilisez-la pour les prototypes, les scripts internes, le jetable, la première version de n'importe quoi. Pour le système dont dépend votre entreprise, ayez quelqu'un qui le comprend de bout en bout — qu'il l'ait tapé ou relu ligne à ligne.