Publier sur Google Play une app créée avec l'IA

Un outil d'IA peut vous mener d'une idée à une app qui marche en un week-end. Google Play se moque de la façon dont le code a été écrit. Il voit un compte de développeur et un Android App Bundle. Si le compte est personnel et a été créé après le 13 novembre 2023, vous devez mener un test fermé avec au moins 12 testeurs inscrits pendant 14 jours sans interruption avant de pouvoir demander l'accès production (Aide Play Console).

Ce qu'un outil d'IA ne décide pas à votre place, c'est tout ce qui vient après le code : la clé de signature, le SDK cible, les déclarations de la Play Console, et deux semaines d'utilisation par de vraies personnes. Cette page vous aide à identifier ce que votre outil a produit, puis liste huit vérifications utiles sur n'importe quelle app générée. La règle elle-même est dans le guide du test fermé.

Étape 1 : identifiez ce que votre outil a produit

Exportez ou téléchargez le projet et regardez les fichiers. Vous tomberez sur l'un de ces cas.

Depuis août 2021, Google Play exige que les nouvelles apps soient publiées au format Android App Bundle (Android Developers). Un APK seul ne suffit pas.

Certains outils annoncent clairement ce qu'ils produisent. La CLI de FlutterFlow, par exemple, permet à des agents de code IA comme Claude Code, Gemini CLI ou Codex de créer et de modifier un projet FlutterFlow Studio via un serveur MCP, et le résultat est une app Flutter (doc FlutterFlow). En cas de doute, les fichiers ci-dessus vous renseignent.

Suivez ensuite la page de votre stack : Flutter, React Native et Expo ou FlutterFlow. Pour les web apps, lisez la suite.

Web apps : deux façons de les encapsuler

Capacitor transforme une web app en projet Android natif que vous compilez dans Android Studio. Ajoutez la plateforme avec npx cap add android, ouvrez-la avec npx cap open android (doc Capacitor). Capacitor prend en charge Android 7 (API 24) et les versions ultérieures.

Capacitor lie le SDK cible à sa version majeure, réglée dans android/variables.gradle. Sa matrice associe 8.x à l'API 36 et 7.x à l'API 35, et la documentation précise que les versions de SDK cible personnalisées ne sont pas prises en charge (doc Capacitor). Si votre enveloppe est sur Capacitor 7, monter le nombre à la main n'est donc pas la solution. Passez à Capacitor 8.

Trusted Web Activity (TWA) affiche votre site en plein écran dans une app Android. Le guide de démarrage rapide de Google utilise Bubblewrap : bubblewrap init --manifest=https://your-site/manifest.json, puis bubblewrap build (Chrome for Developers). Le build écrit aussi un app-release-bundle.aab signé pour Google Play (Bubblewrap).

Deux pièges des TWA :

• Digital Asset Links. Votre site doit publier un fichier qui pointe vers la clé de signature de votre app. Si la vérification échoue, l'app ouvre votre site dans un Custom Tab, avec l'interface du navigateur en haut. Le guide de Google prévient qu'en publiant sur Google Play, l'app peut être signée avec une autre clé que celle que Bubblewrap a configurée. Ajoutez l'empreinte de la clé de signature Play au fichier assetlinks, sinon chaque testeur verra une barre de navigateur.
• Fichiers de projet anciens. Le SDK cible se trouve dans le projet Android généré. bubblewrap update régénère ces fichiers à partir de twa-manifest.json (Bubblewrap). Vérifiez ensuite targetSdkVersion dans app/build.gradle.

Une enveloppe qui ne fait qu'afficher un site donne aussi peu de choses à essayer à vos testeurs, et vous devrez décrire leur utilisation dans le formulaire d'accès production. Assurez-vous que l'app fait quelque chose d'utile sur un téléphone.

Étape 2 : vérifiez le SDK cible

Depuis le 31 août 2026, les nouvelles apps et les mises à jour doivent cibler le niveau d'API 36 ou une version ultérieure (Aide Play Console). Où regarder, avec des valeurs par défaut vérifiées le 8 novembre 2026 :

