Ce que coûte vraiment une application générée par IA une fois en production

Nous développons des logiciels pour vivre et nous utilisons ces outils. Cursor, Claude, Lovable, Replit, Bolt : obtenir un prototype qui fonctionne en une après-midi est réellement nouveau, et prétendre le contraire serait absurde.

Cet article ne dit pas que le code généré est mauvais. Il parle de la facture qui arrive six mois plus tard, quand ce que vous aviez construit pour vous est devenu, sans bruit, quelque chose dont l'entreprise dépend. Presque personne ne budgète cette partie. La voici en chiffres.

Sommaire

• Le faire pour soi, c'est souvent le bon choix
• L'abonnement que personne ne budgète
• Ce qui change quand toute l'entreprise s'en sert
• Un hébergement n'est pas une posture de sécurité
• Ce que nous trouvons vraiment dans le code généré
• Vous n'avez probablement pas besoin de tout jeter

---

Le faire pour soi, c'est souvent le bon choix

Si vous aviez besoin d'un outil, que vous l'avez décrit à un modèle et que vous l'avez maintenant, c'est une bonne chose. Vous avez évité un cycle d'achat, un cahier des charges, une agence et trois mois d'attente, et vous avez obtenu quelque chose taillé pour votre problème plutôt que pour la feuille de route d'un éditeur.

Pour un outil qui sert une personne, ou une équipe de trois qui travaillent ensemble, le conseil honnête est de ne rien changer. N'embauchez personne. Ne réécrivez rien. Ça marche, et le coût de le rendre "propre" ne se justifie pas pour quelque chose qui a un seul utilisateur et aucune conséquence en cas de panne.

Tout ce qui suit concerne le moment où cela cesse d'être vrai.

L'abonnement que personne ne budgète

Pour maintenir une application générée en fonctionnement, vous continuez en général de payer la plateforme qui l'a générée. Vérifié en août 2026 :

Deux détails y comptent plus que le montant affiché.

Chez Lovable, le domaine personnalisé et la suppression du badge de la plateforme sont des fonctions Pro. L'offre gratuite n'est donc pas vraiment un moyen de faire tourner un outil d'entreprise : dès que vous voulez votre propre domaine, vous payez.

Chez Vercel, le tarif est par utilisateur, pas par application. C'est la différence entre une ligne de dépense et une discussion budgétaire.

Et il s'agit du plancher, pas du plafond. L'offre suivante de Replit est à 95 $ par mois en annuel, ou 100 $ en mensuel. Les formules à crédits ajoutent un second axe : vous achetez de la capacité de génération en plus de l'hébergement, donc un mois d'itérations intenses coûte plus qu'un mois calme.

25 $ par mois n'est pas une grosse somme. C'est en revanche exactement le seuil à partir duquel on commence à demander à quoi sert un abonnement. Une application, une personne : personne ne demande rien. Six applications sur quatre équipes, et quelqu'un à la finance pose la question. La réponse doit alors être meilleure que "c'était rapide à construire".

Ce qui change quand toute l'entreprise s'en sert

Le modèle tarifaire des plateformes est conçu pour une personne qui construit une chose. Déployer la même application à l'échelle d'une organisation heurte tout ce qui n'a jamais été prévu pour :

• Une tarification par utilisateur ou par application, qui croît linéairement avec l'adoption alors que la valeur par utilisateur, elle, ne suit pas.
• Aucune connexion à votre annuaire. Pas de SSO, pas de synchronisation, donc les arrivées et les départs se gèrent à la main, ce qui veut dire en pratique qu'ils ne se gèrent pas.
• Des droits en tout ou rien. Acceptable quand tout le monde peut tout voir. Plus du tout la première fois qu'une personne ne doit voir que les chiffres de sa région.
• Des quotas et des limites invisibles à dix utilisateurs, et qui deviennent le seul sujet à deux cents.
• Aucun environnement. Il y a la production, et il y a la modification de la production.

