Cas de rejet App Store / Google Play et checklist pratique pour passer la revue

Vous êtes prêt a publier l'application, puis la revue vous la renvoie. C'est un mur que beaucoup de développeurs rencontrent au moins une fois.

Et les raisons d'un blocage ne se limitent pas aux crashs ou aux builds défectueux. Les textes d'autorisation, la politique de confidentialité, le parcours de paiement, les métadonnées du store ou des notes de revue insuffisantes peuvent aussi être en cause. Il n'est pas rare que des sujets opérationnels en dehors de l'implémentation elle-même déclenchent le rejet.

Dans cet article, je classe par catégorie les cas de rejet fréquents sur l'App Store et Google Play, puis je résume, d'un point de vue très pratique, les points à vérifier avant soumission.

Public visé

• Les personnes qui soumettent une application sur l'App Store / Google Play pour la première fois
• Les personnes déjà rejetées par le passé et qui veulent remettre les causes à plat
• Les personnes qui développent avec des stacks cross-platform comme React Native ou Flutter
• Les équipes qui veulent formaliser une checklist avant mise en ligne

Termes a retenir d'abord

Avant d'aller plus loin, voici un rappel rapide des termes qui apparaîtront dans la suite. Si vous les avez bien en tête, les cas de rejet de la seconde moitié seront plus faciles à lire.

• reviewer: La personne chez Apple ou Google qui examine l'application. Elle ne vérifie pas seulement le binaire, mais aussi le texte de la fiche store, les captures d'écran, les déclarations et les notes de revue.
• IAP (In-App Purchase): Le mécanisme d'achat intégré d'Apple pour vendre du contenu numérique ou des fonctionnalités dans l'application.
• ATT (App Tracking Transparency): Le mécanisme iOS qui demande l'autorisation de l'utilisateur avant tout suivi à travers les apps ou sites d'autres sociétés.
• IDFA: Un identifiant utilisé pour la mesure publicitaire. Si votre configuration s'en sert, il faut souvent vérifier ATT et App Privacy.
• Data safety / App Privacy: Les formulaires d'auto-déclaration de collecte de données sur Google Play / App Store. Si vous ajoutez un SDK sans mettre à jour la déclaration, la cohérence se casse.
• target SDK: La valeur qui indique sur quel niveau d'API Android l'application se base. minSdkVersion désigne l'OS minimal supporté, ce n'est donc pas la même chose.
• métadonnées du store: L'ensemble des informations affichées ou soumises dans le store, comme les captures, la description, le sous-titre, la catégorie, la classification par âge et les champs déclaratifs.
• WebView: Un composant qui affiche une page web dans l'application. C'est pratique, mais si l'essentiel de l'écran repose dessus, la valeur native paraît vite faible.
• UGC (User Generated Content): Le contenu généré par les utilisateurs, comme les commentaires, photos envoyées, profils ou avis.
• restore purchases: Le parcours qui permet de restaurer des achats existants. C'est important pour les abonnements et les achats unitaires.
• entitlement: Un réglage d'autorisation lié à une capability Apple ou à une fonctionnalité particulière. Beaucoup sont accessibles aux apps normales, mais certains entitlements spéciaux demandent une approbation Apple ou des conditions supplémentaires.

Comprendre d'abord le regard de la revue

Pour réduire les rejets, lire les guidelines ne suffit pas. Il est plus utile de comprendre ce que le reviewer vérifie en peu de temps, car cela aide à prioriser les corrections.

Les situations qui bloquent le plus souvent sont les suivantes:

• L'implémentation existe, mais l'explication est insuffisante
• L'application demande une autorisation, mais le lien avec la fonctionnalité n'est pas clair
• Il y a un paiement, mais le prix ou le parcours de résiliation restent flous
• Les captures ou la description ne correspondent pas à l'application réelle
• Le reviewer ne peut pas se connecter et n'arrive pas à vérifier les fonctions principales

Avant l'esthétique de l'UI, la revue regarde surtout la sécurité, la cohérence et la complétude.

Clarifier d'abord les différences entre App Store et Google Play

Les deux plateformes veulent une application sûre, non trompeuse et non inachevée, mais les points sur lesquels elles bloquent le plus souvent diffèrent légèrement.

En simplifiant, l'App Store bloque plus souvent sur la rigueur de l'expérience, du paiement et des explications liées à la confidentialité, tandis que Google Play bloque plus souvent sur les exigences techniques et la cohérence des auto-déclarations.

C'est pourquoi, même pour une même application, l'ordre de préparation change légèrement.

• App Store: régler d'abord le comportement sur appareil réel, l'écran de paiement, les textes d'autorisation et les notes de revue
• Google Play: régler d'abord le target SDK, les permissions, Data safety et les déclarations publicitaires

