Publier une application sur l'App Store et Google Play en 2026 : les règles qui bloquent
Le code est terminé, l'application tourne sur les téléphones de l'équipe, le client demande une date. C'est en général à ce moment qu'un projet mobile découvre son étape finale — la seule où la décision ne lui appartient plus. Publier n'est pas déployer : deux entreprises examinent le binaire, appliquent leurs propres règles et peuvent refuser. Voici ce qui bloque réellement en 2026, documents officiels à l'appui, et ce que nous en avons retenu en publiant Daiky sur l'App Store et MamaSafe Food sur Google Play.
Publier n'est pas déployer
Sur le web, la mise en ligne est un acte technique : on pousse, on invalide un cache, c'est en production. Sur mobile, elle est un acte contractuel. Le binaire part chez un tiers qui l'examine au regard d'un référentiel qu'il écrit seul et qu'il modifie quand il veut. Ce tiers peut demander une correction, une preuve, un compte de démonstration — la règle 2.1 des App Store Review Guidelines exige d'ailleurs explicitement des identifiants de test fonctionnels et un back-end allumé si l'application comporte une authentification.
Cette étape a aussi un coût fixe, distinct du budget de développement : 99 USD par an pour l'Apple Developer Program, et 25 USD une seule fois pour un compte Google Play. Des montants modestes, mais qu'un devis honnête isole plutôt que de les noyer ; nous les traitons comme tels dans notre article sur le coût d'une application mobile et dans le calculateur de budget.
L'inscription d'une organisation chez Apple exige en outre un numéro D‑U‑N‑S, attribué par Dun & Bradstreet, une adresse e‑mail au domaine de la société et un site web public. Ce numéro est gratuit dans la plupart des juridictions, mais pas instantané : c'est la première dépendance externe d'un projet mobile, et elle tombe presque toujours au mauvais moment.
Les deux échéances techniques de 2026
Chaque boutique impose un socle technique minimal, révisé chaque année. Ce ne sont pas des recommandations : en dessous du seuil, la soumission est refusée par l'outil, avant même la revue humaine.
Google Play : cibler Android 16 au 31 août 2026
La règle est datée et publique : « Starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play » (niveau d'API cible requis, aide Google Play). Une extension est possible jusqu'au 1er novembre 2026 pour les équipes qui ont besoin de temps.
Relever le niveau d'API cible n'est pas un changement de ligne dans un fichier de configuration. Chaque palier d'Android durcit des comportements — permissions, tâches en arrière-plan, accès au stockage — et une application qui compile n'est pas une application qui fonctionne encore. C'est un lot de travail à part entière, à planifier avant l'été et non pendant.
App Store : compiler avec Xcode 26 depuis le 28 avril 2026
Côté Apple, l'exigence est en vigueur depuis le printemps : « Apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26 » (Upcoming Requirements, Apple Developer). La même page a imposé, au 31 janvier 2026, de répondre aux questions de notation d'âge actualisées sous peine d'interruption des soumissions.
La conséquence pratique est sous-estimée : une application qu'on ne touche plus pendant huit mois ne peut pas livrer un correctif urgent sans remonter d'abord la chaîne d'outils, revalider les dépendances et refaire passer les tests. C'est pour cela que nous montons les projets avec des environnements séparés et une intégration continue dès le premier jour, comme sur Vulto : le coût est visible au démarrage, et bien plus élevé le jour où il faut réagir vite.
Le compte développeur, l'étape qu'on découvre trop tard
Google Play : 12 testeurs pendant 14 jours
Pour les comptes développeur personnels créés récemment, Google conditionne l'accès à la production à une phase de test fermé : « At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days » (exigences de test fermé, aide Google Play).
Traduit en calendrier : un fondateur seul qui ouvre son compte le jour de la livraison ne publie pas ce jour-là, ni la semaine suivante. Il lui faut douze personnes réelles, inscrites sans interruption, pendant deux semaines. C'est une contrainte de planning, pas un détail administratif — et c'est la raison pour laquelle nous ouvrons les comptes pendant l'atelier de cadrage.
App Store : le statut de professionnel imposé par le DSA
Depuis le 17 février 2025, « apps without trader status will be removed from the App Store in the European Union (EU) until trader status is provided and verified in order to comply with the Digital Services Act » (Upcoming Requirements, Apple Developer). Le règlement européen sur les services numériques oblige Apple à vérifier puis à afficher les coordonnées de contact du professionnel sur la fiche produit.
Deux effets à anticiper : ces coordonnées deviennent publiques sur la fiche de l'application dans les vingt-sept pays de l'Union, ce qu'un développeur publiant sous son nom propre doit mesurer ; et la sanction n'est pas un avertissement mais un retrait, jusqu'à régularisation.
Les déclarations de confidentialité sont devenues bloquantes
Longtemps traitées comme de la paperasse de fin de projet, elles conditionnent aujourd'hui l'envoi du binaire lui-même. Depuis le 1er mai 2024, Apple impose de déclarer, dans un manifeste de confidentialité, une raison approuvée pour chaque API dite « à raison requise » utilisée par le code de l'application ; les applications qui ne satisfont pas aux exigences de manifeste et de signature ne sont pas acceptées (Privacy updates for App Store submissions). L'obligation s'étend aux SDK tiers couramment utilisés : une bibliothèque d'analytics mal choisie bloque la soumission de toute l'application.
Google impose son pendant avec la section « Sécurité des données » : « All developers must declare how they collect and handle user data for the apps they publish on Google Play », y compris les données collectées par les bibliothèques et SDK tiers (Data safety, aide Google Play). La déclaration engage le développeur seul, et elle doit couvrir toutes les versions distribuées.
Les deux boutiques exigent par ailleurs une voie de suppression de compte. Apple : « If your app supports account creation, you must also offer account deletion within the app » (règle 5.1.1(v)). Google demande à la fois un chemin de suppression dans l'application et un lien web permettant d'en faire la demande (suppression du compte, aide Google Play). La règle 5.1.1(i) d'Apple va plus loin : la politique de confidentialité doit être accessible dans les métadonnées et dans l'application, et expliquer les durées de conservation ainsi que la manière de retirer son consentement.
Sur des produits qui touchent au corps et à la santé, ces obligations cessent d'être formelles. Daiky analyse ce qu'une personne s'applique sur la peau, MamaSafe Food ce qu'une femme enceinte s'apprête à manger : le périmètre des données collectées est une décision d'architecture, prise au cadrage, pas une case à cocher à la soumission. C'est la même logique que celle décrite dans notre checklist RGPD pour le développement web, appliquée au mobile.
Les règles de paiement, le poste le plus coûteux à corriger tard
C'est ici que se jouent les refus les plus douloureux, parce qu'ils remettent en cause le modèle économique et non une ligne de code. La règle 3.1.1 d'Apple est sans ambiguïté : « If you want to unlock features or functionality within your app […] you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys […] ».
Deux dérogations décident du sort de la plupart des projets B2B. La règle 3.1.3(c), « Enterprise Services », vise les applications « only sold directly by you to organizations or groups for their employees or students » et leur permet d'ouvrir l'accès à un abonnement déjà acheté ; elle précise que les ventes grand public, individuelles ou familiales, doivent passer par l'achat intégré. La règle 3.1.3(b), « Multiplatform Services », autorise l'accès à un contenu ou un abonnement acquis sur une autre plateforme ou sur votre site, « provided those items are also available as in-app purchases within the app ».
La distinction n'est pas théorique. AquaPro Manager est une plateforme SaaS vendue à des professionnels de la piscine, avec deux plans souscrits par Stripe depuis la plateforme et une application Flutter qui sert d'outil de terrain. La forme du produit — à qui il est vendu, où l'abonnement est souscrit, ce que l'application déverrouille — détermine la règle applicable, et donc l'architecture de facturation. Se poser la question après le développement, c'est réécrire le tunnel de paiement.
Google raisonne différemment mais aboutit à une contrainte comparable : sa politique de paiements réserve l'exemption aux biens physiques et aux services consommés hors application, « such as groceries, clothing, housewares, electronics » ou « transportation services, cleaning services, airfare » (Payments policy, aide Google Play). Un abonnement numérique n'entre dans aucune de ces catégories : le plan Premium de MamaSafe Food, à 4,99 € par mois, relève de la facturation Google Play.
Reste la règle qui coûte le plus cher aux applications les plus légères, la 4.2 « Minimum Functionality » : « Your app should include features, content, and UI that elevate it beyond a repackaged website ». Une application qui se contente d'afficher un site dans une vue web n'a pas sa place sur l'App Store — et c'est exactement ce que produit une conversion à bas coût. Le sujet rejoint celui du choix entre Flutter et React Native : le premier compile en code natif, le second s'appuie sur les composants natifs des deux systèmes ; aucun des deux ne fabrique un habillage de site web.
Ce que nous cadrons désormais avant la première ligne de code
Aucune de ces règles n'est difficile prise isolément. Elles coûtent cher parce qu'on les découvre dans l'ordre inverse de celui où il aurait fallu les traiter. Six points sont donc arbitrés pendant l'atelier de cadrage de nos projets mobiles :
- le modèle économique confronté aux règles de paiement des deux boutiques, avant la maquette ;
- l'ouverture et la vérification des comptes développeur, y compris le numéro D‑U‑N‑S et le statut de professionnel ;
- le périmètre des données collectées, écrit en même temps que les fonctionnalités et non après ;
- le parcours de suppression de compte, dans le périmètre initial ;
- une chaîne d'intégration continue tenue à jour, pour que la prochaine échéance de SDK soit un lot planifié et non une urgence ;
- une fenêtre de revue explicite dans le planning, avec la possibilité d'un aller-retour.
C'est ce que couvre notre service de développement d'application mobile, et ce que nous détaillons aux entreprises de la région sur la page agence application mobile à Antibes. Le compte développeur reste au nom du client : c'est son actif, avec ses avis et son historique de versions.
