Dans cet article
- Huit raisons pour lesquelles la revue de l'App Store vous renvoie votre application
- 1 — Il n'existe aucun compte de démonstration pour que le relecteur ouvre votre application
- 2 — La boutique voit votre application comme un site web réemballé
- 3 — La politique de confidentialité est incomplète ou absente de l'application
- 4 — Il n'y a pas de suppression de compte dans l'application
- 5 — La déclaration de sécurité des données de Google Play ne correspond pas à ce que fait l'application
- 6 — La mise à jour est refusée parce que l'application cible une version Android ancienne
- 7 — Les nouveaux comptes exigent 12 testeurs et 14 jours avant publication
- 8 — Les métadonnées de la boutique, les captures d'écran, et une application distincte par agence
- Comment cette étape s'inscrit dans le plan du projet
Huit raisons pour lesquelles la revue de l'App Store vous renvoie votre application
La réponse courte : la plupart des refus d'applications sur l'App Store et Google Play ne viennent pas d'un défaut de code. Ils viennent d'éléments administratifs que le dirigeant contrôle, pas le développeur — un compte de démonstration avec lequel le relecteur peut se connecter, une politique de confidentialité complète, une déclaration de données conforme à la réalité, un compte développeur au nom de l'entreprise, et une échéance technique déjà passée. Chacun de ces points peut être préparé deux semaines avant le lancement sans écrire une seule ligne de code.
L'effet sur le calendrier est plus important qu'il n'y paraît. Un refus ne signifie pas que l'application est mauvaise ; il signifie qu'elle repart en fin de file d'attente après chaque correction, de sorte qu'une campagne de lancement liée à une saison ou à un événement se transforme en report sans date. C'est pourquoi le dossier de publication mérite d'être traité comme une partie du projet, et non comme de la paperasse laissée au dernier jour.
1 — Il n'existe aucun compte de démonstration pour que le relecteur ouvre votre application
C'est la raison la plus répétée dans les applications qui commencent par un écran de connexion. Le relecteur n'est pas l'un de vos clients et n'a aucun numéro de téléphone enregistré dans votre système : sans identifiants prêts, il s'arrête donc au premier écran. La règle d'exhaustivité de l'application (2.1) d'Apple est explicite : soumettez une version finale, joignez les informations d'un compte de démonstration si votre application comporte une connexion, et activez votre service côté serveur. Si des obligations juridiques ou de sécurité vous empêchent de fournir un compte réel, vous pouvez inclure un mode démonstration intégré qui montre toutes les fonctionnalités de l'application, avec l'accord préalable d'Apple.
En pratique : préparez un compte permanent qui n'expire pas et qui n'est pas effacé lors des nettoyages de données, et assurez-vous que les serveurs de préproduction tournent pendant la fenêtre de revue, et pas seulement pendant vos heures de bureau.
2 — La boutique voit votre application comme un site web réemballé
La règle de fonctionnalité minimale (4.2) indique qu'une application doit comporter des fonctions, du contenu et une interface qui l'élèvent au-delà d'un site web réemballé, et que les applications qui sont essentiellement des supports marketing, des extraits web, des agrégateurs de contenu ou une collection de liens ne sont pas acceptables. Beaucoup d'entreprises demandent une application parce qu'un concurrent en a une, et le produit sort comme une copie du site web dans une coquille.
Il y a deux issues : soit donner à l'application une valeur réelle que le navigateur ne peut pas offrir — usage hors connexion, notifications pilotées par l'état de la commande, lecture de codes-barres, données stockées sur l'appareil, intégration des paiements et des cartes — soit publier une application web progressive au lieu de passer par les boutiques. Nous avons traité ce choix dans application web progressive ou application native.
3 — La politique de confidentialité est incomplète ou absente de l'application
La règle de collecte de données (5.1.1) d'Apple exige un lien vers la politique de confidentialité dans les métadonnées d'App Store Connect et à l'intérieur de l'application, à un endroit facilement accessible. La politique doit préciser quelles données sont collectées, comment, et chacun de leurs usages ; confirmer que tout tiers avec lequel vous partagez des données — outils d'analyse, régies publicitaires, kits de développement tiers — offre la même protection ; et expliquer les politiques de conservation et de suppression ainsi que la façon dont un utilisateur retire son consentement.
Ce n'est pas une page que l'on copie depuis un autre site. C'est une description de ce que votre système fait réellement, et elle doit correspondre à vos obligations au titre de la loi saoudienne sur la protection des données personnelles (PDPL), comme l'explique notre guide pratique de la PDPL.
4 — Il n'y a pas de suppression de compte dans l'application
La règle 5.1.1 (v) est claire : si votre application permet la création d'un compte, vous devez aussi offrir la suppression du compte depuis l'application. Elle ajoute une règle que beaucoup d'équipes manquent : si votre application ne comporte pas de fonctions importantes liées au compte, laissez les personnes l'utiliser sans connexion, et n'exigez pas d'informations personnelles à moins qu'elles ne soient directement liées à la fonction principale ou requises par la loi.
La suppression de compte n'est pas seulement un bouton dans l'interface ; c'est un chemin complet côté serveur. Qu'advient-il des commandes, des factures et des écritures comptables du client, qui ne peuvent pas légalement être supprimées ? La réponse habituelle consiste à séparer les données d'identité des documents financiers avant le début du développement, pas après.
5 — La déclaration de sécurité des données de Google Play ne correspond pas à ce que fait l'application
Google exige de chaque développeur qu'il déclare les données que l'application collecte et transmet hors de l'appareil, y compris les données collectées par des bibliothèques et des kits de développement tiers, si la collecte est obligatoire ou facultative, sa finalité, si les données sont chiffrées en transit, et s'il existe un mécanisme de demande de suppression. La politique précise que le développeur est seul responsable de l'exactitude des déclarations, et que les manquements conduisent au blocage des mises à jour ou au retrait de Google Play.
L'erreur courante est simple : un développeur a ajouté un outil d'analyse ou de remontée de plantages pour se faciliter le travail, et personne ne l'a inscrit dans la déclaration. Posez une seule question à votre équipe avant de soumettre : quelle est la liste complète des paquets tiers dans cette application, et qu'envoie chacun d'eux ?
6 — La mise à jour est refusée parce que l'application cible une version Android ancienne
Depuis le 31 août 2026, Google Play exige que les nouvelles applications et les mises à jour ciblent Android 16 (niveau d'API 36) ou une version supérieure, avec des exceptions : Wear OS et Android Automotive au niveau 35, et Android TV et Android XR au niveau 34. Les développeurs qui ont demandé une prolongation ont jusqu'au 1er novembre 2026.
La conséquence opérationnelle pour un dirigeant : votre application publiée reste dans la boutique, mais vous ne pouvez plus livrer aucune mise à jour — pas même un correctif de sécurité urgent ou un changement de prix — tant qu'elle n'est pas reconstruite sur le niveau exigé. Toute application qui n'a pas été mise à jour depuis un an mérite une vérification sur ce point avant que vous n'ayez besoin d'une publication urgente.
7 — Les nouveaux comptes exigent 12 testeurs et 14 jours avant publication
Les comptes développeur personnels créés après le 13 novembre 2023 sur Google Play ne peuvent pas publier publiquement d'emblée. Ils doivent passer par un test fermé avec au moins 12 testeurs inscrits en continu pendant au moins 14 jours avant de demander l'accès à la production. Cela représente deux semaines supplémentaires au calendrier et 12 personnes réelles avec de vrais comptes Google.
De l'autre côté, l'inscription au programme Apple Developer en tant qu'organisation exige un numéro D-U-N-S et une entité juridique capable de contracter, sous la dénomination légale de l'organisation — pas un nom commercial et pas une succursale. Obtenir le numéro et passer la vérification prend des jours. Lancez cela la première semaine du projet, pas la semaine du lancement.
8 — Les métadonnées de la boutique, les captures d'écran, et une application distincte par agence
Trois petites règles coulent des versions entières : les captures d'écran doivent montrer l'application en cours d'utilisation, et non l'illustration du titre, la page de connexion ou l'écran de démarrage (2.3.3) ; le nom de l'application est limité à 30 caractères et les métadonnées ne peuvent pas être bourrées de termes déposés, de noms d'applications populaires ou de prix (2.3.7) ; et vous ne pouvez pas créer plusieurs identifiants de paquet pour la même application (4.3a) — ce qui est exactement ce qui arrive quand une entreprise demande une application distincte par agence ou par ville. Le bon schéma est une seule application dans laquelle l'utilisateur choisit l'agence.
Comment cette étape s'inscrit dans le plan du projet
- Enregistrez le compte développeur au nom de votre entreprise, pas à celui du développeur ni de l'agence. C'est un actif de l'entreprise, comme le nom de domaine, ainsi que nous l'avons traité dans à qui appartiennent les droits sur votre logiciel.
- Ouvrez les comptes la première semaine : Apple facture 99 $ par an et Google Play 25 $ une seule fois, et c'est la vérification, non le paiement, qui prend du temps.
- Insérez une clause dans le contrat désignant qui soumet la version et répond aux remarques de la revue, et combien de cycles de revue le prix couvre.
- Traitez le dossier de publication comme un livrable à part entière : politique de confidentialité, déclaration de données, captures d'écran, description, compte de démonstration, et liste des paquets tiers.
Le code se termine une semaine avant le lancement. Le dossier de publication demande deux semaines. Se tromper sur cet ordre est à l'origine de la plupart des lancements retardés.
Sources
Questions fréquentes
Combien de temps prend généralement l'approbation sur les deux boutiques ?
La revue elle-même prend en général d'un à trois jours par soumission, mais la durée réelle dépend du nombre de refus que vous recevez. Prévoyez deux semaines pour le dossier de publication avant de soumettre, une semaine de marge pour au moins un cycle de refus et de correction, et deux semaines de plus si le compte Google Play est nouveau et doit encore passer son test fermé.
Notre application est publiée depuis deux ans sans mise à jour. Tout va bien ?
L'application reste disponible au téléchargement, mais aucune nouvelle mise à jour ne sera acceptée sur Google Play si elle ne cible pas Android 16 (niveau d'API 36), une exigence en vigueur depuis le 31 août 2026. Le problème surgit brusquement le jour où vous avez besoin d'un correctif de sécurité ou d'un changement de prix et où vous découvrez qu'une petite mise à jour exige une reconstruction. Vérifiez-le maintenant, pas pendant une urgence.
Avons-nous besoin d'une application distincte pour chacune de nos agences ?
Non, et la règle anti-duplication d'Apple l'interdit explicitement : vous ne pouvez pas créer plusieurs identifiants de paquet de la même application avec une version différente par ville ou par site. La bonne approche est une seule application dans laquelle l'utilisateur choisit l'agence, ce qui est aussi moins cher à construire et à maintenir et meilleur pour votre visibilité dans la recherche de la boutique.
Le compte développeur est au nom de l'agence qui a développé l'application. Quel est le risque ?
Le risque est que l'application, ses avis, ses notes et son historique de téléchargements soient des actifs rattachés à un compte que vous ne possédez pas, et que leur transfert ultérieur exige le consentement de l'autre partie et une procédure de cession. Enregistrez le compte sous votre entité juridique dès le départ et donnez à l'agence un accès délimité que vous pourrez révoquer à la fin du contrat.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
