Reprendre une application générée par IA : coût et démarche

Vous avez une application créée avec Lovable, Bolt, Replit, Cursor ou Claude Code. Elle existe, elle a peut-être déjà des utilisateurs, et quelque chose ne va plus : un bug qui revient, une fonctionnalité qui n'aboutit pas, un doute sur la sécurité, ou simplement le sentiment qu'il faut maintenant quelqu'un qui comprenne ce qui a été construit. Cet article explique ce qu'un développeur vérifie en reprenant ce type de projet, ce qui fait varier le coût d'une reprise, comment préparer la demande, et à quoi reconnaître un prestataire sérieux. Il ne contient aucun tarif, volontairement : les fourchettes qui circulent en ligne sont celles d'agences qui vendent la prestation.

Réponse rapide

Une reprise commence par un audit, c'est-à-dire la lecture complète du code, et se poursuit par des corrections ciblées. Il est rare qu'il faille tout refaire. Le coût dépend de cinq choses : la taille du code, l'état dans lequel l'IA l'a laissé, la présence de vraies données en production, le nombre de systèmes externes reliés, et la possibilité ou non de sortir le code de la plateforme qui l'a généré. Un bon prestataire vous donne un devis écrit pour l'audit, refuse de promettre une sécurité totale et ne parle de réécriture qu'après avoir lu le code.

Les signes qu'il est temps de faire appel à un développeur

• Chaque correction en provoque une autre. L'outil ne voit plus l'ensemble du projet et modifie des morceaux sans tenir compte de ce qui en dépend.
• L'application tient en démonstration et flanche avec de vrais utilisateurs. Charge, saisies inattendues, connexions simultanées : ce sont les cas que personne n'a décrits dans une instruction.
• Vous ne savez pas qui peut voir quoi. Il y a une page de connexion, mais la question des droits entre utilisateurs n'a jamais été posée.
• Une partie n'a jamais été terminée. Paiement, e-mails, export, back-office : l'outil a produit une maquette qui ressemble à la fonctionnalité sans la réaliser.
• Vous devez quitter la plateforme. Coût de l'abonnement, exigence d'un client, besoin d'un hébergement précis : le code doit tourner chez vous.
• Quelqu'un vous a dit qu'il fallait tout refaire. Sans avoir lu le code, cette phrase ne veut rien dire. Elle mérite un second avis.

Ce qu'un développeur vérifie en premier

La reprise sérieuse d'une application générée par IA suit toujours le même ordre, parce que l'ordre protège votre argent : d'abord comprendre, ensuite chiffrer, enfin modifier.

1. Est-ce que le code peut sortir ?

Avec un agent de code comme Cursor ou Claude Code, la question ne se pose pas : le code est dans un dépôt Git ordinaire. Avec un générateur d'applications, il faut vérifier. Lovable conserve le code dans sa plateforme et documente une synchronisation avec GitHub sur toutes ses offres, ainsi qu'un téléchargement direct du code sur les offres payantes. Ce qui ne sort pas avec le code, ce sont la base de données gérée, le stockage de fichiers et les secrets de la plateforme : ils devront être remplacés par les vôtres, ce qui est un travail de migration normal mais qu'il faut compter.

2. Qui a le droit de faire quoi

C'est la première vérification de sécurité, avant même les failles techniques. Un utilisateur connecté peut-il consulter les commandes d'un autre en changeant un numéro dans l'adresse ? Un compte client peut-il appeler les fonctions réservées à l'administrateur ? Dans le code généré, l'authentification est presque toujours présente et l'autorisation presque toujours incomplète.

3. Les secrets

Clés d'API, identifiants de base de données, jetons de services tiers : où sont-ils écrits, qui peut les lire, ont-ils été publiés dans l'historique du dépôt ? Une clé exposée se révoque en cinq minutes ; découvrir qu'elle a été utilisée par quelqu'un d'autre coûte bien davantage.

4. Ce que le serveur vérifie réellement

Les générateurs produisent de très bons formulaires. La validation existe souvent dans l'interface et pas sur le serveur, ce qui signifie qu'elle n'existe pas : quiconque contourne le formulaire envoie ce qu'il veut. Même chose pour les téléversements de fichiers, les montants, les quantités, les dates.

5. L'état général du code

Composants dupliqués, fonctions mortes héritées d'instructions abandonnées, dépendances obsolètes, absence totale de tests. Aucun de ces points n'est une urgence en soi. Ensemble, ils déterminent si chaque future modification sera une affaire d'une heure ou d'une semaine, et donc le coût de tout ce qui suivra.

Ce qui fait varier le coût d'une reprise

Deux applications qui ont « le même problème » peuvent coûter dix fois plus l'une que l'autre à reprendre. Ce ne sont pas les prestataires qui sont incohérents, ce sont les applications qui diffèrent. Voici les facteurs, par ordre d'importance habituel.

