1. Identifier exactement la version testée

Crée une fiche de validation avec la version, le numéro de build, le commit et la date du test. Installe cette version via TestFlight sur un vrai appareil. Le but est de pouvoir répondre à une question simple : les vérifications portent-elles sur le binaire que tu vas sélectionner dans App Store Connect ?

Compare les réglages de production à ceux attendus : serveur utilisé, fonctionnalités activées et contenu disponible. Une démonstration réalisée avec un serveur local ou des données déjà préparées ne suffit pas à valider une première installation.

  • Version et build notés dans la fiche de validation.
  • Installation propre testée avec des données neuves.
  • Services nécessaires accessibles hors du réseau de développement.
  • Aucun écran de débogage ou contenu de démonstration présenté comme réel.

2. Vérifier le parcours complet et ses interruptions

Confie la tâche principale à une personne qui ne connaît pas ton interface. Observe ce qu’elle fait sans lui indiquer les boutons. Puis recommence en retirant une condition : permission refusée, absence de réseau, formulaire incomplet ou session expirée.

Pour chaque échec, vérifie trois choses : le message est compréhensible, les données restent dans un état cohérent et une reprise est possible. Si l’application stocke un brouillon, ferme-la puis rouvre-la pour vérifier ce qui a réellement été conservé.

  • Action centrale réalisable sans explication orale.
  • Chargement, absence de données et erreurs traités.
  • Retour après interruption testé.
  • Texte lisible et commandes accessibles sur les tailles d’écran ciblées.

3. Comparer la fiche App Store au build

Relis le titre et la description en gardant l’application ouverte. Chaque promesse doit correspondre à un comportement présent dans cette version. Vérifie les captures pour les appareils et localisations que tu prends en charge ; les formats attendus sont détaillés dans la documentation Apple.

Fais ensuite un contrôle dans une fenêtre privée de chaque URL renseignée : support, confidentialité et éventuels liens utiles. Une réponse HTTP correcte ne suffit pas : la page doit contenir la bonne information, avec un contact utilisable et un affichage lisible sur mobile.

  • Captures issues de la version soumise.
  • Description sans fonctionnalité future annoncée comme disponible.
  • URLs et contenu vérifiés dans toutes les localisations actives.

4. Vérifier les réponses sur les données

Dresse l’inventaire des données utilisées par l’application et ses services : compte, diagnostic, analytics, paiement éventuel. Compare cet inventaire aux déclarations App Privacy. Apple demande de tenir compte aussi des pratiques des partenaires dont le code est intégré à l’app.

Prends une fonctionnalité et suis son parcours de données, depuis la saisie jusqu’au stockage ou à l’envoi. Cela permet de repérer un outil ajouté pendant le développement mais oublié dans la documentation. Ne déduis pas l’absence de collecte de la seule absence de formulaire visible.

  • Services et SDK réellement présents recensés.
  • Déclarations de confidentialité cohérentes avec leur usage.
  • Politique publique accessible depuis les emplacements nécessaires.
  • Permissions demandées au moment pertinent et avec une explication claire.

5. Rejouer le parcours du reviewer

Apple demande un accès complet pour examiner l’application, avec un compte de démonstration actif ou un mode de démonstration complet lorsque les fonctionnalités reposent sur un compte. Les services nécessaires doivent rester accessibles pendant la review.

Teste toi-même les instructions depuis un appareil sans session existante. Décris les étapes utiles pour atteindre une fonction peu visible et fournis les ressources nécessaires. Si tu dois envoyer un code à la main pour débloquer chaque connexion, tu n’as pas encore vérifié un accès autonome.

  • Accès de review essayé hors de la session du développeur.
  • Notes courtes avec étapes et résultat attendu.
  • Coordonnées de contact vérifiées.

6. Prendre une décision explicite

Classe les résultats en trois colonnes : validé, à corriger, non applicable avec une raison. Garde une preuve simple pour les points importants : build testé, scénario, résultat et date. Un crash bloquant, une perte de données ou un accès de review inutilisable doit être résolu avant l’envoi.

Une fois ces points traités, sélectionne le bon build et termine la soumission dans App Store Connect. Une mise en ligne du binaire n’équivaut pas à une demande de review. Cette checklist organise tes vérifications ; elle ne remplace pas les règles propres à ton app et ne garantit pas l’approbation.