Votre application créée avec l’IA ne marche plus : la sauver ou la refaire ?

Qu’est-ce qui lâche, en général, dans une application générée par IA ?

Les applications produites avec Lovable, Bolt, Replit, v0 ou Cursor cassent presque toujours aux mêmes endroits : l’outil soigne une démo qui marche à l’écran, pas la vie avec de vrais utilisateurs, de vraies données et un second développeur. Le symptôme est rarement la cause : partez de ce tableau.

Ce n’est pas de la malchance. Testant en 2025 le code de plus de 100 modèles de langage, Veracode a vu 45 % des échantillons échouer aux contrôles de sécurité. Sur 211 millions de lignes modifiées, GitClear a vu le copié-collé passer de 8,3 % à 12,3 % entre 2020 et 2024 ; or une logique dupliquée laisse souvent survivre ailleurs un bug corrigé ici.

Que faire dans les 48 premières heures ?

Traitez par ordre de gravité, pas d’agacement : une page lente perd quelques visiteurs, une base ouverte perd les données de vos clients.

1. Geler et copier : arrêtez de demander à l’outil de « tout réparer » en production, poussez le code vers un dépôt Git à vous et sauvegardez la base.
2. Colmater les fuites : renouvelez toute clé passée par le navigateur ou le dépôt, déplacez les appels secrets côté serveur, activez RLS sur chaque table publique et vérifiez sans être connecté.
3. Protéger les données : repérez doublons et enregistrements orphelins, et placez suppression, remboursement et modification en masse derrière un contrôle de rôle.
4. Maintenir le service : ajoutez la journalisation des erreurs, puis testez à la main la connexion, le paiement et le parcours de commande.
5. Ensuite seulement, la vitesse : index, pagination, cache.

Si des données personnelles ont pu fuiter, l’article 33 du RGPD laisse au responsable de traitement 72 heures après en avoir pris connaissance pour notifier la violation à l’autorité de contrôle, la CNIL en France, sauf si elle est peu susceptible d’engendrer un risque pour les personnes. Un juriste rédige la notification ; un développeur vous dit ce qui a été exposé et depuis quand.

Sauver ou refaire : comment trancher ?

Regardez cinq signaux. Si deux ou plus tombent dans la colonne de droite, demandez un devis de refonte avant de payer d’autres corrections.

L’argument classique de Joel Spolsky contre la réécriture : le vieux code contient des années de corrections trouvées en usage réel. Une application générée en deux week-ends n’a pas ce passé ; sa valeur tient aux données, aux parcours dont dépendent vos utilisateurs et aux leçons tirées. La refaire gaspille donc moins qu’il n’y paraît, pourvu que l’application en ligne continue de tourner entre-temps.

La voie médiane la plus sûre est ce que Martin Fowler appelle le figuier étrangleur (strangler fig) : des éléments neufs et testés reprennent un parcours après l’autre derrière l’application en service. La règle d’un guide de nettoyage : nettoyer tant que le total reste sous 5 000 $, refaire au-delà de 8 000 $ d’estimation si l’application a été montée en quelques jours.

Combien coûte un sauvetage sur le marché en 2026 ?

Ce sont des prix affichés par des entreprises qui vendent ce travail, pas des moyennes vérifiées.

Pourquoi un tel écart ? Nos forfaits sont étroits et fermés : un bug, cinq bugs listés, ou un sauvetage qui cartographie les pannes, protège les parcours critiques et livre les corrections convenues. Une refonte à 20 000 $ est un autre produit : si la cartographie en montre le besoin, vous en recevez d’abord le devis écrit, et elle en devient le cahier des charges.

Pourquoi un sauvetage coûte-t-il dix fois plus qu’un autre ?

Axonbuild a relevé environ 3,4 problèmes critiques par application, plus une quarantaine de constats facultatifs, sur 21 applications générées par IA auditées en juin et juillet 2026. Ces quelques points critiques font le prix ; leur difficulté dépend de ceci :

• Rôles : administrateurs, employés et clients imposent de vérifier chaque règle rôle par rôle.
• Plusieurs entreprises clientes dans une même base : les isoler coûte 3 000–8 000 $ dans la grille de vibecoding.app.
• Paiements et webhooks : testés dans le bac à sable du prestataire avant toute modification.
• Intégrations : chacune ajoute des clés, des limites et des cas d’échec.
• Accès : Git, une copie de test et les journaux valent mieux que des captures et un mot de passe partagé.
• Moment : selon le même guide, nettoyer avant le lancement coûte deux à cinq fois moins cher.

Peut-on continuer à développer avec l’IA après le sauvetage ?

Oui. Les développeurs eux-mêmes se méfient : dans l’enquête Stack Overflow 2025, 66 % placent en tête de leurs frustrations les réponses d’IA « presque justes, mais pas tout à fait ». Gardez l’IA, mais placez des contrôles entre le prompt et la production :

• Chaque modification passe par Git et une pull request, même écrite par l’IA.
• Les tests de connexion, de paiement et du parcours principal bloquent une version défaillante.
• Les secrets restent côté serveur ; le navigateur ne reçoit que des clés publiques.
• Chaque version est vérifiée avant publication et peut être annulée.
• Une personne qui sait lire le code valide les changements de règles d’accès et de permissions.

Ce filet, sans sauvetage, c’est le service QA et automatisation des tests : 73 $ assisté par IA ou 93 $ piloté par un spécialiste.

Que fournir pour obtenir un devis précis ?

• Un accès en lecture au dépôt, ou un export depuis l’outil.
• La pile : générateur, base de données, hébergement, authentification, paiement.
• Trois pannes en étapes : ce que vous avez fait, attendu et obtenu.
• Les parcours qui rapportent argent ou contacts, par ordre d’importance.
• Le nombre d’utilisateurs et les données personnelles stockées.

Ne collez jamais de mot de passe dans une messagerie : créez des accès collaborateur révocables après la livraison.

Quand ne faut-il pas payer un sauvetage ?

• L’application n’a pas d’utilisateurs et testait une idée : notez vos leçons et reconstruisez-la proprement sur un vrai cahier des charges.
• La panne vient de la plateforme : écrivez d’abord au support de l’outil.
• Il vous faut une fonctionnalité, pas une réparation : c’est du développement, à chiffrer comme tel.
• Vous allez changer de cap : sauver du code que vous jetterez le mois prochain, c’est payer deux fois.

Méfiez-vous de qui promet de tout réparer en une journée sans avoir lu le code.