Publier une app mobile sur l'App Store et Google Play : ce qu'il faut vraiment savoir en 2026

Publier une app mobile, on croit que c'est un bouton "envoyer" au bout du sprint 12. En pratique, c'est un vrai chantier parallèle qui commence 4 semaines avant la sortie et se rejoue à chaque version. Voici ce qu'on aurait aimé savoir avant de publier notre première app — et ce qu'on remet en place à chaque nouveau produit chez MAG&Cie.

Les comptes développeur : moins cher qu'on le dit, plus long à obtenir

Apple Developer Program. 99 $ HT / an, renouvellement automatique. À prendre au nom d'une entité juridique si vous êtes une entreprise (avec un numéro DUNS — comptez 2 à 5 jours ouvrés pour l'obtenir gratuitement via Dun & Bradstreet). Le compte personnel coûte pareil mais empêche de mettre un nom de société comme éditeur — impossible à changer après.

Google Play Console. 25 $ HT, une seule fois, à vie. Compte perso ou pro. Depuis 2023, Google exige une vérification d'identité (pièce d'identité + adresse). Depuis 2024, les nouveaux comptes personnels doivent démontrer qu'ils ont testé leur app avec au moins 12 testeurs pendant 14 jours avant la première mise en production. C'est une vraie barrière — anticiper.

Le temps caché, c'est la validation légale : mentions "Éditeur", "Support URL", "Marketing URL", politique de confidentialité (URL publique obligatoire, hébergement à faire), rating pegi/esrb, catégorisation. Compter une demi-journée cumulée pour un premier compte.

Guidelines : ce qui bloque, ce qui passe

Les rejets ne viennent presque jamais du code. Ils viennent de la présentation ou de la politique. Les trois zones critiques :

1. Description et captures. Apple guideline 2.3 : "Accurate metadata". Vos captures doivent montrer ce que l'app fait réellement — pas de mockup marketing avec des données inventées, pas de fonctions qui n'existent pas. Toute divergence = rejet 2.3.1. Google est plus tolérant mais peut retirer l'app rétrospectivement.

2. Permissions. Chaque permission demandée dans l'app (localisation, contacts, caméra, notifications) doit être justifiée dans le code (NSLocationWhenInUseUsageDescription côté iOS, <uses-permission> avec justification côté Android) ET dans les captures. Demander une permission sans jamais s'en servir de manière visible = rejet 5.1.1.

3. Contenu généré par l'utilisateur. Si votre app permet à des utilisateurs de publier du contenu, Apple exige (guideline 1.2) : (a) un mécanisme de signalement, (b) un mécanisme de blocage utilisateur, (c) un moyen pour vous de bannir des comptes abusifs, (d) une politique claire dans les CGU. Absence de l'un des quatre = rejet, même si l'app est irréprochable techniquement.

Préparer les visuels : le vrai goulot d'étranglement

Ce que les stores demandent (en 2026, sujet à ajustement continu) :

App Store (iOS) :

• Icône 1024×1024, PNG sans transparence, coins non arrondis (Apple arrondit).
• Captures 6.7" (iPhone 15 Pro Max) et 6.5" (iPhone 11 Pro Max) minimum — le reste (iPad, Apple Watch) uniquement si vous ciblez ces plateformes.
• 3 à 10 captures par taille. Les 3 premières sont montrées sans scroll — elles portent 90 % du taux d'installation.

Google Play :

• Icône 512×512.
• Feature graphic 1024×500 — obligatoire, souvent oublié. C'est la bannière en haut de la fiche.
• Captures téléphone + tablette selon les form-factors ciblés, 2 minimum, 8 max.

Le piège classique : générer les captures depuis un simulateur "à la va-vite" avec des données de dev. Résultat : rejet 2.3 côté Apple, et 50 % du CTR perdu côté Google. Prévoir un mini-shooting Figma / Rotato de 2 à 4 heures, une seule fois, avec un template réutilisable pour les futures versions.

TestFlight et Internal Testing : non négociables

TestFlight (iOS). Compilation avec Xcode ou EAS Build, upload via xcrun altool ou App Store Connect API, activation de TestFlight pour la version. Testeurs internes (jusqu'à 100 sur votre équipe Apple Developer) : accès immédiat. Testeurs externes (jusqu'à 10 000, invités par email ou lien public) : passent par une revue TestFlight — 24 à 48 heures. Beaucoup l'ignorent : TestFlight n'est pas "gratuit et instantané" côté externe.

