L'ordre compte plus que n'importe quelle étape prise séparément. Ce qu'il vous faut avant de pouvoir soumettre, le bouton qui ne soumet pas votre app, et la guideline derrière 40 % des revues qui échouent.
Publier demande quatre choses, dans cet ordre : un compte Apple Developer payant à 99 USD par an, un contrat signé, une fiche d'app dans App Store Connect, et un build rattaché à celle-ci. Apple examine ensuite, et traite 90 % des soumissions en moins de 24 heures.
La plupart des premières soumissions n'échouent pas sur le code. Elles échouent parce qu'un élément de cette liste a été sauté.
Ce qu'il vous faut avant de pouvoir soumettre quoi que ce soit
| Étape | Détail |
|---|---|
| Apple Developer Program | 99 USD par année d'adhésion. Les particuliers doivent donner leur véritable nom légal, pas un pseudonyme, et une adresse physique. Pas de boîte postale. |
| Numéro D-U-N-S | Organisations uniquement. Gratuit auprès de Dun & Bradstreet, jusqu'à 5 jours ouvrés pour être émis, puis jusqu'à 2 de plus pour qu'Apple le reçoive. |
| Contrats | C'est l'Account Holder qui signe. Vendre quoi que ce soit, achats intégrés compris, exige le Paid Apps Agreement plus les informations fiscales et bancaires. |
| Bundle ID | Enregistré dans Certificates, Identifiers & Profiles. Explicite pour une app unique. |
| Fiche d'app | Créée dans App Store Connect avant votre premier envoi. Xcode propose de la créer pour vous. |
| Build | Envoyé et traitement terminé. Apple vous envoie un e-mail quand c'est fait. |
L'ordre est celui d'Apple : signer le contrat et saisir les informations fiscales et bancaires, ajouter utilisateurs et rôles, ajouter l'app et envoyer un build, tester et soumettre, puis surveiller.
Si vous êtes une organisation, lancez d'abord la demande de D-U-N-S. C'est la seule étape de la liste avec une file d'attente que vous ne contrôlez pas, et elle peut manger une semaine avant que vous ayez écrit une ligne de texte de store.
Ce qui doit être rempli
Obligatoire : nom de l'app, catégorie principale, déclaration de droits sur le contenu, classification d'âge, numéro de version, build. Optionnel mais utile : sous-titre, texte promotionnel, URL de support, catégorie secondaire.
Deux choses qu'on oublie.
L'URL de la politique de confidentialité. Les pages d'Apple ne s'accordent pas sur son caractère techniquement obligatoire, mais la guideline 5.1.1 dit que toute app doit inclure un lien vers sa politique de confidentialité — et il doit être accessible depuis l'app aussi, pas seulement depuis votre fiche. Traitez-la comme obligatoire.
Les déclarations App Privacy. Vous déclarez quelles données votre app collecte et quelles données collectent vos partenaires tiers. C'est sur cette seconde moitié que ça coince : vous répondez pour les SDK que vous avez intégrés, pas seulement pour votre propre code. Depuis mai 2024, les apps qui ne décrivent pas leur usage des required-reason API dans un privacy manifest sont rejetées par App Store Connect avant même qu'un humain les voie.
Les captures demandent une taille pour iPhone et une pour iPad. Le guide des captures donne les dimensions et les règles de contenu.
Le bouton qui ne soumet pas votre app
Dans App Store Connect, vous cliquez Add for Review. Le statut passe à Ready for Review.
Votre app n'est pas soumise. Ready for Review signifie que vous avez déclaré une intention. La soumission ne part chez Apple que lorsque vous ouvrez la draft submission et cliquez Submit for Review — le statut devient alors In Review.
Certains y perdent des jours. Regardez le statut, pas le bouton sur lequel vous avez appuyé en dernier.
La guideline qui fait échouer le plus de premières soumissions
Apple publie le chiffre : plus de 40 % des problèmes non résolus concernent la guideline 2.1, App Completeness.
Cette guideline ne parle pas de qualité de code. Elle parle de savoir si la personne qui examine peut réellement utiliser votre app. Dans les mots d'Apple : les soumissions doivent être des versions finales, avec toutes les métadonnées nécessaires et des URL fonctionnelles, et le texte de remplissage et les sites vides doivent être nettoyés avant la soumission.
Ce qui coince concrètement :
Pas de compte de démonstration. Si votre app a une connexion, vous devez fournir des identifiants qui marchent — et Apple ajoute une parenthèse qui dit à quelle fréquence ça rate : allumez votre service back-end. Un compte de démo qui pointe vers un serveur éteint équivaut à pas de compte de démo.
Des notes de revue génériques. La guideline 2.3.1 exige de décrire précisément les nouvelles fonctionnalités dans le champ Notes for Review, et dit clairement que les descriptions génériques sont rejetées.
Des achats intégrés qui ne sont pas actifs. Ils doivent être complets, visibles pour la personne qui examine, et fonctionnels.
Pas de suppression de compte. Guideline 5.1.1(v) : si les gens peuvent créer un compte dans votre app, ils doivent pouvoir le supprimer dans votre app. Pas en vous envoyant un e-mail.
TestFlight, et si vous en avez besoin
Non. Apple recommande les tests bêta mais ne les exige pas.
Si vous l'utilisez : jusqu'à 100 testeurs internes, jusqu'à 10 000 externes. Les tests internes ne passent pas en revue. Les externes, si. Le premier build que vous ajoutez à un groupe externe passe par App Review, et les builds suivants peuvent ne pas nécessiter de revue complète. Les builds expirent au bout de 90 jours.
Cette première revue externe vaut d'être connue avant de promettre une bêta à qui que ce soit. C'est une file distincte, avec ses propres statuts, et Apple ne publie aucun délai pour elle.
Choisir la mise en ligne
Trois options, avec les libellés d'Apple : publier cette version manuellement, la publier automatiquement, ou la publier automatiquement après la revue, pas avant une date que vous choisissez.
La publication manuelle gare l'app en Pending Developer Release. Apple envoie un rappel par e-mail si elle y reste plus de 30 jours. Après avoir appuyé sur publier, elle peut mettre jusqu'à 24 heures à apparaître sur le store.
Le déploiement progressif est fait pour les mises à jour, pas pour les nouvelles apps. Il se déroule sur sept jours à 1 %, 2 %, 5 %, 10 %, 20 %, 50 %, puis 100 %, et ne gouverne que les mises à jour automatiques. N'importe qui peut télécharger la nouvelle version manuellement pendant tout ce temps. Vous pouvez suspendre jusqu'à 30 jours au total et reprendre où vous en étiez, ou terminer plus tôt avec Release to All Users.
Pour une première publication, le choix utile est la programmation : prenez une date assez lointaine pour que la revue ne vous la fasse pas manquer, et avancez-la si vous sortez tôt.
Quatre choses qui ont changé récemment
Le SDK Xcode 26 est le plancher. Depuis le 28 avril 2026, les envois doivent être compilés avec Xcode 26 et le SDK iOS 26 ou plus récent.
Les classifications d'âge ont été refondues. Les paliers sont désormais 4+, 9+, 13+, 16+ et 18+, et tout a migré le 31 janvier 2026. Le questionnaire interroge maintenant sur les contrôles intégrés, les sujets médicaux et de bien-être, et les fonctions d'assistant IA ou de chatbot.
Les questions sur les réseaux sociaux sont devenues obligatoires en septembre 2026. Elles ajoutent un descripteur Réseaux sociaux à votre page produit et alimentent les Time Allowances parentales. Si vous désactivez les fonctions sociales pour les moins de 13 ans, votre app n'est pas comptée dans ce quota.
Le statut de professionnel dans l'UE s'applique même si vous n'y distribuez pas. Vous devez quand même le déclarer. Si vous y distribuez, votre adresse vérifiée, votre téléphone et votre e-mail sont publiés publiquement sur votre page produit dans les 27 territoires. Les particuliers peuvent, pour ce cas précis, fournir une boîte postale.
Par contraste, Google Play
Vingt-cinq dollars, une fois, pas par an. Vérification d'identité avec une pièce officielle et une carte bancaire au même nom légal.
Le piège est plus récent : les comptes Play Console personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs inscrits en continu pendant 14 jours avant de pouvoir demander l'accès à la production. Cette demande est elle-même examinée, généralement sous sept jours.
La forme est donc inversée. Apple coûte plus cher par an et peut vous mettre en ligne en un jour. Play coûte moins et peut retenir trois semaines un développeur solo qui publie pour la première fois, avant même que l'app soit examinable.
Ce qu'Uprate en fait
L'agent de soumission passe vos soumissions Apple et Google au crible des blocages et revient avec le champ exact et le correctif. Avant que vous soumettiez, pas après qu'Apple vous l'a renvoyée.
Rien ne passe en ligne tant que vous ne l'avez pas approuvé.
Cet article vous a-t-il aidé ?
