Depuis le 31 août 2026, Google Play refuse toute nouvelle application et toute mise à jour qui ne cible pas Android 16 (API 36). Pour les retardataires, le délai de grâce accordé sur demande s'achève le 1er novembre 2026. C'est le rendez-vous annuel de la maintenance application mobile : voici ce qu'il change concrètement pour une PME qui a une application sur le Play Store, et comment s'y préparer sans précipitation.

Ce que Google exige exactement

Chaque année, Google relève le niveau d'API minimal que doivent cibler les applications publiées sur son magasin. La règle 2026, publiée sur la documentation officielle Android Developers, tient en trois points :

  • Nouvelles applications et mises à jour : elles doivent cibler Android 16 (API 36) ou plus pour être soumises. Les applications Wear OS et Android Automotive doivent cibler Android 15 (API 35), celles pour Android TV et Android XR Android 14 (API 34).
  • Applications existantes : elles doivent cibler au moins Android 15 (API 35) pour rester proposées aux nouveaux utilisateurs dont le téléphone tourne sous une version plus récente d'Android.
  • Délai supplémentaire : Google permet de demander une prolongation jusqu'au 1er novembre 2026, via un formulaire dans la Play Console.

Une exception existe : les applications privées, réservées aux utilisateurs d'une organisation et diffusées uniquement en interne, ne sont pas soumises à cette exigence.

Ce qui se passe si vous ne faites rien

L'application ne disparaît pas du jour au lendemain, et c'est précisément ce qui rend le sujet piégeux. Vos utilisateurs actuels la gardent et continuent de s'en servir. Mais deux effets apparaissent :

  • Vous ne pouvez plus publier de mise à jour. Le jour où un bug bloquant apparaît, où une API partenaire change ou où une faille doit être corrigée, la Play Console refuse votre version tant que le niveau d'API cible n'est pas remonté. La mise en conformité se fait alors dans l'urgence, en même temps que le correctif.
  • Vous perdez progressivement de nouveaux utilisateurs. Une application qui cible Android 14 ou moins n'est plus proposée aux nouveaux utilisateurs équipés d'une version d'Android plus récente que celle qu'elle cible. Pour une application client ou une application utilisée par des techniciens qui renouvellent leurs téléphones, l'érosion est silencieuse mais réelle.
Le vrai risque n'est pas le retrait de l'application, c'est de se retrouver incapable de la corriger le jour où vous en avez besoin.

Niveau d'API cible : de quoi parle-t-on ?

Le niveau d'API cible, déclaré dans le paramètre targetSdkVersion, indique la version d'Android pour laquelle l'application a été conçue et testée. Il ne limite pas les téléphones sur lesquels elle s'installe : une application qui cible Android 16 peut très bien fonctionner sur un appareil sous Android 10.

Ce qui change, c'est le comportement du système. Chaque nouvelle version d'Android introduit des règles plus strictes en matière de sécurité, de confidentialité ou d'affichage, mais ne les applique qu'aux applications qui déclarent les supporter. Relever le niveau d'API cible, c'est accepter ces nouvelles règles, et donc vérifier que l'application les respecte.

Les changements Android 16 qui peuvent casser une application

D'après la liste officielle des changements de comportement pour les applications ciblant Android 16, plusieurs points méritent un test attentif sur une application métier ou une application client :

Affichage bord à bord obligatoire

Android 15 imposait déjà l'affichage bord à bord, avec une option de désactivation. Pour les applications ciblant Android 16, cette option est désactivée sur les appareils Android 16 : l'interface s'étend sous la barre d'état et la barre de navigation. Un bouton ou un champ trop près du bord peut se retrouver masqué.

Retour prédictif activé par défaut

Les animations de « retour prédictif » sont activées par défaut, et l'ancienne méthode onBackPressed n'est plus appelée. Si votre application intercepte le bouton retour, par exemple pour demander « Voulez-vous enregistrer ce formulaire ? », ce comportement doit être migré vers les nouvelles API, ou temporairement désactivé.

Tablettes et grands écrans

