Publier une app Lovable sur l'App Store et Google Play

Le problème

Le prototype tourne. Il a été généré avec Lovable en quelques jours, la démo passe bien, les premiers testeurs ont donné leur avis. Et puis la question arrive : comment publier une application Lovable sur l’App Store et Google Play ? Le fondateur exporte le code, le voit tenir dans un dépôt Git, et la suite demande d’autres compétences : compte développeur, build signé, revue Apple.

Le deuxième sujet est moins visible. Dans un prototype généré, les règles qui comptent vivent souvent dans l’interface, et c’est normal à ce stade : le but était de valider un MVP, pas de tenir face à des inconnus. Le jour où l’application est dans les mains d’utilisateurs via un store, ces règles doivent être vérifiées côté serveur, et le choix de la coque mobile devient un vrai choix d’architecture.

L’approche

C’est la reprise que j’ai menée pour GoPronos, une application de pronostics sportifs, orientée basket, gratuite, avec des classements par club et par saison. Elle est aujourd’hui publiée sur l’App Store et Google Play, avec une application d’administration pour piloter les matchs et les équipes, et des maillots stylisés pour représenter les clubs. Le point de départ était un prototype Lovable. Voilà dans quel ordre je l’ai fait.

Auditer le prototype avant d’engager du développement

J’ai commencé par un audit, envoyé au porteur du projet : l’état du prototype, ce qui devait passer côté serveur avant une mise en ligne publique, et une comparaison de trois voies vers le mobile (PWA, Capacitor, React Native), avec ma recommandation pour un lancement ciblé. Le modèle de données et le calcul des points, lui déjà en SQL dans le prototype, ont été conservés.

Ancrer les règles du jeu dans la base

Le premier jour de reprise, en mai 2026, j’ai importé le prototype tel quel dans un commit, puis j’ai passé la journée à le structurer : découpage en monorepo, TypeScript strict, tests sur le barème de points, et surtout les policies Supabase qui font respecter les règles du jeu, détaillées plus bas.

Encapsuler l’application web avec Capacitor, sans réécrire

Capacitor a été ajouté le même jour, version épinglée en 8.0.0, avec les projets iOS et Android générés dans la foulée. L’application web reste l’application ; Capacitor la met dans une coque native. Quatre workflows GitHub construisent les versions iOS et Android, dont deux les signent et les publient.

Publier sur les deux stores

Une soumission iOS a demandé un ajustement de vocabulaire et d’icône pour lever une classification automatique d’Apple, réglé le jour même. L’application est en ligne sur l’App Store et Google Play, en version 1.0.

Stack et choix techniques

Sur une reprise de prototype no-code, ce que je regarde en premier, c’est où vivent les règles qui comptent. Ici, elles sont vérifiées en base : les pronostics sont verrouillés au coup d’envoi, les pronostics des autres joueurs sont révélés au lancement du match, et les rôles sont vérifiés en SQL. Deux fonctions security definer, match_is_open_for_predictions() et match_predictions_revealed(), portent ces règles, et les policies de la table predictions s’appuient dessus. Le dépôt compte 78 policies RLS sur 53 migrations.

Ce qui compte pour le classement se décide dans la base, jamais dans le téléphone.

Industrialiser ne veut pas dire jeter. Les 19 migrations héritées de Lovable sont toujours là, jamais réécrites, seulement complétées. Le trigger de calcul des points aussi : il était juste, il est resté. Un fichier scoring.ts côté client sert à l’affichage, avec ses tests, mais il ne décide de rien.

Pour le mobile, j’ai choisi Capacitor plutôt qu’une réécriture React Native, parce que l’application web était bonne et qu’il n’y avait aucune raison de la refaire. La chaîne de publication est automatisée : un workflow de release iOS avec signature et profil App Store, un workflow Android équivalent, et une publication qui ne demande plus de geste à la main.

Côté monétisation, AdMob est intégré depuis la génération des projets natifs : bannière, interstitiels et formats récompensés qui donnent des bonus dans le jeu. Sur iOS, la demande d’autorisation de suivi (ATT) et la liste SKAdNetwork ont été ajoutées en juillet. Les identifiants AdMob réels sont injectés par la CI, pas écrits dans le code, et le site publie son app-ads.txt. La suppression de compte est une Edge Function dédiée, accessible depuis l’app, ce que les deux stores demandent aujourd’hui.

Les clubs, enfin, sont représentés par des maillots stylisés plutôt que par des logos de clubs, qui sont des marques déposées. Une Edge Function lit une photo d’un vrai maillot et en extrait deux couleurs et un motif parmi 11, pour pré-remplir la fiche du club dans l’app admin. La photo n’est jamais stockée.

Résultat

L’application est publiée sur l’App Store et sur Google Play, avec une chaîne de publication automatisée. Les chiffres du dépôt au 20 septembre 2026 :

Questions fréquentes

Comment publier une application Lovable sur l’App Store et Google Play ?

Tu exportes le code depuis Lovable vers un dépôt Git, tu ajoutes Capacitor pour générer les projets iOS et Android, puis tu construis des versions signées que tu envoies à TestFlight et à la Play Console depuis des comptes développeur. C’est le geste technique, et il est documenté partout. Ici, l’ajout de Capacitor et la génération des projets natifs ont pris une journée. Ce qui prend du temps, c’est ce qu’il y a avant (les règles côté serveur) et après (la revue).

Lovable et Capacitor, ça tient pour une app en production ?

Ici, oui : l’application publiée est le code Vite + React du prototype, prolongé, dans une coque Capacitor 8. La contrainte, c’est la discipline sur les versions natives et une CI qui signe et publie à ta place ; sans elle, chaque release redevient un rituel manuel.

Que regarde la revue Apple sur une app de pronostics ?

Trois choses en pratique. Le vocabulaire : une app gratuite qui parle de « pari » ou de « mise », même pour dire qu’il n’y en a pas, peut être classée automatiquement comme jeu d’argent, donc mieux vaut un lexique de score et de classement. Le manifeste de confidentialité, qui doit déclarer le suivi publicitaire et les données collectées. Et la suppression de compte, accessible depuis l’app. Si ces trois points sont prêts avant la soumission, la revue n’a rien à redire.

Comment sécuriser les règles métier d’une app générée par Lovable avant de la publier ?

Tu regardes chaque table Supabase et tu te demandes qui peut lire et écrire quoi, et à quel moment. Ici, le verrou temporel et la visibilité des pronostics sont des fonctions SQL appelées par la RLS, et le rôle est vérifié en SQL, jamais dans l’interface. Ce travail se fait avant le premier build mobile.

Si ton prototype Lovable ou Bolt est validé et que tu veux savoir ce qui doit passer côté serveur avant les stores, et ce que la revue va regarder, c’est ce que je traite en premier dans un audit de reprise.