Depuis le 31 août 2026, Google Play applique une règle simple à dire et coûteuse à ignorer : pour publier une nouvelle version d'une app, celle-ci doit viser Android 16, ce que les développeurs appellent l'API 36. Les apps qui n'ont pas suivi ne disparaissent pas du Play Store, mais elles perdent quelque chose de plus discret et de plus gênant.
Les deux règles, en clair
Pour publier. Toute mise à jour envoyée sur le Play Store doit cibler l'API 36. Un correctif d'une ligne compte comme une mise à jour : si l'app n'a pas été portée sur la nouvelle version d'Android, elle ne peut plus sortir de correctif du tout. Google a laissé la possibilité de demander un délai, et ces délais se terminent le 1er novembre 2026.
Pour être trouvée. Une app déjà publiée qui cible encore Android 14 (API 34) ou moins n'est plus proposée aux nouveaux utilisateurs dont le téléphone tourne sous une version d'Android plus récente que celle visée par l'app. Les utilisateurs actuels la gardent. Les nouveaux, sur un téléphone récent, ne la voient plus.
C'est cette deuxième règle qui fait mal sans prévenir. Rien ne casse, aucune alerte n'arrive, et les installations se tarissent doucement, ce qu'on met facilement sur le compte du marché.
Comment savoir si vous êtes concerné
Sans accès au code, la date de dernière mise à jour sur la fiche Play Store donne déjà une bonne indication. Une app qui n'a pas été mise à jour depuis l'été 2025 vise très probablement l'API 34 ou moins, parce que la règle précédente (l'API 35) est entrée en vigueur le 31 août 2025.
Avec accès à la Play Console, c'est exact : la version de chaque release indique l'API ciblée, et la console signale les versions qui ne respectent plus les exigences.
Ce que coûte la remise à niveau
Rarement ce que les gens imaginent. Passer d'une version d'Android à la suivante n'est pas une réécriture : c'est une montée de version du projet, des dépendances qui suivent, puis les comportements qu'Android a durcis en route. Les vrais sujets, dans cet ordre :
- les permissions et l'accès aux fichiers, qui se sont resserrés à chaque version ;
- les tâches en arrière-plan et les notifications, plus encadrées ;
- les bibliothèques abandonnées, qui n'ont pas de version compatible et qu'il faut remplacer ;
- la chaîne de build elle-même, souvent bloquée sur un Gradle ou un plugin trop ancien.
Sur une app de taille moyenne et en bonne santé, cela se compte en jours. Sur une app laissée de côté trois ans, avec des dépendances mortes, cela peut prendre deux à trois semaines. La différence ne vient pas de la règle Google, elle vient de la dette accumulée avant elle.
Et si l'app n'évolue plus ?
C'est une décision légitime. Une app en fin de vie peut rester en place pour ses utilisateurs actuels, sans mise à jour. Mais il faut le décider, pas le subir : tant que rien n'est fait, elle continue de perdre des installations, et le jour où un bug bloquant apparaît, aucun correctif ne peut sortir.
Si vous voulez de l'aide
Je remets des apps iOS et Android en conformité : build à jour, mise à jour acceptée par le store, et un compte rendu clair de ce qui a été touché. Le détail des règles et des dates est résumé sur la page Mise à jour et conformité des stores, et un audit de cinq jours répond à la question plus large de l'état de l'app.
Sources officielles : Exigences de niveau d'API cible sur Google Play et l'aide Google Play pour les développeurs.