Achat intégré : l’étape que la plupart des constructeurs par IA ne résolvent toujours pas
Il y a un moment où presque tout projet construit par IA se bloque, et il arrive tard : l’app est prête, elle est belle, elle marche dans le navigateur, et vous décidez de la publier sur l’App Store ou Google Play pour vendre un abonnement. C’est là que vous découvrez que le bouton de paiement qui marchait sur le web est précisément ce qui fait refuser l’app.
Ce guide explique pourquoi, ce qui doit exister avant de pouvoir vendre un abonnement dans une app publiée, et où s’arrêtent la plupart des outils d’IA en 2026.
La règle qui piège tout le monde
Apple et Google exigent que le contenu numérique vendu dans une app installée passe par leur propre facturation. Abonnements, cours, espaces membres, suppression des publicités, fonctions premium : tout cela est numérique.
Mettre un checkout Stripe dans l’app n’est pas un raccourci risqué, c’est l’exemple littéral que les deux politiques emploient pour décrire ce qui est interdit. Et la sanction n’est pas seulement un refus en revue. Une app déjà publiée peut être retirée, et cela arrive avec des abonnés à l’intérieur.
Base44 le dit dans sa propre documentation, noir sur blanc : "Do not use Stripe for payments inside your mobile app. Apple and Google require their own billing systems for digital content."
Il existe une exception importante : les biens physiques et les services rendus hors de l’app peuvent toujours passer par une passerelle. Une boutique de vêtements, un restaurant qui livre, un salon qui prend des rendez-vous : là, la passerelle est la bonne voie, et le store ne prend rien.
Ce que livrent aujourd’hui la plupart des constructeurs par IA
Deux choses sont vendues ensemble, et il vaut la peine de les séparer.
Arriver sur le store est la première. Plusieurs constructeurs le font déjà, en emballant l’app web dans une coque native (un webview) qui ouvre votre URL. Cela fonctionne, et une bonne part des apps du marché sont faites ainsi.
Vendre dans l’app est la seconde, et là la liste se réduit. Selon la documentation de Base44 elle-même, la coque qu’elle génère "does not support in-app purchase systems", et l’entreprise affirme : "We are working on a built-in integration for StoreKit and Google Play Billing to handle digital purchases and keep your app compliant." Sur la feuille de route, donc, pas dans le produit.
Lovable se situe avant cette étape : c’est un constructeur web, et atteindre les stores dépend de services tiers qui emballent l’app.
Pour être juste avec le marché : il existe des outils no-code qui gèrent déjà l’achat intégré, certains depuis des années. Ce qui n’existe presque pas, c’est cela dans un constructeur qui génère l’app entière à partir d’une description en texte. C’est de cet écart que parle cet article.
Ce que fait Fabapp
Fabapp publie l’app native et vend à l’intérieur avec la facturation du store, de bout en bout. Le premier achat complet est passé en septembre 2026, et le chemin est celui-ci :
- vous créez l’app en décrivant ce que vous voulez, en texte ;
- la plateforme construit la version native et l’envoie sur votre compte développeur ;
- vous reliez les offres de l’app aux produits du store, et la plateforme crée le produit sur Google Play pour vous ;
- le client achète depuis l’écran du store lui-même, dans l’app ;
- l’achat est vérifié sur le serveur avec votre identifiant, et l’accès est ouvert.
Trois détails de ce chemin méritent d’être dits à voix haute, car ce sont eux qui séparent une intégration qui fonctionne d’une qui en a l’air.
L’argent est le vôtre, et la plateforme n’est pas sur le chemin
L’app est publiée sur votre compte développeur, avec vos identifiants. Le store verse sur le compte bancaire que vous avez enregistré chez Apple et Google. Fabapp n’est pas intermédiaire de la vente et ne prend aucun pourcentage de ce que vous facturez.
Cela paraît évident et ne l’est pas : sur les plateformes où l’app est publiée sur le compte du fournisseur, vous dépendez de lui pour être payé, et partir signifie perdre la fiche du store et les abonnés avec elle.
L’appareil ne décide jamais
Quand quelqu’un achète, l’app renvoie un identifiant de transaction. C’est une affirmation, pas une preuve, et la traiter comme une preuve, c’est ainsi qu’un reçu falsifié ouvre un accès payant.
Tout ce qui déplace de l’argent (quel produit, à qui, jusqu’à quand, encore actif) est redemandé au store, avec votre identifiant, sur le serveur. C’est pourquoi un achat prend quelques secondes entre l’acceptation du store et l’ouverture dans l’app.
Le renouvellement est une étape, pas une conséquence
C’est le détail que le plus de gens découvrent tard, et il coûte cher.
Quand quelqu’un s’abonne, le store indique jusqu’à quand cet accès vaut. Chaque mois, au renouvellement, il envoie une notification disant que l’échéance a avancé. Si personne ne l’écoute, vous obtenez le pire montage possible : Google continue de prélever votre client tous les mois, et son accès expire à la fin du premier. Un remboursement cesse aussi de retirer l’accès, si bien que celui qui se fait rembourser continue d’utiliser l’app.
Chez Fabapp, ce canal s’active en collant une ligne dans la Play Console, et l’écran le confirme tout seul quand la première notification arrive, au lieu de vous demander de promettre que vous l’avez fait. Sur iOS c’est automatique.
Ce qui reste votre travail
Aucun outil ne supprime cela, et méfiez-vous de qui prétend le contraire :
- les comptes développeur : 25 $ une fois chez Google, 99 $ par an chez Apple ;
- créer le produit dans la console du store, ou relire celui que la plateforme a créé ;
- les autorisations du compte de service sur Google Play. Publier et lire les achats sont des autorisations différentes, et on coche souvent la première en oubliant la seconde. Le symptôme trompe : la publication marche, et l’achat aboutit dans le store sans rien débloquer dans l’app ;
- la revue d’Apple, qui pour le premier abonnement se fait en même temps que la version de l’app.
Est-ce que cela vaut le coup, vu la commission ?
Le store garde une part de chaque vente, et les deux ont des paliers réduits pour la plupart des petits développeurs, chacun avec ses règles. Consultez les pages officielles avant de décider, car les conditions changent.
Le calcul qui tranche n’est pas la commission seule, c’est celui-ci : une app qui ne peut pas vendre en son sein pousse le client vers un navigateur au milieu de l’achat, et une bonne part ne revient tout simplement pas. Une commission sur une vente qui a lieu vaut souvent mieux que zéro pour cent sur une vente qui n’a pas lieu.
Et il y a une voie intermédiaire qu’on oublie : vous pouvez vendre l’abonnement sur le site via votre passerelle, sans aucune commission de store, et n’utiliser la facturation du store que dans l’app installée. Les deux coexistent, et la plateforme traite chacune à sa place.
Par où commencer
Si vous n’avez pas encore l’app, commencez par décrire ce qu’elle fait et laissez la facturation pour plus tard : il est moins cher de bien régler le parcours gratuit d’abord. Si vous l’avez déjà, le chemin est l’onglet Application, à l’étape Comptes.
Les guides Vendre des abonnements dans l’app et Connecter vos comptes Apple et Google le déroulent avec les écrans.