Préparer votre application pour la revue des stores

Cet article décrit le processus de revue des soumissions d’applications par les stores et propose des conseils pour accélérer l’approbation. Il s’appuie sur les directives de soumission officielles :

Important

Les deux stores suivent un processus de révision similaire. Lorsqu’une règle ne s’applique qu’à l’un des stores, l’article le mentionne explicitement.

Les utilisateurs d’Adapty doivent accorder 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

Vérifiez que votre application est prête pour la soumission.

Adapty propose une checklist de publication pour préparer votre app avant sa mise en ligne.

Le Google Play Store exige que les nouveaux éditeurs testent leur app 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 buguées soumises aux équipes de validation de Google.

Vue d’ensemble du processus de révision

Étape 1 : La vérification automatisée

L’App Store et le Google Play Store suivent tous deux un processus de révision en deux étapes similaire. Immédiatement après la soumission, votre application fait l’objet d’une analyse automatisée qui peut prendre plusieurs heures.

Les deux stores analysent vos applications à la recherche de logiciels malveillants, Google accordant une attention particulière à ce processus. Il recherche des indicateurs comportementaux d’activité malveillante, comme des contacts avec des serveurs suspects ou des accès injustifiés aux données des utilisateurs. Si votre application est jugée potentiellement dangereuse, elle est signalée et transmise à un analyste en sécurité. 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 nuisibles ou gravement obsolètes, et l’intégrité de votre build.

Étape 2 : La révision humaine

Une fois que votre application a passé la vérification automatisée, elle est examinée par un réviseur humain. Cette étape peut prendre jusqu’à plusieurs jours, selon la complexité de votre application et la file d’attente de révision en cours. Les applications qui traitent des données sensibles prennent plus de temps à examiner.

Exigences générales

Stabilité

Les applications qui plantent lors de l’examen sont rejetées. Les examinateurs peuvent intentionnellement simuler des conditions réseau peu fiables, 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 des stores.

  • Les espaces réservés, les écrans « bientôt disponible » et les fonctionnalités défaillantes entraînent des rejets pour les apps iOS.
  • Google est plus flexible, notamment si votre application est en Early Access.
  • Les deux stores rejettent les apps qui ont peu ou pas de fonctionnalités. Cela inclut les apps qui affichent une seule image, un fichier PDF ou une page web.

Le contenu manquant entre dans la même catégorie.

  • Si votre 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 la version soumise, l’application sera rejetée.

Précision 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 refus.

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 reviewer recherchera une documentation supplémentaire expliquant ses workflows. Incluez des instructions claires dans les métadonnées de l’application.

Classification par âge

Le contenu de votre application doit correspondre à sa classification déclarée.

  • La politique de confidentialité de votre application doit être accessible depuis l’intérieur de l’application. Vous pouvez utiliser le bouton de lien du Paywall Builder.
  • Demandez aux utilisateurs de lire et d’accepter tout accord légal avant qu’il n’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 de connexion valides à l’évaluateur du store. L’impossibilité d’accéder au contenu dans son intégralité peut entraîner 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 indiquer clairement la raison de chaque autorisation demandée. Les autorisations les plus sensibles (par exemple, l’accès aux SMS 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.

Les violations de politique commerciale comptent parmi les raisons les plus fréquentes de rejet d’application. Si vos principales méthodes de monétisation sont les abonnements et les achats intégrés, votre application sera soumise à un examen plus approfondi.

Exigences relatives aux paywalls

Les évaluateurs d’applications attendent des paywalls clairs et faciles à comprendre.

Si vous êtes soupçonné de manipulation des utilisateurs, l’application est rejetée. Si plusieurs évaluations révèlent des pratiques trompeuses, votre compte peut être désactivé et votre application suspendue. Google Play utilise un système d’avertissements qui peut entraîner la suppression de toutes vos applications.

Respectez les pratiques suivantes dans la conception de votre paywall :

  • 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 à effectuer un achat.

    Distinguez clairement les achats uniques des 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 de formulations intentionnellement ambiguës pour induire l’utilisateur en erreur.

Paywall comparison: clear vs confusing product description
  • Soyez cohérent.

    Les prix des produits doivent correspondre entre la fiche App Store, les écrans intégrés à l’app, les écrans de gestion des abonnements et le contenu marketing. Le moindre écart de prix peut entraîner un refus.

    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, ni ne masquez les moins chères.

  • Évitez les « dark patterns ».

    Ne créez pas de fausse impression d’urgence ou de rareté.

    Ne forcez pas les utilisateurs à effectuer des achats en rendant intentionnellement les fonctionnalités gratuites peu pratiques ou difficiles à trouver.

    Comparaison de paywalls : sélection de produits trompeuse ou conforme

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éverrouiller 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 nuire à 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 créé votre paywall avec le Flow & Paywall Builder, le bouton de restauration déclenche automatiquement le processus de restauration. Si vous avez implémenté un paywall manuellement, ajoutez le 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.

Le SDK doit être capable de reconnaître les achats intégrés effectués depuis la page du produit dans le store, ou ailleurs dans l’App Store.

Méthodes de paiement acceptées

Les deux stores interdisent la vente de biens physiques via des achats intégrés et exigent leur propre système de facturation pour la plupart des biens numériques.

Cette obligation ne s’applique pas dans certaines zones géographiques, notamment aux États-Unis et dans l’UE. Selon le pays, vous pouvez être en mesure de contourner entièrement la facturation du store, ou de proposer à l’utilisateur un choix entre la facturation du store et une solution de paiement alternative.

Certaines catégories d’applications (comme les liseuses ou les applications de rencontre) peuvent être éligibles aux modes de paiement alternatifs même en dehors de ces régions. Consultez les directives officielles des stores pour plus de détails.

Tip

Contrairement à Google, Apple ne propose pas de liste définitive des pays autorisant les modes de facturation alternatifs. À mesure que de nouvelles juridictions adoptent des lois similaires, la disponibilité s’élargira. Consultez la documentation propre à votre pays avant de continuer.

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 utilisant ces services.

Gérer un refus

Si votre application est rejetée, le reviewer indiquera quelle(s) règle(s) ont été enfreintes. Lisez la règle en entier et corrigez le problème :

Si vous estimez que le refus est injustifié, vous avez le droit de faire appel. Fournissez des preuves de conformité et contactez le store.

  • Ne mettez pas l’application à jour pendant qu’elle est en cours de révision.
  • Chaque fois que vous soumettez votre application pour révision, vous pouvez tomber sur un réviseur différent. Cela peut jouer en votre faveur ou contre vous.
  • Ne corrigez pas les problèmes un par un. Soumettez l’application pour une nouvelle révision une fois toutes les corrections effectuées.
  • Si Google Play a rejeté votre application pour violation des règles, mettez à jour les données concernées sur toutes les pistes, même celles qui sont en pause ou inactives.
  • Les révisions suivantes prennent généralement moins de temps que la première.
  • Une révision accélérée peut être disponible pour les bugs critiques et les délais urgents — utilisez-la avec parcimonie.

Après la validation : surveillance continue

Les deux stores continuent de surveiller votre application même après qu’elle a passé la validation.

Si les fonctionnalités de votre app changent après approbation (par exemple, via du code chargé dynamiquement), elle sera signalée et retirée. Un afflux de retours négatifs de la part des utilisateurs constitue également un motif de contrôle supplémentaire.

Entre 2024 et 2025, Google a supprimé 47 % de ses applications Play Store afin d’en améliorer la qualité globale.

Abandonner votre application comporte également des risques. Google et Apple retirent les applications qui ne reçoivent pas de mises à jour ou de téléchargements.

Voir aussi