• Flutter : targetSdk dans android/app/build.gradle(.kts). S'il indique flutter.targetSdkVersion, Flutter 3.47 stable le fixe à 36 (code source Flutter). Un nombre écrit en dur reste ce qu'il est.
• Expo : c'est la version du SDK qui décide. Les SDK 56, 57 et 58 ciblent 36 (doc Expo).
• Capacitor : la version 8.x pour 36.

Les projets générés peuvent partir d'un modèle plus ancien que celui de la version actuelle de l'outil. Vérifiez le nombre, ne le supposez pas.

Étape 3 : huit vérifications pour une app générée

1. Un nom de package provisoire. Les modèles démarrent avec des valeurs provisoires ; celui de Flutter est livré avec com.example.[project] (doc Flutter). Google fixe le nom du package dès que vous importez un bundle (Aide Play Console), et créer l'app dans la Play Console l'associe à votre compte pour la vérification des développeurs (Android Developers). Renommez-le avant le premier envoi.

2. Une clé de signature que vous n'avez jamais vue. Certains outils et services de build dans le cloud génèrent le keystore pour vous ; EAS, par exemple, peut le générer et le stocker sur les serveurs d'Expo (doc Expo). Téléchargez-le et sauvegardez-le. La FAQ de Google sur la vérification des développeurs précise que si vous perdez votre clé de signature, vous ne pourrez pas enregistrer vos packages (FAQ Android Developers).

3. Une fiche Play Store qui promet plus que ce que fait l'app. Si vous avez laissé l'IA écrire la description, relisez-la en regard de l'app réelle. Google indique que si une fonctionnalité décrite dans la fiche n'est pas dans l'app, l'app peut être refusée (Aide Play Console).

4. Des boutons morts et des écrans vides. Une app générée peut avoir l'air finie avant que chaque parcours fonctionne. Google vous demande de vous assurer que l'app ne présente pas « de fonctionnalités défectueuses, de plantages ni d'écrans manquants » avant de faire la demande, et rappelle que l'examen « n'est pas une étape de dépannage » (Aide Play Console). Touchez chaque écran sur un vrai téléphone, avec un build release.

5. Des autorisations dont personne n'a besoin. Lisez le manifeste final et retirez ce que l'app n'utilise pas. Les autorisations à haut risque, comme les SMS ou le journal d'appels, déclenchent un formulaire de déclaration, et Google les évalue aussi sur les canaux de test (Aide Play Console).

6. Pas de règles de confidentialité. Google indique que vous devez ajouter un lien vers vos règles de confidentialité sur votre fiche Play Store et dans votre app, même si l'app n'accède à aucune donnée sensible ou à caractère personnel. Elles doivent être sur une page web publique avec un certificat SSL valide, pas dans un PDF (Aide Play Console).

7. Un écran de connexion. Si l'app exige un compte, donnez aux examinateurs de Google des identifiants qui fonctionnent dans Accès aux applications, et donnez aussi un compte à vos testeurs (Aide Play Console).

8. Des secrets dans le bundle. Tout ce qui se trouve dans un AAB peut être extrait. Gardez les clés d'API privées sur un serveur, pas dans l'app.

Étape 4 : menez le test fermé comme s'il comptait

Importez l'AAB dans Tester et publier > Tests > Tests fermés, ajoutez les testeurs, publiez et partagez le lien d'inscription (opt-in).

Ensuite, servez-vous des 14 jours. Le formulaire de Google demande si les testeurs ont utilisé toutes les fonctionnalités, quels retours vous avez reçus et ce que vous avez modifié en conséquence (Aide Play Console). Un outil d'IA permet de publier des correctifs vite. C'est un avantage ici : deux ou trois vraies mises à jour pendant le test vous donnent des réponses concrètes.

Combien de temps ça prend

• Export, encapsulation (pour les web apps), signature et correction du SDK cible : une journée pour une première fois.
• Premier examen de Google : jusqu'à sept jours, voire plus dans des cas exceptionnels, pour certains nouveaux comptes (Aide Play Console). Ensuite, le lien d'inscription peut mettre plusieurs heures à fonctionner.
• Le test : 14 jours sans interruption. Examen de l'accès production : généralement une semaine ou moins (Aide Play Console).

Prévoyez trois à quatre semaines entre votre premier envoi en test fermé et une publication publique.