App Store et Google Play : éviter le rejet
La plupart des rejets viennent d'une préparation manquante, pas d'un code défaillant. Ce qui doit être prêt avant de soumettre, pour les deux stores.
Équipe rabbitclipPublié: 5 min de lecture
En bref
La plupart des rejets sur l'App Store et Google Play viennent non pas d'un code défaillant mais d'une politique de confidentialité manquante, d'une demande de permission non expliquée, ou d'un compte de test manquant. Quand tout cela est prêt avant la soumission, l'application passe généralement la validation dès la première fois.
Les deux stores valident différemment. Apple s'appuie sur une revue humaine et se montre plus strict ; Google s'appuie davantage sur des analyses automatisées mais agit tout aussi fermement en cas de violation des règles. Chacun demande sa propre préparation.
Ce qui doit être prêt avant de soumettre
Une politique de confidentialité est obligatoire pour les deux stores, et elle doit refléter réellement les données que l'application collecte ; un modèle copié-collé tend à poser problème en validation.
Si l'application demande une permission (localisation, caméra, notifications), une courte explication de la raison doit être visible pour l'utilisateur comme pour le validateur. Apple y prête une attention particulière.
- Une politique de confidentialité (accessible via une URL en ligne)
- Des explications de permission (localisation, caméra, notifications, contacts)
- Un compte de test pour la validation (pour les applications nécessitant une connexion)
- Des captures d'écran et un texte de store qui reflètent l'interface réelle
Pourquoi Apple rejette des applications
Parmi les motifs de rejet les plus fréquents d'Apple figurent une fonctionnalité manquante (plantages, écrans vides), une permission non expliquée et des violations des règles d'achat intégré. Le validateur utilise réellement l'application ; si le compte de test ne fonctionne pas, le rejet suit.
Une autre raison fréquente est que l'application ressemble à une simple coquille autour d'un site web. Apple veut voir une vraie valeur ajoutée native ; cela rend le soin apporté à l'interface et à l'expérience payant.
Pourquoi Google Play rejette des applications
Côté Google, le problème le plus courant est un formulaire Data Safety qui ne correspond pas à ce que l'application collecte réellement. Si ce formulaire est rempli de façon incomplète ou incorrecte, les systèmes automatisés le signalent.
Le niveau d'API cible doit aussi rester à jour ; Google relève le niveau d'API cible minimum chaque année, et les applications laissées sur un ancien niveau peuvent perdre la possibilité d'être installées ou mises à jour.
L'expérience d'un fabricant de vêtements de travail
L'application de commande B2B d'un fabricant de vêtements de travail a été rejetée dès la première soumission car la raison de la demande de permission de localisation n'était pas expliquée. Une explication a été ajoutée et la même version resoumise le jour même ; elle est passée à la seconde validation.
C'est un exemple utile : le rejet vient généralement non pas d'un mauvais code mais de quelque chose qu'un validateur n'a pas pu voir expliqué. Bien poser la liste de préparation en amont évite l'essentiel des rejets.
Le critère de décision ici était simple : pour chaque permission demandée par l'application, une réponse en une phrase à « à quoi sert réellement cette permission dans l'application » a été écrite. Cette seule étape a permis à la seconde soumission de passer sans encombre chez Apple comme chez Google.
Comment se préparer : étape par étape
Traiter la préparation de la soumission comme une séquence plutôt qu'une checklist ponctuelle réduit le risque sur les deux stores. La première étape consiste à lister chaque permission demandée par l'application et à rédiger l'explication destinée à l'utilisateur pour chacune, à l'avance ; cela peut se faire dès la phase de design, avant la fin du développement.
La deuxième étape consiste à créer un compte de test qui fonctionne réellement pour chaque écran nécessitant une connexion, et à parcourir l'application de bout en bout comme le ferait un validateur. La troisième consiste à recenser chaque donnée réellement collectée par l'application, y compris tout outil d'analyse ou service de notification, lors du remplissage du formulaire Data Safety de Google Play ; même un service tiers oublié peut invalider tout le formulaire.
La dernière étape consiste à vérifier que les captures d'écran de soumission et le texte du store correspondent exactement à l'interface actuelle de l'application ; une capture d'écran issue d'un ancien design est une raison de rejet à la fois modeste et étonnamment fréquente.
Erreurs fréquentes
L'erreur la plus fréquente consiste à rédiger la politique de confidentialité et les explications de permission au dernier moment, la nuit précédant la soumission, une fois le développement terminé ; un texte rédigé dans la précipitation tend à se réduire à des phrases génériques qui ne satisfont ni le validateur ni l'utilisateur.
La seconde consiste à supposer qu'une version validée sur une plateforme le sera aussi sur l'autre sans changement. Apple et Google regardent des points différents ; une explication de permission qui satisfait Apple peut encore laisser le formulaire Data Safety de Google incomplet. Chaque store doit se préparer selon ses propres critères.
- Laisser la politique de confidentialité et les textes de permission jusqu'au dernier moment
- Supposer qu'une préparation suffisante pour un store l'est aussi pour l'autre
- Créer le compte de test juste avant la soumission, sans réellement l'essayer
Combien de temps prend la validation
La validation d'Apple se conclut en général en quelques jours, mais un cycle de rejet et resoumission allonge ce délai. La validation automatisée de Google va plus vite, mais les applications signalées pour un problème de règles passent en revue manuelle et peuvent prendre plus de temps.
Le rejet d'un store est généralement un manque de préparation, pas un problème de code ; quand la politique de confidentialité, les explications de permission et le compte de test sont complets dès le départ, le processus se déroule sans accroc. Que vous soumettiez pour la première fois ou de nouveau avec une mise à jour, cette checklist vaut la peine d'être revue ensemble.
Questions fréquentes
Combien de temps prend la validation de l'App Store ?
En général quelques jours ; il n'y a pas de délai garanti, cela varie selon le volume de validation.
Pourquoi le formulaire Data Safety compte-t-il autant sur Google Play ?
Si les données déclarées dans le formulaire ne correspondent pas à ce que l'application collecte réellement, les systèmes automatisés le signalent, ce qui peut mener à un rejet ou une suspension.
Une application peut-elle être soumise sans compte de test ?
Pas pour les applications qui nécessitent une connexion ; le validateur ou le système doit pouvoir réellement utiliser l'application.
Le processus repart-il de zéro après un rejet ?
Non, en général le problème signalé est corrigé, la même version est resoumise, et elle réintègre la file de validation.