Internal Testing (Google Play). Upload d'un AAB (Android App Bundle, pas APK depuis 2021), assignation à une piste "Test interne" avec la liste d'emails Google. Accès immédiat, pas de revue. Utile pour valider vos crashes en conditions réelles avant la piste fermée puis la prod.

Piste fermée (Closed Testing) côté Google : c'est elle qui déclenche le compteur "12 testeurs × 14 jours" pour les nouveaux comptes perso. Sans ça, impossible de sortir en production.

Notre règle chez MAG&Cie : jamais d'update en prod qui n'ait pas tourné au moins 48 heures sur TestFlight/Internal. Ce qui casse en prod aurait cassé en test — mais en test, ça se répare à coût zéro.

Le premier envoi : la checklist

Avant de cliquer "Submit for Review", vérifier :

• Numéro de version monotone croissant : la buildNumber (iOS) et le versionCode (Android) doivent être strictement supérieurs à celui de la dernière version publiée, même si vous avez incrémenté le version sémantique.
• Signing. iOS : distribution certificate + provisioning profile App Store à jour (à renouveler chaque année, l'oublier = 12 mois d'attente). Android : upload key en Play App Signing (Google gère la signing key finale).
• Data safety (Play Console). Formulaire à remplir à la main, à chaque nouvelle version qui change les données collectées. Google confronte ce formulaire à l'analyse statique de votre APK — un mismatch bloque la publication.
• Privacy Manifest (iOS). Depuis mai 2024, iOS 17.4, obligatoire pour toute app qui utilise des SDK sur la liste "required reason APIs" (UserDefaults, filesystem timestamp, etc.). Fichier PrivacyInfo.xcprivacy à inclure dans le bundle, plus une déclaration dans App Store Connect.
• Age rating cohérent avec le contenu.
• URL de support qui répond en HTTP 200 (pas un domaine parqué).

Le versioning après publication

Une fois publié, la vraie discipline commence. Chez MAG&Cie, sur Lirix et MyOpenSpot, on tient les règles suivantes :

• Semver strict côté marketing (1.2.3), incréments monotones côté store (buildNumber iOS, versionCode Android). Automatisation via GitHub Actions + EAS.
• Release notes localisées systématiques : rien de pire qu'un utilisateur qui voit "Bug fixes and improvements" à chaque update.
• Phased release (iOS) activée par défaut : Apple pousse la nouvelle version à 1 %, 2 %, 5 %, 10 %, 20 %, 50 %, 100 % sur 7 jours. Permet de retirer l'update en cas de crash massif détecté sur les 10 000 premiers utilisateurs.
• Staged rollout (Android) : équivalent côté Google, à activer manuellement, canal par canal.
• Sentry ou équivalent connecté aux crash reports natifs + JS. Un crash > 0.1 % de sessions = rollback avant d'attendre le mail Apple.

Ce qui coûte le plus cher

Ce n'est pas la publication elle-même. C'est :

1. La double gymnastique iOS + Android — deux stores, deux formats de capture, deux systèmes de signing, deux formulaires de privacy, deux consoles à tenir à jour. La lazy solution — un pipeline EAS Build unique qui pousse sur les deux — coûte 2 jours à mettre en place, puis se rentabilise à chaque version.
2. Le premier rejet Apple — 3 à 5 jours perdus, souvent au pire moment (juste avant un event marketing). La parade : lancer la revue 14 jours avant la date de sortie visée, avec un buffer.
3. La maintenance des comptes — expiration du DUNS, renouvellement des certificats, mise à jour du Privacy Manifest à chaque nouveau SDK, formulaire data safety qui change de format Google tous les 6 mois. Compter une demi-journée par trimestre juste pour tenir la conformité.

À qui confier ça

Si vous publiez votre première app et que vous n'avez pas d'équipe technique dédiée, le calcul est simple : une agence facturera 2 000 à 6 000 € pour le premier setup complet (comptes + pipelines + première publication) — le prix d'éviter les 3 à 5 rejets classiques et de récupérer un template réutilisable. À partir de la 3ᵉ ou 4ᵉ app, l'automation s'amortit et vous internalisez.

MAG&Cie propose exactement ce format : setup complet + première publication + transfert de compétence à vos équipes internes. Voir notre prestation de développement d'applications ou nos réalisations mobiles (Lirix, MyOpenSpot).

Publier, c'est facile. Publier sans être bloqué la semaine du lancement, c'est un métier.