Publier son application sur l’App Store étape par étape
Votre application fonctionne sur votre téléphone, et maintenant ? La faire arriver sur l’App Store reste l’étape qui intimide le plus les porteurs de projet, et même pas mal de développeurs. Compte développeur, signature, build, TestFlight, fiche produit : la procédure d’Apple est longue, mais elle n’a rien d’insurmontable quand on la prend dans le bon ordre.
Ce guide déroule le parcours complet, de la préparation du projet jusqu’au bouton « Add for Review ». Il s’adresse autant au développeur qui publie sa première application qu’au porteur de projet qui veut comprendre ce que son prestataire fabrique pendant cette phase. À la fin, votre application est dans la file de validation d’Apple.
Les points essentiels à retenir
- Un compte développeur Apple (99 dollars par an) et un Mac avec Xcode sont indispensables, et la validation du compte prend un à deux jours.
- Le bundle identifier ne peut plus être modifié après la première publication : il se choisit avec soin, avant tout le reste.
- La signature du build se gère aujourd’hui automatiquement dans Xcode, ce n’est plus l’étape redoutée d’autrefois.
- TestFlight permet de tester la version réelle de l’application avant de la soumettre à la validation.
- Les captures d’écran et la fiche App Store Connect prennent souvent plus de temps que la partie technique.
Avant de commencer : le compte, le Mac et l’application
Trois prérequis, pas un de plus. D’abord un compte développeur Apple, facturé 99 dollars par an. Son ouverture n’est pas instantanée : Apple vérifie l’identité du titulaire, comptez un à deux jours. Si vous publiez pour une société, prévoyez aussi le numéro D-U-N-S de l’entreprise. Ensuite, un Mac avec Xcode installé, téléchargeable gratuitement depuis le Mac App Store. Enfin, une application terminée, quelle que soit la façon dont elle a été construite : SwiftUI, React Native, Expo, Flutter ou avec l’aide d’un assistant de code, le parcours de publication reste le même.
Un conseil qui évite bien des déceptions : vérifiez que le nom envisagé n’est pas déjà porté par des dizaines d’applications concurrentes. Une recherche dans l’App Store suffit pour s’en rendre compte, et un nom distinctif facilitera tout le référencement par la suite.
Préparer le projet : nom, bundle identifier et version
Le bundle identifier est l’identifiant unique de votre application, en général construit sur le modèle com.votremarque.nomdelapp. Point capital : une fois l’application créée et publiée, cet identifiant ne pourra plus jamais changer. Il n’est pas visible des utilisateurs, mais prenez le temps de le poser proprement.
Deux réglages méritent une attention particulière à ce stade. Le support de l’iPad d’abord : si vous l’activez dès la première version, Apple exigera des captures d’écran iPad et vous ne pourrez plus retirer ce support ensuite. Pour une première publication, il est plus prudent de le désactiver, quitte à l’ajouter plus tard une fois l’affichage vérifié. La déclaration de chiffrement ensuite : si votre application n’utilise pas de chiffrement particulier, déclarez-le dans la configuration du projet (la clé ITSAppUsesNonExemptEncryption sur iOS). Cela vous évitera de répondre à la question à chaque envoi de build.
Vérifiez enfin le numéro de version, 1.0.0 pour une première sortie. Une seule version peut être en cours de publication à la fois, et vous l’incrémenterez à chaque mise à jour.
Ouvrir le projet natif dans Xcode et signer le build
Si votre application est écrite avec Expo, il faut d’abord générer le projet natif : la commande npx expo prebuild –platform ios crée le dossier ios du projet. Ouvrez ensuite ce dossier dans Xcode. Si vous développez directement en Swift, vous êtes déjà au bon endroit.
Vient alors la signature, l’étape qui a terrorisé des générations de développeurs iOS. Bonne nouvelle : c’est largement automatisé aujourd’hui. Dans les réglages de Xcode, connectez votre compte développeur Apple. Puis, dans l’onglet Signing and Capabilities de votre cible, cochez « Automatically manage signing » et sélectionnez votre équipe. Xcode s’occupe des profils de provisionnement et des certificats.
Un détail qui piège souvent : si votre application embarque plusieurs cibles, par exemple un widget, chaque cible doit être signée avec la même équipe. Passez-les en revue une par une dans la colonne de gauche.
Compiler et téléverser : Archive puis App Store Connect
Dans la barre de cibles de Xcode, remplacez votre iPhone branché par « Any iOS Device (arm64) », puis lancez Product, Archive. Xcode compile une version de distribution, ce qui prend quelques minutes.
Une fois l’archive prête, une fenêtre propose de distribuer l’application : choisissez App Store Connect et laissez-vous guider. Au premier envoi, Xcode propose d’enregistrer l’application sur votre compte : vérifiez une dernière fois le bundle identifier et le nom, puis validez. Quelques avertissements peuvent s’afficher en fin d’envoi, ils sont sans gravité. Votre build est maintenant sur App Store Connect, en cours de traitement par les serveurs d’Apple.
Tester la version réelle avec TestFlight
Avant de soumettre quoi que ce soit à la validation, testez le build exact que vous venez d’envoyer. C’est le rôle de TestFlight, l’application de test d’Apple, à installer depuis l’App Store sur votre iPhone.
Dans App Store Connect, onglet TestFlight, créez un groupe de test interne et activez la distribution automatique : chaque nouveau build parviendra tout seul à vos testeurs. Ajoutez-vous comme testeur, acceptez l’invitation reçue par courriel, et installez l’application via TestFlight. Vous testez alors la version de production, pas une version de développement : c’est le moment de vérifier les parcours critiques, le mode sombre, les notifications, tout ce qui doit fonctionner le jour J.
Remplir la fiche : captures d’écran, description et mots-clés
Voici la partie la plus longue, et celle que tout le monde sous-estime. Apple exige de vraies captures d’écran de l’application, aux bons formats. Prenez vos captures directement sur l’iPhone, puis habillez-les dans un gabarit (un fichier Figma fait très bien l’affaire) avec un court texte d’accroche par écran. Montrez les fonctionnalités les plus parlantes : c’est votre vitrine, elle pèse directement sur le taux d’installation.
Complétez ensuite le texte promotionnel, la description et le champ de mots-clés. Ces mots-clés déterminent en grande partie comment on vous trouvera dans la recherche de l’App Store, choisissez-les avec méthode plutôt qu’au feeling. Il faut aussi une URL de support et, obligatoire pour toutes les applications, une URL de politique de confidentialité. Renseignez enfin la catégorie, le questionnaire de classification d’âge et la section App Privacy, qui décrit les données collectées. Si vous ne collectez rien, le questionnaire est expédié en deux minutes.
Prix, disponibilité et soumission à la validation
Dans Pricing and Availability, choisissez la gratuité ou un prix de vente. Apple décline automatiquement le tarif choisi dans chaque pays, et vous pouvez restreindre ou élargir la liste des pays de diffusion. Un point d’organisation : vendre l’application à un prix fixe est bien plus simple à mettre en place que des achats intégrés ou des abonnements, qui demandent une configuration à part entière.
Dernière ligne droite : sélectionnez le build testé, indiquez si un compte de démonstration est nécessaire à l’équipe de validation (obligatoire si votre application demande une connexion), et choisissez entre publication automatique dès l’approbation ou publication manuelle. Cliquez enfin sur « Add for Review ». App Store Connect vous signale à ce moment tout champ oublié ; corrigez, sauvegardez, soumettez. Votre application est dans la file d’examen d’Apple.
Les erreurs fréquentes qui retardent une validation
- Soumettre sans avoir testé le build via TestFlight, et découvrir un plantage en production.
- Activer le support iPad « pour voir », puis se retrouver contraint de le maintenir à chaque mise à jour.
- Oublier l’URL de politique de confidentialité, exigée pour toutes les applications sans exception.
- Ne pas fournir de compte de démonstration alors que l’application exige une connexion : rejet quasi garanti.
- Négliger les captures d’écran, alors qu’elles conditionnent la conversion de la fiche.
Si votre projet en est encore au stade de la définition, notre guide du cahier des charges d’application mobile vous aidera à cadrer ce qui doit l’être avant la moindre ligne de code. Et pour situer l’enveloppe globale d’un projet, consultez notre guide des prix d’une application mobile.
Questions fréquentes
Combien de temps dure la validation d’Apple ?
La grande majorité des applications sont examinées en 24 à 48 heures. Une première soumission peut prendre un peu plus de temps, et un rejet suivi d’une nouvelle soumission relance le délai.
Peut-on publier sans Mac ?
Pour la voie classique décrite ici, non : Xcode ne tourne que sur macOS. Des services de build à distance existent, mais pour une première publication, un accès à un Mac reste le chemin le plus simple et le plus prévisible.
Faut-il payer les 99 dollars même pour une application gratuite ?
Oui. L’adhésion au programme développeur d’Apple est annuelle et conditionne toute publication sur l’App Store, que l’application soit gratuite ou payante.
Que se passe-t-il en cas de rejet ?
Apple motive sa décision dans App Store Connect. On corrige le point soulevé, on renvoie un build si nécessaire, et on soumet à nouveau. Un rejet n’a rien de définitif ni d’exceptionnel.
Quiz : avez-vous tout retenu ?
1. Peut-on changer le bundle identifier après la première publication ?
Non. C’est justement pour cela qu’il faut le choisir avec soin avant de créer l’application sur App Store Connect.
2. À quoi sert TestFlight ?
À installer et tester la version de production exacte de l’application avant de la soumettre à la validation d’Apple.
3. Quelle cible faut-il sélectionner dans Xcode avant d’archiver ?
« Any iOS Device (arm64) », afin de produire un binaire valable pour tous les appareils.
4. La politique de confidentialité est-elle obligatoire ?
Oui, une URL de politique de confidentialité est exigée pour toutes les applications, même celles qui ne collectent aucune donnée.
Besoin d’un avis technique sur votre projet d’application ?
Derrière ce guide, il y a des développeurs mobiles en exercice. On répond aux questions techniques, on chiffre les projets, et on dit aussi franchement quand une idée n’est pas prête.
Réserver un appel conseil gratuit
Par téléphone : 06 32 64 24 80
Cadre du projet, ensuite
Un tutoriel store ou technique ne remplace pas un cahier des charges. Quand le périmètre existe (deux stores, un back-office, un paiement), ouvrez le modèle de CDC, les fourchettes du guide des prix, et la grille de devis. Les captures annotées de nos articles suivent la même logique que l’analyse d’écrans du CDC : une source réelle, une exigence écrite, pas une moodboard.
Fourchettes HT, France : MVP 15 000 à 40 000 €, ambition moyenne 40 000 à 120 000 €, complexe 120 000 à 300 000 €. Maintenance 15 à 20 % par an. Aucune note d’avis sur les agences : le classement est Sirene, millésimé, déclaré.
Par la rédaction d’Agence Application Mobile. Article publié le 19 août 2026, mis à jour le 21 août 2026.
