Application générée par IA : la reprendre ou tout refaire ?

Un dirigeant de TPE me donne l’accès à son outil de génération de contenu. Il l’a fait construire avec Claude Code, il s’en sert tous les jours, il en est content. Sa question tient en une phrase : pourquoi, chaque fois qu’il demande une modification, quelque chose casse ailleurs ?

Si vous avez fait générer un outil, avec Claude Code, Lovable, Bolt, Replit ou n’importe quel autre, vous connaissez peut-être la suite : vous n’osez plus rien demander parce que la dernière modification a cassé autre chose, et si celui qui l’a fabriqué s’arrête demain, vous ignorez ce que vous récupérez.

Je lance la commande qui prépare son application pour la mise en ligne. Des erreurs défilent, rien ne sort ; des erreurs d’authentification apparaissent. Sur sa machine à lui, tout démarre : les autorisations y sont larges par défaut, l’application n’a jamais eu à se justifier auprès de personne. Et partout traîne du code que plus personne n’appelle. Le problème n’est pas Claude Code, je m’en sers tous les jours. C’est que personne n’est allé voir où ce projet allait casser.

En clair : gardez votre outil tel quel tant qu’il ne stocke aucune donnée de vos clients, ne sert qu’à un seul type d’utilisateur et n’est pas censé durer plus de dix-huit mois. Passé un de ces six seuils, tous listés plus bas, la question n’est plus de savoir s’il marche, mais si vous acceptez de dépendre d’un code que personne ne sait faire évoluer.

Ce qui bloque en premier, c’est la mise en ligne

Les articles sur le sujet parlent presque tous de fuites de données. Le risque existe, j’y viens. Mais ce n’est pas le mur sur lequel ce dirigeant s’était arrêté, et je doute que ce soit le premier qu’on rencontre.

Vous n’avez rien fait d’anormal. Selon le rapport DORA « State of AI-assisted Software Development » publié par Google Cloud le 23 septembre 2025, 90 % des 4 867 professionnels de la tech interrogés déclarent utiliser l’IA dans leur travail. Précision utile : Google Cloud vend par ailleurs des outils d’IA. Coder avec une IA est devenu la norme. Ce que les professionnels ont en plus tient en une habitude : ils savent d’avance où un projet lâche, et ils vont l’ouvrir avant de livrer.

Les seuils qui changent la réponse

Six critères. En dessous, votre outil peut vivre sa vie. Au-dessus d’un seul, ce qui compte n’est plus qu’il marche aujourd’hui, mais qui paie le jour où il s’arrête.

Critère	Seuil de bascule	Ce que ça change
Données stockées	Ce sont celles de vos clients	En cas d’incident, vous n’êtes plus seul à perdre
Profils	Plus d’un profil aux droits différents : vous, un salarié, un client	Chaque droit devient une règle à vérifier, écran par écran
Paiement	Dès le premier euro encaissé	Vous répondez d’un débit devant une banque, pas devant votre développeur
Durée de vie	Au-delà de dix-huit mois	Quelqu’un devra relire ce code sans son auteur
Regard extérieur	Un client ou un assureur vous interroge sur vos données	Il faut répondre par écrit, pas de mémoire
Coût d’un arrêt	Une journée sans l’outil coûte plus qu’une journée de votre temps	Vous réparez quand ça tombe, pas quand vous voulez

Un seuil franchi : faites relire le projet avant la prochaine évolution. Deux ou plus : ne mettez rien en ligne tant que personne n’a ouvert le code. Le tableau dit s’il faut faire regarder, pas ce qu’on trouvera.

Le symptôme le plus fiable : ça ne marche que sur une machine

C’est ce que j’ai trouvé chez ce dirigeant, et c’est ce que je regarde en premier depuis. Une machine de développement est permissive par construction : accès larges, vérifications désactivées, clés en clair. Un serveur de production refuse par défaut. La correction tentante est la mauvaise : élargir les autorisations jusqu’à ce que ça passe.

Ce raccourci a déjà coûté cher ailleurs. Le 2 février 2026, les chercheurs de Wiz Research ont révélé que la base de données de Moltbook, un réseau social pour agents IA construit en dictant les fonctionnalités à une IA, était accessible en lecture et en écriture sans aucune authentification, faute d’avoir activé le Row Level Security de Supabase, le verrou qui empêche un utilisateur de lire les lignes d’un autre.

