Le premier jour d’une application créée au feeling est la meilleure démo que vous ayez jamais faite. Le prompt a fonctionné, les écrans sont propres, la base de données contient des lignes, et vous avez publié un tweet avec un enregistrement d’écran. Nous avons connu 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 discussion de lancement n’en parle. 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 rencontre le fossé entre le “généré” et l‘“ingénierie”.
À quoi ressemble réellement le deuxième jour
Cela commence rarement par un plantage. Cela commence par quelque chose de bizarre : un formulaire qui accepte n’importe quoi, une page qui plante pour un utilisateur spécifique, un chiffre erroné d’une manière que personne ne peut reproduire. Vous collez l’erreur dans le chat. L’IA la corrige avec assurance. Le correctif casse autre chose.
Bienvenue dans le jeu du whack-a-mole des prompts. Parce que l’IA corrige les symptômes plutôt que les causes racines, chaque patch s’empile sur le précédent, et la base de code devient discrètement ce que les développeurs appellent du code Frankenstein : un patchwork de styles contradictoires, de fonctions en double et d’une 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 précédentes 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 silencieux du déploiement. 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 son correctif “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 avez une v5 gonflée d’un code dont la v1 était correcte.
La partie que vous ne voyez pas
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 sommes fermes à ce sujet pour les builds professionnels.
Les recherches ici sont vraiment dérangeantes. Le code généré par LLM compile avec succès environ 90% du temps, mais environ 45% d’entre eux contiennent des vulnérabilités du Top 10 de l’OWASP - des vérifications de connexion contournables, des failles d’injection. Les outils d’IA optimisent le fonctionnement de la démo, ce qui produit des raccourcis prévisibles : un contrôle d’accès implémenté dans le navigateur où n’importe quel utilisateur peut le contourner en modifiant la page, des permissions de base de données totalement ouvertes pour que rien ne plante pendant le build, et des clés API codées en dur dans les fichiers parce que le créateur ne sait pas ce qu’est une variable d’environnement. Ces fichiers sont ensuite poussés vers des repos GitHub publics, où les scrapers d’identifiants les trouvent comme prévu.
Voici ce qui fait de cela un problème spécifique du deuxième jour : une application exploitable fonctionne parfaitement. Il n’y a pas de message d’erreur pour “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-le simplement !”) se heurte à la réalité : les créateurs non techniques testent le chemin nominal, alors que l’échec réside dans les cas limites - le bug de concurrence, le flux de réinitialisation de mot de passe oublié que l’IA n’a jamais généré parce que 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 considérons comme le prêt à taux usuraire de la dette technique : un logiciel instantané maintenant, des intérêts composés plus tard. Chaque raccourci pris par l’IA est un futur correctif. Chaque correctif coûte quelques crédits de plus et un peu plus de gonflement du code. Les mises à jour de la plateforme arrivent et cassent des choses que vous n’avez pas touchées - les créateurs à long terme sur les plateformes de prompt-to-app rapportent facturer des frais de maintenance mensuels aux clients juste pour gérer les régressions provenant de la plateforme elle-même.
C’est la blague amère au centre de tout cela : 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 finit par se retrouver exactement avec la chose qu’il utilisait l’IA pour éviter - une base de code nécessitant le jugement d’un développeur - sauf que maintenant, elle soutient son entreprise, et il ne peut pas la lire.
Le carrefour de l’honnêteté
Alors, que faire concrètement ? Après beaucoup de builds et quelques cicatrices, nous pensons que tout se résume à un carrefour avec deux voies honnêtes, et que le milieu malhonnête est la seule mauvaise réponse.
Voie une : apprendre à maintenir le code. Si vous aimez assez cela pour aller plus loin, le vibe coding devient un accélérateur légitime au lieu d’un piège. Lisez ce que l’agent écrit. Apprenez ce que signifie RLS avant de livrer 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 développer un vrai jugement. Cette voie est réellement formidable - c’est juste un chemin, avec des mois de marche, et prétendre qu’on y est tout en livrant du code non lu aux clients est le piège.
Voie deux : placer les parties dangereuses sur une fondation qui n’est pas générée. Admettez honnêtement que votre application est un outil métier - un portail client, un tracker, un CRM interne - et remarquez que 80% de celle-ci correspond exactement à la plomberie que l’IA génère le moins bien : l’authentification, les permissions, les réinitialisations de mots de passe, l’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, et où l’AI Co-Builder vous donne toujours la vitesse du premier jour. Lorsque vous voulez un style personnalisé, son bloc de vibe-coding limite le code généré à un seul composant, afin que l’IA puisse décorer la maison sans faire s’effondrer le toit. Le deuxième jour sur cette voie est une modification, pas une fouille archéologique - c’est pourquoi elle domine notre classement des portails clients.
Continuez à faire du vibe coding pour les trucs amusants sans retenue - les prototypes, les jouets, les expériences de week-end sont exactement ce pour quoi ces outils sont brillants. Décidez simplement, avant que les vrais utilisateurs n’arrivent, de quel côté du carrefour vous vous trouvez. Le deuxième jour ne demande pas poliment.