Lovable, Base44 : est-ce que ça marche pour une application mobile ? Tu as vu les démos. Tu décris ton idée en trois phrases, et quelques minutes plus tard il y a quelque chose à l'écran qui ressemble à une application. C'est bluffant, et ce n'est pas un trucage : ces outils font vraiment ce qu'ils montrent.
Je m'appelle Noé Calmes, je conçois des applications mobiles pensées pour générer des revenus. J'ai publié plus de 20 applications sur l'App Store et Google Play, et j'utilise l'IA tous les jours pour écrire du code. Cet article n'est pas un procès contre ces outils. C'est la réponse à une question précise que personne ne pose avant de s'abonner : est-ce que ce que tu vas obtenir est bien une application mobile ?
Ce que ces outils font vraiment bien
Autant commencer par là, parce que c'est réel et que beaucoup d'articles le passent sous silence pour vendre autre chose.
La vitesse de prototypage. Passer d'une idée à un écran cliquable en une soirée, aucun développeur ne fait ça, moi compris.La levée de la barrière technique. Base de données, authentification et hébergement sont branchés sans que tu aies à comprendre comment.Le coût d'entrée. Quelques dizaines d'euros par mois contre plusieurs milliers pour un développement sur mesure.La validation d'une intuition. Montrer un écran réel à dix personnes de ta cible vaut mieux que le décrire à l'oral.
Si ton objectif est de tester une idée avant d'engager un budget, ce sont d'excellents outils. Je le dis sans réserve, et c'est même ce que je recommande à des gens qui me contactent trop tôt.
Le point que les démos ne montrent jamais : c'est un site, pas une application
Voilà la chose la plus importante de cet article, et elle n'a rien d'une opinion.
Lovable génère une application web , en React. Tu peux l'ouvrir sur ton téléphone, l'épingler sur l'écran d'accueil, lui donner une icône. Ça reste un site qui tourne dans un navigateur. Ce n'est pas une application iOS ou Android.
La différence n'est pas cosmétique, elle est bloquante. Apple exige un binaire natif, et sa règle de validation 4.2 « Minimum Functionality » rejette explicitement les sites web réempaquetés. La sous-règle 4.2.2 vise nommément les « web clippings ». Apple précise même qu'ajouter des notifications ou la géolocalisation ne suffit pas à rendre un site acceptable sur l'App Store.
Ce que ça veut dire concrètement
Tu peux passer trois mois à construire ton produit sur ces outils, puis découvrir au moment de la publication que l'App Store le refuse. Le refus n'arrive pas au début, il arrive à la fin, quand tu as déjà tout investi.
Il existe des solutions de contournement, qui consistent à emballer le site dans une coquille native. Elles se heurtent à la même règle 4.2, et les refus sont fréquents.
Pas d'App Store, pas d'abonnement App Store
C'est la conséquence business, et c'est celle qui coûte le plus cher.
Le modèle de revenus le plus rentable en mobile est l'abonnement encaissé par l'App Store et Google Play. Il fonctionne parce qu'il est intégré au téléphone : deux taps, l'empreinte digitale, c'est payé, et ça se renouvelle tout seul. Un paiement web demande une carte bancaire saisie à la main sur un petit écran, et il convertit bien moins.
13 000 €
générés chaque mois par une application que j'ai conçue, via un abonnement encaissé par les stores. Ce mécanisme-là passe par l'achat intégré, réservé au mobile. En web, le même abonnement s'encaisse par carte, sans commission : il te reste davantage, mais c'est à toi d'aller chercher l'abonné.
Si ton projet vit de la récurrence, la question n'est donc plus « quel outil est le plus rapide », mais « lequel me permet d'encaisser ». Le sujet est développé dans application par abonnement : combien ça rapporte .
Pourquoi elles se ressemblent toutes
Ouvre cinq applications générées par ces outils et tu verras la même chose : les mêmes cartes arrondies, les mêmes dégradés, la même barre de navigation, la même page d'accueil avec trois blocs et un bouton violet.
Ce n'est pas un hasard. Ces générateurs s'appuient sur les mêmes bibliothèques de composants et sur les mêmes conventions apprises pendant leur entraînement. Ils produisent donc une moyenne statistique du design existant. C'est propre, c'est correct, et c'est interchangeable.
Le problème n'est pas esthétique. Une interface générée est optimisée pour paraître crédible sur une capture d'écran, pas pour amener un utilisateur au moment où il comprend l'intérêt de ton produit, puis à l'écran qui lui propose de payer. Ce chemin-là se décide, il ne se génère pas.
Le vrai coût, celui qui arrive après
L'abonnement mensuel n'est pas le coût de ces outils. Le coût réel apparaît le jour où tu veux dépasser ce qu'ils savent faire.
La dépendance à la plateforme. Ton produit vit chez un éditeur qui peut changer ses tarifs, ses limites ou sa direction. Base44 appartient désormais à Wix.Le code que personne n'a relu. Il compile, donc il rassure. La gestion des données personnelles et la sécurité y sont rarement traitées, et ça ne se voit pas tant que rien n'a explosé.La reprise. Quand un expert récupère le projet, il passe d'abord du temps à comprendre du code que personne n'a écrit intentionnellement. C'est facturé, et ce temps n'existerait pas sur une base construite à la main.
L'erreur la plus fréquente
Croire qu'on économise en commençant là, puis payer deux fois : l'abonnement pendant des mois, puis la reprise complète. Le budget total finit régulièrement au-dessus de ce qu'aurait coûté un développement cadré dès le départ.
Pour les ordres de grandeur d'un développement sur mesure, regarde combien coûte une application mobile .
Quand ces outils sont le bon choix
Ils le sont vraiment dans trois cas, et je préfère te le dire plutôt que de te vendre autre chose.
Tu veux valider une idée. Construis le prototype, montre-le, mesure si des gens s'inscrivent. C'est du temps et de l'argent économisés.Ton produit est un outil web. Un tableau de bord, un back-office, un espace client utilisé sur ordinateur : le mobile natif n'apporte rien, et ces outils sont pertinents.Tu as besoin d'un support de démonstration. Pour convaincre un associé ou un financeur, un écran cliquable vaut mieux qu'un document.
Dans ces trois cas, la réponse est oui. Le piège n'est pas l'outil, il est de confondre un prototype avec un produit qui encaisse.
Par où commencer
Trois choses, dans cet ordre.
Réponds à une seule question : ton produit a-t-il besoin d'être sur les stores ? S'il vit d'un usage quotidien sur téléphone, de notifications ou d'un abonnement récurrent, la réponse est oui, et aucun générateur ne t'y emmènera.Si tu n'es pas sûr de ton idée, prototype d'abord. Utilise ces outils pour ça, c'est exactement leur terrain.Si tu es sûr, ne passe pas par la case prototype payant. Cadre le modèle de revenus, puis construis directement ce qui pourra encaisser.
Si tu as déjà un prototype généré et que tu te demandes ce qui est récupérable, c'est une question fréquente et elle a une vraie réponse, mais elle demande de regarder le code. Le fond du sujet est traité dans créer une application avec l'IA .
À lire aussi :
← Retour au blog Accueil · Concevoir une application qui rapporte · Ma méthode · Blog · Tester ton idée · FAQ