Comment publier une application sur l'App Store et Google Play ?

Quelles sont les étapes pour publier une application ?

Sur les deux stores, le chemin est le même : compte développeur, fiche complète, version testée, puis revue par Apple ou Google avant la mise en ligne.

1. Ouvrir les comptes développeur au nom de l'entreprise : Apple Developer Program et Google Play Console.
2. Rédiger la fiche : nom, descriptions, captures d'écran, icône, catégorie, coordonnées de contact.
3. Publier une politique de confidentialité en ligne et remplir les déclarations sur les données collectées.
4. Faire tester la version par de vrais utilisateurs : TestFlight chez Apple, pistes de test chez Google.
5. Soumettre à la revue, avec un compte de démonstration si l'application demande une connexion.
6. Corriger et répondre aux éventuels refus, puis choisir la date de mise en ligne.

Avec Flutter, qu'utilise YMHB Web, une seule base de code sert iOS et Android, mais chaque store garde ses propres règles : la publication se prépare deux fois, en parallèle.

Combien coûtent les comptes développeur, et quel compte ouvrir ?

Apple facture 99 dollars par année d'adhésion, convertis en devise locale le cas échéant ; Google facture 25 dollars une seule fois (tarifs publics relevés en octobre 2026). Pour une entreprise, le compte d'organisation est le bon choix sur les deux stores.

Le numéro D-U-N-S est un identifiant à neuf chiffres attribué par Dun & Bradstreet : demandez-le en premier. Ouvrez les comptes au nom de votre société, pas de votre prestataire, puis invitez-le avec un rôle limité. Récupérer une application publiée sur le compte d'un tiers est pénible, comme le montre la page récupérer le code source de son application.

Que faut-il préparer pour la fiche et la confidentialité ?

Les deux stores exigent des visuels aux formats précis, une politique de confidentialité en ligne et une déclaration des données collectées.

• Visuels Apple : de 1 à 10 captures d'écran par taille d'écran. Les règles d'Apple demandent qu'elles montrent l'application en usage, pas seulement l'écran de connexion ou l'écran de démarrage.
• Visuels Google : icône de 512 × 512 pixels en PNG 32 bits, image de présentation de 1 024 × 500 pixels, au moins deux captures d'écran pour publier la fiche et jusqu'à huit par type d'appareil, description courte limitée à 80 caractères.
• Politique de confidentialité : Apple exige son adresse pour toute application iOS ; Google l'exige même pour une application qui ne collecte aucune donnée.
• Déclarations de données : Apple demande de décrire ses pratiques et celles des partenaires dont le code est intégré (mesure d'audience, publicité, paiement) ; Google impose la section Sécurité des données à toute application présente en test fermé, en test ouvert ou en production.
• Statut de professionnel : pour distribuer dans l'Union européenne, Apple demande de déclarer si le compte est celui d'un professionnel au sens du règlement sur les services numériques ; l'adresse, le téléphone et l'e-mail d'un professionnel sont alors publiés sur la fiche de l'application.

Ces déclarations doivent refléter ce que fait réellement l'application ; elles se préparent avec la cartographie des données détaillée dans le guide RGPD et logiciel métier.

Comment fonctionne le test fermé exigé par Google ?

Google impose aux comptes personnels de la Play Console créés après le 13 novembre 2023 de faire tester leur application par au moins 12 testeurs, inscrits sans interruption pendant au moins 14 jours, avant de pouvoir demander l'accès à la production.

La demande d'accès, faite depuis la Play Console, comporte des questions sur le test fermé, sur l'application et sur sa préparation à la production. Google propose trois pistes de test :

Chez Apple, TestFlight permet d'inviter jusqu'à 100 membres de l'équipe et jusqu'à 10 000 testeurs externes ; la première version proposée aux testeurs externes doit être approuvée par l'App Review. Recrutez les testeurs (salariés, clients pilotes) avant la fin du développement, avec un vrai scénario : voir le guide de la recette logicielle.

Combien de temps prend la revue ?

Apple indique traiter en général au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures ; Google prévient que, pour certains comptes de développeur, la revue peut prendre jusqu'à 7 jours, voire davantage dans des cas exceptionnels.

Chez Apple, une revue accélérée peut être demandée pour corriger un bug critique ou pour une application liée à un événement daté, et un refus peut être contesté une fois devant l'App Review Board. Chez Google, une contrainte technique s'ajoute : depuis le 31 août 2026, les nouvelles applications et leurs mises à jour doivent cibler Android 16 (niveau d'API 36), hors applications Wear OS, Android Automotive OS, Android TV et Android XR, avec un délai supplémentaire possible jusqu'au 1er novembre 2026 sur demande.

Quels sont les motifs de refus les plus fréquents ?

Selon Apple, en moyenne, plus de 40 % des problèmes non résolus relèvent de la règle 2.1 sur l'application complète : plantages, contenus provisoires, informations manquantes.

Le refus au titre de la règle 4.2 vise souvent des projets qui auraient dû être une application web : le comparatif PWA ou application native aide à trancher avant de développer.

Qui doit publier : vous ou votre prestataire ?

L'entreprise doit être titulaire des comptes et de l'application ; le prestataire prépare la publication et la mène, avec un accès délégué.

Le dirigeant ouvre les comptes, car Apple exige que la personne qui inscrit l'organisation ait l'autorité pour l'engager juridiquement ; le prestataire prépare ensuite versions, fiche, déclarations et réponses aux refus. C'est la même logique que pour le code, que YMHB Web dépose chez le client sur ses projets d'application mobile iOS et Android : le titulaire des comptes peut changer de prestataire sans republier son application.