Si vous avez créé une application avec Lovable, Bolt, Claude Code ou Cursor et qu'elle fonctionne en démo, vous avez déjà répondu à la première question sur votre idée : peut-on la montrer, cliquer dedans et l'expliquer à quelqu'un ? Ce qu'une démo ne prouve pas, c'est que vous pouvez confier l'application à des inconnus qui y mettront de vraies données et de l'argent. Entre les deux, on retrouve presque toujours la même courte liste : qui voit quelles données, ce qui se passe quand un paiement ou un e-mail échoue, où sont stockées les données et qui contrôle les comptes. Certains prototypes passent ce cap. Pour d'autres, il revient moins cher de reconstruire, en gardant le prototype comme cahier des charges.

Ce que ces outils font bien

Les générateurs d'applications par IA excellent sur la partie d'un produit qui était autrefois la plus lente : transformer une idée en écrans que l'on peut essayer. Un fondateur peut aujourd'hui montrer un parcours qui fonctionne à dix clients potentiels en une semaine, sans embaucher personne, et voir s'ils en veulent. Cela vaut beaucoup. La plupart des idées de produit devraient être testées exactement ainsi avant que quiconque y mette de l'argent sérieux.

Ces outils produisent aussi du vrai code. Lovable, par exemple, indique que le code que vous créez vous appartient et permet de le synchroniser avec un dépôt GitHub. Un prototype n'est donc pas jetable par principe. Qu'il vaille la peine d'être gardé dépend de ce qu'il contient.

Ce qui casse le plus souvent

Qui peut lire quelles données

C'est le premier point à vérifier. Beaucoup d'applications construites avec l'IA utilisent Supabase comme base de données et l'interrogent directement depuis le navigateur. Cette architecture n'est sûre que si chaque table a la Row Level Security (RLS, sécurité au niveau des lignes) activée, avec des règles qui disent quel utilisateur peut lire et modifier quelles lignes. La documentation de Supabase le dit elle-même : activez la RLS sur chaque table d'un schéma exposé.

Sans cela, n'importe qui ouvrant les outils de développement de son navigateur peut interroger la base. En 2025, ce problème a été enregistré sous la référence CVE-2025-48757 : une sécurité au niveau des lignes insuffisante dans les applications générées par Lovable jusqu'au 15 avril 2025 permettait à des visiteurs non connectés de lire ou d'écrire dans des tables arbitraires. Lovable conteste cette CVE, au motif que chaque client est responsable de la protection des données de sa propre application. Quelle que soit la réponse sur la responsabilité, la conséquence pratique est la même pour tous les outils : ces règles font partie de votre application, et elles ne valent que ce que vaut la dernière relecture.

Les clés font partie de la même liste. Une clé publique (publishable key) dans le navigateur, c'est normal. Une clé secrète, non : Supabase dit de ne jamais utiliser une clé secrète dans le navigateur, et Stripe demande de ne pas intégrer les clés d'API ni les secrets de webhook dans le code source ou dans les applications côté client.

Les rôles et les comptes

Une démo n'a en général qu'un type d'utilisateur. Un produit en a au moins deux : le client et vous, l'administrateur. Souvent davantage, comme un compte entreprise avec des collègues, ou un client et un fournisseur qui ne doivent jamais voir les données l'un de l'autre. Ajouter des rôles après coup oblige à revoir chaque écran et chaque règle de la base. C'est la raison la plus fréquente pour laquelle un prototype est reconstruit.

Le modèle de données et les migrations

Dans un prototype, la structure de la base change à chaque fois que vous demandez une fonctionnalité. Dès que de vrais clients y ont des données, chaque changement doit être une migration qui conserve ce qui existe déjà. Vérifiez si votre projet contient des fichiers de migration qui décrivent comment la base est arrivée à sa forme actuelle, et si un champ contenant un montant, une date ou un statut a un type et un sens clairs. Si les tables ont été remaniées par des dizaines de prompts, il est souvent plus rapide de repenser le modèle que de le démêler.

Les paiements

Encaisser un paiement de test est facile. Un vrai parcours de paiement doit aussi gérer la carte refusée, le client qui ferme l'onglet avant la page de confirmation, le remboursement et l'abonnement qui se renouvelle. Avec Stripe, cela veut dire un traitement côté serveur qui vérifie la signature de chaque événement avant de marquer quoi que ce soit comme payé. Si le prototype met un champ « payé » à jour depuis le navigateur, la partie paiement est à refaire.

Les e-mails

Les confirmations d'inscription, les réinitialisations de mot de passe et les factures doivent arriver. Depuis le 1er février 2024, Gmail exige de tout expéditeur une authentification SPF ou DKIM, et les expéditeurs de plus de 5 000 messages par jour ont besoin de SPF, DKIM et DMARC. Il faut donc envoyer depuis votre propre domaine, via un vrai prestataire d'e-mail, avec des enregistrements DNS que vous contrôlez.

Le RGPD et l'endroit où vivent les données