Études de cas à partir de vrais messages de retour et de blocage

Dans cette section, je cite des messages de revue App Store et des messages de blocage Google Play courants, puis j'explique ce qu'ils veulent vraiment dire et quoi corriger en premier. Les catégories plus loin peuvent se lire comme le détail de ces cas.

Case 1: crash immédiat au lancement sur l'App Store

"Nous avons découvert un ou plusieurs bugs dans votre application lors de la revue sur un iPhone sous iOS 17.0 en Wi-Fi. Plus précisément, l'application a crashé immédiatement au lancement."

Ce n'est pas traité comme un échec temporaire, mais comme un défaut majeur reproductible sur l'appareil de revue. La première chose à faire est de vérifier la reproduction en mode avion, après une installation propre, avec un compte vide et sur réseau lent, puis de lister tous les traitements exécutés juste après le lancement.

Case 2: Privacy Policy manquante sur l'App Store

"Votre application collecte des données utilisateur ou d'usage mais ne dispose pas d'une privacy policy URL."

Cela signifie que l'application manipule des données via des SDK ou des API maison, mais que l'explication publique accessible aux utilisateurs manque. La première chose à faire est de publier une URL publique décrivant les données collectées, leur usage, l'éventuel partage à des tiers et le point de contact, puis d'aligner App Store Connect et App Privacy.

Case 3: les achats numériques n'utilisent pas IAP sur l'App Store

"Votre application permet l'achat de contenu numérique, mais le mécanisme d'achat n'utilise pas in-app purchase."

Ce n'est pas un problème d'affichage du prix. Le message dit surtout que le mécanisme de paiement ne correspond pas à la nature de ce qui est vendu. La première chose à faire est de découper précisément ce qui est vendu et de faire converger vers IAP tout ce qui constitue une valeur numérique consommée dans l'application.

Case 4: Google Play ne satisfait pas l'exigence de target API

"Lorsque vous publiez une nouvelle application, vous devez cibler Android 15 (API level 35) ou supérieur."

Google Play ne se contente pas d'envoyer des rejection mails classiques. Il peut aussi bloquer la publication en amont via des prérequis visibles dans la Console. Lorsque ce texte apparaît, le problème n'est pas encore la qualité de l'app, mais le non-respect d'un prérequis de publication. La première chose à faire est d'élaborer un plan de mise à jour qui couvre non seulement targetSdkVersion, mais aussi les dépendances, les différences de permissions, les notifications et les comportements en arrière-plan.

Case 5: un nouveau personal account Google Play ne peut pas passer en production

"Vous devez exécuter un closed test avec au minimum 12 testers restés opted-in de façon continue pendant les 14 derniers jours."

Lors d'une première mise en ligne, on peut être bloqué par un production gate lié au type de compte, indépendamment de la qualité de l'application. Un nouveau personal account ne peut pas aller jusqu'à la publication tant que les conditions de closed test et de production access ne sont pas remplies. En plus, une device verification Android par le propriétaire du compte peut être requise.

La première chose à faire est de vérifier si le compte visé est bien un nouveau personal account, puis de finaliser le plus tôt possible le closed test 12 personnes / 14 jours, l'opt-in continu des testers et la device verification via la Play Console mobile app.

L'App Store renvoie souvent ces sujets sous forme de commentaires de revue, alors que Google Play bloque plus souvent via des exigences Console ou des écarts déclaratifs. Mais, au fond, l'essentiel est commun: la plupart des cas relèvent d'une app inachevée, d'une explication insuffisante, d'une déclaration incohérente ou d'un prérequis de publication non rempli.

Catégorie 1: Complétude de l'application

1. L'application crash juste après le lancement

Les erreurs d'API au premier lancement, les échecs d'initialisation de DB locale ou les accès a un objet nil font partie des causes de retour les plus classiques. Ici, un accès nil signifie que l'application lit un objet avant qu'une valeur valide y soit placée. Comme l'environnement du reviewer ne correspond jamais parfaitement au vôtre, il vaut mieux surprotéger la sécurité du démarrage.

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onAppear {
                    setupApp()
                }
        }
    }

    private func setupApp() {
        do {
            try initializeDatabase()
        } catch {
            print("DB init failed: \(error)")
        }
    }
}

Points à vérifier:

• L'application ne crash pas au premier lancement même sans compte existant
• L'application peut au moins démarrer même sans réseau
• Si la récupération des données obligatoires échoue, un écran de fallback reste accessible

Une solution efficace consiste à séparer le traitement de démarrage en deux types:

• Le traitement qui doit absolument réussir avant de pouvoir afficher quoi que ce soit
• Le traitement qui peut échouer et être rejoué plus tard