Le projet que j’ai ouvert n’avait rien à voir avec ça : il ne partait pas en ligne, donc il n’exposait rien. Si je le raconte ici, c’est pour la raison inverse de celle qu’on attend. Une application qui refuse de se déployer vous rend service : elle vous prévient avant, pas après.

Les cas où je vous dirai de ne rien toucher

Refaire n’est pas la réponse par défaut. Cinq situations où y toucher serait du gaspillage.

Un outil interne pour moins de dix personnes, sans donnée de client : calculateur de marge, suivi de stock, générateur de documents. Le pire scénario, c’est une matinée perdue.

Un prototype fait pour être jeté : le jour où vos équipes s’en servent vraiment, vous ne le réparez pas, vous construisez la vraie version.

Un formulaire sans base de données derrière : les réponses arrivent dans votre boîte mail, et c’est elle qu’il faut sécuriser. Annoncez ce que vous faites de ces réponses, mais ne refaites pas l’outil pour ça.

Un outil saisonnier de moins de six mois : une opération commerciale, un salon, une campagne. Il n’aura pas le temps de vieillir.

Une application qui stocke déjà des données de clients, tourne depuis des mois et à laquelle vous n’avez rien de nouveau à demander : elle a franchi un seuil, mais elle ne bouge plus, et c’est quand une application ne bouge plus qu’elle casse le moins. Payez la refonte le jour où vous aurez quelque chose à demander.

Une règle dans ces cinq cas : notez la date où vous avez décidé que ça resterait comme ça, et posez-vous un rappel à six mois. Les outils provisoires ne posent pas de problème ; ceux qu’on a oublié de rejuger, si.

Ce qui fait exploser le devis d’une reprise

Ce qui suit est une grille d’évaluation, pas un retour de chantier : je n’ai jamais mené de reprise d’application générée par IA, et je préfère le dire que vous vendre une expérience que je n’ai pas.

Le prix ne dépend presque pas du nombre de lignes de code, mais de ce qu’on ne peut pas vérifier vite. Les droits, d’abord : tant qu’on n’a pas la certitude que l’utilisateur A ne peut pas lire les données de l’utilisateur B, on ne met rien en ligne, et cette certitude se construit écran par écran. Les données déjà saisies, ensuite : six mois de saisie réelle, souvent dans un format bancal, ajoutent un chantier de migration. L’absence de tests, enfin : chaque correction est à revérifier à la main, partout, et une journée de travail devient une semaine.

Aucune de ces trois inconnues ne se voit depuis l’écran : une application peut sembler parfaite à l’usage et laisser fuir les données d’un utilisateur chez un autre. Je ne donnerai aucun chiffre sur une reprise sans avoir ouvert le projet. Mes fourchettes pour un projet neuf sont sur ma page tarifs, le cadre d’un chantier complet sur ma page développement d’application métier à Bordeaux, et le coût sur cinq ans dans mon comparatif WordPress et sur-mesure.

À ce dirigeant, j’ai recommandé de refaire. Et je n’ai pas pris la mission. Pas par principe : parce que je n’avais pas la place. Le chantier était gros, j’avais déjà trop de clients en cours, et je l’aurais mené en pointillé. Un devis de plus, ça m’arrangeait. Un chantier de cette taille traité à moitié, non. Et ça se serait vu au bout de six semaines.

Les 8 questions à poser avant de confier la reprise

Copiez-les, envoyez-les. Les réponses vous en diront plus qu’un portfolio.

1. Utilisez-vous l’IA pour coder, et sur quelle part du code ?
2. Qui relit le code généré, et selon quels critères ?
3. Mon code et mes données passent-ils par un service extérieur, lequel, et combien de temps y sont-ils conservés ?
4. Qui est titulaire des droits sur le livrable ?
5. Quelle part du projet sera couverte par des tests automatisés ?
6. Qui répond si tout tombe un samedi soir, et sous quel délai ?
7. Qu’est-ce que je récupère si on arrête demain : le code, la base, les accès, hébergés à mon nom ?
8. Avez-vous ouvert mon projet avant de me répondre, et qu’y avez-vous vu ?

