Comment publier une application sur l'App Store et le Play Store

Développer l'application ne représente que la moitié du travail — la mettre en ligne sur l'App Store et Google Play est un projet à part entière, et la première soumission prend toujours plus de temps que les équipes ne l'anticipent. Des refus, des assets manquants et la configuration des comptes peuvent faire glisser le planning de plusieurs semaines si vous n'êtes pas préparé. Voici la checklist que nous suivons pour que la première mise en production se passe sans accroc.

Créez vos comptes le plus tôt possible

C'est l'étape qui prend les équipes par surprise — commencez par là :

• Apple Developer Program, 99 $/an, et la vérification d'identité pour les organisations peut prendre plusieurs jours. Un compte entreprise nécessite un numéro D-U-N-S, ce qui peut prendre encore plus de temps.
• Google Play Developer, un abonnement unique à 25 $, plus rapide à configurer, mais les nouveaux comptes personnels sont désormais soumis à une exigence de tests avant toute publication publique.

Lancez les deux démarches dès que vous vous engagez à publier. Attendre que l'application soit terminée pour créer les comptes, c'est la garantie de rater la date de lancement.

Préparez vos assets pour les stores

Les deux stores exigent une fiche produit soignée, et la bâcler nuit à la conversion :

• Icône de l'application dans les tailles requises
• Captures d'écran pour chaque type d'appareil (et souvent une vidéo de présentation)
• Un titre clair, un sous-titre et une description riche en mots-clés
• URL de la politique de confidentialité (obligatoire sur les deux stores)
• Catégorie, classification du contenu et coordonnées de contact

La « nutrition label » App Privacy d'Apple et le formulaire Data Safety de Google vous obligent à déclarer précisément quelles données vous collectez et pourquoi. Remplissez-les honnêtement et avec soin — les incohérences sont l'une des causes de refus les plus fréquentes.

Compilez et importez correctement

Générez un build de production propre, signé pour la distribution :

1. iOS : archivez et importez vers App Store Connect via Xcode ou un service de build. Apple gère les certificats de signature et les profils de provisionnement — configurez-les correctement, sinon l'import échouera.
2. Android : générez un App Bundle (.aab) signé, et non un ancien APK, et protégez soigneusement votre clé de signature. La perdre signifie que vous ne pourrez plus jamais mettre à jour l'application sous la même fiche.

Si vous utilisez React Native avec Expo, EAS Build prend en charge la majeure partie de cette mécanique de signature et d'import, ce qui simplifie considérablement les choses.

Survivez à la revue

La revue d'Apple est plus stricte et plus lente (généralement un à deux jours, parfois davantage) ; celle de Google est plus rapide et plus automatisée. Les causes de refus les plus courantes :

• Un écran de connexion sans compte de démonstration fourni aux reviewers
• Liens cassés, crashs ou contenu provisoire
• Déclarations de confidentialité manquantes ou inexactes
• Utilisation d'API privées ou non-respect des règles de la plateforme
• Paiements contournant le système de facturation obligatoire de la plateforme pour les biens numériques

Fournissez des identifiants de test, des notes à l'attention des reviewers et un build fonctionnel. La plupart des refus lors de la première soumission sont dus à des problèmes de procédure évitables, et non à des défauts profonds.

Déployez progressivement

N'ouvrez pas les vannes à 100 % de vos utilisateurs dès le premier jour :

• Utilisez TestFlight (iOS) et les tracks de test interne/fermé de Google pour valider le build de production auprès de vrais testeurs en amont.
• Google Play propose un déploiement progressif — publiez auprès d'un faible pourcentage d'utilisateurs, surveillez les métriques de crash et les notes, puis montez en charge. Stoppez et corrigez si quelque chose se casse.

Après le lancement

La publication n'est pas la ligne d'arrivée. Surveillez les rapports de crash et les avis, répondez aux retours, et planifiez votre rythme de mises à jour — chaque nouvelle version passe à nouveau en revue, intégrez-le à votre cycle de release.

Si vous souhaitez confier votre première publication de bout en bout — comptes, assets, signature et revue — sans les mauvaises surprises, parlons-en.