Par exemple, il n'est pas nécessaire de bloquer toute l'application sur un chargement de configuration distante ou une prélecture de recommandations. Si vous affichez d'abord l'écran d'accueil, ou au moins une structure minimale, puis ne réessayez que les traitements en échec, l'application résistera bien mieux aux différences d'environnement de revue.

En pratique, l'ordre le plus rapide est souvent le suivant:

• Récupérer les crash logs
• Lister les traitements d'initialisation lancés au démarrage
• Réduire ce qui doit absolument réussir de manière synchrone
• Vérifier sur appareil réel en mode avion, après une installation fraîche et avec des données vides

2. Des fonctions ne sont pas implémentées ou des placeholders restent visibles

Des écrans qui affichent seulement "Coming Soon", des boutons qui ne font rien et des liens cassés donnent vite l'impression d'une app inachevée.

Juste avant la soumission, il est souvent plus sûr de traiter d'abord les points suivants au lieu d'ajouter encore des fonctions:

• Supprimer les fonctions non implémentées dont seul l'accès existe déjà
• Effacer les textes factices et les libellés de test
• Amener les écrans d'erreur et les états vides à un minimum acceptable

3. Impossible de vérifier quoi que ce soit sans se connecter

Même pour une application avec authentification obligatoire, le risque de rejet augmente si le reviewer ne peut pas atteindre les fonctions principales.

Ce qu'il faut n'est pas juste un compte, mais le chemin de vérification le plus court possible.

• Prévoir un demo account
• Si 2FA est requis, écrire la procédure
• Si certaines fonctions ne sont visibles qu'avec un rôle précis, l'expliquer
• Si des sandbox data sont nécessaires, décrire l'état initial

La base de la réponse consiste à créer une situation dans laquelle le reviewer peut vérifier la valeur de l'application par le chemin le plus court. L'idéal est un compte de revue read-only qui permet d'atteindre les écrans principaux sans inscription ni échange avec le support.

Ici, les sandbox data désignent des données factices destinées à la revue et aux tests, sans impact sur les vrais utilisateurs. Historique de commandes, publications, statut d'abonnement ou magasins sur une carte deviennent beaucoup plus faciles à évaluer lorsqu'ils ne sont pas vides.

Si l'application repose sur SMS ou sur un système d'invitation, il vaut mieux ne pas laisser le reviewer se débrouiller seul avec cela.

• Fournir un compte de revue avec une longue durée de validité
• Si 2FA est nécessaire, joindre un code de secours ou une procédure alternative
• Si un état initial vide masque la valeur de l'application, précharger des données de test
• Utiliser le modèle présenté plus loin pour décrire aussi le chemin d'accès dans les notes de soumission

Catégorie 2: Confidentialité et permissions

4. Il n'y a pas d'URL de politique de confidentialité

Si l'application traite des données utilisateur ou d'usage mais n'a pas de Privacy Policy URL, le risque est très élevé. Il s'agit moins d'un problème du binaire que d'un dossier de soumission incomplet.

Au minimum, la politique de confidentialité devrait indiquer clairement les points suivants:

• Les types de données collectées
• La finalité d'usage
• L'existence ou non d'un partage avec des tiers
• La durée de conservation
• Le moyen pour l'utilisateur de demander suppression ou correction

Ce qui prête facilement à confusion ici, c'est que Privacy Policy et App Privacy / Data safety sont deux choses différentes.

• Privacy Policy: Un document public que l'utilisateur peut lire
• App Privacy / Data safety: Une auto-déclaration soumise au store

Avoir l'un sans l'autre ne suffit pas. Le contenu doit aussi être cohérent des deux côtés.

La solution la plus courte consiste souvent à publier d'abord une page publique qui explique ce qui est collecté, dans quel but et comment vous contacter. Ensuite, comparez-la à votre inventaire de SDK et mettez à jour les déclarations dans App Store Connect / Play Console.

5. L'application demande des permissions qu'elle n'utilise pas

Les permissions comme la localisation, les contacts, le micro ou la caméra suscitent vite de la méfiance si elles ne sont pas fortement liées à une fonction. Dans de nombreux cas, une bibliothèque ajoute des permissions inutiles par effet de bord.

import { Alert } from 'react-native'
import * as Location from 'expo-location'

async function requestLocationForMap() {
  const { status } = await Location.requestForegroundPermissionsAsync()
  if (status !== 'granted') {
    Alert.alert('L\'autorisation de localisation est nécessaire pour afficher les magasins proches sur la carte')
    return
  }

  // Flux d'affichage de la carte
}

L'idée clé est de ne demander que les permissions réellement utilisées, au moment précis où elles deviennent nécessaires.

