Publier une app sur l'App Store tient en quatre éléments : un compte Apple Developer à 99 $ par an, un build signé envoyé sur App Store Connect, une fiche complète, et une review qui rend sa décision en moins de 48 heures dans 98 % des cas. Aucun de ces éléments n'est difficile isolément. Ce qui coûte du temps, c'est de les découvrir dans le désordre.
Le vrai risque n'est plus technique : la signature de build, cauchemar historique d'iOS, est aujourd'hui automatisée par les services de build cloud. Le risque, ce sont les refus évitables : un compte de démonstration oublié, un questionnaire de confidentialité bâclé, un paiement qui contourne l'achat intégré. Ce guide suit l'ordre réel des opérations et s'arrête sur chaque point qui fait échouer une première soumission. Si vous avez construit l'app avec un créateur d'application iOS sans code comme Cadrant, le build et la soumission sont guidés, et les règles de review restent les mêmes.
Il couvre uniquement iOS. Pour Android, le parcours est différent et fait l'objet d'un guide dédié : publier une app sur Google Play. Pour comparer les deux stores avant de vous lancer, notre checklist App Store et Google Play met les deux parcours côte à côte.
Ce qu'il faut préparer avant de commencer
Tout ce qui suit peut se préparer en parallèle du développement. Le jour de la soumission, il vous faut :
- Un compte Apple Developer actif. 99 $ par an, en tant que particulier ou en tant que société. Le compte société exige un numéro DUNS et permet de publier sous le nom de l'entreprise.
- Une app testée sur un vrai appareil. Le simulateur ne montre ni les performances réelles ni les permissions système.
- Une icône 1024 × 1024 en PNG, sans transparence et sans coins arrondis : Apple les applique lui-même.
- Une politique de confidentialité en ligne. Son URL est obligatoire dans la fiche, même pour une app qui ne collecte presque rien.
- Un compte de démonstration si votre app demande une connexion : identifiant et mot de passe valides, transmis dans les informations de review.
Combien coûte la publication sur l'App Store ?
Publier une application sur l'App Store, que beaucoup appellent encore l'Apple Store, coûte 99 $ par an et rien d'autre côté Apple : ni frais de soumission, ni commission sur une app gratuite. Le reste dépend de vos choix d'outillage. Voici les postes réels, hors développement de l'application elle-même.
| Poste | Prix | Remarque |
|---|---|---|
| Compte Apple Developer | 99 $ par an | Obligatoire, particulier ou société. Le compte expire si vous ne le renouvelez pas, et l'app est retirée du store avec lui. |
| Mac et Xcode | 0 $ | Plus nécessaires : un service de build cloud comme EAS compile et signe le binaire pour vous. Le plan gratuit d'Expo couvre 15 builds iOS par mois. |
| Politique de confidentialité | 0 $ | Une page sur votre site suffit ; les générateurs gratuits produisent un texte correct en dix minutes. |
| Commission Apple | 0 à 30 % | Seulement sur les ventes de contenu numérique via l'achat intégré : 15 % sous le programme Small Business, 30 % au-delà d'un million de dollars de revenus annuels. |
| Google Play, pour comparer | 25 $ une fois | Pas d'abonnement annuel côté Android, mais la règle des 12 testeurs pour un compte personnel. |
Pour une app gratuite publiée avec un outil de build cloud, la première année revient donc à 99 $, et chaque année suivante au même prix. Le budget de l'application elle-même est un autre sujet, détaillé dans notre guide sur le prix d'une application mobile.
Les six étapes, du build à la mise en ligne
Voici le parcours complet, dans l'ordre où il se passe réellement. Les délais indiqués supposent un dossier complet du premier coup.
- Inscrivez-vous à l'Apple Developer Program. L'inscription se fait sur developer.apple.com avec votre identifiant Apple et une vérification d'identité. C'est ce compte qui ouvre l'accès à App Store Connect, la console où vivent vos apps.
- Générez un build signé. Un binaire iOS doit être signé par un certificat de distribution et un profil de provisionnement liés à votre compte. Un service de build cloud comme EAS crée les deux automatiquement et compile sur des machines macOS distantes ; avec Xcode, vous le faites localement sur Mac.
- Créez la fiche sur App Store Connect. Nom affiché, identifiant de bundle (définitif, choisissez-le bien) et catégorie. La fiche peut rester en brouillon pendant que vous testez.
- Testez avec TestFlight. C'est le binaire exact que recevront vos utilisateurs, pas une preview. Les testeurs internes y accèdent immédiatement ; les testeurs externes après une courte beta review. Le fonctionnement complet est dans notre guide TestFlight : comment ça marche.
- Complétez la fiche. Description, mots-clés, captures d'écran iPhone (et iPad si votre app le supporte), questionnaire « App Privacy », classification d'âge, et les informations de review avec le compte de démonstration.
- Soumettez, puis publiez. Une fois la version approuvée, vous choisissez : publication immédiate, automatique dès l'approbation, ou progressive sur sept jours pour surveiller les premiers retours.
La review Apple : délais réels et motifs de refus
Apple annonce que 90 % des soumissions reçoivent une décision en moins de 24 heures, et 98 % en moins de 48 heures. En pratique, prévoyez un à trois jours ouvrés pour une première soumission. Les catégories réglementées (finance, santé, apps pour enfants) passent devant des reviewers spécialisés et peuvent demander des justificatifs, donc plusieurs jours de plus. La file ralentit aussi en septembre, autour de la sortie d'iOS, et avant le gel des fêtes en décembre.
Les motifs de refus sont très concentrés. Les App Review Guidelines en listent des dizaines, mais cinq familles couvrent l'essentiel des premières soumissions :
| Motif de refus | Guideline | Comment l'éviter |
|---|---|---|
| Crash ou bug au lancement | 2.1 | Tester le binaire TestFlight sur plusieurs appareils, pas seulement la preview. |
| Compte de démonstration absent ou invalide | 2.1 | Fournir un identifiant qui fonctionne, avec des données réalistes déjà en place. |
| Confidentialité : permissions injustifiées | 5.1 | Ne demander que les permissions utilisées, avec un texte d'explication clair pour chacune. |
| Paiement numérique hors achat intégré | 3.1.1 | Vendre du contenu numérique via l'achat intégré Apple ; les biens physiques peuvent utiliser un paiement externe. |
| App jugée trop minimale ou dupliquée | 4.2 / 4.3 | Apporter une vraie valeur applicative : un site reconditionné sans fonctionnalité propre est refusé. |
Un refus n'est pas une sanction : le Resolution Center indique le motif exact, vous corrigez, vous resoumettez. La deuxième review est souvent plus rapide que la première. Le cas échéant, notre guide sur les refus App Store et comment y répondre passe en revue les statuts, les huit motifs habituels et les options de réponse et d'appel.
Votre kit de soumission : checklist, textes à copier et calendrier
Les étapes ci-dessus disent quoi faire. Cette section donne ce qu'il faut cocher et ce qu'il faut coller. Gardez-la ouverte à côté d'App Store Connect : chaque ligne correspond à un champ qu'Apple vérifie avant qu'une version arrive chez un reviewer.
La checklist avant soumission
Les tailles et limites viennent des spécifications de captures d'écran d'Apple, de l'aide d'App Store Connect et des règles citées plus haut, vérifiées en octobre 2026.
| Élément | Ce qu'Apple attend | Où |
|---|---|---|
| ☐ Nom et sous-titre | 30 caractères chacun | Informations sur l'app |
| ☐ Texte promotionnel, description, mots-clés | 170 caractères, 4 000 caractères, 100 octets | Page de la version |
| ☐ Captures iPhone | 1 à 10 en 1206 × 2622 ou 1179 × 2556 px, la taille qu'Apple indique comme obligatoire ; PNG ou JPEG sans transparence | Page de la version |
| ☐ Captures iPad | Si l'app tourne sur iPad : 2064 × 2752 ou 2048 × 2732 px | Page de la version |
| ☐ Politique de confidentialité | URL obligatoire pour toute app, et un lien dans l'app aussi | Confidentialité de l'app |
| ☐ Étiquettes de confidentialité | Données collectées, y compris par les SDK tiers | Confidentialité de l'app |
| ☐ Classification par âge | Questionnaire mis à jour (4+, 9+, 13+, 16+, 18+), réponses exigées pour soumettre | Informations sur l'app |
| ☐ Conformité à l'exportation | Questions sur le chiffrement ; renseignez ITSAppUsesNonExemptEncryption (usesNonExemptEncryption avec Expo) pour ne plus les voir à chaque build | Build |
| ☐ Compte de démo | Un identifiant qui marche, avec des données, et le back-end allumé (règle 2.1) | Informations pour la vérification |
| ☐ Suppression de compte | Dans l'app, si l'utilisateur peut créer un compte (5.1.1(v)) | Votre app |
| ☐ Connexion tierce | Une connexion Google ou Facebook pour le compte principal impose une option équivalente et respectueuse de la vie privée, comme Se connecter avec Apple (4.8) | Votre app |
| ☐ URL d'assistance | Une page où les utilisateurs peuvent vous joindre | Page de la version |
| ☐ Statut de professionnel (UE) | Déclarer si vous êtes professionnel ou non pour être distribué dans l'UE | Business |
| ☐ SDK récent | Compilé avec Xcode 26 et le SDK iOS 26 depuis le 28 avril 2026 | Votre outil de build |
Les textes prêts à copier
Remplacez les crochets, gardez la structure. Le texte promotionnel se modifie à tout moment sans nouvelle version, c'est donc la place des nouveautés ; la description, elle, ne change qu'avec une nouvelle version.
Répondez dans le Resolution Center, un point par motif de refus, sans comparer avec d'autres apps. Pour le recours et les huit motifs habituels, voir notre guide sur les refus App Store.
Le calendrier jour par jour
Un calendrier réaliste pour un compte individuel et une première soumission propre.
| Jour | Étape | Ce qui peut ralentir |
|---|---|---|
| Jour 0 | Inscription, 99 $, vérification d'identité | Organisation : obtenir d'abord le numéro DUNS, plusieurs jours ouvrés |
| Jours 1 à 3 | Compte validé ; créer la fiche de l'app et lancer le premier build (moins d'une heure dans le cloud) | Erreurs de signature, bundle ID déjà pris |
| Jour 3 | Build traité ; les testeurs TestFlight internes l'installent | Le traitement peut prendre jusqu'à une heure |
| Jours 3 à 4 | TestFlight externe après une courte review bêta | Informations de test manquantes |
| Jours 4 à 5 | Fiche, captures, confidentialité, classification par âge, notes pour la review ; soumission | Captures à la mauvaise taille |
| Jours 5 à 7 | Review Apple : 90 % des décisions en moins de 24 heures | Catégorie réglementée, rush de septembre |
| Jour 7 | Mise en ligne : manuelle, automatique ou progressive sur 7 jours | Chaque refus ajoute 1 à 3 jours |
Publier sur l'App Store depuis Cadrant
Si votre app a été construite avec le créateur d'application mobile de Cadrant, la partie build et soumission est guidée de bout en bout. Deux comptes vous appartiennent et restent les vôtres : le build tourne sur votre compte Expo (le plan gratuit couvre 15 builds iOS par mois), et le binaire arrive sur votre compte App Store Connect.
- Connexion Apple sécurisée : l'authentification utilise le protocole SRP, votre mot de passe Apple n'est jamais stocké.
- Fiche créée pour vous : nom, icône 1024 × 1024 et identifiant de bundle sont posés sur App Store Connect automatiquement.
- Certificat provisionné automatiquement : le certificat de distribution et le profil sont créés sans manipulation, ou importés en .p12 si vous en avez déjà un.
- Build puis soumission : le build iOS se lance sur votre compte Expo, et Expo dépose le binaire sur votre App Store Connect. Vous reprenez la main pour TestFlight, la fiche et la soumission.
En résumé
- Ouvrez le compte Apple Developer dès aujourd'hui : c'est le seul délai incompressible du parcours.
- Testez le binaire TestFlight, pas la preview : c'est lui qui passe en review.
- Soignez les trois points qui concentrent les refus : stabilité, compte de démonstration, confidentialité.