Vous avez « vibe codé » une application et elle casse ? Voici comment se déroule un vrai sauvetage

Il y a un moment que tout « vibe codeur » qui réussit finit par vivre. Il arrive généralement juste après le premier goût d'une vraie traction: un utilisateur signale que ses données ont disparu, ou un paiement est parti de travers, ou vous avez demandé à l'IA un petit changement et trois choses sans rapport ont cassé. Vous « promptez » plus fort. L'IA s'excuse avec assurance et casse autre chose. Et quelque part dans cette boucle, une pensée atterrit: j'ai construit quelque chose que je ne comprends pas, et je ne peux pas le réparer.

D'abord: respirez. Vous êtes arrivé à l'étape la plus prévisible du vibe coding, pas à la fin de votre produit. Je sauve des applications construites par IA au cœur de mon service de vibe coding, et je peux vous dire deux choses par expérience votre situation est fréquente, et dans la plupart des cas elle se répare très bien. Voici exactement comment se déroule un sauvetage, pour que vous sachiez ce qu'un développeur devrait faire — et combien de temps cela devrait vous coûter.

Étape 1: arrêtez d'ajouter des fonctionnalités. Sérieusement.

Quand une application construite par IA commence à vaciller, l'instinct est de s'en sortir à coups de prompts: une fonctionnalité de plus pour contourner le bug, une régénération de plus pour réparer la page. Résistez. Chaque ajout à un code instable multiplie la réparation finale, parce que l'IA construit par-dessus les mêmes fondations branlantes et réécrit par moments des parties qui fonctionnaient.

Gelez le périmètre. Écrivez — en mots, pas en code — ce que l'application doit faire pour les utilisateurs aujourd'hui. Cette liste devient le contrat du sauvetage. (C'est aussi, accessoirement, la spécification dont toute reconstruction future a besoin.)

Étape 2: l'audit — découvrir ce que vous possédez vraiment

Un vrai sauvetage commence par un audit, pas par une réécriture. Quiconque vous chiffre une reconstruction complète dès la première conversation vend, il ne diagnostique pas. Mon audit d'une application « vibe codée » couvre:

• La sécurité d'abord. Des clés API ou des identifiants sont-ils exposés dans le code ou le dépôt? Les règles d'accès à la base de données limitent-elles réellement les utilisateurs à leurs propres données? L'authentification est-elle appliquée côté serveur, ou seulement suggérée par des boutons cachés? La recherche montre sans cesse pourquoi cela passe en premier: Veracode a mesuré que le code généré par IA échoue aux tests de sécurité dans 45 % des cas. Partez du principe que c'est exposé jusqu'à preuve du contraire; faites tourner tout secret qui a déjà été public.

• La base de données. Les constructeurs IA conçoivent des tables pour la démo. Je vérifie si la structure peut survivre à vos six prochains mois de fonctionnalités, ou si elle est discrètement la source de vos bugs bizarres.

• La duplication et le code mort. La signature d'un code « vibe codé »: la même fonctionnalité implémentée de deux ou trois façons, dans des fichiers différents, issus de sessions de prompts différentes. Tant que ce n'est pas cartographié, chaque « petite correction » est un pile ou face.

• La dépendance à la plateforme. Quelle part de votre application vit entre les murs de Lovable, Bolt, Replit ou Base44? Le code et les données peuvent-ils être exportés intégralement vers des comptes que vous contrôlez? Un verrouillage découvert en pleine crise est un verrouillage au prix le plus élevé.

• Un test de réalité. Des volumes de données réels, un deuxième compte utilisateur, les parcours malheureux: cartes expirées, états vides, double-clics. Les démos testent le parcours heureux; la production, c'est tout le reste.

L'audit se conclut par un verdict écrit en trois catégories: ce qui peut être conservé tel quel, ce qui doit être réparé, et ce qui doit réellement être reconstruit. Sur les applications que je vois, la répartition honnête surprend les fondateurs — souvent, on peut en sauver plus qu'ils ne le craignaient, parce que le travail d'interface de l'IA est souvent correct. C'est la tuyauterie invisible qui a besoin d'un professionnel.

Étape 3: stabiliser avant d'améliorer

Le sauvetage lui-même suit un ordre strict, et sauter des étapes est la façon dont les sauvetages échouent:

1. Verrouillez la sécurité. Secrets dans un stockage d'environnement propre, règles d'accès appliquées, authentification vérifiée. Cela se fait avant tout travail cosmétique, toujours.

2. Mettez le code dans un dépôt qui vous appartient, avec un historique de versions. À partir de là, chaque changement est suivi et réversible — fini les modifications de production « aux vibes ».

3. Démêlez la duplication en composants et fonctions uniques, nommés, compris. C'est le travail ingrat qui rend l'application maintenable par n'importe quel développeur compétent, et pas seulement « sauvable » par un seul.

4. Reconstruisez uniquement ce que l'audit a condamné — généralement la couche de données et les parcours critiques (inscription, paiement, transaction centrale) — en réutilisant les écrans et le design que vos utilisateurs connaissent déjà.

5. Ajoutez les filets de sécurité que l'IA a sautés: des tests automatisés sur les parcours critiques, une journalisation des erreurs pour que le prochain problème de 2 h du matin s'annonce tout seul, et des sauvegardes qui restaurent vraiment.

Étape 4: relancer comme il se doit

Une application sauvée repart comme un nouveau produit devrait le faire: environnement de préproduction d'abord, un passage de check-list (la même rigueur que celle que j'applique avant tout lancement), puis la production avec supervision active. La différence entre ce lancement et le premier, c'est que désormais, quand quelque chose arrive, vous avez des journaux, des tests, un historique de versions — et un humain capable de lire les trois.

Combien de temps, et combien ça coûte?

Les délais dépendent de l'audit, évidemment, mais pour vous donner la forme: un audit ciblé prend quelques jours. Un sauvetage « stabiliser et durcir » pour une application de fondateur typique — corrections de sécurité, dépôt, dé-duplication, réparation des parcours critiques — prend habituellement une à trois semaines. Une reconstruction partielle du cœur s'étale plus longtemps, et quiconque vous promet un chiffre avant l'audit devine avec votre argent.

Comparez avec l'alternative que la plupart des fondateurs redoutent, une reconstruction complète depuis zéro: elle est rarement nécessaire, et c'est précisément ce que l'audit existe pour éviter de payer. Mon analyse des coûts d'un MVP montre ce que construire de zéro coûte; un sauvetage qui récupère votre produit fonctionnel atterrit presque toujours bien en dessous.

La leçon que votre application cassée est en train de vous donner

Chaque fondateur dont je sauve l'application dit une variante de la même phrase à la fin: « J'aurais aimé faire regarder ça par un développeur à cinquante utilisateurs plutôt qu'à cinq cents. » Pas parce que le vibe coding était une erreur — le prototype a brillamment fait son travail, prouvant l'idée à une vitesse et un prix autrefois impossibles. L'erreur a été de traiter la démo comme la destination.

Alors traitez cette étape pour ce qu'elle est: la remise de diplôme. Votre application a compté assez pour casser sous un usage réel. Elle mérite maintenant des fondations à la hauteur de ses ambitions. Si vous êtes dans cette boucle de prompts et de prières, envoyez-moi le lien de votre application et dites-moi ce qui casse. Je l'auditerai, je vous dirai honnêtement dans quelle catégorie tombe chaque partie, et je vous donnerai un devis ferme pour la rendre prête pour la production — c'est littéralement à cela que sert mon service de sauvetage vibe coding.