L'astuce pratique consiste à ne pas regarder uniquement les appels dans le code, mais aussi les déclarations introduites par les dépendances. Sur Android, cela signifie vérifier AndroidManifest.xml; sur iOS, Info.plist et les SDK installés ensemble. Sinon, des permissions non voulues restent facilement présentes.

6. Le texte d'autorisation est trop abstrait

Des formules comme "pour améliorer l'expérience" ne disent pas à quoi sert réellement la permission. Le texte doit être relié à une fonction concrète.

Bons exemples:

• Pour afficher les magasins proches sur la carte
• Pour prendre une photo de profil
• Pour utiliser la caméra afin de scanner des codes-barres

Exemples faibles:

• Pour améliorer l'expérience
• Pour plus de confort
• Pour améliorer la qualité du service

<key>NSLocationWhenInUseUsageDescription</key>
<string>Utilisé pour afficher les magasins proches sur la carte</string>

<key>NSCameraUsageDescription</key>
<string>Utilisé pour prendre une photo de profil</string>

7. App Tracking Transparency n'est pas correctement géré

Si l'application utilise IDFA, il faut une cohérence entre la boîte de dialogue ATT et la déclaration App Privacy. L'application doit également être conçue pour fonctionner même si l'utilisateur refuse le tracking.

Ici, ATT désigne le mécanisme qui demande l'autorisation avant l'accès à IDFA, souvent utilisé pour la mesure publicitaire et l'attribution. En pratique, on peut retenir ceci: si vous avez ajouté un SDK publicitaire, si un SDK de mesure lit l'IDFA, ou si vous suivez l'utilisateur à travers des données tierces, cette zone sera plus facilement examinée.

import AppTrackingTransparency

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        switch status {
        case .authorized:
            break
        case .denied, .restricted, .notDetermined:
            break
        @unknown default:
            break
        }
    }
}

Dans la pratique, l'ordre réaliste des corrections est celui-ci:

• Recenser quels SDK utilisent IDFA ou le tracking
• Réévaluer si le tracking est réellement nécessaire
• Si ce n'est pas nécessaire, retirer les réglages ou dépendances concernés pour rendre ATT inutile
• Si c'est nécessaire, aligner la boîte de dialogue ATT, App Privacy et l'explication dans l'application
• Vérifier que les fonctions principales marchent même sans autorisation

Catégorie 3: Paiement et modèle économique

8. Le contenu numérique est orienté vers un paiement externe

Si l'application vend des biens numériques ou des déverrouillages de fonctions dans l'application, l'App Store attend en principe l'usage de IAP. Rediriger vers un paiement web ou un achat sur un site externe mène très souvent a un blocage.

Ce qu'il faut clarifier est le suivant:

• Les produits physiques et services en présentiel peuvent souvent utiliser un paiement externe
• Les contenus numériques et fonctions premium doivent en principe utiliser IAP
• Si une Reader App affiche des liens de création ou de gestion de compte vers un site externe, elle a besoin de l'External Link Account Entitlement
• Même lorsque l'exception Reader App s'applique, la catégorie et les conditions d'implémentation sont très limitées

Quand vous hésitez sur l'usage de IAP, le critère le plus utile est de savoir si vous vendez une valeur numérique consommée dans l'application.

• Exemples orientés IAP: suppression des publicités, fonctions premium, monnaie de jeu, lecture illimitée d'articles, accès illimité aux vidéos
• Exemples souvent compatibles avec un paiement externe: biens physiques, VTC, cours en présentiel, livraison de repas, réservation d'hôtel

Si l'application oriente déjà vers une facturation externe et que c'est cela qui bloque, il faut généralement aller vers l'une de ces solutions:

• Reconcevoir la facturation autour de IAP
• Vérifier sérieusement si l'application entre vraiment dans le cadre Reader App
• Séparer les biens numériques des services physiques et réorganiser le parcours dans l'application

9. L'explication de l'abonnement est trop faible

Pour les abonnements, un prix flou, un cycle de renouvellement mal expliqué, l'auto-renew ou le chemin de résiliation mal présenté affaiblissent l'interface du point de vue de la protection de l'utilisateur.

Au minimum, l'écran d'achat ou la description du store doit rendre ces points explicites:

• Le nom du plan, sa durée et ce qu'il comprend
• Le montant total facturé est clair; pour un plan annuel, le total annuel doit être le chiffre le plus évident
• Le cycle de renouvellement et le caractère auto-renew sont compréhensibles
• Le prix normal après l'essai gratuit est clair
• Des liens vers Terms of Service et Privacy Policy existent
• Un parcours sign in ou restore purchases est présent pour les abonnés existants
• La méthode de résiliation est compréhensible

