Comment les apps sont approuvees sur l'App Store et Google Play
L'examen refuse chaque jour des coquilles web vides, des liens morts et des failles de confidentialite. Voici pourquoi les apps sont refusees, ce que verifient les examinateurs et comment passer sur les deux stores.
Pourquoi l'examen existe (et ce qu'il teste vraiment)
Avant d'atteindre le moindre utilisateur, votre app passe par l'examen d'Apple et de Google. Cet examen n'est pas la pour vous compliquer la vie : il protege les gens des apps dangereuses, cassees, trompeuses ou tout simplement vides. Pour faire approuver votre app sur l'App Store et Google Play, vous devez satisfaire deux corpus de regles distincts : les App Review Guidelines d'Apple et les Regles du programme pour les developpeurs de Google Play.
Les deux stores se rejoignent sur l'essentiel — securite, confidentialite, metadonnees honnetes et fonctionnalite reelle — mais different par le ton et le processus. L'examen d'Apple est plus strict et largement manuel : une personne ouvre votre app et l'utilise. Google s'appuie davantage sur l'analyse automatique, avec des examinateurs humains pour les cas limites. Au fond, les deux posent la meme question : 'est-ce un produit reel, sur et utile ?'. Une fois cela integre, vous cessez de deviner et vous concevez pour l'approbation.
Les motifs de refus les plus frequents
Le grand fautif reste la coquille web vide. La directive 4.2 d'Apple (fonctionnalite minimale) indique explicitement qu'une app doit proposer des fonctions, du contenu et une interface qui depassent un site web reempaquete, et Google Play sanctionne les apps qui ne sont qu'un habillage d'un site mobile sans valeur ajoutee. Si votre app est un navigateur pointe vers votre URL, attendez-vous a un refus.
Les autres causes sont pratiques : liens morts ou ecrans sans issue, plantages et bugs pendant l'examen, une politique de confidentialite absente ou inaccessible, des declarations de confidentialite incompletes (les etiquettes d'Apple, le formulaire Securite des donnees de Google), le suivi des utilisateurs sans l'invite App Tracking Transparency d'Apple, des captures ou metadonnees trompeuses, et des murs de connexion sans identifiants de test pour l'examinateur. Chacune est evitable et documentee : ce sont des raisons repetables de voir une soumission rejetee.
Ce que les examinateurs recherchent vraiment
Les examinateurs suivent une courte liste mentale. D'abord : l'app fait-elle quelque chose de natif et d'utile, ou est-ce une page qu'on pourrait ouvrir dans Safari ou Chrome ? Ensuite : est-elle stable — pas de plantages, pas d'ecrans blancs, pas de parcours manifestement casses ? Enfin : est-elle honnete — les captures, la description et la categorie correspondent-elles a ce que l'app fait reellement ?
Viennent ensuite la confidentialite et les autorisations. Si votre app demande la camera, la localisation ou les notifications, l'examinateur attend une raison claire et contextuelle, et une declaration de confidentialite coherente. Si elle gere des comptes, il doit pouvoir entrer : un identifiant de test qui fonctionne (ou un mode invite) est donc non negociable. Enfin, il verifie la classification du contenu, les options de connexion et les regles propres a chaque plateforme. Rien n'est secret — tout figure dans les guides — mais il faut vraiment s'y conformer, pas seulement le declarer.
Pourquoi une vraie app native passe l'examen (et pas une coquille fine)
La voie la plus fiable pour franchir la fonctionnalite minimale est d'offrir au store un comportement natif reel. Une vraie app native — une coquille Swift sur iOS, une coquille Kotlin sur Android — qui charge votre site en direct dans un conteneur natif performant et ajoute des fonctions de l'appareil via un pont JavaScript est un produit d'une autre categorie qu'un simple habillage. Notifications push, mode hors ligne, connexion biometrique, deep links, camera, widgets sur l'ecran d'accueil et raccourcis d'app sont exactement la 'valeur native' que les examinateurs doivent rechercher.
C'est l'approche de Transform To APP. Le contenu publie sur votre site continue d'apparaitre instantanement dans l'app — sans resoumission pour un article ou un changement de prix — tandis que la coquille native fournit la fonctionnalite qui satisfait les deux stores. Vous obtenez les mises a jour rapides du web et la profondeur native qui passe l'examen, sans avoir a choisir.
Votre checklist avant soumission sur les deux stores
Passez-la en revue avant de cliquer sur 'Soumettre'. Elle evite la plupart des refus evitables :
- Valeur native : au moins une ou deux vraies fonctions de l'appareil (push, hors ligne, biometrie, camera, widgets), pas juste une URL chargee. - Stabilite : testez sur un appareil reel ; pas de plantages, pas d'ecrans blancs, chaque lien et bouton fonctionne. - Politique de confidentialite : URL active et accessible, reliee dans l'app et dans la fiche du store. - Declarations : etiquettes de confidentialite Apple et formulaire Securite des donnees Google remplis avec exactitude ; invite ATT si vous suivez. - Autorisations : ne demandez que ce que vous utilisez, chacune avec une explication claire et contextuelle. - Acces : compte de test operationnel ou mode invite pour l'examinateur en cas de connexion. - Metadonnees : captures et description conformes a l'app reelle ; categorie et classification correctes.
Cochez chaque case et vous supprimez presque toutes les raisons de vous refuser.
Publier sous vos propres comptes developpeur
L'approbation depend aussi de l'endroit ou vit l'app. Les deux stores exigent des comptes developpeur : l'Apple Developer Program coute 99 USD par an et un compte developpeur Google Play est un paiement unique de 25 USD. Publier sous vos propres comptes fait porter a l'app votre marque, votre icone et le nom de votre entreprise, sans trace de tiers dans la fiche.
Transform To APP construit et soumet sous les comptes Apple et Google du client lui-meme, et non sous une identite d'editeur partagee : la fiche est donc entierement la votre et vous controlez les futures mises a jour. Comme le contenu circule depuis votre site en direct, seules les modifications natives exigent une nouvelle compilation et une nouvelle soumission — et nous nous en chargeons. Le resultat est une vraie app native qui passe l'examen, que vous possedez entierement, et qui reste a jour sans repasser par la file d'attente a chaque mot change sur votre site.
FAQ
Combien de temps dure l'examen d'une app ?+
Cela varie. Apple examine souvent en un a deux jours, tandis que Google peut aller de quelques heures a plusieurs jours, et les deux peuvent prendre plus de temps pour une premiere soumission, un point signale ou une periode chargee. Soumettez avec de la marge avant toute date de lancement et ne promettez jamais une sortie publique dependant d'une approbation le jour meme.
Une app creee a partir de mon site sera-t-elle refusee ?+
Une coquille fine qui ne fait que charger votre site sans fonctionnalite ajoutee est un motif courant de refus au titre de la fonctionnalite minimale d'Apple et de la regle equivalente de Google. Une vraie app native qui charge votre site en direct dans une coquille native et ajoute de vraies fonctions de l'appareil (push, hors ligne, biometrie, widgets) est exactement ce que recherchent les examinateurs, et passe donc l'examen.
Ai-je besoin de mes propres comptes developpeur Apple et Google ?+
Oui. L'Apple Developer Program coute 99 USD par an et un compte Google Play est un paiement unique de 25 USD. Publier sous vos propres comptes maintient l'app sous votre marque et vous donne la pleine propriete de la fiche et des futures mises a jour.
Que se passe-t-il si mon app est refusee ?+
Vous recevez le motif precis et la directive concernee. Dans la plupart des cas, vous corrigez le probleme et resoumettez ; beaucoup de refus se resolvent vite une fois la cause claire. Si vous estimez le refus injustifie, les deux stores proposent une procedure d'appel ou de resolution.
Si je mets a jour mon site, dois-je resoumettre l'app ?+
Non. Avec une app native qui charge votre site en direct, les changements de contenu — nouveaux articles, produits ou prix — apparaissent instantanement dans l'app sans resoumission. Seules les modifications natives, comme une nouvelle fonction de l'appareil, exigent une recompilation et un nouvel examen.