Le délai de grâce de l'API 36 sur Google Play est terminé, et les échéances de 2027 sur les permissions sont déjà fixées

Depuis le 31 août 2026, Google Play n'accepte plus que les nouvelles applications et les mises à jour qui ciblent Android 16 (API level 36) ou une version supérieure. Les applications Wear OS, Android Automotive OS, Android TV et Android XR sont exemptées. Les équipes qui avaient besoin de plus de temps pouvaient demander une prolongation jusqu'au 1er novembre 2026. Cette date est passée. Si votre targetSdkVersion est encore inférieure à 36, vous ne pouvez pas publier de mise à jour sur Play pour le moment, y compris le correctif urgent dont vous pourriez avoir besoin la semaine prochaine.

Les applications existantes qui ne sont pas mises à jour sont soumises à une règle distincte. Elles doivent cibler au moins Android 15 (API level 35) pour rester disponibles pour les nouveaux utilisateurs sur des appareils dont la version d'Android est plus récente que la cible de l'application. En dessous, l'application n'apparaît plus que pour les appareils qui tournent sous la même version d'Android ou une version plus ancienne. Une application que personne n'a touchée depuis un moment n'est donc pas retirée, elle devient simplement de plus en plus difficile à trouver.

Par-dessus, Google a annoncé le 29 octobre 2026 une série de changements de politique, dont les dates d'application s'étalent sur 2027. Aucun n'est urgent aujourd'hui. Mais tous risquent de tourner à la panique si on les découvre deux semaines avant l'échéance.

Le calendrier de 2027

Voici les dates issues du tableau des échéances (Policy Deadlines) de Google et de la page des politiques Play :

• 27 janvier 2027 : contacts. La politique d'autorisation Contacts restreint l'accès étendu aux contacts des utilisateurs. Les applications qui n'ont pas besoin d'un accès étendu doivent utiliser l'Android Contact Picker.
• 27 janvier 2027 : localisation précise. Les applications ciblant Android 17 (API 37+) doivent utiliser le bouton de localisation Android pour les demandes de localisation précise ponctuelles ou peu fréquentes. Si vous conservez ACCESS_FINE_LOCATION, vous devez fournir une déclaration dans la Play Console expliquant pourquoi le bouton de localisation ou la localisation approximative ne suffit pas.
• 27 janvier 2027 : remises d'abonnement. Les abonnements avec des remises permanentes soumises à des conditions d'éligibilité, comme les offres étudiantes, doivent indiquer clairement les critères d'éligibilité, le fonctionnement de la vérification, et ce qu'il advient du prix et des avantages lorsque l'utilisateur n'est plus éligible.
• 14 avril 2027 : AppFunctions. AppFunctions ne doit pas tromper ni manipuler les agents d'IA, contourner leurs contrôles de sécurité ou gêner d'autres applications.
• 25 août 2027 : ACCESS_LOCAL_NETWORK. L'accès au réseau local est réservé aux applications qui en ont besoin pour leur fonctionnalité principale lorsque les sélecteurs d'appareils comme NsdManager ne suffisent pas. Les applications ciblant Android 17 ou une version supérieure doivent fournir une déclaration dans la Play Console pour l'utiliser.
• 25 août 2027 : MANAGE_CONTACTS. Réservée aux applications dont la fonctionnalité principale en a besoin lorsque les sélecteurs système ne suffisent pas, avec une déclaration dans la Play Console. Tous les autres doivent utiliser des intents de plateforme à portée restreinte.

Pourquoi la hausse du niveau d'API cible piège toujours autant d'équipes

Dans nos projets Android natifs, relever targetSdkVersion est rarement la partie difficile. Changer un chiffre dans Gradle prend une minute. Le travail, c'est tout ce que ce chiffre active : les nouveaux comportements de la plateforme auxquels votre application adhère désormais, les bibliothèques qui n'ont pas suivi, et les appareils de test qui ne couvrent pas la nouvelle version. Nous avons vu une modification d'une seule ligne se transformer en sprint de trois semaines parce qu'un SDK de paiement ou une bibliothèque BLE n'avait pas encore publié de version compatible.

Le scénario que nous voyons le plus souvent : l'application fonctionne, personne n'en est responsable, et l'exigence sur l'API cible n'apparaît que sous la forme d'un avertissement de la Play Console, perdu dans une boîte mail partagée. Puis un vrai bug survient, le correctif est prêt, et l'envoi est rejeté. Vous voilà en pleine migration de plateforme, sous pression, avec un incident de production ouvert. C'est la situation dans laquelle se trouvent beaucoup d'équipes cette semaine.