Une erreur courante consiste à mettre en avant l'équivalent mensuel en gros tout en rendant difficile à lire le montant réellement prélevé et les conditions de renouvellement. Pour un plan annuel, il est plus sûr d'afficher d'abord le total annuel et de placer l'équivalent mensuel en information secondaire.

Pour revoir un écran d'abonnement, cette grille aide souvent:

• Nom du plan
• Moment de facturation
• Montant total facturé
• Prix normal après l'essai gratuit
• Parcours de restauration
• Conditions d'utilisation et politique de confidentialité
• Écran de gestion ou chemin de résiliation

Par exemple, une phrase comme "7 jours gratuits, puis renouvellement automatique a 7 200 JPY par an" se comprend en une seule lecture et limite les malentendus en revue.

Pour rendre l'écran d'achat plus robuste face à la revue, il est aussi utile de répondre directement dans l'écran aux questions qui prêtent le plus souvent à confusion:

• Quel plan est sélectionné actuellement?
• Quel montant sera prélevé maintenant?
• Quel sera le prix après la fin de la période gratuite?
• Jusqu'à quand faut-il résilier pour éviter la prochaine facturation?
• Ou un abonné existant peut-il restaurer l'achat?

// React Native seul ne peut pas ouvrir directement la system-provided UI de StoreKit,
// voici donc un exemple de fallback si vous ne pouvez pas faire le bridge d'une implémentation iOS native.
import { Linking, Text, TouchableOpacity } from 'react-native'

function SubscriptionSettings() {
  return (
    <TouchableOpacity
      onPress={() => Linking.openURL('https://apps.apple.com/account/subscriptions')}
    >
      <Text>Gérer l'abonnement</Text>
    </TouchableOpacity>
  )
}

Si une implémentation iOS native est possible, il est plus naturel d'ouvrir la system-provided management UI via showManageSubscriptions(in:) comme Apple le recommande.

10. L'exception Reader App est interprétée trop largement

L'exception Reader App semble pratique, mais son périmètre est très limité. La fonction principale doit réellement relever de magazines, journaux, livres, audio, musique ou vidéo, et l'application doit permettre de consulter ou lire des contenus ou abonnements achetés hors de l'application.

En outre, l'affichage de liens de création ou de gestion de compte vers un site externe exige l'External Link Account Entitlement. Les applications qui proposent IAP sur iOS / iPadOS / tvOS n'y sont pas éligibles. L'idée selon laquelle "nous sommes une Reader App donc nous pouvons librement rediriger vers un paiement externe" est donc fausse.

Les contenus de consommation comme la vidéo, la musique ou les livres sont traités différemment des fonctionnalités d'application ou de la monnaie de jeu. Si vous soumettez l'app sans clarifier sa vraie catégorie, l'évaluation devient facilement incohérente.

En cas d'hésitation, il est plus sûr d'ordonner si vous vendez du contenu ou une fonctionnalité, et où se situe le parcours d'achat, puis d'expliquer cela aussi dans la fiche store et les notes de revue.

Avant soumission, ces trois questions Yes / No rendent la décision plus simple:

• La fonction principale consiste-t-elle réellement à fournir magazines, journaux, livres, audio, musique ou vidéo?
• La structure sert-elle à accéder a des contenus déjà achetés hors de l'application?
• La version iOS n'offre-t-elle pas IAP?

Si l'une de ces trois réponses reste ambiguë, il est plus sûr de ne pas concevoir l'application en se reposant sur l'exception Reader App.

Catégorie 4: Design et qualité d'expérience

11. L'UI s'écarte trop des attentes de la plateforme

Un système de navigation entièrement maison, l'absence de chemin de retour ou un contraste difficile à lire dégradent la sensation d'utilisabilité. En revue, il est généralement plus favorable de privilégier une ergonomie alignée sur la plateforme plutôt qu'une originalité visuelle trop poussée.

12. L'application donne l'impression d'être un simple emballage WebView

Une application qui se contente pratiquement d'afficher un site web peut être jugée comme apportant trop peu de valeur native.

Schémas risqués:

• Presque tout l'écran est un WebView
• Il n'y a aucune fonction réellement native
• Rien ne fonctionne hors ligne
• Il n'y a aucune valeur spécifique à l'app comme l'intégration au device ou les notifications

Pour éviter de ressembler à un simple wrapper, il est préférable de rendre visible la valeur d'intégration au device via le partage, les notifications, la caméra, le stockage local, l'UX hors ligne, etc.

WebView n'est pas mauvais en soi. Le vrai problème apparaît lorsque vous soumettez une app native, mais que l'expérience interne ressemble presque exactement au site. Si vous utilisez WebView, essayez au minimum d'apporter de la valeur côté natif sur au moins un de ces points:

