Alexgub84/store-publishing

Que fait store-publishing ?

Cette procédure a été testée pour la dernière fois contre la vraie Google Play Console et App Store Connect le 2026-11-08. Les deux consoles changent leurs écrans, noms de champs et navigation sans préavis – si une étape ci-dessous ne correspond pas à ce que vous voyez, ouvrez un problème dans ce dépôt plutôt que de deviner, et envoyez une PR avec la correction si vous en trouvez une.

0. Décidez sur quel chemin vous êtes

Situation	Aller à
L'application n'a jamais été soumise, aucun enregistrement dans l'une ou l'autre console	§1, puis §2, §3, §4
L'application est déjà listée, une nouvelle build doit être expédiée	§5 (le chemin des mises à jour répétées)
Question de compte (individuel vs organisation, transfert, nom de paquet)	§6
Le relecteur ne peut pas se connecter, ou l'application a été rejetée	§7

Règle qui s'applique partout : chaque upload nécessite des notes de version dans chaque langue de la fiche dans laquelle il est expédié. Ne laissez jamais une boîte « Nouveautés » vide – une boîte vide est perçue comme une build non testée par un relecteur.

1. Liste de contrôle de première configuration (les deux magasins)

Faites-les dans l'ordre ; chacune débloque la suivante.

1. Les comptes développeur existent et sont vérifiés. L'application doit être publiée depuis le compte qui possède réellement le produit – l'éditeur officiel, pas un compte partagé ou d'agence utilisé pour des applications non liées. Apple en particulier rejette les applications qui semblent provenir d'un modèle commercialisé ou d'un service de génération d'applications lorsqu'elles sont soumises sous un compte qui détient de nombreux produits non liés, et séparément (directive 5.2.1) attend que le propriétaire de la PI soit celui qui soumet. Voir §6 pour la décision individuel-vs-organisation.
2. Les pages légales sont sur le domaine de production : une politique de confidentialité, des conditions d'utilisation, et une page de suppression de compte si l'application permet l'inscription. Les deux magasins demandent ces URL ; le formulaire de sécurité des données de Google lie directement la page de suppression. Obtenez l'approbation du texte légal par le propriétaire du produit avant de l'utiliser dans une soumission – c'est une décision commerciale, pas technique.
3. Une véritable icône d'application, pas un défaut du framework – les deux magasins rejettent ou signalent une icône par défaut non modifiée comme étant de faible qualité. Ressources nécessaires : l'icône adaptive/de premier plan dans le binaire, une icône Play 512×512, un graphique de fonctionnalité Play 1024×500, et une icône Apple 1024×1024 dans le catalogue d'actifs (pas de transparence – Apple l'aplatit, généralement en noir).
4. Un compte de démonstration pour la révision, si l'application nécessite une connexion. Il nécessite : un identifiant fixe (téléphone, email ou nom d'utilisateur) avec un code unique fixe ou un mot de passe honoré uniquement pour cet identifiant, un état de démonstration pré-rempli que le relecteur peut réellement exercer, et aucun effet de bord sortant (pas de vrai SMS, pas de vrai paiement). Stockez l'identifiant ailleurs que dans les pages de la console – jamais sous forme de texte brut collé dans les notes de révision de l'application où il deviendrait un enregistrement permanent et largement lisible. Vérifiez que la connexion fonctionne avec la build exacte soumise, à chaque fois, juste avant de soumettre.
5. Un inventaire des données : un document (dans le dépôt, dans un wiki, là où l'équipe garde les specs) listant chaque type de données collectées par l'application, pourquoi, et via quel SDK. Les formulaires de sécurité des données de Google et de confidentialité d'Apple sont remplis À PARTIR de ce document, jamais de mémoire – et chaque fois que l'application obtient une nouvelle autorisation ou un nouveau SDK d'analyse/diagnostic, l'inventaire change dans le même changement qui ajoute l'autorisation, et les deux formulaires sont refaits avant la soumission suivante. Un décalage entre ce que disent les formulaires et ce que fait réellement le binaire est une raison de rejet courante et évitable.
6. Google Play — Créer l'application, puis parcourez « Configurer votre application » de haut en bas : URL de la politique de confidentialité, accès à l'application (public ou restreint avec le compte de révision et les instructions), déclaration de publicité, questionnaire de classification du contenu (répondu honnêtement en fonction du comportement réel de l'application), public cible et âge, déclaration d'applications gouvernementales, déclaration de fonctionnalités financières, déclaration de santé, sécurité des données (à partir de l'inventaire), déclaration d'ID publicitaire. Acceptez la signature Play (Play App Signing) pour que Google détienne la clé de signature de l'application et que la clé d'upload reste remplaçable. Remplissez la fiche principale du magasin (nom, descriptions, icône, graphique de fonctionnalité, au moins 2 captures d'écran de téléphone). Créez ensuite une piste de test fermé et une version avant de toucher à la production.
7. Apple — enregistrez l'App ID explicite, créez l'enregistrement de l'application dans App Store Connect (nom, SKU, langue principale), remplissez les informations de l'application (catégorie, droits de contenu, classification d'âge), confidentialité de l'application (à partir de l'inventaire), tarification et disponibilité, la page de version (captures d'écran, description, mots-clés ≤100 caractères, URL de support, droits d'auteur), informations de révision de l'application (instructions de connexion si nécessaire, contact de révision, notes), et choisissez une option de publication (la publication manuelle est la valeur par défaut la plus sûre – elle place la décision de « mise en ligne » dans un clic séparé et délibéré après l'approbation). Pour les builds TestFlight, répondez à la question de conformité d'exportation à chaque fois, ou ajoutez ITSAppUsesNonExemptEncryption=false à Info.plist une fois si cela est vrai, pour arrêter la question récurrente.
8. Soumettez les deux tôt. La révision prend des heures à jours sur chaque magasin, et la première révision est généralement là où les vrais problèmes apparaissent – prévoyez au moins un rejet et une resoumission, surtout chez Apple.

2. Construction du paquet de publication

Quel que soit l'outillage — Flutter, React Native, Expo, ou un projet natif Swift/Kotlin — construisez à partir d'un checkout propre du commit exact en cours de publication, jamais d'un répertoire de travail avec des modifications non validées. Des modifications non validées s'infiltrant dans un binaire de magasin sont très difficiles à remarquer après coup.

• Android : produisez un AAB signé de publication (jamais un APK pour un upload de magasin), avec un numéro de build (versionCode ou équivalent) strictement supérieur au dernier expédié. Vérifiez que le nom de paquet intégré dans le bundle correspond à celui que le compte Play cible possède avant de télécharger – un nom de paquet non correspondant échoue à l'étape de téléchargement.
• iOS : archivez et exportez (ou téléchargez directement sur App Store Connect depuis l'étape d'archivage), signé sous la bonne adhésion au programme développeur Apple (l'« équipe » à laquelle appartiennent les certificats de l'application et l'enregistrement de l'application), avec un numéro de build strictement supérieur au dernier expédié, et l'identifiant de bundle exact avec lequel l'enregistrement d'App Store Connect a été créé. La signature automatique sous la bonne équipe évite la plupart des problèmes de certificats.
• Les deux : pointez la build vers l'API/backend de production, pas un environnement de staging ou local – vérifiez que cela est réellement intégré dans le binaire, pas seulement passé comme un indicateur de build qui pourrait silencieusement tomber sur une valeur par défaut. Gardez iOS et Android sur le même numéro de build/version lorsque le produit a une chaîne de version partagée, afin qu'une conversation de support sur « version 2.3 » signifie la même chose sur les deux plateformes.

3. Captures d'écran

Captures réelles uniquement – la directive 2.3.3 d'Apple rejette explicitement les maquettes et composites marketing présentés comme captures d'écran. Le modèle fiable est un test UI automatisé qui exécute l'application réelle, se connecte avec le compte de révision contre un backend réel (pas simulé), navigue vers chaque écran, et capture l'image – jamais une photo de téléphone tenue à la main d'un simulateur.

Tailles d'appareils typiques à couvrir (vérifiez les exigences actuelles du magasin avant de vous fier à celles-ci, elles bougent) : un grand iPhone moderne (exigence « la plus grande » actuelle d'Apple), un iPad si l'application supporte iPad, et un téléphone et/ou une tablette Android représentatifs pour Play. Apple dérive les tailles d'iPhone plus petites automatiquement à partir du plus grand ensemble dans la plupart des cas.

Choisissez un petit ensemble (5 à 8 images) qui raconte l'histoire du produit dans l'ordre : une vue liste ou d'accueil, un écran structurel principal, une vue unité/détail unique, le flux de travail principal en cours, un état terminé/réussi, et les paramètres si pertinent. Sautez les écrans de connexion nus et les états vides – ils ne disent rien sur ce que fait l'application.

Pièges connus, indépendants de l'outillage :

• Une build de débogage affiche souvent un ruban ou un filigrane de débogage visible – désactivez-le avant de capturer.
• Une session de simulateur ou d'émulateur peut conserver une connexion précédente lors de réinstallations ; déconnectez-vous explicitement dans le test, ou effacez d'abord l'état du simulateur/émulateur.
• Re-naviguer vers le « même » écran avec des paramètres différents ne réaffiche parfois pas correctement un écran avec état ; naviguez à travers un écran parent entre les captures.
• L'exécution de deux sessions de capture à partir du même répertoire de projet a tendance à entrer en conflit sur les artefacts de build générés ; utilisez des copies de travail séparées si vous exécutez en parallèle.

4. Flux de mise à jour (application déjà listée)

Voir §5 pour la liste de contrôle dédiée aux publications répétées. La version courte : une nouvelle build reçoit un numéro de build strictement supérieur au dernier expédié, la différence d'inventaire des données depuis la dernière publication décide si les formulaires de confidentialité doivent être mis à jour, les notes de version ne sont jamais sautées, et le compte de démonstration de révision est revérifié sur l'environnement exact que le nouveau binaire cible avant chaque soumission.

5. Le chemin des mises à jour répétées — une publication lorsque l'application est déjà en ligne

Une publication = un passage à travers cette liste, de haut en bas.

Préconditions (arrêtez si l'une d'elles échoue)

• Le code expédié est réellement déployé en production, avec toutes les migrations de base de données déjà appliquées – un déploiement et une migration ne sont pas la même étape, et déployer avant de migrer (ou ne pas migrer du tout) produit une build qui parle à un backend qui n'est pas prêt pour elle.
• Le compte de démonstration de révision se connecte à la production et atteint l'état de démonstration qu'un relecteur aurait besoin de voir.
• La différence d'inventaire des données depuis la dernière build expédiée est vérifiée. Toute nouvelle ligne signifie que les formulaires de confidentialité changent AVANT de soumettre, pas après qu'un rejet le signale.
• Le créneau de version d'Apple est libre. Si une version précédente est en statut « En attente de publication développeur » ou encore en révision, App Store Connect ne vous permettra pas de créer la ligne de version suivante. Publiez ou annulez d'abord la version en attente – il n'y a pas d'option « gardez celle-ci, soumettez la build plus récente à la place ».
• La chaîne de version et le numéro de build sont décidés : numéro de build = dernier expédié + 1 sur chaque plateforme ; la chaîne de version n'est incrémentée que pour un changement qu'un utilisateur remarquerait réellement.

Notes de version

Rédigez-les à partir de ce qui a réellement été expédié (les changements fusionnés depuis la dernière publication), uniquement les éléments visibles par l'utilisateur, environ 4 à 8 points, dans chaque langue que la fiche supporte – vérifiez ce que la fiche a réellement avant de supposer qu'elle a besoin de plusieurs langues ; une fiche avec une seule langue configurée rejettera un champ de notes de version pour une langue qu'elle n'a pas. Chez Apple, ajouter une toute nouvelle langue à une fiche est un projet en soi (nom, sous-titre, description, mots-clés, et son propre ensemble de captures d'écran) – ne supposez jamais que c'est juste un changement de champ de texte.

Captures d'écran

Ne les refaites que si les écrans ont réellement changé d'une manière qu'un acheteur remarquerait. Sinon, laissez l'ensemble existant tranquille. Si vous remplacez, remplacez l'ensemble complet dans le même ordre qu'avant plutôt que d'ajouter – la plupart des consoles limitent le nombre de captures d'écran par fiche, donc un remplacement partiel risque d'atteindre cette limite.

Consoles

Google Play : si l'inventaire a changé, mettez d'abord à jour le formulaire de sécurité des données. Ensuite : la piste de test ou de production pertinente → créer une nouvelle version → télécharger l'AAB → notes de version dans chaque langue configurée → réviser la version → lancer le déploiement (traitez « lancer le déploiement » comme une action délibérée et confirmée – c'est le seul clic irréversible dans le flux Play). Un déploiement en production peut être étagé par pourcentage et mis en pause si quelque chose semble anormal après quelques pour cent.

Apple App Store Connect : attachez la nouvelle build à TestFlight d'abord (conformité d'exportation, « quoi tester »), puis soit modifiez la page de version existante (si la chaîne de version n'a pas changé et que la version précédente n'est pas encore publiée), soit créez une nouvelle version (possible uniquement lorsqu'aucune version n'est actuellement en statut « Préparer pour soumission » – voir la précondition ci-dessus). Revérifiez que les informations de révision de l'application sont toujours exactes, revérifiez la confidentialité de l'application si l'inventaire a changé, sélectionnez la nouvelle build, remplissez « Nouveautés », et soumettez pour révision. Traitez « soumettre pour révision » de la même manière que le clic de déploiement de Play – une action délibérée et confirmée, pas quelque chose à déclencher automatiquement.

Tenue de registres

Quelle que soit la tenue de registres que l'équipe a déjà pour les publications (un journal des modifications, un problème de publication, une feuille de calcul) elle devrait inclure : les numéros de version et de build expédiés, les heures de téléchargement, quelle piste/étape, qui a confirmé le déploiement ou la soumission, et le résultat de la révision une fois connu. Mettez à jour le fichier de version du projet pour correspondre à ce qui a réellement été expédié – un décalage ici est exactement la façon dont la prochaine publication réutilise accidentellement un numéro de build.

Ne laissez jamais une version préparée en attente

Une version en statut « Préparer pour soumission » sur App Store Connect occupe le seul créneau de version disponible – aucune nouvelle version ne peut être créée en dessous. Donc : décidez du sort d'une version préparée dans la même session où elle est préparée. Soit soumettez-la, soit ne créez pas encore la ligne.

Si une build plus récente est prête alors qu'une version préparée plus ancienne est toujours en attente, ne supprimez pas la ligne en attente et ne soumettez pas la build obsolète juste pour libérer le créneau. Pendant qu'une version est en statut « Préparer pour soumission », sa chaîne de version est toujours un champ modifiable – faites-la avancer sur place : changez la chaîne de version pour la nouvelle, attachez la nouvelle build, remplacez « Nouveautés ». Les captures d'écran, notes de révision et réponses de confidentialité sont reportées, donc rien de préparé n'est perdu.

Une build de test (TestFlight) et une soumission publique sont des décisions indépendantes – la piste de test interne de TestFlight en particulier n'a besoin d'aucune révision et d'aucune ligne de version du tout, donc « les testeurs ont besoin d'une build aujourd'hui » n'est jamais une raison pour qu'une soumission publique doive attendre, et une soumission publique en attente n'est jamais une raison pour que les testeurs attendent non plus.

6. Comptes, transferts, noms de paquet

• Un compte développeur Google Play personnel créé après la date limite de la politique (13 novembre 2023 au moment de la rédaction – vérifiez la politique en vigueur) doit effectuer un test fermé avec un minimum de ...

[... tronqué pour la traduction]