Publier sur l'App Store et Google Play : la checklist complète 2026

Construire l'application, tout le monde le prévoit. La publier, c'est la partie qui surprend, parce que c'est surtout du travail administratif avec des règles strictes et des boucles de retour asynchrones. Un refus que vous auriez pu éviter en dix minutes vous coûte une semaine de calendrier. Ce guide déroule les deux stores dans l'ordre où vous en avez réellement besoin : comptes, visuels, déclarations, soumission, validation, puis ce qu'il faut faire le lendemain du lancement.

Avant tout : les deux comptes

Les deux stores exigent un compte développeur payant, et les deux mettent du temps à s'activer. Lancez cette étape avant que l'application soit finie, pas après.

Une décision à prendre tôt : inscrivez-vous au nom de votre société, pas au vôtre. Transférer une application d'un compte à un autre est possible mais fastidieux, et un nom de personne physique affiché publiquement sur votre fiche fait amateur auprès d'une clientèle professionnelle.

Les éléments qu'on va vous demander

Les deux stores réclament à peu près les mêmes matériaux, avec des tailles différentes et une tolérance différente à l'approximation. Préparez tout d'un coup plutôt que de découvrir chaque exigence en cours de soumission.

• L'icône. Un carré haute résolution, sans transparence et sans coins arrondis de votre part : les stores appliquent le masque. Évitez le petit texte, illisible à taille réelle.
• Les captures d'écran. Plusieurs tailles d'appareil, dont au moins un grand téléphone. C'est le premier levier du taux d'installation : annotez-les d'un bénéfice court plutôt que de livrer des captures brutes.
• Le titre et le sous-titre. Courts, et indexés par la recherche du store. Mettez le vrai mot-clé que les gens tapent dans le titre, pas une formule de marque astucieuse.
• La description. Seules les deux premières lignes sont réellement lues. Commencez par ce que l'application fait pour l'utilisateur, pas par l'histoire de votre entreprise.
• Le visuel de mise en avant (Google Play). Une bannière large affichée à plusieurs endroits. Éloignez le texte essentiel des bords, qui sont rognés.
• Le questionnaire de classification par âge. Répondez honnêtement. Une incohérence entre vos réponses et votre contenu réel est le moyen le plus sûr d'être retiré après le lancement.

La confidentialité : ce qui fait refuser les applications

Les deux stores exigent désormais un inventaire explicite et structuré des données que vous collectez et de leur finalité. Apple parle d'étiquettes de confidentialité, Google de section Sécurité des données. Ce sont deux formulaires distincts, avec un vocabulaire différent, et les deux doivent correspondre à ce que fait réellement votre application.

• Une URL de politique de confidentialité accessible. Obligatoire des deux côtés, en ligne avant la soumission, et décrivant réellement votre application plutôt qu'un modèle générique.
• Un inventaire de données exact. Listez chaque catégorie collectée, y compris par vos SDK d'analytics ou de rapport de crash. Ce que collectent les bibliothèques tierces pour votre compte vous est imputé.
• La suppression de compte. Si l'utilisateur peut créer un compte dans l'application, vous devez lui offrir un moyen de le supprimer, accessible depuis l'application. C'est l'un des refus tardifs les plus fréquents.
• L'autorisation de suivi sur iOS. Si vous suivez les utilisateurs à travers les applications ou sites d'autres sociétés, vous devez demander l'autorisation via l'invite système. S'en passer entraîne un retrait.

Les canaux de test : ne soumettez jamais directement en production

Les deux stores offrent un circuit de préproduction, gratuit dans les deux cas. Utilisez-le : un bug trouvé par dix testeurs ne coûte rien, le même bug trouvé par un validateur vous coûte un cycle de validation.

• TestFlight (Apple). Distribution quasi immédiate à des testeurs internes, ou à des testeurs externes après une revue allégée. Les builds expirent au bout de 90 jours.
• Tests internes, fermés et ouverts (Google). Le test interne est quasi instantané. Un test fermé sur un petit groupe mérite au moins une semaine avant la production, et les nouveaux comptes développeurs personnels peuvent être obligés d'en mener un.

Quel que soit le canal, testez au minimum sur un petit Android ancien et un iPhone récent. Ces deux appareils couvrent l'essentiel des surprises de mise en page et de performance.

La soumission, étape par étape