• Navigation ou écran de réglages natifs
• Fonctions du device comme le partage, les notifications, la caméra ou l'enregistrement de fichiers
• Explications ou cache consultable hors ligne
• Interaction spécifique à l'application absente de la version web

13. Les publicités ou le parcours de paiement sont trop agressifs

Si la publicité attire plus l'œil que le contenu, si la mise en page provoque des taps involontaires ou si les interstitials difficiles a fermer sont trop fréquents, l'impact est négatif à la fois sur la revue et sur les évaluations. Une logique de monétisation peut exister, mais il faut vérifier sur appareil réel qu'elle ne détruit pas l'expérience.

Catégorie 5: Métadonnées du store et informations déclarées

La revue ne regarde pas seulement l'application elle-même, mais aussi le texte du store et les déclarations. Si ces éléments ne correspondent pas à la réalité, l'application peut être bloquée même si l'implémentation est correcte.

Éléments à revoir:

• Captures d'écran
• Description de l'application
• Sous-titre
• Classification par âge
• App Privacy / Data safety
• Déclaration de présence de publicité

Le cas le plus dangereux consiste à mentionner dans la description des fonctions qui ne sont pas implémentées. Il vaut mieux aussi éviter d'afficher à l'avance des fonctions seulement prévues pour plus tard.

Catégorie 6: UGC et catégories à risque élevé

14. Il y a de l'UGC mais aucun parcours de modération

Si l'application gère du contenu généré par les utilisateurs, le simple fait d'avoir une fonction de publication ne suffit pas. Au minimum, il est préférable de prévoir:

• Un mécanisme de signalement
• Une fonction de blocage
• Des conditions d'utilisation
• Un point de contact
• Une politique de traitement des contenus en infraction

S'il y a de l'UGC mais aucun garde-fou visible, la revue s'inquiète rapidement du risque opérationnel.

15. La responsabilité d'explication est insuffisante dans les catégories santé, finance ou enfants

Les applications médicales ou santé, finance ou investissement, destinées aux enfants, ou utilisant en continu la localisation sont examinées plus strictement que les catégories générales. Il vaut mieux partir du principe qu'un niveau plus élevé est attendu en matière d'exactitude, de conformité, de clarté sans ambiguïté et d'information de contact.

Dans ce type de catégorie, une formule marketing qui semble pratique peut se retourner contre vous. Les formulations autour de la santé ou de l'investissement doivent éviter les promesses de résultat, les formulations trompeuses et les attentes excessives.

En pratique, on réduit les risques en revoyant ces angles:

• Médical ou santé: évitez-vous d'affirmer un diagnostic ou un traitement de façon catégorique?
• Finance: évitez-vous de garantir des gains ou de susciter des attentes excessives?
• Enfants: les liens externes, publicités ou parcours de paiement ne sont-ils pas trop agressifs?
• Localisation permanente: la collecte en continu est-elle vraiment nécessaire, ou existe-t-il une alternative?

Dans cette catégorie, il est plus important de vérifier si vous n'en dites pas trop et si vous assumez bien votre devoir d'explication que d'ajouter de nouvelles fonctions.

Comment lire les formulations de rejet les plus courantes

Les messages de revue sont souvent courts et abstraits. Pris tels quels, il est difficile de savoir quoi corriger. En pratique, il devient plus simple d'agir si on les relit de la manière suivante.

L'important est de lire la formulation de revue comme une spécification. Même lorsqu'elle paraît abstraite, elle se range généralement dans l'une des catégories suivantes: application inachevée, explication insuffisante ou déclaration incohérente.

Points faciles a manquer sur Google Play

Conditions de première mise en ligne pour un nouveau personal account

Pour les lecteurs qui publient pour la première fois sur Google Play, ce point est particulièrement important. Un personal developer account nouvellement créé possède des exigences liées au compte pour accéder à la production, indépendamment du contenu de l'application.

Les plus représentatives sont ces deux-ci:

• Au moins 12 testers doivent participer de façon continue au closed test
• La device verification sur Android via la Play Console mobile app doit être terminée

Cela agit moins comme un e-mail de rejet classique que comme un blocage dans la Play Console qui empêche d'accéder à production. En d'autres termes, même si l'application est prête, elle ne peut pas être publiée si les conditions côté compte ne sont pas remplies.

Points de blocage fréquents lors d'une première publication:

• Le nombre de testers est suffisant, mais la condition d'opt-in continu pendant 14 jours n'est pas remplie
• Les testers ont rejoint le test, mais l'usage réel ou le feedback restent faibles
• Le propriétaire du compte n'a pas terminé la device verification
• On pense qu'un internal test suffit et on oublie la condition de closed test

