Première publicationMis à jour le 22 octobre 202614 min de lecture

Comment publier une application iOS sur l'App Store : le guide complet, étape par étape

Compte Apple Developer, fiche App Store Connect, build, TestFlight, envoi en revue : comment publier ta première app iOS sur l'App Store, dans l'ordre.

Sources Apple vérifiées le 22 octobre 2026 · relu par Équipe Briksell

Sommaire

Réponse courte

Pour publier une application iOS sur l'App Store, tu passes par sept étapes, toujours dans le même ordre :

  1. T'inscrire à l'Apple Developer Program, l'abonnement développeur payant d'Apple (99 $/an, affiché en euros à l'inscription).
  2. Accepter les accords dans App Store Connect, le site où tu gères tes apps (et, si ton app est payante, l'accord « Paid Apps », la banque et la fiscalité).
  3. Créer la fiche de ton app dans App Store Connect : nom, description, captures d'écran, confidentialité, classement par âge.
  4. Construire et envoyer le fichier de ton app (on dit « le build ») vers App Store Connect.
  5. Tester ce build sur un vrai iPhone avec TestFlight, l'outil de test d'Apple.
  6. Remplir les informations pour l'équipe de revue (App Review) : compte de démonstration, explications.
  7. Envoyer en revue, puis publier une fois l'app acceptée.

Apple annonce examiner au moins 50 % des envois en moins de 24 heures et 90 % en moins de 48 heures. C'est un ordre de grandeur, pas une promesse : une première app, sans historique, peut prendre plus longtemps (voir Combien de temps dure la validation App Store). Et c'est toujours Apple qui décide d'accepter ou non l'app.

Qui est concerné, et les exceptions

Toute personne qui veut distribuer une app sur l'App Store

Un compte Apple Developer gratuit permet de tester une app sur tes propres appareils avec Xcode, mais pas de la publier. Pour la publier sur l'App Store, ou pour inviter des testeurs externes avec TestFlight, il faut l'adhésion payante à l'Apple Developer Program.

Particulier ou organisation : un choix qui se voit

Tu peux t'inscrire en tant que particulier (ou entrepreneur individuel) ou en tant qu'organisation (société, association…). La conséquence concrète : le nom affiché comme vendeur sous ton app sur l'App Store. En particulier, c'est ton nom légal ; en organisation, c'est le nom de l'entité juridique. Le choix et ses pièges sont détaillés dans le guide S'inscrire à l'Apple Developer Program.

Les cas où Apple attend une organisation

Les règles d'Apple (section 5.1.1(ix) des App Store Review Guidelines) demandent que les apps des secteurs très réglementés, comme la banque, la santé, les jeux d'argent ou les cryptomonnaies, soient publiées par l'entité juridique qui fournit le service, et non par un développeur à titre personnel.

Les apps créées à partir d'un modèle ou d'un service de génération

La section 4.2.6 précise que les apps créées à partir d'un modèle commercial ou d'un service de génération d'apps (« app generation service ») sont refusées, sauf si elles sont soumises directement par celui qui fournit le contenu de l'app. Ces services ne doivent pas publier à la place de leurs clients. En pratique : chaque créateur publie depuis son propre compte Apple Developer, et son app doit avoir son propre contenu et sa propre utilité. C'est exactement le modèle de Briksell : l'outil t'aide à construire l'app, mais c'est toi qui la soumets, sous ton nom. Si tu as créé ton app avec l'IA, lis aussi Créer une app avec l'IA.

Ce que ce guide ne couvre pas

  • La distribution en dehors de l'App Store (places de marché alternatives, distribution web), possible seulement dans certaines régions.
  • L'Apple Developer Enterprise Program (299 USD par an), réservé à la distribution interne aux employés d'une organisation, hors App Store.

Procédure pas à pas

Étape 1 : t'inscrire à l'Apple Developer Program

Ce dont tu as besoin, selon la page d'inscription d'Apple :

  • un identifiant Apple (Apple Account) avec la double authentification activée ;
  • ton nom légal dans les champs prénom et nom de ce compte (un pseudo ou un nom de société à cet endroit retarde la validation) ;
  • pour une organisation : un numéro D-U-N-S (identifiant d'entreprise à neuf chiffres attribué par Dun & Bradstreet, sauf pour les entités gouvernementales), un e-mail professionnel au nom de domaine de l'organisation et un site web public et fonctionnel ;
  • le pouvoir d'engager l'organisation juridiquement, si tu inscris une organisation.

Tu payes ensuite la cotisation : 99 $/an, affiché en euros à l'inscription. Les organisations à but non lucratif, établissements d'enseignement accrédités et entités gouvernementales peuvent, sous conditions, demander une exonération.

Le détail des pièces, des délais et des erreurs fréquentes est dans S'inscrire à l'Apple Developer Program.

Étape 2 : accepter les accords

Une fois l'adhésion active, ouvre App Store Connect, rubrique Business. Tu ne peux pas créer de fiche d'app tant que le titulaire du compte (Account Holder) n'a pas signé le dernier accord en vigueur.

Si ton app sera payante ou proposera des achats intégrés, le titulaire du compte doit aussi signer l'accord Paid Apps et renseigner la banque et la fiscalité. Ce point est détaillé dans Abonnements et achats intégrés Apple.

Étape 3 : créer la fiche de ton app dans App Store Connect

Dans App Store Connect, va dans Apps, clique sur le bouton +, puis New App. Tu choisis la plateforme, le nom, la langue principale, l'identifiant de l'app (le « bundle ID », une sorte de plaque d'immatriculation unique) et une référence interne. Une fois créée, la fiche est au statut Prepare for Submission.

Ensuite, tu remplis la fiche. Les points qui bloquent le plus souvent :

  • Le nom : 30 caractères maximum (section 2.3.7), sans mots-clés de remplissage ni nom d'une autre app.
  • Les captures d'écran : au moins une capture pour iPhone avec Dynamic Island (taille d'écran moyenne), et au moins une pour iPad 13 pouces si ton app fonctionne sur iPad. Jusqu'à 10 captures par taille. Elles doivent montrer l'app en cours d'utilisation, pas seulement l'écran de connexion (section 2.3.3).
  • La politique de confidentialité : un lien est obligatoire dans App Store Connect et dans l'app (section 5.1.1(i)).
  • Les informations de confidentialité (App Privacy) : quelles données ton app et ses outils tiers collectent. Elles sont obligatoires, y compris pour les données collectées par les outils tiers. Voir Étiquettes de confidentialité App Store.
  • Le classement par âge : un questionnaire à remplir honnêtement (section 2.3.6). Voir Classement par âge sur l'App Store.

Pour le nom et l'icône, des conseils concrets sont dans Nommer son app et choisir son icône.

Étape 4 : construire et envoyer le build

Le build, c'est le fichier de ton app prêt à être installé. Apple impose des versions minimales d'outils. À la date de vérification :

  • depuis le 28 avril 2026, les apps envoyées doivent être construites avec Xcode 26 ou plus récent et le SDK iOS 26 ;
  • depuis le 9 septembre 2026, les apps iOS envoyées doivent cibler iOS 13 ou plus récent ;
  • Apple annonce qu'à partir d'avril 2027, il faudra le SDK iOS 27 et cibler iOS 15 ou plus récent.

Pour l'envoi, Apple accepte Xcode, Transporter (une app Mac), l'outil en ligne de commande altool ou l'API App Store Connect. Après l'envoi, le build est d'abord traité par Apple ; tu reçois un e-mail quand il apparaît dans App Store Connect.

Si ton app est faite avec Expo (React Native), Expo propose EAS Build (construire le build sur ses serveurs) et EAS Submit (l'envoyer à App Store Connect). D'après la documentation d'Expo, EAS Submit fonctionne sur macOS, Linux et Windows : pas besoin de Mac pour l'envoi. Voir aussi Publier une app sur l'App Store sans Mac. Tout ce qu'il faut vérifier côté technique avant l'envoi est regroupé dans Préparer techniquement une app iOS avant App Review.

Étape 5 : tester avec TestFlight

TestFlight te permet d'installer ton build sur de vrais iPhone avant la sortie :

  • jusqu'à 100 testeurs internes (membres de ton équipe App Store Connect) ;
  • jusqu'à 10 000 testeurs externes, invités par e-mail ou par lien public.

Chaque build reste testable 90 jours. Le premier build envoyé à un groupe de testeurs externes passe par une revue d'Apple (la « review bêta »). Apple rappelle aussi qu'il teste les apps sur de vrais appareils : un test uniquement sur simulateur ne suffit pas. Le pas à pas est dans TestFlight : tester ton app sur iPhone.

Étape 6 : remplir les informations pour App Review

Dans la section App Review Information de ta version, donne à l'équipe de revue tout ce qu'il faut pour tester l'app sans toi :

  • un compte de démonstration qui fonctionne (identifiant et mot de passe) si l'app demande une connexion ;
  • une explication du concept de l'app, de son public et de son modèle économique ;
  • les services externes utilisés (connexion, paiement, IA…) ;
  • tes coordonnées à jour.

Et laisse ton serveur allumé pendant la revue : la section 2.1 le demande explicitement. Si ton app propose des abonnements, Apple demande un compte de démonstration avec un abonnement expiré, pour tester tout le parcours d'achat.

Étape 7 : envoyer en revue

D'après l'aide App Store Connect :

  1. Dans Apps, sélectionne ton app, puis la version à soumettre.
  2. Dans la section Build, vérifie que le bon build est sélectionné (un seul build par version). Si le build est au statut Missing Compliance, réponds d'abord aux questions sur le chiffrement (aide « Choose a build to submit »).
  3. En haut à droite, clique sur Add for Review. La version passe à Ready for Review, mais n'est pas encore envoyée.
  4. Si tu proposes des achats intégrés pour la première fois, ajoute-les à la même soumission (aide « Submit an In-App Purchase »).
  5. Clique sur Submit for Review.

Tu suis ensuite le statut dans la section App Review : Waiting for Review (en attente), In Review (en cours), puis acceptation ou Unresolved Issues (problèmes à corriger).

Étape 8 : après l'acceptation

Si tu as choisi une date de sortie future, l'app n'apparaît qu'à cette date, même acceptée. Apple précise qu'il peut falloir jusqu'à 24 heures pour qu'elle apparaisse dans tous les pays choisis (section « Release Date » des règles).

Erreurs fréquentes

Envoyer une app pas terminée

Selon Apple, plus de 40 % des problèmes non résolus en revue relèvent de la section 2.1 (App Completeness) : plantages, textes provisoires, liens cassés, informations manquantes. Teste chaque écran avant d'envoyer.

Oublier le compte de démonstration ou éteindre le serveur

Si l'équipe de revue ne peut pas se connecter, elle ne peut pas tester, et l'app est refusée. Vérifie que le compte fonctionne le jour de l'envoi.

Des captures d'écran qui ne montrent pas l'app

Un écran de démarrage ou une page de connexion ne suffit pas (section 2.3.3). Montre l'app en cours d'utilisation.

Pas de lien vers la politique de confidentialité ni vers le support

Un lien de support avec des coordonnées à jour et un lien vers la politique de confidentialité sont demandés pour toutes les apps (sections 1.5, 2.1 et 5.1.1(i)).

Une création de compte sans suppression de compte

Si ton app permet de créer un compte, elle doit aussi permettre de le supprimer depuis l'app (section 5.1.1(v)). Voir Suppression de compte obligatoire.

Une connexion Google ou Facebook sans alternative

Si ton app propose une connexion par Google ou Facebook pour le compte principal, la section 4.8 demande aussi une option qui limite la collecte au nom et à l'e-mail, permet de masquer son e-mail et ne piste pas pour la publicité. Sign in with Apple remplit ces critères : voir Sign in with Apple.

Une fonction cachée

La section 2.5.19 interdit les fonctions cachées, inactives ou non documentées : tout ce que fait l'app doit être visible pour l'utilisateur et pour l'équipe de revue.

Des achats intégrés non ajoutés à la soumission

Le premier achat intégré de chaque type doit être soumis avec une nouvelle version de l'app. S'il manque, l'équipe de revue ne peut pas le tester.

Les autres causes de refus sont détaillées dans Pourquoi Apple refuse une application.

Vérification

Avant de cliquer sur Submit for Review, coche chaque point ci-dessous. La liste est enregistrée seulement dans ton navigateur.

Ta checklist0/9

Tes cases sont gardées dans ce navigateur. Cocher une case ne prouve rien à Apple : vérifie chaque point pour de vrai.

Sources Apple et date de vérification

Vérifié le 22 octobre 2026 sur les pages officielles d'Apple :

Les règles et exigences d'Apple changent régulièrement : relis les pages officielles avant chaque envoi.

FAQ

Combien coûte la publication d'une app sur l'App Store ?

L'adhésion à l'Apple Developer Program coûte 99 $/an, affiché en euros à l'inscription. Si tu vends ton app ou des achats intégrés, Apple prélève une commission sur chaque vente (15 % avec le Small Business Program, 30 % sinon) : voir Abonnements et achats intégrés Apple.

Combien de temps dure la revue d'Apple ?

Apple annonce examiner au moins 50 % des envois en moins de 24 heures et 90 % en moins de 48 heures. Apple précise aussi que les apps avec peu ou pas d'historique de revue, celles qui demandent des documents ou celles qui touchent des sujets sensibles peuvent prendre plus de temps. Aucun délai n'est garanti. Une revue accélérée peut être demandée dans des cas précis (bug critique, événement daté).

Faut-il un Mac pour publier une app iOS ?

Avec Xcode, oui : Xcode est une app Mac. Avec Expo, la documentation d'Expo indique qu'EAS Submit fonctionne sur macOS, Linux et Windows, donc l'envoi peut se faire sans Mac. Il te faut quand même un iPhone pour tester.

Peut-on publier une app en tant que particulier ?

Oui. Ton nom légal apparaîtra alors comme vendeur sur l'App Store. Pour certains secteurs réglementés (banque, santé, jeux d'argent…), Apple attend une publication par l'entité juridique qui fournit le service (section 5.1.1(ix)).

Que faire si mon app est refusée ?

Lis le message dans la section App Review d'App Store Connect : il cite la règle concernée. Selon le cas, tu réponds directement à Apple ou tu corriges et renvoies un nouveau build. Tout est expliqué dans Pourquoi Apple refuse une application.

Passer à l'action

Publier une app, c'est surtout réussir les étapes 3 à 6 sans rien oublier. Avec Briksell, tu décris ton app à l'écrit ou à la voix et l'IA écrit le code d'une vraie app React Native / Expo, que tu testes sur ton téléphone en scannant un QR code. Tu obtiens aussi une icône 1024×1024, des pages légales hébergées (confidentialité, conditions, support : des modèles à relire, pas un conseil juridique) et, pour les abonnés, App Store Readiness, un contrôle du code sur les règles Apple qui concernent ton app. Seule Apple décide de la validation.

L'envoi sur TestFlight et la publication App Store depuis Briksell arrivent bientôt. En attendant, tu exportes le code et tu l'envoies avec EAS Build et EAS Submit, depuis ton propre compte Apple Developer, comme le demande la section 4.2.6. Créer mon app.

Sources officielles

À lire ensuite

← Tous les guides « Première publication »Tous les thèmes