Chaque démo de vibe coding est une histoire de Jour 1. Un prompt, une application qui marche, un écran qui semble prêt à être déployé. Le problème, c’est qu’un logiciel ne vit pas seulement le Jour 1. Il vit le Jour 2, quand de vrais utilisateurs se connectent, que les données ne sont plus des échantillons et que quelqu’un doit modifier un élément sans tout casser. C’est ce jour-là que l’on réalise que la démo et le produit sont deux objets différents.
Pourquoi le Jour 2 est une machine différente
Le Jour 1 demande au modèle d’écrire sur une toile blanche, ce qu’il fait très bien. Le Jour 2 lui demande de modifier un système dont il ne se souvient que partiellement, ce qu’il fait mal. Le vibe coding reste une couche d’abstraction, pas une échappatoire au génie logiciel : vous ne tapez pas la syntaxe, mais vous gérez toujours l’état, concevez des schémas relationnels et gérez des cas limites, car l’IA vous a transféré cette complexité plutôt que de l’éliminer.
L’artefact se dégrade à mesure qu’il croît. Une fois que la base de code dépasse la fenêtre de contexte du modèle, celui-ci commence à oublier ses propres décisions structurelles et propose du code qui contredit les modèles précédents. Ce contexte limité signifie aussi qu’il réécrit des fonctions utilitaires qu’il ne voit plus, dispersant ainsi une logique dupliquée dans tout le projet. Les modèles entraînés sur des dates de coupure différentes écrivent pour des versions conflictuelles des mêmes bibliothèques, entraînant une dérive des versions. On aboutit alors à un code Frankenstein : un patchwork de styles où la logique d’interface, les requêtes de base de données et les règles métier sont entremêlées dans des fichiers improvisés, et chaque modification ultérieure doit naviguer à travers ce chaos.
Les pannes ne s’annoncent pas
Un plantage est honnête ; il vous indique que quelque chose ne va pas. Les pannes du Jour 2, celles qui font vraiment mal, sont silencieuses. L’IA construit le chemin critique du succès décrit dans le prompt et ignore les cas que personne ne présente en démo : modifications simultanées de deux utilisateurs, formulaire qui perd la connexion en plein envoi, double-clic sur un bouton, saisie mal formatée. Une petite erreur d’arrondi ou de calcul s’exécute sans erreur sur chaque transaction et ne refait surface que des mois plus tard dans un rapport de facturation ou un décompte de réservations qui ne concorde plus.
C’est l’écart de confiance qui rend cela dangereux plutôt que simplement agaçant. Un opérateur non technique ne peut pas lire le code généré pour confirmer son action, et les tests manuels vérifient le parcours nominal, pas les failles. Ainsi, l’application qui « fonctionne parfaitement » en aperçu et celle qui corrompt silencieusement un quart de ses enregistrements peuvent être, et sont souvent, la même application. Vous l’apprenez via un client, pas via un test.
La clause de maintenance
C’est là que le Jour 2 s’ajoute au reste de la facture. Chaque modification est une nouvelle génération, et c’est là que résident les coûts et les risques. Relancer un prompt pour une fonctionnalité liée à l’authentification revient à relancer les dés de la sécurité évoqués dans ce que signifie réellement « 45 % du code IA est vulnérable » ; une couche déjà vérifiée doit donc l’être à nouveau. Et chaque cycle de correction des symptômes plutôt que des causes racines alimente la taxe de la boucle de correction : ce cycle de débogage payant qui transforme un abonnement bon marché en un coût illimité, la même dynamique qui sépare les prétendants dans le duel Lovable vs Bolt.
L’infrastructure apporte ses propres surprises au Jour 2. Les créateurs qui choisissent l’auto-hébergement pour éviter l’enfermement propriétaire finissent par synchroniser manuellement une base de données Supabase, un frontend Cloudflare Worker et une plateforme de cron ; une désynchronisation de l’un d’eux fait tomber tout le système. Ceux qui restent sur l’hébergement d’une plateforme unique héritent en revanche de la disponibilité, des tarifs et de la feuille de route de cette plateforme. Aucune de ces options n’est la solution gratuite suggérée par la démo.
Ce qu’il faut continuer à générer, et ce qu’il ne faut pas
Le constat honnête n’est pas que le vibe coding est inutile ; il est excellent pour les outils personnels, les prototypes et les composants personnalisés délimités dont le périmètre reste réduit. L’erreur est de l’utiliser pour les parties d’une application qui doivent survivre à la maintenance. Si vous travaillez dans une véritable base de code et que vous assurez la revue, un outil orienté code comme Cursor ou une plateforme cloud comme Replit vous permet de garder le contrôle sur ce qui change et quand.
Pour les applications métier - portails, outils internes, CRM, tout ce qui comporte des connexions, des rôles et des données réelles - la couche qui casse au Jour 2 est principalement l’authentification, les permissions et la plomberie CRUD. Sur une plateforme comme Softr, ces éléments ne sont pas générés par projet ; ils font partie de l’infrastructure configurée de la plateforme. Ainsi, modifier une permission est un réglage, pas un cycle de régénération, et il n’y a pas de boucle de correction à subir. Softr propose des crédits IA pour son Co-Builder, mais comme tout ce que l’IA fait peut également être fait manuellement, un solde vide ne bloque jamais une correction. Le Jour 2 le moins coûteux est celui où la partie la plus importante n’a jamais été générée.