Pour une première publication, il est plus sûr de traiter ces prérequis très tôt, en parallèle des vérifications d'implémentation.

Retard dans le suivi du target SDK

Les exigences de Google Play concernant le target API level évoluent en continu. Il faut donc adopter une pratique consistant à vérifier dans la Play Console la valeur exigée au moment de la soumission, et non la valeur qui était actuelle au moment de la rédaction de cet article.

Ce qui prête facilement à confusion ici, c'est la différence entre targetSdkVersion et minSdkVersion.

• targetSdkVersion: Jusqu'où l'on se déclare compatible avec les comportements récents d'Android
• minSdkVersion: Jusqu'à quelle ancienneté d'Android on continue à prendre en charge

Autrement dit, même si minSdkVersion ne change pas, Google Play peut bloquer la soumission simplement parce que targetSdkVersion est trop bas au regard de l'exigence actuelle.

android {
    compileSdkVersion rootProject.ext.compileSdkVersion

    defaultConfig {
        targetSdkVersion rootProject.ext.targetSdkVersion
        minSdkVersion 24
    }
}

L'important est de ne pas s'arrêter à un simple changement de chiffre. Monter le target SDK peut modifier le modèle de permissions, les restrictions de fond, le comportement des notifications, les foreground services, l'accès aux fichiers, etc. Lors d'une mise à jour, il faut vérifier ensemble:

• La compatibilité de l'Android Gradle Plugin et des dépendances
• Les différences de comportement des dialogues de permissions
• Les restrictions sur les notifications et les traitements d'arrière-plan
• Les tests sur les principaux appareils cibles

Des permissions sensibles restent dans le manifest

Si des permissions sensibles non utilisées restent dans le manifest, cela crée à lui seul un devoir d'explication. CONTACTS, CALL_LOG, SMS et READ_PHONE_STATE méritent en particulier une revue attentive.

<!-- Ne déclarez pas des permissions non utilisées -->
<!-- <uses-permission android:name="android.permission.READ_CONTACTS" /> -->
<!-- <uses-permission android:name="android.permission.READ_CALL_LOG" /> -->

Data safety ne correspond pas à l'implémentation

Il est plus fréquent qu'on ne le pense d'ajouter un Analytics SDK ou un SDK publicitaire et de laisser la déclaration Console dans un état obsolète. Chaque changement de SDK devrait inclure Data safety dans la liste des éléments à mettre à jour.

Data safety est la section de Google Play dans laquelle on déclare quelles données l'application collecte ou partage et à quoi elles servent. App Privacy côté Apple suit une logique proche, et tout écart avec l'implémentation fait baisser la confiance.

La méthode la plus sûre est de ne pas remplir cela à l'intuition, mais de faire un véritable inventaire:

• Lister les SDK présents
• Vérifier les types de données manipulées par chacun
• Recenser aussi les données envoyées par vos API maison
• Comparer le tout avec les déclarations dans Play Console / App Store Connect
• Si quelque chose a changé, mettre à jour aussi la politique de confidentialité

Demander les permissions au moment ou elles servent

Une conception qui enchaîne plusieurs dialogues de permissions juste après le lancement laisse facilement une mauvaise impression aux utilisateurs comme aux reviewers.

La meilleure politique est la suivante:

• Demander la permission lorsque l'utilisateur atteint la fonctionnalité
• Afficher juste avant une courte explication pre-permission
• Prévoir un parcours alternatif en cas de deny

Cela aide non seulement pour la revue, mais améliore aussi souvent le taux d'acceptation.

Ce qu'il faut écrire dans les notes de soumission

Le champ de commentaires de revue est souvent sous-estimé, alors qu'il est crucial pour réduire les hésitations du reviewer. Il est particulièrement utile pour les apps avec login obligatoire, usage de permissions ou dépendance à des appareils externes.

Informations utiles à inclure:

• Les identifiants du demo account
• Les étapes pour atteindre les fonctions principales
• L'explication de l'écran ou les permissions sont utilisées
• Des précisions si 2FA ou un rôle particulier est requis
• Des précisions s'il existe une dépendance a un serveur ou à un appareil externe

Exemple de modèle court:

Compte de revue:
Email: reviewer-demo@example.com
Password: xxxxxxxx

Flux de test principal:
1. Se connecter avec le compte de revue
2. Ouvrir l'onglet Map pour tester la permission de localisation
3. Ouvrir Settings > Subscription pour vérifier l'explication de résiliation

Ligne de conduite après un rejet

Après un rejet, l'important n'est pas de répondre de manière émotionnelle, mais de classer correctement le problème signalé.

L'ordre de travail de base est le suivant:

