Ce que je vérifie avant chaque soumission à l’App Store

Cette liste n’est pas théorique. Chaque point correspond à un aller-retour que j’ai réellement subi, ou que j’ai évité de justesse. Je la parcours entièrement avant chaque soumission, y compris pour une mise à jour mineure.

1. L’accès du relecteur

S’il y a une connexion, fournir un compte de démonstration avec des données dedans. Une application vide ne montre rien, et le relecteur ne devinera pas ce qu’elle sait faire.

Si l’authentification passe par un SMS ou un e-mail, prévoir un code de contournement et l’écrire dans les notes de revue. Sinon, le relecteur est bloqué à l’écran un, et le refus est automatique.

2. Le fonctionnement hors contexte

Le relecteur n’est pas chez vous. Je teste systématiquement dans ces trois conditions :

• En mode avion, pour voir ce qui s’affiche quand il n’y a rien.
• Sur un réseau volontairement lent, pour vérifier que les écrans de chargement existent.
• Avec une position hors de France, quand l’application dépend de la localisation.

C’est ce test qui m’a poussé à embarquer la fiche horaire complète dans Amiens : sans réseau, l’application devait continuer à répondre.

3. Le questionnaire de confidentialité

Le remplir après avoir listé les dépendances réellement embarquées, pas de mémoire. Un SDK oublié qui collecte un identifiant publicitaire contredit une déclaration « aucune collecte », et cette contradiction est détectable.

Vérifier aussi que chaque chaîne d’autorisation explique l’usage en langage clair, et pas en jargon juridique.

4. Les achats intégrés

• Le bouton « Restaurer un achat » existe et fonctionne, sur un appareil vierge.
• Les produits sont en statut « Prêt à soumettre » dans App Store Connect.
• Le prix affiché dans l’application correspond à celui d’App Store Connect, y compris après un changement de devise.
• Pour un abonnement : la durée, le prix et les conditions de renouvellement sont visibles avant l’achat, pas après.

5. Les cas limites de l’interface

C’est le point le plus souvent négligé, et celui qui fait le plus mauvais effet en revue.

• Le plus petit appareil supporté : le texte déborde-t-il ?
• La plus grande taille de texte du système : l’écran reste-t-il utilisable ?
• Les états vides : que voit un utilisateur au tout premier lancement, avant d’avoir rien créé ?
• Les erreurs : que se passe-t-il quand une requête échoue ? Un message, ou un écran figé ?

6. L’accessibilité

VoiceOver au moins sur le parcours principal. Chaque bouton doit avoir un libellé, chaque image informative un texte alternatif. Ce n’est pas seulement une question de conformité : c’est aussi ce qui révèle des boutons non libellés qu’on n’aurait jamais vus autrement.

7. La fiche et les captures

• Les captures montrent l’application réelle, pas une maquette embellie qui n’existe pas.
• Le texte de la fiche ne promet rien que l’application ne fait pas.
• Aucune mention d’une autre plateforme (« disponible aussi sur Android ») : c’est refusé.
• L’URL de support répond, et l’URL de confidentialité aussi.

Ce dernier point est la raison pour laquelle les pages de support d’Ose+ vivent sur ce site : une URL qui tombe en 404 est un motif de refus à elle seule.

8. La version et le build

Le numéro de version a bien été incrémenté, le build est monté sur le bon identifiant, et les notes de version décrivent ce qui a changé. Une note « corrections de bugs » sur une mise à jour qui ajoute une fonctionnalité majeure attire l’attention, et rarement dans le bon sens.

Combien de temps ça prend

Une heure, à peu près, sur une application que je connais. Un refus coûte rarement moins d’une semaine. L’arbitrage est vite fait.

Si vous préparez une première soumission et que vous voulez un regard extérieur avant d’envoyer, c’est exactement ce que couvre l’audit.