Sur les écrans d'au moins 600 dp de largeur minimale, typiquement les tablettes et les pliables ouverts, Android ignore désormais les restrictions d'orientation et de redimensionnement. Une application verrouillée en mode portrait s'affichera en plein écran, éventuellement en paysage. Pour les applications de terrain utilisées sur tablette, c'est souvent le point le plus visible : mises en page étirées, éléments hors champ, saisie perdue lors d'une rotation. Une désactivation temporaire existe, mais Google annonce qu'elle ne fonctionnera plus avec la future API 37.

Capteurs de santé et Bluetooth

Les applications qui lisent la fréquence cardiaque ou d'autres capteurs corporels doivent demander de nouvelles autorisations plus fines. Côté Bluetooth, Android 16 introduit de nouveaux signaux pour gérer la perte d'appairage, utiles pour les applications connectées à des appareils de mesure, imprimantes ou lecteurs.

La méthode en 5 étapes pour passer le cap

  1. Faire l'état des lieux. Vérifiez dans la Play Console le niveau d'API ciblé par chaque application et la date de la dernière mise à jour. Une application qui cible encore Android 13 ou 14 cumule plusieurs années de changements à absorber.
  2. Demander le délai si nécessaire. Si la mise en conformité ne peut pas aboutir avant le 1er novembre, la demande de prolongation se fait depuis la Play Console. Elle donne de l'air, pas une solution.
  3. Mettre à jour la chaîne de développement. Selon la technologie utilisée (natif Kotlin, Flutter, React Native…), il faut d'abord monter de version les outils de compilation et les bibliothèques. C'est souvent là que se cache l'essentiel de l'effort, surtout si les dépendances n'ont pas été suivies.
  4. Tester les parcours critiques sur Android 16. Connexion, saisie, photo, synchronisation, impression : testez sur un téléphone et sur une tablette, en rotation, avec le geste retour. Les tests automatisés de non-régression réduisent fortement ce travail.
  5. Publier en déploiement progressif. La Play Console permet de diffuser une version à une fraction des utilisateurs avant de l'étendre. Surveillez les plantages remontés pendant quelques jours avant de passer à 100 %.

Faire de cette échéance un rendez-vous de maintenance

L'exigence revient chaque année, avec un nouveau niveau d'API. Les entreprises qui la subissent sont souvent celles dont l'application a été livrée puis laissée de côté. Le plus efficace est d'intégrer cette montée de version au contrat de maintenance de l'application mobile : veille sur les annonces de Google et d'Apple, mise à jour des dépendances au fil de l'eau, test annuel sur la nouvelle version du système. L'effort est alors étalé et prévisible, plutôt que concentré dans l'urgence d'un correctif bloqué.

Si votre application a été développée par un prestataire qui n'est plus joignable, ou si vous ne savez même pas où se trouve le code source, c'est le bon moment pour faire un audit. Notre offre de reprise et modernisation d'applications part justement de cette situation.

Questions fréquentes

Mon application Android disparaît-elle du Google Play si je ne cible pas Android 16 ?

Non. Une application déjà publiée reste installée chez ses utilisateurs actuels. En revanche, vous ne pouvez plus soumettre de mise à jour tant qu'elle ne cible pas Android 16 (API 36), et si elle cible Android 14 ou moins, elle devient invisible pour les nouveaux utilisateurs équipés d'une version plus récente d'Android.

Qu'est-ce que le niveau d'API cible d'une application ?

C'est la version d'Android pour laquelle l'application déclare avoir été testée, via le paramètre targetSdkVersion. Il ne fixe pas les téléphones compatibles : il indique au système quels nouveaux comportements appliquer à l'application.

Une application interne à mon entreprise est-elle concernée ?

Les applications privées, réservées aux utilisateurs d'une organisation et diffusées uniquement en interne, font partie des exceptions prévues par Google. Une application publique, même destinée à vos seuls clients ou techniciens, reste concernée.

Combien de temps faut-il pour passer une application à Android 16 ?

Cela dépend de l'écart entre la version ciblée actuellement et Android 16, de la technologie utilisée et de la couverture de tests. Une application maintenue régulièrement se met à niveau en quelques jours ; une application restée plusieurs versions en arrière demande un audit avant de s'engager sur un délai.

Votre application est-elle prête pour Android 16 ?

Pulsar Forge vérifie l'état de votre application, estime l'effort de mise à niveau et peut prendre en charge sa maintenance dans la durée, que nous l'ayons développée ou non. Parlons de votre application.