erberkk/review-readiness

Préparation à l'examen (Review readiness)

Objectif

Soumettre une seule fois et passer. La plupart des rejets ne concernent pas l'idée de l'application ; ils sont dus à un examinateur qui n'a pas pu se connecter, acheter, a vu un espace réservé, ou a trouvé une contradiction entre les métadonnées et l'application.

Prérequis

• La version exacte à soumettre est sur TestFlight / une piste de test Play.
• Le point de contrôle subscriptions-and-payments est réussi (un achat réel a débloqué le premium sur les deux plateformes).
• privacy-and-declarations terminé ; le validateur listing-and-aso est propre ; les captures d'écran sont téléchargées.

Pensez comme un examinateur sans connaissance préalable

Supposons que l'examinateur installe une version propre sur un appareil que vous n'avez pas testé (une application iPhone uniquement peut être examinée sur un iPad en mode de compatibilité), avec un compte store frais, et dispose de peu de temps. Il lit vos notes, essaie la connexion, cherche l'achat et compare les captures d'écran avec l'application. Un seul rejet peut combiner plusieurs couches : état du compte, comportement du backend et métadonnées.

Procédure

1. Compte de démonstration

• Les identifiants sont placés dans App Store Connect › App Review Information ("Connexion requise") et Play › Contenu de l'application › Accès à l'application. Jamais dans le dépôt.
• Le compte se connecte avec email + mot de passe. Si votre méthode de connexion habituelle est un code email unique ou un lien magique, l'examinateur ne peut pas le recevoir. Ajoutez un chemin de mot de passe pour l'adresse de révision uniquement (liste blanche côté serveur) ou un code de test fixe qui ne fonctionne que pour cette adresse.
• Rempli de données : profil complet, quelques jours d'historique, chaque écran principal peuplé. Un compte vide cache des fonctionnalités et invite à dire "nous n'avons pas pu localiser la fonctionnalité X".
• Premium débloqué via un droit manuel côté serveur (sans expiration pendant l'examen), afin que les examinateurs voient les fonctionnalités payantes sans acheter.
• Séparément, assurez-vous qu'un nouvel utilisateur peut atteindre le paywall et acheter avec le compte sandbox de l'examinateur (il testera également l'achat).
• Ne modifiez pas, ne supprimez pas et ne réensemencez pas ce compte pendant qu'un examen est en cours.

2. Achats (2.1(b) et 3.1.x)

• Les abonnements de première version sont attachés à la version dans App Store Connect (section "Achats intégrés et abonnements") et ont une capture d'écran d'examen et des notes. Dans l'interface plus récente d'App Store Connect, il n'y a peut-être pas de telle section sur la page de version : ouvrez le groupe d'abonnement et chaque abonnement et utilisez Ajouter pour examen → Projet de soumission ; la version elle-même est ajoutée depuis sa propre page. Le projet doit lister la version, le groupe et chaque abonnement avant d'appuyer sur Soumettre pour examen.
• Chaque abonnement nécessite au moins une localisation de nom d'affichage + description et une capture d'écran d'examen ; sans cela, "Ajouter pour examen" échoue ("Vous devez ajouter au moins une localisation d'abonnement / une capture d'écran des informations d'examen").
• La capture d'écran d'examen doit montrer le vrai paywall avec de vrais prix et la formulation correcte du store. Si vous la générez à partir d'un widget/test UI, forcez la plateforme iOS (sinon elle affichera "Google Play") et saisissez des prix de store réalistes ; un état "prix indisponibles" n'est pas acceptable.
• La chaîne de version de l'App Store doit correspondre à la version de marketing des builds (CFBundleShortVersionString). Une version nommée 1.0 n'offrira pas les builds téléchargés en tant que 1.0.0 ; la section Build indique juste "Télécharger vos builds" sans bouton Ajouter un build. Renommez la version pour qu'elle corresponde.
• Sur TestFlight avec un nouveau compte Apple sandbox (non lié à aucun de vos comptes d'application) : les produits se chargent, l'achat fonctionne, la restauration fonctionne.
• L'état d'erreur du paywall doit montrer une option de réessai, jamais un "À venir" désactivé.
• Si un achat intégré ne peut pas être atteint dans l'application (par exemple uniquement pour une région), expliquez pourquoi dans les notes de révision.
• Les liens "Restaurer les achats", "Conditions générales", "Confidentialité" et "Gérer l'abonnement" doivent être présents.

3. Appareils et builds

• Démarrage à froid sans réseau, réseau lent, et mode avion activé : pas de crash, pas de spinner infini.
• iPad : même une application iPhone uniquement fonctionne sur iPad en mode compatibilité et peut y être examinée. Exécutez le flux complet sur un simulateur iPad : connexion (y compris Connexion avec Apple), défilement du paywall, feuille d'achat, clavier sur les formulaires, invites de permission, rotation. Si HealthKit ou une autre API n'est pas disponible, affichez un message poli, pas un crash.
• Téléphone le plus petit supporté et taille de texte la plus grande : pas de boutons tronqués sur le paywall ou les écrans de consentement.
• Build de version, pas de débogage : pas de bannière de débogage, pas de menus de test, analytique/rapport de crash en configuration de production.
• Parcourez le cycle de vie complet du compte sur un appareil physique avec la version exacte que vous soumettez : installation, inscription, fonctionnalités principales, achat sandbox, suppression de compte, et ce que l'application affiche après la suppression.

4. Contenu et métadonnées

• Recherchez dans les chaînes et listes de l'application : TODO, lorem, à venir, beta, test, [PRIX], images d'espace réservé. Aucun ne doit être rendu.
• Le build iOS et les métadonnées ne contiennent aucune formulation Android / Google Play ; Play ne contient aucune formulation propre à Apple (2.3.10). Inclut les chaînes dans l'application comme "Annuler dans l'App Store ou Google Play" — choisissez le texte de la plateforme au moment de l'exécution.
• Chaque capture d'écran correspond à l'interface actuelle ; chaque chiffre dans la description correspond à l'application.
• Les URL de politique de confidentialité, conditions générales, support et suppression de compte se chargent sans connexion, mentionnent l'application et correspondent aux formulaires de confidentialité.
• Classification par âge cohérente avec les conditions générales.

5. Backend

• Le backend est opérationnel et sur un plan qui n'atteindra pas les limites pendant l'examen (les niveaux gratuits qui se mettent en pause ou limitent le débit = rejet).
• Pas de déploiement de changements cassants pendant l'examen. API rétrocompatible pour le build en cours d'examen.
• Des alertes sont en place (post-launch-ops) pour détecter une panne pendant l'examen.

6. Notes de révision

Remplissez templates/review-notes.md. Restez factuel : où se trouvent les fonctionnalités, comment se connecter, comment tester l'achat, comment les données AI et de santé sont traitées, où se trouve la suppression de compte.

Apple peut répondre avec Directive 2.1 "Informations requises" au lieu d'examiner. Dans un cas observé, il a demandé les six éléments ci-dessous ; y répondre dès la première soumission évite un aller-retour :

1. Un enregistrement d'écran à partir d'un appareil physique avec le dernier OS, commençant au lancement de l'application et montrant le flux typique : inscription, connexion, suppression de compte, tout contenu généré par l'utilisateur avec signalement/blocage, et accès au contenu payant. Enregistrez-le avec le build soumis ; joignez le fichier à la réponse dans les Messages de la soumission (ou liez-le) et mentionnez-le dans les Notes. N'utilisez jamais le compte de démonstration pour la partie suppression : créez un compte frais dans l'enregistrement.
2. Le but et le public cible de l'application : le problème qu'elle résout et sa valeur.
3. Les instructions de configuration et d'accès pour les fonctionnalités principales, avec les identifiants de démonstration et les chemins de menu.
4. Chaque service externe derrière les fonctionnalités principales : auth/base de données, paiements (StoreKit + tout wrapper), fournisseurs AI, sources de données (par exemple API cartographiques), email, frameworks de santé.
5. Les différences régionales, ou une déclaration selon laquelle les fonctionnalités sont identiques partout.
6. Pour les zones réglementées ou le contenu protégé par des tiers : documentation ou déclaration qu'aucun ne s'applique (par exemple "bien-être général, pas un dispositif médical").

7. Rapport go/no-go

Remplissez templates/go-no-go-report.md avec des preuves pour chaque ligne (capture d'écran, numéro de build, sortie de commande). Tout Non sur une ligne bloquante signifie pas de soumission.

8. Soumettre (APPROBATION)

Demandez une approbation explicite au titulaire du compte avec le rapport joint. Sur iOS, choisissez publication manuelle pour que l'approbation ne publie pas immédiatement. Sur Play, l'accès à la production (nouveaux comptes personnels) nécessite d'abord le test fermé de 14 jours et la demande d'accès à la production.

Après un rejet

Consultez references/rejection-playbook.md : lisez la directive exacte, reproduisez, corrigez la cause racine (souvent plus d'une couche), répondez dans le Centre de résolution avec des détails, resoumettez ; faites appel uniquement lorsque l'examinateur a mal interprété un fait que vous pouvez prouver.

Points de décision nécessitant une approbation humaine

Soumettre, choisir la méthode de publication, répondre à un rejet (ton et engagements), déposer un appel, accorder le premium au compte d'examen.

Vérification

Le rapport go/no-go est complet avec des preuves, et une personne qui n'a pas construit la fonctionnalité a parcouru les notes de révision sur un appareil propre et a réussi.

Pièges courants

• Le compte de démonstration dépend d'un code email que l'examinateur ne peut pas lire.
• Le compte de démonstration est vide, gelé ou supprimé par un travail de nettoyage.
• Produits dans "Métadonnées manquantes" (pas de capture d'écran d'examen), donc ils ne se chargent jamais lors de l'examen.
• Supprimer une version de l'examen ("Rejetée par le développeur") supprime également les abonnements du projet ; réajoutez le groupe et chaque abonnement avant de resoumettre, sinon la version part seule.
• Les ressources de la page produit sont verrouillées pendant que la version est "En attente d'examen" (par exemple le nouvel en-tête). Ajoutez tout avant de soumettre ; sinon, vous devez retirer la version de l'examen, modifier, et resoumettre (vous perdez votre place dans la file d'attente).
• Le contrôle "Ajouter pour examen" d'Apple réussit, mais cela ne signifie pas que les ressources optionnelles sont définies : un en-tête vide est autorisé, donc décidez avant de soumettre.
• Le nouveau compte Apple de l'examinateur entre en conflit avec vos règles de restauration/transfert et l'achat "échoue".
• Backend sur un plan qui se met en pause après inactivité ou limite le débit de l'examinateur.
• "À venir" n'importe où dans le build.
• Texte dans l'application mentionnant l'autre store.
• Notes de révision qui n'expliquent que la connexion de démonstration (pas d'enregistrement, de but, de services ou de régions).