La deuxième est la plus importante et c’est celle qu’on pose le moins. Ce que vous y cherchez : un critère nommé, les droits d’accès ou ce qui touche à l’argent, pas « je relis tout ». La relecture se joue chez votre prestataire, pas dans sa boîte à outils.

Elles ne valent que pour une application déjà générée. Pour choisir un développeur en général, tout est dans mon guide : comment choisir un développeur web.

Votre prototype n’est pas un déchet, c’est un cahier des charges

Je code avec l’IA tous les jours, Claude Code compris. Je ne suis pas neutre, autant que vous le sachiez avant de lire ce qui suit.

Le prototype que vous avez généré est le meilleur cahier des charges qu’un client puisse m’apporter. Un document Word décrit une intention ; votre prototype la montre. J’y clique, je vois dans quel ordre vous pensez votre métier, ce qui compte et ce qui ne compte pas. Ça remplace plusieurs réunions de cadrage. Pour formaliser ce qu’il dit déjà : rédiger un cahier des charges web.

Alors ne le jetez pas, et ne le mettez pas en ligne non plus. Prenons trente minutes : vous me montrez l’outil, je vous dis ce que je regarderais et dans quel ordre, et vous saurez si le sujet mérite qu’on ouvre le code. Au dirigeant dont je parlais en ouvrant, j’ai remis un diagnostic écrit à l’issue de cette conversation, et il ne m’a rien acheté. Parlons-en.

Faire le point sur mon application en 30 minutes →

Faire développer une application métier à Bordeaux →

Voir mes fourchettes de budget →

---

Questions fréquentes

Faut-il forcément refaire une application générée par IA ?

Non, et c’est même inutile dans cinq cas : un outil interne pour moins de dix personnes sans donnée de client, un prototype destiné à être jeté, un formulaire sans base de données derrière, un outil saisonnier de moins de six mois, et une application déjà en production à laquelle vous n’avez plus rien de nouveau à demander. La question se pose vraiment quand vous stockez les données de vos clients, quand plus d’un profil d’utilisateur a des droits différents, quand vous encaissez un paiement ou quand vous comptez sur cet outil au-delà de dix-huit mois.

Mon application fonctionne en local mais pas en ligne, est-ce grave ?

C’est un signal sérieux qu’elle n’est pas prête. Une machine de développement est permissive par construction : les accès y sont larges et les vérifications désactivées, pour aller vite. Un serveur de production fait l’inverse, il refuse par défaut. La panne se répare. Ce qui coûte cher, c’est la façon dont on est tenté de la réparer : desserrer les autorisations du serveur jusqu’à ce que l’application passe.

Combien coûte la reprise d’une application générée par IA ?

Aucun chiffre sérieux ne peut être donné sans avoir ouvert le projet. Le devis ne dépend pas du nombre de lignes de code mais de trois inconnues qui ne se voient pas depuis l’écran : la solidité de l’authentification et des droits, le volume de données déjà saisies en production et leur format, et l’absence éventuelle de tests automatisés. Les fourchettes de mes projets neufs sont publiées sur ma page tarifs.

Le code généré par IA est-il moins sûr que le code écrit par un humain ?

Personne ne peut l’affirmer aujourd’hui. Les publications disponibles mesurent le code produit par des modèles sur des exercices de codage isolés, sans jamais le comparer à du code humain écrit dans les mêmes conditions, et aucune ne dispose d’un groupe témoin. Ce qui est documenté, c’est autre chose : Moltbook, un réseau social pour agents IA construit en dictant les fonctionnalités à une IA, a été mis en ligne en février 2026 avec une base de données accessible en lecture et en écriture sans aucune authentification.

Que faire de mon prototype si je repars de zéro ?

Gardez-le et transmettez-le au développeur. Un prototype montre l’intention au lieu de la décrire : l’ordre des écrans, les champs qui comptent vraiment, le vocabulaire de votre métier. Il fait gagner plusieurs réunions de cadrage. Il ne sert pas de base de code. Il sert de cahier des charges qu’on peut ouvrir et cliquer.