Publier son app sur l'App Store et le Play Store
Vos comptes développeurs existent, votre build tourne : voici comment soumettre votre app sur l'App Store et le Play Store, étape par étape, sans se prendre un rejet.
Prérequis avant de soumettre votre app
Votre app est finie, elle tourne bien sur votre téléphone, et vous pensez qu'il suffit d'appuyer sur un bouton pour la mettre en ligne. Mauvaise nouvelle : entre un build qui marche et une app publiée, il y a une série d'étapes que personne ne vous explique clairement. La bonne nouvelle, c'est qu'elles sont toutes franchissables en un après-midi si vous savez quoi préparer.
On part du principe que vos comptes développeurs existent déjà : Apple Developer Program (99 dollars par an) côté Apple, et Google Play Console (25 dollars une seule fois) côté Google. Si ce n'est pas le cas, créez-les d'abord, la validation d'identité peut prendre plusieurs jours chez Apple. Ici, on s'attaque à la suite : passer du code au store.
Avant même de toucher aux stores, vérifiez que votre app est vraiment prête : pas de crash au démarrage, une politique de confidentialité accessible en ligne, et des écrans qui tiennent la route sur un vrai appareil. Si vous hésitez encore sur la façon dont votre produit a été construit, on a écrit un guide sur no-code ou sur-mesure pour un premier produit.
Soumettre sur l'App Store, étape par étape
Chez Apple, tout passe par App Store Connect, le tableau de bord web qui pilote vos apps. Le principe : vous téléversez un build depuis Xcode, vous remplissez la fiche, puis vous soumettez à la review. Voici la séquence dans l'ordre.
Créer l'app dans App Store Connect
Connectez-vous à App Store Connect, allez dans Mes apps, cliquez sur le plus, puis Nouvelle app. Renseignez le nom, la langue principale, le bundle ID (le même que dans votre projet Xcode) et un SKU interne. Le nom doit être unique sur tout l'App Store : si le vôtre est pris, trouvez une variante.
Téléverser le build via Xcode ou Transporter
Dans Xcode, choisissez la cible Any iOS Device, puis Product, Archive. Une fois l'archive prête, cliquez sur Distribute App, App Store Connect, et laissez Xcode signer et envoyer. Le build apparaît dans App Store Connect au bout de quelques minutes à une heure, le temps du traitement Apple.
Tester via TestFlight (recommandé)
Avant de soumettre au public, invitez-vous vous-même et quelques proches sur TestFlight. C'est le canal de test d'Apple : il vous permet de vérifier le build exact qui partira en review, sur de vrais appareils, sans attendre la publication. Les bugs vus ici vous évitent un rejet ou une mauvaise note au lancement.
Remplir la fiche et soumettre à la review
Ajoutez les captures d'écran (aux bonnes dimensions), la description, les mots-clés, l'URL de support et la politique de confidentialité. Remplissez le questionnaire de confidentialité des données (App Privacy) : Apple exige de déclarer ce que vous collectez. Rattachez votre build, choisissez la sortie manuelle ou automatique, puis cliquez sur Ajouter pour examen.
Une fois soumis, votre app passe au statut Waiting for Review, puis In Review. Comptez en général de 24 à 48 heures pour un premier verdict. Si tout est bon, l'app passe en Ready for Sale et sort selon l'option choisie. Sinon, Apple vous explique le motif dans le Resolution Center, et vous corrigez avant de renvoyer.
Publier sur Google Play, étape par étape
Google est plus souple qu'Apple sur la review, mais impose désormais une phase de test avant qu'un nouveau compte puisse passer une app en production. Tout se pilote depuis la Google Play Console. Voici la marche à suivre.
Créer l'app et remplir la fiche du Store
Dans la Play Console, cliquez sur Créer une application, donnez le nom, la langue par défaut et le type (app ou jeu, gratuite ou payante). Remplissez ensuite la fiche : description courte et longue, icône, captures, bannière. Complétez aussi les sections obligatoires : contenu de l'app, public cible, sécurité des données et politique de confidentialité.
Téléverser l'AAB sur un canal de test
Google privilégie le format Android App Bundle (AAB). Créez d'abord une release sur un canal de test : interne (rapide, quelques testeurs), fermé ou ouvert. Depuis 2023, un nouveau compte développeur particulier doit faire tester son app par au moins 12 personnes pendant 14 jours avant d'accéder à la production. Anticipez ce délai.
Passer en production et déployer
Une fois le test validé, créez une release sur le canal Production, rattachez votre AAB, rédigez les notes de version, puis envoyez pour examen. Vous pouvez déployer à 100 pour cent ou faire un déploiement progressif (par exemple 20 pour cent des utilisateurs) pour surveiller les crashs avant la diffusion complète.
La review Google est en grande partie automatisée et prend souvent de quelques heures à quelques jours. Une fois validée, votre app est disponible dans le monde entier (ou sur les pays que vous avez choisis). Pour outiller tout ce cycle de publication, jetez un oeil à notre sélection d' outils qui font gagner du temps à un fondateur.
La review Apple : motifs de rejet fréquents
C'est là que ça coince le plus souvent. Apple applique ses App Store Review Guidelines de façon stricte, et un premier rejet est presque un passage obligé. Le rejet n'est pas grave en soi : vous corrigez et vous renvoyez. Mais chaque aller-retour coûte un ou deux jours. Autant éviter les pièges les plus courants.
Le motif le plus fréquent reste la simple app incomplète : Apple ouvre votre app, tombe sur un bug ou un écran de connexion sans compte de test, et rejette. Fournissez toujours un compte de démonstration dans les notes pour la review si votre app exige une connexion. C'est le détail oublié qui bloque des milliers de soumissions.
“Un rejet Apple, ce n'est pas un échec. C'est une checklist gratuite pour rendre votre app meilleure avant qu'un vrai utilisateur ne la voie.”
Checklist pré-soumission
Avant de cliquer sur Soumettre, passez cette liste en revue. Cinq minutes ici vous économisent plusieurs jours de rejets. Elle vaut pour les deux stores, en adaptant les termes.
Une dernière chose : gardez une trace de vos identifiants, certificats et clés dans un endroit sûr et partagé avec votre équipe. Publier une première fois est simple, mais republier une mise à jour six mois plus tard sans la bonne clé est un cauchemar. Pour structurer tout ça proprement dès le départ, lisez notre retour sur comment on a transformé un side-project en vrai SaaS.
Conclusion
Publier sur l'App Store et le Play Store n'a rien de magique. C'est une suite d'étapes précises : un build propre, une fiche complète, des déclarations de confidentialité honnêtes, et un peu de patience face à la review. Le premier passage impressionne, mais une fois la mécanique comprise, chaque mise à jour suivante devient une routine de quelques minutes.
Si vous voulez éviter les allers-retours et publier du premier coup, l'idéal est de préparer la soumission dès la conception du produit, pas à la fin. C'est exactement ce qu'on fait chez Figue : on construit votre app en pensant à sa publication et à ses mises à jour, pour que le jour du lancement soit un non-événement.
“Le meilleur lancement, c'est celui qui ne surprend personne : tout était prêt, la review n'est qu'une formalité.”
Articles similaires
Qu'est-ce qu'un product studio ? Définition, modèle et prix
Product studio : le mot est partout, la définition nulle part. Voici ce que le modèle recouvre vraiment, comment il fonctionne, ce qu'il coûte et pour qui il est fait.
Intégrer l'IA dans une PME : le guide concret pour créer de la valeur
On vous répète qu'il faut faire de l'IA, sans jamais dire où ni pour gagner quoi. Voici où elle crée vraiment de la valeur dans une PME, des cas d'usage concrets, le choix sur mesure ou no-code, les coûts, le ROI et les erreurs à éviter.
CTO à temps partagé : ce que c'est, quand y recourir et comment le choisir
Un produit qui décolle, une petite équipe, et personne pour arbitrer les choix techniques qui vous suivront cinq ans. Le CTO à temps partagé comble ce vide sans le coût d'un temps plein. Quand y recourir, ce qu'il fait vraiment, combien ça coûte.
Plan go-to-market SaaS : les 8 premières semaines pour trouver vos premiers clients
Un produit propre qui ne se vend pas, c'est presque toujours un problème de go-to-market, pas de technique. Voici un plan concret sur 8 semaines : positionnement, canaux, pricing, boucle de croissance. De fondateur à fondateur.
No-code ou sur-mesure : comment choisir pour lancer son premier produit
No-code pour aller vite, ou sur-mesure pour faire les choses bien ? La vraie question n'est pas le camp, c'est le moment. Voici la grille pour trancher quand on a déjà une audience ou une traction.
Tech as a Service : du renfort technique senior pour livrer 3x plus vite
Vous avez une équipe technique mais un goulot d'étranglement sur la vélocité ? Le renfort senior plug-and-play permet de tenir vos deadlines sans recruter. Voici comment, et quand y recourir.
ReactIn : de side project a outil d'outreach complet sur LinkedIn
Comment un outil interne de prospection LinkedIn est devenu un SaaS a $6K MRR en bootstrapped, sans pub payante ni levee de fonds.
On a triple nos prix : le vrai pivot de notre offre design
Comment on est passe d'un abonnement design a 2K/mois a un product studio premium a 6K+. Moins de clients, 3x plus de revenu, meilleure qualite.
Nos meilleurs outils SaaS (et comment on les utilise vraiment)
La stack complète d'un product studio qui build des SaaS : dev, design, growth et ops. Outils, coûts réels et retours d'expérience après 3 ans.
Bootstrap vs levée de fonds, freelance vs agence, solo vs associés : nos choix de fondateurs
3 dilemmes qui définissent la trajectoire de votre startup. Retour sur nos choix chez Figue, avec des chiffres et des leçons concrètes.
Product studio vs agence classique : pourquoi ça change tout
Le modèle agence optimise pour le volume. Le product studio optimise pour le résultat. Voici pourquoi ça fait toute la différence pour votre projet.