Mon avis sincère : traitez la hausse annuelle de l'API cible comme une dépendance dont vous êtes responsable, pas comme une corvée imposée par Google. Inscrivez-la à la feuille de route chaque printemps, quand la nouvelle exigence est annoncée, et faites-la tant que rien n'est en feu.

Les changements sur les permissions comptent plus qu'il n'y paraît

Les règles de 2027 reposent sur une même idée. Les permissions étendues sont remplacées par des sélecteurs et des boutons système, et si vous voulez conserver la version étendue, vous devez vous justifier dans la Play Console.

Nous l'avons constaté surtout dans les applications de santé et d'IoT. Les applications IoT demandent souvent l'accès au réseau local très tôt, car la découverte des appareils est le premier écran, et il est facile de demander plus que nécessaire. Si un sélecteur basé sur NsdManager couvre votre parcours de découverte, la règle d'août 2027 se résume surtout à de la paperasse que vous pouvez éviter. Sinon, commencez dès maintenant à consigner pourquoi la fonctionnalité principale a besoin de cette permission, car c'est ce que demande la déclaration.

Il en va de même pour les contacts. Beaucoup d'applications demandent l'accès complet aux contacts pour un seul écran « inviter un ami ». Le Contact Picker couvre ce cas, et y passer avant janvier supprime une permission dont les utilisateurs se méfient de toute façon. Côté sécurité, c'est aussi une bonne nouvelle. Dans nos missions de test d'intrusion, les permissions trop larges reviennent régulièrement : des données dont l'application n'avait jamais besoin, stockées dans un cache local, accessibles à quiconque prend pied sur l'appareil. Moins d'accès, c'est moins à faire fuiter.

La règle du bouton de localisation ne s'applique qu'une fois que vous ciblez Android 17, mais si vous proposez un localisateur de magasins ou un champ « utiliser ma position » dans le paiement, planifiez dès maintenant la modification de l'interface. Un bouton en un clic est un parcours différent d'une boîte de dialogue de permission à l'exécution, et les designers voudront leur mot à dire.

Ne négligez pas les règles sur les abonnements et AppFunctions

La règle de transparence sur les abonnements passe facilement inaperçue, car elle relève du produit et du juridique, pas du code. Si vous proposez une offre étudiante ou une autre offre soumise à éligibilité, quelqu'un doit rédiger le processus de vérification et le prix après perte d'éligibilité sur le paywall lui-même. Dans le travail web et back-end que nous menons pour des clients entreprise, ce type d'exigence implique généralement de modifier à la fois les textes de l'application et le serveur qui détermine qui reste éligible : impliquez donc l'équipe back-end dès le début.

AppFunctions est un terrain plus récent. La politique est courte : ne trompez pas les agents d'IA, ne contournez pas leurs contrôles de sécurité, ne gênez pas d'autres applications. Si vous exposez des actions de votre application à des agents, passez-les en revue comme vous le feriez pour une API publique. Vérifiez ce que chaque fonction peut faire sans confirmation de l'utilisateur, et partez du principe que quelque chose l'appellera avec des entrées que vous n'aviez pas prévues.

Que faire cette semaine

1. Vérifiez dès aujourd'hui votre niveau d'API cible. S'il est inférieur à 36, la mise à niveau bloque désormais chaque version. Créez une branche, relevez-le, lancez toute votre suite de tests sur un appareil Android 16 et mettez à jour toute bibliothèque qui casse.
2. Auditez votre manifeste. Listez chaque usage de READ_CONTACTS, MANAGE_CONTACTS, ACCESS_FINE_LOCATION et ACCESS_LOCAL_NETWORK, et notez en face de chacun si un sélecteur ou un bouton pourrait le remplacer.
3. Mettez les dates de 2027 dans un calendrier partagé, avec un responsable pour chacune, pas seulement un rappel Slack.
4. Affectez quelqu'un à la boîte de réception de la Play Console. La plupart des problèmes que nous voyons commencent par un avertissement que personne n'a lu.

Si vous voulez voir comment nous avons déjà mené des migrations de plateforme de ce type, notre portfolio en présente quelques exemples, et notre travail de développement couvre à la fois Android natif et les back-ends qui l'accompagnent.

Si un targetSdkVersion bloqué ou un audit de permissions sans cesse repoussé vous parle, discutons-en.