Publier sur les magasins : le calendrier réel
La revue d'une application prend quelques jours dans le meilleur cas. Ce qui coûte du temps se situe avant, dans des formalités que personne n'anticipe.
La date de lancement est fixée à partir de la fin du développement. Elle ignore une série d’étapes administratives dont certaines se comptent en semaines et ne dépendent pas de l’équipe.
Ce qui doit exister avant le premier envoi
Les comptes développeur. Leur création, en entité professionnelle, demande une vérification d’identité de l’entreprise. Le délai est variable, parfois long, et il ne s’accélère pas.
Les certificats et clés de signature. Perdre la clé de signature d’une application publiée empêche de publier toute mise à jour ultérieure. Sa conservation est un sujet à part entière, au même titre qu’un secret de production.
La fiche du magasin. Description, captures d’écran à plusieurs dimensions, icône, catégorie, classification d’âge. Cela paraît accessoire, cela demande une demi-journée, et cela bloque l’envoi si c’est incomplet.
La politique de confidentialité, publiée à une adresse accessible, et le formulaire déclarant les données collectées. Une déclaration incohérente avec le comportement réel de l’application est un motif de rejet fréquent.
Les rejets courants
Ils portent rarement sur le code. Les motifs les plus répandus : une fonctionnalité inaccessible au relecteur faute de compte de démonstration fourni, une mention de plateforme concurrente, un lien de paiement contournant le système du magasin, une permission demandée sans justification apparente, ou une application jugée trop mince fonctionnellement.
Un compte de test avec ses identifiants, joint à l’envoi, supprime le motif le plus fréquent.
Prévoir deux cycles
Le premier envoi est rarement accepté. Le calendrier réaliste prévoit un rejet, une correction, un second envoi — soit une à deux semaines au-delà de la fin du développement, sans compter la création des comptes.
Annoncer une date de lancement publique avant la première validation est un pari.
Après la publication, le rythme change
Une correction urgente n’est pas en ligne le jour même : elle passe par la revue. Certains mécanismes permettent d’accélérer un cas critique, mais ils ne se déclenchent pas à volonté.
C’est une différence structurelle avec le web, où un correctif se déploie en minutes, et elle doit être connue de ceux qui traitent les incidents.
Ce qui se prépare en parallèle
L’application installée n’est jamais mise à jour par tout le monde. Le serveur doit rester compatible avec les versions anciennes pendant longtemps, et l’application doit savoir dire à son utilisateur qu’une mise à jour est nécessaire — plutôt que d’échouer sans explication.