Le premier jour d’une application vibe-codée est la meilleure démo que vous ayez jamais faite. Le prompt a fonctionné, les écrans sont propres, la base de données est remplie et vous avez publié un tweet avec un enregistrement d’écran. Nous avons vécu ce jour-là maintes fois. Nous ne sommes pas là pour vous le retirer.
Nous sommes là pour parler du deuxième jour, car aucun fil de lancement sur Twitter ne le mentionne. Le deuxième jour, c’est quand un utilisateur réel se connecte, fait quelque chose que vous n’aviez pas pensé à tester, et que votre application se heurte au fossé entre le « généré » et l’« ingénieré ».
À quoi ressemble réellement le deuxième jour
Cela commence rarement par un crash. Cela commence par un truc bizarre : un formulaire qui accepte n’importe quoi, une page qui plante pour un utilisateur spécifique, un chiffre erroné que personne ne parvient à reproduire. Vous collez l’erreur dans le chat. L’IA la corrige avec assurance. La correction casse autre chose.
Bienvenue dans le jeu du tape-taupe des prompts. Parce que l’IA corrige les symptômes plutôt que les causes racines, chaque correctif s’empile sur le précédent, et le code devient discrètement ce que les développeurs appellent du « code Frankenstein » : un patchwork de styles contradictoires, de fonctions dupliquées et de logique emmêlée où les requêtes de base de données vivent à l’intérieur du code d’interface. À mesure que le projet dépasse la fenêtre de contexte de l’IA, le modèle commence à oublier ses propres décisions antérieures et propose du code qui les contredit. Vous ne maintenez plus une application. Vous négociez avec elle.
Il existe une variante encore plus cruelle : l’échec de déploiement silencieux. Votre build d’hébergement échoue sur une erreur mineure, l’URL en direct continue d’afficher l’ancienne version, et vous — ne voyant aucun changement — dites à l’IA que sa correction « n’a pas fonctionné ». Elle génère alors une solution complètement différente et plus complexe à un problème qui était déjà résolu. Plusieurs cycles plus tard, vous vous retrouvez avec une version 5 hypertrophiée d’un code dont la version 1 était très bien.
La partie invisible
Le tapis roulant du débogage est au moins visible. Les problèmes de sécurité ne le sont pas, et c’est la raison pour laquelle nous nous montrons fermes à ce sujet pour les builds professionnels.
Les recherches à ce sujet sont franchement alarmantes. Le code généré par LLM compile avec succès environ 90 % du temps, mais près de 45 % d’entre eux contiennent des vulnérabilités du Top 10 de l’OWASP — comme des contrôles de connexion contournables ou des failles d’injection. Les outils d’IA optimisent l’effet « démo », ce qui conduit à des raccourcis prévisibles : un contrôle d’accès implémenté dans le navigateur (qu’un utilisateur peut contourner en modifiant simplement la page), des permissions de base de données totalement ouvertes pour éviter toute erreur lors du build, et des clés API codées en dur car le générateur ignore tout des variables d’environnement. Ces fichiers se retrouvent ensuite sur des dépôts GitHub publics, où des scrapers de credentials les récupèrent systématiquement.
C’est précisément ce qui en fait un problème de « jour deux » : une application exploitable fonctionne parfaitement en apparence. Il n’y a aucun message d’erreur indiquant que « le client A peut techniquement lire les dossiers du client B ». Vous l’apprenez par un utilisateur, si vous avez de la chance, ou bien pire si vous n’en avez pas. Et le conseil standard (« testez simplement ! ») se heurte à la réalité : les créateurs non techniques testent le « happy path » (le scénario idéal), alors que les failles se cachent dans les cas limites — le bug de concurrence, ou le flux de réinitialisation de mot de passe oublié que l’IA n’a jamais généré car la démo n’en avait pas besoin.
La dette de maintenance que personne ne comptabilise
Cumulez ces mécanismes sur plusieurs mois et vous obtenez ce que nous appelons le « crédit rapide » de la dette technique : un logiciel instantané maintenant, des intérêts composés plus tard. Chaque raccourci pris par l’IA est un correctif futur. Chaque correctif consomme encore quelques crédits et alourdit encore le code. Des mises à jour de la plateforme surviennent et cassent des éléments que vous n’avez même pas touchés ; certains créateurs à long terme sur des plateformes de « prompt-to-app » disent facturer des frais de maintenance mensuels à leurs clients juste pour gérer les régressions provenant de la plateforme elle-même.
C’est là l’ironie amère de l’histoire : le « vibe coding » promettait de démocratiser le logiciel, et pour les applications de production, il a surtout démocratisé la dette technique. Le créateur non technique se retrouve avec exactement ce qu’il utilisait l’IA pour éviter — un codebase nécessitant le jugement d’un développeur — sauf qu’à présent, c’est le pilier de son entreprise, et il est incapable de le lire.
Le carrefour de la vérité
Alors, que faire concrètement ? Après de nombreux builds et quelques cicatrices, nous pensons qu’il s’agit d’un choix entre deux voies honnêtes, et que le compromis tiède est la seule mauvaise réponse.
Première voie : apprendre à maintenir le code. Si vous aimez assez cela pour aller plus loin, le vibe coding devient un accélérateur légitime plutôt qu’un piège. Lisez ce que l’agent écrit. Apprenez ce que signifie RLS avant de déployer une application qui en dépend. Passez des outils basés uniquement sur le prompt à Cursor ou Replit, où le code est l’interface et où vous pouvez forger un véritable jugement technique. Cette voie est réellement enrichissante — c’est un chemin qui demande des mois de pratique, et prétendre l’emprunter tout en livrant du code non lu à des clients est le véritable piège.
Deuxième voie : bâtir les parties critiques sur des fondations non générées. Admettez honnêtement que votre application est un outil métier — un portail client, un tracker, un CRM interne — et remarquez que 80 % de l’app consiste précisément en la plomberie que l’IA gère le moins bien : authentification, permissions, réinitialisation de mots de passe, accès aux données. Construisez cette catégorie sur une plateforme no-code comme Softr, où la plomberie est une infrastructure testée que vous configurez visuellement, tandis que l’AI Co-Builder vous apporte toujours la rapidité du premier jour. Lorsque vous voulez une touche personnalisée, son bloc de vibe-coding limite le code généré à un seul composant, permettant à l’IA de décorer la maison sans risquer de faire s’effondrer le toit. Le « jour deux » sur cette voie est une simple modification, pas une fouille archéologique — c’est pourquoi elle arrive en tête de notre classement des portails clients.
Continuez à utiliser le vibe coding pour les choses amusantes sans complexe — les prototypes, les jouets, les expériences du week-end sont précisément les domaines où ces outils excellent. Décidez simplement, avant l’arrivée des vrais utilisateurs, de quel côté du carrefour vous vous situez. Le jour deux, lui, ne demande pas la permission.