Le facteur le plus sous-estimé est la présence de vraies données. Corriger un défaut de droits d'accès sur une application vide prend une heure. Le corriger sur une application où des clients ont déjà des comptes, tout en gardant le service ouvert et sans perdre une ligne, est un autre métier. Si votre application est en ligne, dites-le dès le premier message : c'est la première chose qui change le devis.

Audit, correction, stabilisation ou finition

Une reprise n'est pas une prestation unique. Quatre périmètres reviennent, et vous n'avez pas à choisir avant d'avoir lu le rapport d'audit.

• L'audit seul. Lecture complète du code et rapport écrit : constats classés par gravité, effort estimé pour chacun, et ce qui bloque la mise en ligne. C'est aussi le meilleur moyen d'obtenir un second avis avant de payer quelqu'un d'autre.
• Lever les blocages. Corriger ce qui empêche la mise en production ou met les données en danger, documenter le reste. Le chemin le plus court vers un lancement défendable.
• Stabiliser. Après les blocages, restructurer ce qui rend chaque évolution risquée, ajouter des tests sur les parcours critiques et mettre en place un déploiement reproductible. Pour une application qui va continuer à évoluer.
• Terminer. Construire ce qui n'a jamais été construit, sur la base d'un cahier des charges écrit. C'est un projet de développement à part entière, chiffré comme tel.

Comment préparer votre demande

Un développeur qui reçoit « mon application ne marche pas, combien pour la réparer ? » ne peut rien répondre d'honnête. Celui qui reçoit les éléments suivants peut souvent proposer un audit chiffré dans la journée.

• L'outil ou la plateforme utilisé, et si le code est déjà dans un dépôt Git ou encore dans la plateforme
• Ce que fait l'application, qui l'utilise aujourd'hui et si elle est en ligne avec de vraies données
• Un ou deux problèmes concrets, reproductibles, plutôt qu'une liste de tout ce qui vous inquiète
• La pile technique si vous la connaissez (le prestataire la déduira sinon du dépôt)
• Votre échéance et ce que vous espérez : mettre en ligne, sécuriser, terminer, ou simplement savoir où vous en êtes

Reconnaître un prestataire sérieux

Le marché de la « réparation d'applications IA » s'est rempli très vite. Quelques signaux permettent de trier.

• Il lit avant de juger. Un prestataire qui annonce « il faut tout refaire » avant d'avoir ouvert le dépôt ne vous parle pas de votre application. Un audit écrit vient avant toute recommandation.
• Il ne promet pas la sécurité totale. Personne ne peut l'honorer. Il doit vous dire ce qu'il a vérifié, ce qu'il a trouvé, ce qu'il a corrigé et ce qui reste accepté comme risque.
• Il travaille dans votre dépôt, sur une branche. Jamais directement sur l'application en ligne, et avec des tests sur ce qu'il corrige.
• Il vous laisse libre ensuite. Code documenté, accès rendus, aucune dépendance créée. Vous devez pouvoir confier la suite à quelqu'un d'autre.
• Il connaît votre pile technique. Un excellent développeur Python ne reprend pas bien une application Next.js, et inversement. Demandez sur quoi il travaille vraiment.
• Il dit non quand il le faut. Application mobile native, code impossible à extraire, technologie qu'il ne pratique pas : un refus clair vaut mieux qu'une troisième semaine perdue.

Et si l'on repartait de zéro ?

Refaire est parfois la bonne décision : quand l'architecture ne peut pas porter le produit tel qu'il est devenu, ou quand le coût des corrections dépasse celui d'une réécriture propre. Mais c'est une conclusion, pas un point de départ. Un prototype vibe codé a une valeur même s'il est jeté : il montre exactement ce que vous voulez, et il a déjà été confronté à des utilisateurs. Un développeur qui repart de zéro à partir de ce prototype travaille bien plus vite qu'à partir d'un cahier des charges. Si c'est la voie retenue, le cadre est celui du développement d'application web sur mesure, avec un cahier des charges écrit et un devis par étapes.

Et si vous n'en êtes pas encore là, si vous vous demandez encore ce que le vibe coding peut produire pour votre entreprise et à quel moment il cesse de suffire, le guide du vibe coding pour dirigeants répond à cette question en amont.

Conclusion

Une application générée par IA qui pose problème n'est ni un échec ni une fatalité. C'est une application dont personne n'a encore lu le code. La reprise consiste à faire ce travail dans le bon ordre : comprendre, chiffrer, corriger, puis transmettre. Exigez un audit écrit, méfiez-vous des promesses absolues dans un sens comme dans l'autre, et donnez au prestataire les éléments qui lui permettent de vous répondre honnêtement.