Checklist publication App Store Google Play

Réponse courte

Avant de publier une app mobile en 2026, il faut préparer les comptes développeur, les builds, les fiches store, les captures, la politique de confidentialité et les déclarations de données. La review Apple bloque souvent sur la qualité, les données, les permissions ou les écrans incomplets. Google Play demande aussi une fiche claire, une déclaration Data Safety et une version testable.

Publier ne commence pas après le développement

La publication store ne doit pas être traitée comme une formalité. C'est une phase produit à part entière. Elle demande du contenu, des preuves, des accès et des décisions.

Une app peut être techniquement prête et bloquée pendant plusieurs jours parce que le compte Apple n'est pas validé. Une autre peut échouer parce que la politique de confidentialité ne correspond pas aux données déclarées.

Chez Inyka, la publication est prévue dès le cadrage pour les projets Launch et Scale. Le but est simple : éviter que la livraison se termine sur une file d'attente administrative.

Comptes développeur à préparer

Le client doit posséder ses comptes développeur. C'est plus propre pour la propriété de l'app, les paiements, les accès et les mises à jour futures.

Pour Apple, il faut un compte Apple Developer Program. Pour Google, il faut un compte Play Console. Ces comptes demandent une identité claire, parfois des vérifications supplémentaires, et des délais variables.

Le point à ne pas rater : utilisez une adresse email durable. Pas l'adresse personnelle d'un stagiaire, pas un compte Gmail créé trop vite. Le compte store deviendra un actif de l'entreprise.

Assets nécessaires avant soumission

Une publication mobile demande plusieurs éléments visuels et textuels. Il faut les préparer avant le build final.

La checklist minimale :

nom de l'application ;
icône en haute qualité ;
captures d'écran iPhone et Android ;
description courte et description longue ;
catégorie ;
mots-clés côté Apple ;
email support ;
URL de politique de confidentialité ;
compte de démo si l'app demande une connexion.

Les captures d'écran ne doivent pas mentir. Montrer une fonctionnalité absente est une bonne manière de créer un refus ou des utilisateurs déçus.

Déclarations de données et confidentialité

Apple demande des informations sur les pratiques de confidentialité dans App Store Connect. Google Play demande une section Data Safety dans Play Console.

Il faut savoir quelles données sont collectées, pourquoi, si elles sont liées à l'utilisateur, si elles sont partagées, et comment elles sont protégées. Les SDK tiers comptent aussi. Analytics, crash reporting, paiement, support, notifications : chaque outil peut modifier la déclaration.

Ce travail doit être cohérent avec la politique de confidentialité. Une app qui déclare peu de collecte mais utilise plusieurs SDK indiscrets crée un risque inutile.

Inyka privilégie les stacks simples pour limiter cette charge. Moins il y a d'outils externes, plus la déclaration est lisible.

Tests avant envoi en review

Avant soumission, l'app doit être testée sur de vrais appareils. Le simulateur ne suffit pas.

Il faut vérifier la connexion, la création de compte, la récupération de mot de passe, les permissions, les écrans vides, les erreurs réseau, les notifications et les parcours payants. Il faut aussi tester l'app avec un compte neuf, pas seulement avec le compte du développeur.

Apple refuse les apps qui semblent incomplètes, instables ou inutilisables. Google Play a aussi renforcé les contrôles autour de la sécurité, des permissions et des déclarations.

Une app MVP peut être petite. Elle ne doit pas paraître cassée.

Pièges fréquents côté Apple

Apple regarde beaucoup la qualité perçue. Une app avec boutons morts, contenu placeholder ou parcours bloqué sera refusée.

Les permissions doivent être justifiées. Demander la localisation, la caméra ou les contacts sans usage évident crée un signal mauvais. Les textes de permission doivent être clairs pour l'utilisateur.

Les apps avec comptes doivent fournir un accès de démo si le reviewer ne peut pas créer de compte facilement. Sinon, la review peut bloquer sur une demande d'identifiants.

Les fonctionnalités payantes doivent respecter les règles Apple. Ce sujet doit être cadré avant développement, surtout pour les abonnements ou achats numériques.

Spécificités Android

Google Play demande une fiche complète, une politique de confidentialité et une déclaration Data Safety. Les permissions sensibles doivent être justifiées. Les tests internes ou fermés peuvent aussi être utiles avant la mise en production.

Android ajoute souvent une contrainte de compatibilité appareils. Il faut tester sur différentes tailles d'écran, pas seulement sur un téléphone récent.

Les builds doivent être propres, signés et versionnés. Expo EAS Build aide à produire des builds prêts pour les stores, mais la configuration doit rester sérieuse.

Planning de soumission

Pour une première publication, je conseille de prévoir plusieurs jours de marge. Même quand l'app est prête, les stores peuvent demander des corrections.

Un planning propre ressemble à ceci : préparation des comptes avant développement, rédaction des fiches pendant la QA, build final, test interne, soumission, correction éventuelle, validation, puis mise en ligne.

La page prix application mobile détaille les offres Inyka qui incluent une app publiable dans le format Launch.

Sources

Questions fréquentes

Combien de temps prend une review Apple ?

Le délai varie selon le contexte et les demandes de correction. Il faut prévoir une marge, surtout pour une première publication.

Faut-il une politique de confidentialité ?

Oui, dès que l'app collecte des données ou utilise des services tiers. En pratique, il vaut mieux en prévoir une pour presque toute app publiée.

Qui doit posséder les comptes développeur ?

Le client doit les posséder. Le prestataire peut aider à publier, mais le compte doit rester contrôlé par l'entreprise propriétaire de l'app.

Peut-on publier un MVP sur les stores ?

Oui, si le MVP est fonctionnel, stable et honnête dans sa présentation. Un MVP n'est pas une excuse pour publier une app cassée.