• 1. Créer la fiche applicative. Réservez le nom et l'identifiant de bundle ou de package. Cet identifiant est définitif : il ne se change pas après publication, on ne peut que publier une nouvelle application.
• 2. Téléverser un build signé. Apple exige une archive signée envoyée depuis macOS. Google exige un Android App Bundle et une clé de signature à ne jamais perdre : activez Play App Signing pour que Google en conserve une copie.
• 3. Remplir la fiche du store. Titre, description, captures, catégorie, coordonnées et URL de support.
• 4. Compléter les déclarations. Confidentialité, sécurité des données, classification par âge, publicité, conformité à l'export, et le questionnaire sur les permissions si vous en utilisez de sensibles.
• 5. Donner un compte fonctionnel aux validateurs. Si votre application a une connexion, fournissez des identifiants de test et, au besoin, une note courte expliquant comment atteindre la fonctionnalité principale. L'oublier est la première cause de refus inutile.
• 6. Soumettre et choisir la stratégie de sortie. Optez pour une publication manuelle si vous voulez coordonner une date, et utilisez un déploiement progressif sur Google Play pour qu'un build défectueux touche 5 % des utilisateurs plutôt que la totalité.

Les motifs de refus que vous rencontrerez vraiment

Les refus sont normaux, y compris pour des équipes expérimentées. Ils tiennent presque tous en une poignée de catégories.

• Le validateur n'a pas pu se connecter. Identifiants de démonstration absents ou expirés, ou connexion exigeant un code envoyé sur votre téléphone.
• Liens morts ou plantages. Une URL de support inaccessible ou un crash sur la version de l'appareil du validateur. Testez chaque lien de votre fiche avant de soumettre.
• « Fonctionnalités insuffisantes ». Apple refuse les applications qui ne sont qu'un site emballé, sans valeur native. Si vous livrez une WebView, ajoutez de vraies fonctions appareil et un comportement hors ligne.
• Paiements hors store. Vendre du contenu numérique consommé dans l'application impose en général l'achat intégré. Les biens physiques et les services du monde réel, non.
• Déclaration de confidentialité incohérente. Vous déclarez ne rien collecter, mais un SDK d'analytics récupère un identifiant d'appareil.
• Problèmes de métadonnées. Captures qui ne correspondent plus à l'application, noms de concurrents dans la description, ou un texte de remplacement resté en place.

En cas de refus, lisez le numéro exact de la règle citée, corrigez uniquement ce point, et répondez dans le centre de résolution par une explication factuelle et courte. Discuter aide rarement ; une réponse précise, presque toujours.

Après le lancement : les trente premiers jours

Être en ligne est le début du travail, pas la fin. Le premier mois détermine votre classement dans les stores et la rétention de vos premiers utilisateurs.

• Surveillez le taux de crash par appareil. Les deux consoles le remontent. Au-delà d'environ 1 % des sessions, votre classement et vos avis en pâtissent.
• Répondez à chaque avis, vite. Les réponses publiques changent visiblement la lecture d'une fiche, et une plainte résolue se transforme souvent en note relevée.
• Itérez sur la fiche, pas seulement sur l'application. Changer la première capture ou le sous-titre déplace souvent plus le taux d'installation qu'une nouvelle fonctionnalité.
• Publiez une petite mise à jour toutes les quelques semaines. La fraîcheur est un signal de classement, et un rythme régulier rend les délais de validation prévisibles.
• Amenez votre propre trafic. La recherche du store ne vous découvrira pas toute seule. Votre site, votre liste e-mail et vos clients existants sont le vrai canal de lancement.

Ce que Cadrant apporte

Cadrant intervient sur ce qui précède la soumission : mettre une application réelle et fonctionnelle entre les mains d'utilisateurs assez vite pour savoir ce qui mérite d'être publié. Vous décrivez vos écrans, vos données et vos rôles utilisateurs en langage naturel, vous itérez sur une application vivante en quelques heures plutôt qu'en quelques mois, et la base de données reste dans votre propre projet Supabase. Quand le produit a fait ses preuves auprès de vrais utilisateurs, vous abordez le parcours store avec un périmètre stable au lieu de deviner.

L'ordre compte. La plupart des primo-éditeurs soumettent un périmètre que personne n'a testé, puis dépensent leurs cycles de validation à corriger des problèmes de produit plutôt que des problèmes de store.

En résumé

Publier est un projet administratif qui dépend du code. Ouvrez les deux comptes développeurs tôt, préparez icône, captures, description, politique de confidentialité et déclarations de données en une seule passe, faites tourner un vrai canal de test avant la production, et donnez aux validateurs un compte fonctionnel avec des consignes claires. À ce prix, la validation elle-même est généralement la partie facile.