Publier sur l'App Store et Google Play : ce que personne ne dit avant
Oussama
Développeur mobile
En bref
Combien de temps et quelles contraintes pour publier une application sur les magasins iOS et Android ?
Comptez deux à quatre semaines entre l'application finie et sa disponibilité publique, dont la moitié en préparation administrative. Apple relit chaque version manuellement — de quelques heures à plusieurs jours — et refuse pour des motifs souvent non fonctionnels : formulaire de confidentialité incomplet, connexion imposée sans justification, mécanisme de paiement hors du sien. Google publie plus vite mais impose une validation d'identité et des phases de déploiement progressif. Les comptes développeur, les certificats et les fiches produit doivent être créés au nom de l'entreprise, jamais d'une personne.
L’application est finie. Elle fonctionne, elle est testée, tout le monde est content. Reste à la publier — ce que beaucoup de plannings comptent pour une journée.
C’est plutôt deux à quatre semaines, dont une bonne moitié n’a rien à voir avec du développement. Voici ce qu’il y a dedans, pour que ça n’arrive pas en surprise.
Ce qu’il faut créer avant, et au nom de qui
Deux comptes développeur : un chez Apple, un chez Google. Payants tous les deux, l’un annuellement, l’autre une fois.
Le point important n’est pas le prix, c’est au nom de qui ils sont créés. Ces comptes doivent appartenir à l’entreprise, avec une adresse électronique de l’entreprise et un moyen de paiement de l’entreprise.
J’ai vu plusieurs fois le scénario inverse : le compte créé au nom d’un développeur ou d’un prestataire, parce que c’était plus rapide. Le jour où la personne part, l’application est bloquée — on ne peut plus publier de mise à jour, et le transfert de propriété est une procédure longue qui suppose la coopération de celui qui détient le compte.
L’inscription en tant qu’entreprise demande par ailleurs une vérification d’identité juridique, qui prend elle-même plusieurs jours. C’est le premier délai à anticiper, et il tombe souvent au plus mauvais moment.
La fiche produit : plus long qu’il n’y paraît
Chaque magasin veut le même type d’éléments, dans des formats différents.
Un nom, une description courte, une description longue. Une icône. Des captures d’écran, en plusieurs tailles, parce que les magasins veulent voir l’application sur différents formats d’appareil. Une politique de confidentialité, accessible sur une adresse publique.
Ce dernier point n’est pas optionnel : sans page de confidentialité en ligne, la publication est refusée. Et le document doit correspondre à ce que l’application fait réellement.
À cela s’ajoute, côté Apple, un formulaire déclaratif sur les données collectées : quelles données, à quelle fin, sont-elles reliées à l’identité de l’utilisateur, servent-elles au suivi publicitaire. Ce formulaire est engageant, il est vérifié, et une déclaration incohérente avec le comportement observé de l’application entraîne un refus.
Comptez deux à trois jours de travail pour l’ensemble, et impliquez quelqu’un du côté juridique ou de la direction. Ce n’est pas un travail de développeur.
La relecture Apple
C’est l’étape qui inquiète, et qui mérite d’être comprise plutôt que redoutée.
Chaque version soumise est examinée par une personne. Le délai courant se compte en heures à quelques jours, avec des pointes avant les périodes de forte activité. Un refus n’est pas une catastrophe : on corrige et on resoumet, mais chaque aller-retour coûte un nouveau délai.
Les motifs que je rencontre le plus souvent :
Une connexion obligatoire non justifiée. Si l’application demande un compte pour afficher du contenu qui ne le nécessite pas, elle est refusée. La règle vise à éviter les murs d’inscription artificiels.
Un paiement hors du système d’Apple. Vendre un contenu numérique consommé dans l’application impose de passer par son mécanisme d’achat, avec la commission correspondante. La frontière avec un service consommé hors application est subtile et se vérifie avant de construire, pas après.
Des autorisations demandées sans explication. Chaque accès sensible — position, appareil photo, contacts — doit être accompagné d’un texte expliquant à quoi il sert. Un texte vague vaut un refus.
Une application jugée trop pauvre. Si elle se contente d’afficher un site web sans rien apporter de spécifiquement mobile, elle peut être refusée au motif qu’un site web suffirait. C’est le refus le plus douloureux, parce qu’il remet en cause le principe même du projet.
Des fonctionnalités inaccessibles au relecteur. Si l’application demande un compte, il faut fournir un compte de test fonctionnel. Un compte expiré ou un accès réservé bloque la relecture et déclenche un refus administratif.
Photo : SpaceX — licence CC0.
Le côté Google
Le fonctionnement est différent, et les délais aussi.
La publication est plus rapide, avec une part importante de contrôles automatisés. Mais Google impose des exigences propres : une vérification d’identité du compte développeur, une déclaration de sécurité des données comparable à celle d’Apple, et une politique de version minimale du système à respecter pour les nouvelles publications.
Google propose aussi un déploiement progressif : publier d’abord pour un pourcentage des utilisateurs, observer les rapports de plantage, puis étendre. C’est un excellent filet de sécurité, et je le recommande systématiquement pour toute mise à jour significative.
Un point d’attention : la clé de signature de l’application. Elle prouve que la nouvelle version vient bien du même éditeur. La perdre signifie ne plus jamais pouvoir mettre à jour l’application existante — les utilisateurs devraient réinstaller une nouvelle fiche. Cette clé doit être sauvegardée hors du poste du développeur, au même titre qu’un accès de production.
Les tests avant publication
Les deux magasins proposent des circuits de distribution interne, avant publication publique. C’est là que se joue la qualité perçue.
Côté Apple, un outil de distribution permet d’envoyer une version à des testeurs internes en quelques minutes, et à des testeurs externes après une relecture allégée. Côté Google, plusieurs pistes de test coexistent, de la piste interne à la piste ouverte.
Ce que je recommande : faire tester par des personnes qui n’ont pas participé au projet, sur leurs propres appareils, avec leurs propres réglages. C’est le seul moyen de découvrir ce qu’aucun test en interne ne trouve — une police système agrandie qui casse un écran, un mode sombre inattendu, un appareil ancien deux fois plus lent, une langue système différente.
Photo : SpaceX — licence CC0.
Le planning réaliste
Voici la séquence que je propose systématiquement, en jours ouvrés.
| Étape | Durée |
|---|---|
| Création et vérification des comptes développeur | 3 à 7 jours |
| Fiches produit, captures, politique de confidentialité | 2 à 3 jours |
| Distribution interne et corrections | 5 à 10 jours |
| Première soumission et relecture | 1 à 5 jours |
| Marge pour un refus et une resoumission | 3 à 5 jours |
Soit deux à quatre semaines entre « l’application est finie » et « elle est téléchargeable ». Sur un projet qui vise une date de lancement commercial, ce délai doit figurer dans le planning dès le départ, pas être découvert à la fin.
Après la publication, ça continue
Publier n’est pas la fin, c’est le début d’un engagement récurrent.
Chaque année, les deux systèmes publient une version majeure. Il faut tester l’application dessus, corriger ce qui a changé, et republier. Les magasins font aussi évoluer leurs exigences — version minimale de l’outillage, nouvelles déclarations obligatoires — avec des échéances fermes : une application non conforme finit par ne plus accepter de mise à jour, puis par être retirée.
C’est le vrai coût de possession d’une application mobile, et c’est celui qu’on oublie le plus souvent au moment du devis. Quelques jours par an et par plateforme, même sans ajouter la moindre fonctionnalité.
Le conseil que je donne toujours
Publiez une version minimale très tôt, avant que l’application ne soit complète.
Une première version réduite mais fonctionnelle permet de traverser tout le parcours administratif pendant que le développement continue. Les comptes sont créés, les fiches existent, la première relecture est passée, les surprises sont derrière.
Les mises à jour suivantes se publient alors en quelques heures, et le lancement commercial ne dépend plus d’une file d’attente sur laquelle personne n’a la main.