1. Relire le message exactement tel qu'il a été écrit
2. Vérifier les conditions de reproduction
3. Le classer en défaut d'implémentation, explication manquante ou erreur déclarative
4. Ajouter si besoin des captures d'écran ou une vidéo

Même lorsqu'il semble y avoir une erreur de jugement, il est souvent plus rapide de combler d'abord le manque d'explication. En pratique, mieux vaut considérer l'appel comme le dernier recours.

Dans la réponse elle-même, il est généralement plus efficace d'écrire brièvement et clairement ce qui a changé plutôt que de produire une longue défense.

Merci pour la revue.

Nous avons identifié le problème comme [implementation / metadata / clarification].
Nous avons apporté les modifications suivantes:
1. Correction de [issue]
2. Mise a jour de [metadata or review notes]
3. Ajout de [account / explanation / screenshot]

Comment vérifier:
1. Se connecter avec le compte de revue
2. Ouvrir [screen name]
3. Appuyer sur [action]

Si nécessaire, nous pouvons fournir des captures d'écran supplémentaires ou un enregistrement d'écran.

En pratique, trois points suffisent: la cause, ce qui a été changé et comment vérifier. Plus une équipe s'enlise dans les allers-retours de revue, plus ces trois points ont tendance à se mélanger et à compliquer la communication.

Ce qu'il faut faire dans les 48 heures avant la soumission

Juste avant une mise en ligne, l'envie d'ajouter encore une fonctionnalité est forte. Pourtant, si l'objectif est d'augmenter le taux de passage en revue, il est généralement plus efficace d'utiliser la dernière ligne droite pour la vérification plutôt que pour l'implémentation.

48 heures avant

• Revoir la description du store, les captures d'écran, la classification par âge et Data safety / App Privacy
• Faire l'inventaire des SDK utilisés et de la liste des permissions
• Préparer le compte reviewer et les notes de revue

24 heures avant

• Vérifier le lancement sur le dernier iPhone OS, une version iOS précédente et plusieurs appareils Android
• Tester le mode avion, un réseau lent et l'état après installation propre
• Parcourir de bout en bout le paiement, le login, les demandes de permissions et le parcours de suppression de compte

6 heures avant

• Faire une dernière passe pour vérifier que les captures correspondent encore à l'application réelle
• Vérifier qu'il n'y a aucun écart entre les déclarations store et la configuration SDK
• Rédiger complètement les notes de revue avec le chemin d'accès aux fonctions principales et les compléments nécessaires

Le simple fait d'appliquer ce flux des 48 heures à chaque release suffit déjà souvent à réduire fortement le taux de rejet.

Pratiques opérationnelles pour éviter les récidives

Même après une validation réussie, les mêmes problèmes reviennent facilement avec de nouvelles fonctions ou des changements de SDK. En solo comme en équipe, les pratiques suivantes réduisent nettement les incidents:

• Lorsqu'un SDK est ajouté, traiter permissions, Data safety et App Privacy comme une mise à jour unique
• Limiter le texte du store aux fonctions réellement implémentées
• Lorsqu'une nouvelle permission est ajoutée, vérifier dans le PR l'écran d'usage et le texte explicatif ensemble
• Transformer la checklist avant release en issue ou modèle réutilisable
• Conserver les formulations de rejet et les réponses apportées pour les réutiliser dans les prochaines notes de revue

Le gain le plus durable consiste a ne plus traiter la réponse au review comme quelque chose qu'on improvise à chaque fois.

Checklist avant soumission

On repère plus facilement les oublis si la checklist est séparée en formes directement utilisables pour chaque store. Même les points communs sont inclus dans chaque tableau.

Checklist App Store avant soumission

Checklist Google Play avant soumission

Résumé

Ce qui bloque le plus souvent les revues d'applications, ce ne sont pas les bugs simples, mais les écarts entre implémentation et explication ainsi que les insuffisances de préparation opérationnelle.

Les quatre points les plus importants sont les suivants:

• Le reviewer peut vérifier les fonctions principales sans hésitation
• Les raisons des permissions et de la collecte de données sont expliquées concrètement
• Les règles de paiement et les déclarations store sont correctement alignées
• Les métadonnées du store correspondent à l'implémentation réelle

Plus on approche du release, plus la tentation d'ajouter une dernière fonction augmente. Mais si l'objectif est d'améliorer le taux de passage en revue, il est plus efficace d'utiliser la dernière journée pour épuiser la checklist.

Liens de référence

• App Store Review Guidelines
• Auto-renewable subscriptions
• Google Play Policy Center
• Human Interface Guidelines
• In-App Purchase (Human Interface Guidelines)
• Distributing reader apps with a link to your website
• App testing requirements for new personal developer accounts
• Device verification requirements for new developer accounts
• Target API level requirements for Google Play apps
• App Tracking Transparency