Dès que vous stockez des données personnelles de vraies personnes, le RGPD s'applique à vous, pas à l'outil. Chaque service qui traite ces données pour votre compte (hébergement de la base, prestataire d'e-mail, outil d'analyse) doit être lié à vous par un contrat de sous-traitance au sens de l'article 28, et une violation de données à caractère personnel doit être notifiée à l'autorité de contrôle si possible dans les 72 heures après en avoir pris connaissance (article 33). Vérifiez dans quelle région tourne votre base : Supabase déploie chaque projet dans une région principale, et sa liste comprend des régions de l'UE comme Francfort, Paris et l'Irlande, à côté de Londres et Zurich, qui sont hors de l'UE.

Les erreurs, les tests et les coûts

Un prototype tombe en panne en silence. Un produit a besoin d'un suivi des erreurs, pour que vous voyiez un plantage avant qu'un client ne vous écrive, et de tests sur les quelques parcours qui comptent le plus : l'inscription, le parcours principal et la partie qui encaisse l'argent. Regardez aussi comment le backend est facturé. Les services facturés à l'usage coûtent peu avec dix utilisateurs. Consultez la page de prix de chaque service dont vous dépendez et calculez ce que coûteraient mille utilisateurs actifs avant de promettre un prix à vos propres clients.

Les stores, si c'est une application mobile

Si vous comptez publier une application web emballée sur l'App Store, lisez d'abord la règle 4.2 d'Apple : une application doit aller au-delà d'un site web reconditionné. Les deux stores exigent aussi qu'une application permettant de créer un compte permette de le supprimer : dans l'application sur iOS et, sur Google Play, dans l'application et via un lien web.

À qui appartiennent les comptes

Dressez la liste de chaque compte dont dépend le produit : le générateur, le dépôt GitHub, la base de données, le nom de domaine, Stripe, le prestataire d'e-mail, les comptes développeur Apple et Google. Chacun doit être au nom de votre entreprise, avec votre adresse e-mail comme propriétaire. Le code n'est qu'une partie de l'ensemble. La FAQ de Lovable précise que l'export de la base ne comprend ni les fichiers stockés, ni le code des Edge Functions, ni les secrets, et son guide d'hébergement indique que déplacer la base seule ne déplace ni l'authentification, ni le stockage, ni le temps réel, ni les Edge Functions. Prévoyez-les à part si vous déménagez un jour.

Garder ou reconstruire ?

Le prototype vaut probablement la peine d'être gardé si :

le code est dans un dépôt Git que vous contrôlez, avec un historique lisible ;
la RLS (ou un contrôle équivalent côté serveur) est activée sur chaque table, et les règles correspondent à qui doit voir quoi ;
la base a des fichiers de migration et une structure que vous savez expliquer ;
aucune clé secrète ne se trouve dans le code exécuté par le navigateur ;
il a déjà les rôles dont vous aurez besoin, ou les ajouter ne touche qu'une petite partie.

Reconstruire revient généralement moins cher si :

le modèle de données a été remanié par de nombreux prompts et plus personne ne sait à quoi sert chaque table ;
il vous faut des rôles ou des comptes multi-entreprises que le prototype n'a jamais eus ;
les paiements sont confirmés depuis le navigateur ;
chaque nouveau prompt casse quelque chose qui fonctionnait.

Reconstruire ne veut pas dire jeter le prototype. C'est le cahier des charges le plus clair qu'un développeur puisse recevoir : les écrans, le parcours et les choix que vous avez déjà testés avec des utilisateurs. Souvent, une partie survit, par exemple les composants d'interface.

Comment se passe la reprise par un studio

Vous donnez accès au dépôt, au projet de base de données et aux comptes listés plus haut, avec une courte note sur vos utilisateurs et ce qu'ils doivent pouvoir faire. Le studio lit le code, le fait tourner, vérifie les points de cet article et vous dit ce qu'il garderait, corrigerait ou remplacerait, et à quel prix. Ensuite, il termine le produit existant ou construit la première vraie version de zéro.

Nous faisons les deux. Notre MVP web (une première version utilisable en production par de vrais utilisateurs) coûte 14 000 € hors TVA, en 8–10 semaines : un parcours principal, des comptes et l'authentification, une administration simple, une intégration ou un moyen de paiement, des tests sur les parcours critiques, la mise en production, le monitoring et la documentation, avec le dépôt et les comptes à votre nom. Le web d'abord : les applications natives iOS et Android, les intégrations supplémentaires, les langues supplémentaires et la reprise de données sont des options à prix fixe, chiffrées avant de commencer. La liste complète se trouve sur la page MVP et sur la page des prix.

Nous reprenons aussi des produits commencés par d'autres développeurs. Pour Getizy, nous avons repris une application iOS et Android existante à la société de développement précédente, corrigé les bugs et la dette technique hérités et continué à publier de nouvelles fonctionnalités sur les deux stores. Une reprise commence chez nous par une revue payante du code, le Product Decision Sprint (2 500 €, 5 jours ouvrés), déduit intégralement d'un projet démarré dans les 30 jours. Le devis à prix fixe vient après cette revue, sur la base de ce que contient réellement le dépôt. Les réunions de projet se déroulent en anglais ou en russe.