Préparer votre application pour la revue des stores
Cet article décrit le processus que suivent les stores lors de l’examen des soumissions d’applications, et propose des conseils pour obtenir une approbation plus rapide. Il s’appuie sur les directives officielles de soumission :
Les deux stores suivent un processus de revue similaire. Lorsqu’une règle ne s’applique qu’à l’un d’eux, l’article le mentionne par son nom.
Les utilisateurs d’Adapty doivent porter une attention particulière aux problèmes de conformité liés aux paywalls et aux achats intégrés. Ce sont parmi les raisons de rejet les plus fréquentes.
Avant de commencer
Confirmez que votre application est prête pour la soumission.
Adapty propose une checklist de mise en production pour préparer votre app à la publication.
Le Google Play Store exige que les éditeurs qui publient pour la première fois testent l’application avant de la soumettre. Le test doit impliquer au moins 12 personnes et durer un minimum de 14 jours consécutifs. Cette exigence a été introduite en 2025 pour réduire le nombre d’applications défectueuses qui parviennent aux équipes de revue de Google.
Vue d’ensemble du processus de revue
Étape 1 : Le filtrage automatisé
L’App Store et le Google Play Store suivent tous deux un processus de revue en deux étapes. Immédiatement après la soumission, votre application passe par un scan automatisé qui peut prendre plusieurs heures.
Les deux stores analysent votre application à la recherche de malwares, Google accordant une importance particulière à cette étape. Il recherche des indicateurs comportementaux d’activité malveillante, comme des contacts avec des serveurs suspects ou un accès injustifié aux données utilisateur. Si votre application est jugée potentiellement dangereuse, elle est signalée et transmise à un analyste en sécurité humain. La documentation Google Play Protect contient une liste approximative des vérifications effectuées lors de cette étape.
Les stores vérifient également la présence des métadonnées nécessaires, l’absence de dépendances dangereuses ou obsolètes, ainsi que l’intégrité de votre build.
Étape 2 : La revue humaine
Une fois que votre application a passé le filtrage automatisé, elle est examinée par un relecteur humain. Cette étape peut prendre jusqu’à plusieurs jours, selon la complexité de votre application et la file d’attente de revue en cours. Les applications qui traitent des données sensibles prennent plus longtemps à examiner.
Exigences générales
Stabilité
Les applications qui plantent pendant la revue sont rejetées. Les relecteurs peuvent intentionnellement simuler des conditions réseau instables, l’application doit donc être capable de les gérer correctement.
Complétude
Apple et Google imposent tous deux une exigence de complétude (« fonctionnalité minimale ») sur le contenu soumis aux stores.
- Les espaces réservés, les écrans « bientôt disponible » et les fonctionnalités cassées entraînent des rejets pour les applications iOS.
- Google est plus flexible, notamment si votre application est en Accès anticipé.
- Les deux stores rejettent les applications qui ont peu ou pas de fonctionnalités. Cela inclut les applications qui affichent une seule image, un fichier PDF ou une page web.
Le contenu manquant entre dans la même catégorie.
- Si l’application ne fait pas ce que vous annoncez, elle sera rejetée.
- Si vous configurez un achat intégré dans votre tableau de bord, mais ne l’incluez pas dans le build, l’application sera rejetée.
Exactitude des métadonnées
Des informations trompeuses, inexactes ou incohérentes dans la description, les captures d’écran et autres métadonnées peuvent entraîner un rejet.
N’utilisez pas votre fiche store pour promouvoir des fonctionnalités futures de l’application.
Si l’application n’est pas destinée au grand public, le relecteur recherchera une documentation supplémentaire expliquant ses workflows. Incluez des instructions claires dans les métadonnées de l’application.
Classification du contenu
Le contenu de votre application doit correspondre à la classification déclarée.
Aspects légaux
- La politique de confidentialité de votre application doit être accessible depuis l’intérieur de l’application. Vous pouvez utiliser le bouton lien du Paywall Builder.
- Exigez des utilisateurs qu’ils lisent et acceptent tout accord juridique avant qu’il entre en vigueur.
- Signalez la présence de publicités dans votre application. Ne pas le faire peut entraîner un rejet.
- Si votre application iOS inclut des achats intégrés, vous devez accepter le Paid Apps Agreement dans votre tableau de bord App Store Connect.
Authentification
Si une partie du contenu de votre application n’est accessible qu’après authentification, fournissez des identifiants d’accès valides au relecteur du store. L’impossibilité d’accéder à l’intégralité du contenu justifie un rejet.
Si votre application permet aux utilisateurs de créer un compte, elle doit également leur permettre de le supprimer. Rediriger les utilisateurs vers un support par e-mail ou un site web ne satisfait pas cette exigence.
Accès et confidentialité
Les métadonnées de l’application doivent clairement indiquer la raison de chaque permission demandée. Les permissions les plus sensibles (par exemple, l’accès aux messages texte et aux journaux d’appels) peuvent nécessiter une démonstration vidéo.
Le même principe s’applique aux données utilisateur sensibles : si vous les demandez, expliquez pourquoi.
Exigences liées aux achats intégrés
Les violations de la politique commerciale font partie des raisons de rejet les plus fréquentes. Si les principales méthodes de monétisation de votre application sont les abonnements et les achats intégrés, elle fera l’objet d’un examen plus approfondi.
Exigences relatives aux paywalls
Les relecteurs d’applications attendent des paywalls simples et faciles à comprendre.
Si vous êtes soupçonné de manipulation des utilisateurs, l’application est rejetée. Si plusieurs revues trouvent des preuves de pratiques trompeuses, votre compte peut être désactivé et votre application suspendue. Google Play utilise un système de pénalités qui peut conduire à la suppression de toutes vos applications.
Respectez les pratiques suivantes dans la conception de vos paywalls :
-
Soyez transparent et direct.
Affichez le prix exact des produits, la fréquence de facturation, les avantages et les conditions d’annulation avant d’inviter l’utilisateur à acheter.
Différenciez clairement les achats uniques et les produits nécessitant des paiements récurrents.
Si un produit est accompagné d’un essai gratuit, indiquez clairement sa durée et ses conditions.
N’utilisez pas un langage intentionnellement confus pour induire l’utilisateur en erreur.
-
Soyez cohérent.
Les prix des produits doivent correspondre sur la fiche App Store, dans les écrans intégrés à l’application, les écrans de gestion des abonnements et le contenu marketing. Toute différence de prix, même minime, est un motif de rejet.
Le Paywall Builder d’Adapty synchronise automatiquement les prix entre votre paywall et votre produit App Store Connect. Si votre paywall est codé manuellement, vous devez récupérer le prix de chaque produit depuis son tableau de données.
-
Affichez tous les niveaux de manière équitable.
Ne présélectionnez pas l’option la plus chère et ne cachez pas les moins chères.
-
Évitez les « dark patterns ».
Ne créez pas de fausse urgence ou de rareté artificielle.
Ne forcez pas les utilisateurs à effectuer des achats en rendant intentionnellement les fonctionnalités gratuites peu pratiques ou difficiles à trouver.
Garantie d’accès
L’application doit garantir aux utilisateurs le droit d’accéder à leurs achats.
-
Accès immédiat
Un achat réussi doit immédiatement débloquer l’accès au produit, sans délai visible.
Les états intermédiaires d’autorisation de paiement ne doivent pas générer d’erreurs ni perturber l’expérience utilisateur.
Un achat réussi doit immédiatement masquer le paywall. Si vous continuez à afficher le paywall après un achat, vous empêchez l’utilisateur d’accéder au contenu qu’il a payé.
-
Restauration de l’accès
Un utilisateur doit pouvoir restaurer l’accès au produit depuis un nouvel appareil. Placez le bouton de restauration à un endroit visible.
Si vous avez conçu votre paywall avec le Flow Builder, le bouton de restauration déclenche automatiquement le processus de restauration. Si vous avez implémenté un paywall manuellement, ajoutez du code qui appelle la méthode restorePurchases. Adapty restaurera le niveau d’accès de l’utilisateur, sauf si vous utilisez le SDK en mode observateur.
L’application doit être capable de reconnaître les achats intégrés effectués depuis la page store du produit, ou ailleurs dans l’app store.
Méthodes de paiement appropriées
Les deux stores interdisent la vente de biens physiques via les achats intégrés, et exigent la facturation en store pour la plupart des biens numériques.
L’exigence de facturation en store ne s’applique pas dans certaines juridictions géographiques, notamment aux États-Unis et dans l’UE. Selon le pays, vous pourrez peut-être contourner entièrement la facturation en store, ou présenter à l’utilisateur un choix entre la facturation via l’app store et une facturation alternative.
Certaines catégories d’applications (comme les lecteurs de livres numériques ou les applications de rencontres) peuvent être éligibles à des méthodes de paiement alternatives même en dehors de ces régions. Consultez les directives officielles des stores pour plus de détails.
Contrairement à Google, Apple ne propose pas de liste définitive des pays autorisant les méthodes de facturation alternatives. À mesure que de nouvelles juridictions adoptent des lois similaires, la disponibilité s’élargira. Lisez la documentation relative à votre pays en particulier avant de procéder.
Notez que les deux stores appliquent des directives pour les intégrations de fournisseurs de paiement, et continuent de prélever une commission sur les transactions effectuées via ces services.
Gestion des rejets
Si votre application est rejetée, le relecteur indiquera quelle(s) directive(s) elle a violée. Lisez la directive en intégralité et corrigez le problème :
Si vous estimez que le rejet est injustifié, vous avez le droit de le contester. Fournissez des preuves de conformité et contactez le store.
- Ne mettez pas à jour l’application pendant son examen.
- À chaque soumission, vous pouvez avoir un relecteur différent. Cela peut jouer en votre faveur ou contre vous.
- Ne corrigez pas les problèmes un par un. Soumettez l’application à une nouvelle revue une fois que toutes les corrections sont en place.
- Si Google Play a rejeté votre application pour des violations de politique, mettez à jour les données en question sur toutes les tracks, même celles en pause ou inactives.
- Les revues suivantes prennent généralement moins de temps que la première.
- Une revue accélérée peut être disponible pour les bugs critiques et les délais urgents — à utiliser avec parcimonie.
Après la revue : surveillance continue
Les deux app stores continuent de surveiller votre application même après qu’elle a passé le processus de revue.
Si la fonction de votre application change après approbation (par exemple, en raison d’un code chargé dynamiquement), elle sera signalée et dépubliée. Un afflux de retours négatifs des utilisateurs constitue également un motif d’examen supplémentaire.
Entre 2024 et 2025, Google a supprimé 47 % de ses applications du Play Store pour améliorer leur qualité moyenne.
Abandonner votre application comporte également un risque. Google et Apple retirent tous deux des listes les applications qui ne reçoivent pas de mises à jour ou de téléchargements.