Vous avez passé un week-end sur Lovable, Bolt, v0, Replit ou Cursor et vous avez une application qui tourne. Vos associés ont trouvé ça bluffant. Puis vous avez voulu ouvrir des comptes à vos clients, brancher votre ERP ou publier sur l’App Store, et quelque chose a coincé. La question qui suit est toujours la même : est-ce que je continue seul, ou est-ce que j’appelle un développeur ?
Chez Playmoweb, nous recevons de plus en plus de demandes qui commencent par « j’ai déjà un prototype fait avec Lovable ». Nous utilisons ces outils nous aussi pour prototyper et cadrer, et nous les trouvons utiles. Cet article vous donne une grille de lecture honnête : ce qu’une application créée avec IA fait bien, où elle casse, les signaux d’alerte, et les trois scénarios possibles pour la suite, avec des ordres de grandeur de budget.
Sommaire
Commençons par ce qui marche, parce que ça marche vraiment. Ces outils transforment une description en français en application web fonctionnelle en quelques heures, pour 20 à 25 dollars par mois sur les formules d’entrée (Lovable Pro à 25 $, Bolt Pro à 25 $, Cursor Pro à 20 $ en septembre 2026).
Le premier usage pertinent, c’est la validation d’une idée. Un prototype cliquable mis devant dix clients potentiels vous apprend plus qu’un document de quarante pages (voir notre article cahier des charges ou prototype).
Le deuxième usage, c’est l’outil interne simple : un tableau de suivi pour trois personnes, un formulaire de congés, un calculateur métier. Pas de données sensibles, pas de charge, un périmètre stable.
Le troisième usage, celui que nous pratiquons le plus, c’est la maquette qui sert à cadrer. Un prototype montré à une agence fixe les écrans, les parcours et le vocabulaire mieux qu’une longue réunion. Il ne fixe pas l’architecture, et c’est là que les problèmes commencent.
Le prototype marche en démo parce qu’une démo ne teste rien de ce qui compte en production. Voici où se situe la frontière.
| Sujet | Ce que l’outil fait bien | Où ça se complique |
|---|---|---|
| Authentification et rôles | Un écran de connexion, un compte administrateur | Des rôles multiples, le cloisonnement des données entre organisations, le SSO d’entreprise |
| RGPD et hébergement | Une base de données créée en un clic | Savoir où sont les données, signer un contrat de sous-traitance, gérer conservation et demandes d’accès |
| Montée en charge | 10 utilisateurs qui testent | 500 utilisateurs simultanés, des exports lourds, des requêtes non optimisées qui font exploser la facture cloud |
| Intégrations SI | Un appel à une API publique | L’ERP, le CRM, la paie, avec des règles de synchronisation et des cas d’erreur |
| Publication sur les stores | Une application web responsive | Un vrai binaire iOS et Android, les comptes développeur, la validation d’Apple et de Google, les mises à jour |
| Maintenance et dette | Une première version en quelques heures | Du code que personne n’a lu, des dépendances à mettre à jour, des régressions à chaque demande |
| Sécurité | Du code plausible | Des règles d’accès à la base absentes, des clés d’API exposées côté client, aucune revue |
| Tests | Une vérification manuelle en cliquant | Des tests automatisés qui garantissent qu’une modification ne casse pas l’existant |
Sur la sécurité, les chiffres sont sans appel. En 2025, un chercheur a documenté une faille (CVE-2025-48757) touchant plus de 170 applications construites avec Lovable : les règles d’accès à la base étaient absentes, et n’importe qui pouvait lire des emails, des numéros de téléphone, des données de paiement et des clés d’API sans être connecté. En août 2026, un scan de 30 998 applications générées par IA et déployées en ligne a montré que 57 % de celles reposant sur une base Supabase accessible autorisaient encore la lecture de tables sans authentification. Une autre étude publiée le même mois mesure 4,4 fois plus de vulnérabilités dans les dépôts assistés par IA que dans le code écrit par des humains seuls.
L’outil n’est pas mauvais. Simplement, la sécurité repose sur des décisions que personne n’a prises.
Sur les stores, une précision : Lovable produit des applications web, pas des applications iOS ou Android. Pour arriver sur l’App Store ou Google Play, il faut une enveloppe native (Capacitor ou un service tiers), les comptes développeur (99 $ par an chez Apple, 25 $ une fois chez Google) et passer la validation. Bolt propose une intégration avec Expo qui génère un vrai projet mobile, un progrès réel, mais la publication, les mises à jour et les règles des stores restent à votre charge.
Il y a un moment où continuer seul coûte plus cher que de demander de l’aide. Ces signaux reviennent dans presque toutes nos conversations.
Vous corrigez un bug et deux autres apparaissent. L’outil modifie du code qu’il ne comprend plus globalement, et vous consommez des crédits pour revenir au point de départ.
Vous avez demandé « ajoute une gestion des rôles » trois fois et ça ne marche toujours pas. Les permissions et le cloisonnement des données sont le premier mur des applications générées. C’est un problème d’architecture, pas d’énoncé.
Vous êtes sur le point d’y mettre de vraies données clients. Dès que des noms, des emails ou des données de paiement entrent dans l’application, vous en êtes responsable au sens du RGPD.
Quelqu’un d’autre que vous doit s’en servir tous les jours. Un outil que vous utilisez seul tolère les bugs. Un outil qu’utilisent vos commerciaux ou vos clients, non.
Vous voulez le brancher à votre système d’information ou le publier sur les stores. Ces deux chantiers demandent des règles métier, de la gestion d’erreurs et des tests que l’outil ne fournira pas sans quelqu’un qui sait quoi lui demander.
Si vous cochez deux de ces signaux, il est temps de faire regarder le prototype par quelqu’un dont c’est le métier. Pas forcément pour tout refaire.
Une application créée avec IA n’a pas un seul avenir possible. Nous en voyons trois, et le bon dépend de ce que vous voulez en faire.
Si l’application sert à quelques personnes en interne, sans données sensibles ni intégration critique, gardez-la. Faites simplement vérifier trois points par un développeur, une demi-journée suffit souvent : les règles d’accès à la base, les clés d’API côté client, l’existence d’une sauvegarde. Coût : quelques centaines à quelques milliers d’euros, plus l’abonnement de l’outil.
Pertinent quand le prototype est proche du besoin final, que le périmètre est raisonnable et que le code est exportable (Lovable et Bolt synchronisent avec GitHub). Un développeur reprend la base, corrige la sécurité, ajoute des tests, restructure ce qui doit l’être et met en place un hébergement que vous maîtrisez. Comptez en ordre de grandeur 10 à 40 k€ selon le périmètre. La limite : si les fondations sont inadaptées (mauvais découpage des données, pas de séparation entre organisations), consolider revient à repeindre une maison dont les murs sont de travers.
Le prototype devient le cahier des charges vivant, et une équipe redéveloppe proprement à partir de cette base. C’est souvent le meilleur choix quand l’application doit aller sur les stores, gérer plusieurs organisations ou s’intégrer au SI. Vous ne repartez pas de zéro : le cadrage est déjà fait, et c’est lui qui coûte le plus cher en allers-retours. Pour un MVP, comptez 25 à 50 k€, et 50 à 120 k€ pour une application métier plus complète, conformément aux fourchettes que nous avons publiées en 2026.
Dans tous les cas, prévoyez la maintenance : 15 à 25 % du coût initial par an. Ce poste existe aussi pour une application générée, il est juste invisible tant que personne ne s’en occupe.
Avant de choisir un scénario, il faut regarder ce qu’il y a dans le prototype. C’est l’objet d’un audit technique, que nous menons en quelques jours et qui suit toujours le même déroulé.
Nous commençons par l’accès au code et à l’hébergement. Si le code n’est pas exportable ou si le compte appartient à un stagiaire parti depuis, la conclusion est déjà claire. Ensuite, nous lisons le code : structure, dépendances, règles d’accès, secrets, couverture de tests. Nous testons l’application sous charge légère, puis nous vérifions où sont les données et sous quel contrat.
Le livrable est un document court : les risques classés par gravité, l’estimation de chaque scénario, une recommandation. La méthode est la même que pour reprendre une application développée par un autre prestataire, sauf que la documentation est souvent inexistante et que le code n’a jamais été relu.
Voici les pièges que nous rencontrons le plus souvent.
Avant de décider quoi faire de votre application créée avec IA, répondez à ces six questions.
Si vous répondez « mes clients », « oui » ou « je ne sais pas » à plus de deux questions, faites auditer le prototype avant d’y investir davantage. Et si vous n’avez pas encore commencé, lisez notre méthode pour valider une idée d’application avant de la développer : un prototype Lovable y a toute sa place, à condition de savoir à quoi il sert.
Vous avez un prototype construit avec Lovable, Bolt ou Cursor et vous vous demandez quoi en faire ? Contactez-nous pour un échange gratuit et sans engagement : nous regardons votre application et nous vous disons franchement lequel des trois scénarios s’applique. 👉 playmoweb.com/nous-contacter