Rien de tout cela n'est un défaut des outils. C'est un décalage entre ce à quoi ils servent et ce que l'application est devenue.

Un hébergement n'est pas une posture de sécurité

Un hébergement vous donne une URL qui répond. Il ne vous donne rien de ce qui suit, et tout cela vous incombe, que vous y ayez pensé ou non :

• La gestion des secrets. Des clés d'API et des identifiants de base de données qui ne traînent pas dans le code ou collés dans un champ de configuration.
• Un contrôle des accès qui résiste au partage d'un lien.
• Le cloisonnement des données, pour que les lignes d'un client ne soient pas lisibles depuis la session d'un autre.
• La journalisation, pour pouvoir répondre à "qui a modifié cet enregistrement" des mois plus tard.
• Les obligations RGPD : où vivent les données, combien de temps vous les gardez, et comment vous les supprimez quand on vous le demande.

Pour une application qui ne contient que vos notes, l'enjeu est réellement faible et nous vous le dirons. Pour tout ce qui contient des données de clients ou de salariés, cette liste cesse d'être optionnelle, et rien n'y apparaît par défaut parce que le déploiement a réussi.

Ce que nous trouvons vraiment dans le code généré

Les mêmes quelques points, dans presque chaque audit. Non pas parce qu'un modèle écrit du mauvais code, mais parce que ce sont les problèmes qui n'apparaissent qu'en charge réelle, et un prototype ne voit jamais la charge réelle.

• Des requêtes N+1. La page charge une liste, puis interroge la base une fois par ligne. Instantané avec vingt lignes, inutilisable avec deux mille.
• De la logique copiée au lieu d'être partagée. La même règle écrite à quatre endroits : la corriger suppose de trouver les quatre, et le cinquième que vous ignoriez est le bug.
• Aucun test. C'est le point le plus important, parce que c'est lui qui rend tout le reste cher. Sans tests, impossible de savoir si un changement a cassé quelque chose, donc chaque changement devient un pari et l'équipe cesse d'en faire.
• Aucune migration. Le schéma a été modifié à la main dans une interface, donc personne ne peut recréer la base à partir de zéro, et il n'existe aucun retour en arrière après un mauvais changement.
• Des secrets dans le dépôt. En général parce que c'était plus rapide, et en général toujours là.

Le schéma est constant : ce que le modèle a écrit fonctionne pour le cas qu'on lui a montré. Ce qui manque, c'est tout ce qui rend la deuxième année moins chère que la première.

Vous n'avez probablement pas besoin de tout jeter

Le réflexe d'un développeur devant une base de code générée est de la réécrire. Résistez, et méfiez-vous de quiconque commence par là. Une réécriture jette du travail déjà payé, repousse la prochaine mise en production de plusieurs mois, et réintroduit tous les bugs que vous avez déjà trouvés et corrigés.

Ce qui fonctionne en général, dans cet ordre : lire le code et établir ce qui est vrai, écrire des tests sur les parcours dont une panne coûte de l'argent, rendre la base de données reproductible, puis remplacer les parties faibles une par une pendant que l'application continue de tourner.

La première étape mérite d'être payée pour elle seule, parce que c'est celle qui vous dit si le reste vaut la peine. C'est exactement ce qu'est notre audit de code et reprise de projet : une lecture au forfait de ce que vous avez, qui se termine par un rapport disant ce qui est sain, ce qui est à reprendre, et ce que chaque correction coûte. Si notre conclusion est qu'il faut laisser l'application exactement telle quelle, nous l'écrivons et vous gardez le rapport.

Avant tout cela, vérifiez cependant un point : que vous pouvez exporter le code. Dépôt complet, historique, schéma de base de données, migrations, variables d'environnement. Tout le reste de cette page est un problème technique avec un prix. Ne pas pouvoir récupérer son code est le seul qui n'a pas de solution.

À lire aussi : low-code, no-code ou sur mesure, comment choisir, et le cahier des charges qui évite qu'un projet dérape.