Google Play exige Android 16 : votre application peut-elle encore être mise à jour ?

Une application mobile ne vieillit pas comme un site web. Chaque année, Google et Apple relèvent le niveau minimum exigé pour publier, et une application qui ne suit pas ne disparaît pas : elle se fige. Si votre application a été développée par un prestataire qui n’est plus là, ou si personne ne s’en occupe depuis un an, l’échéance du 1er novembre 2026 vous concerne directement. Le plus sûr est de commencer par un audit de reprise qui dit précisément ce qu’il faut changer avant d’y toucher.

Que change l’obligation Android 16 de Google Play ?

Depuis le 31 août 2026, Google Play refuse toute nouvelle application et toute mise à jour qui ne cible pas Android 16, soit le niveau d’API 36. Les développeurs peuvent demander un délai jusqu’au 1er novembre 2026. Les applications déjà publiées doivent cibler au moins Android 15 pour rester visibles des nouveaux utilisateurs.

Le niveau d’API cible est un réglage déclaré dans chaque application Android, qui indique pour quelle version du système elle a été conçue et testée. Android adapte son comportement à ce niveau : une application qui cible une version récente reçoit les nouvelles règles de sécurité, d’affichage et de confidentialité.

Le calendrier, tel que Google le publie dans l’aide de la Play Console :

Ce n’est pas une règle nouvelle : Google relève ce plancher tous les ans, à la même période. En 2025, il fallait déjà cibler Android 15 depuis le 31 août. Une application sans maintenance prend donc un an de retard chaque année, et le rattrapage coûte plus cher à chaque saut.

Mon application va-t-elle disparaître du Play Store ?

Non, une application qui ne cible pas Android 16 n’est pas supprimée : elle reste en ligne et ses utilisateurs actuels la gardent. Mais elle est gelée. Vous ne pouvez plus publier de correctif, de nouveauté ni de mise à jour de sécurité tant qu’elle ne cible pas le niveau exigé.

La seconde conséquence est plus silencieuse. Une application qui cible Android 14 ou moins n’est plus proposée aux nouveaux utilisateurs dont le téléphone tourne sur une version plus récente d’Android. Elle ne disparaît pas de votre Play Console, elle disparaît des recherches de vos futurs clients.

Concrètement, trois signaux montrent que vous êtes déjà concerné :

• la Play Console affiche un avertissement sur le niveau d’API cible de votre application ;
• votre dernière tentative de publication a été refusée à l’envoi ;
• les installations de votre application baissent sans raison commerciale apparente.

Qu’est-ce qui casse quand on passe à Android 16 ?

Changer le niveau d’API cible ne se résume pas à modifier un chiffre. En ciblant Android 16, l’application accepte trois changements de comportement qui cassent régulièrement l’affichage ou la navigation. C’est pour cela qu’une mise à jour bâclée est plus risquée qu’une application gelée.

Les trois changements qui touchent le plus d’applications, d’après la documentation officielle d’Android 16 :

1. L’affichage bord à bord devient obligatoire. L’affichage bord à bord est le mode dans lequel l’application dessine sous la barre d’état et la barre de navigation du téléphone. Android 15 permettait encore de le désactiver ; avec Android 16, cette échappatoire disparaît. Une application qui n’a pas été adaptée voit ses boutons ou ses titres passer sous l’heure et la batterie.
2. Le retour arrière change de mécanique. Le geste de retour prédictif, qui montre un aperçu de l’écran précédent pendant le geste, est activé par défaut. L’ancienne façon d’intercepter le bouton retour n’est plus appelée : un formulaire qui demandait « voulez-vous vraiment quitter ? » peut se fermer sans prévenir.
3. Les tablettes et les écrans pliables imposent leur format. Sur les écrans larges, Android 16 ignore désormais les verrouillages d’orientation et de proportions. Une application pensée uniquement en portrait s’étire sur toute la largeur d’une tablette, avec une mise en page qui n’a jamais été prévue pour ça.

À ces trois changements s’ajoute le problème le plus fréquent : les dépendances. Une application utilise des briques tierces pour le paiement, les notifications ou la cartographie, appelées SDK (kits de développement fournis par un éditeur pour intégrer son service). Si l’une d’elles n’a pas été mise à jour pour Android 16, la migration bloque tant qu’elle n’est pas remplacée ou mise à niveau.

Côté framework, une application écrite en Flutter, le framework de Google qui produit iOS et Android depuis une seule base de code, se migre en mettant à jour Flutter puis ses dépendances. Chez Krafter, Flutter tourne en production depuis 2024 : Melimelo, notre application d’organisation du foyer, compte plus de 50 versions publiées et suit chaque nouvelle version d’Android et d’iOS. C’est ce rythme régulier qui évite les migrations douloureuses.

Et sur iPhone, que demande Apple en 2026 ?

Apple impose ses propres échéances. Depuis le 28 avril 2026, toute application envoyée à l’App Store doit être compilée avec Xcode 26 ou plus récent et le SDK d’iOS 26. Depuis le 9 septembre 2026, elle doit aussi fonctionner au minimum sur iOS 13. Une application qui n’a pas été recompilée depuis un an ne peut plus recevoir de mise à jour.

Ces deux exigences sont publiées sur la page des prochaines exigences d’Apple. Xcode est l’outil d’Apple qui compile les applications iPhone ; changer de version d’Xcode oblige souvent à mettre à jour les dépendances, exactement comme côté Android.

La différence avec Google tient au moment où le problème apparaît. Apple ne masque pas l’application existante : il refuse simplement la prochaine version. Le jour où vous devez corriger un bug urgent ou répondre à une exigence de confidentialité, vous découvrez qu’il faut d’abord rattraper un an d’outils. Sur Melimelo, une review Apple prend en général 1 à 2 jours : le délai qui compte, c’est celui du rattrapage technique avant l’envoi, pas celui de la review.

Comment savoir si votre application est concernée ?

Une première vérification ne demande pas de développeur, à condition d’avoir les bons accès. La méthode, dans l’ordre :

1. Ouvrez la Play Console de votre application. La Play Console est l’espace de gestion de Google où l’on publie et suit une application Android. Elle affiche le niveau d’API cible de la dernière version et un avertissement si celui-ci est trop ancien.
2. Vérifiez à qui appartiennent les comptes. Le compte Google Play et le compte Apple Developer doivent être au nom de votre société. S’ils sont au nom d’un ancien prestataire, la mise à jour bloquera avant même le code. Nous détaillons ce point dans notre article sur la propriété du code de votre logiciel.
3. Récupérez le code source à jour, dans un dépôt dont vous avez les droits. Sans lui, personne ne peut recompiler l’application, quelle que soit sa bonne volonté.
4. Notez la date de la dernière publication sur chaque store. Plus de douze mois sans version signifie presque toujours un retard côté Android et côté iPhone à la fois.
5. Demandez le délai Google si vous êtes pris de court. La demande se fait dans la Play Console et repousse l’échéance au 1er novembre 2026. Utilisez ce temps pour planifier, pas pour attendre.

Les pièges que nous voyons le plus souvent sur des applications reprises :

• le compte développeur au nom du freelance qui a créé l’application ;
• un code source introuvable, ou plus ancien que la version publiée ;
• un SDK de paiement ou de notifications abandonné par son éditeur ;
• un niveau d’API modifié sans tests, qui casse l’affichage sur les téléphones récents ;
• le délai Google demandé, puis oublié jusqu’au 31 octobre.

Si l’un de ces points vous parle, le cas de figure est celui d’une application sans maître : nous l’avons décrit dans que faire quand votre logiciel n’a plus de développeur.

Combien coûte une mise en conformité, et quand ne pas la faire ?

Le coût dépend de l’écart de versions et de l’état du code. Une application maintenue se met à jour au temps passé. Une application abandonnée commence par un audit qui chiffre les corrections avant toute intervention. Une application trop ancienne se reconstruit parfois pour moins cher qu’elle ne se répare.

Les ordres de grandeur, avec la grille publique de Krafter :

Prenons un scénario type. Une application de réservation a été développée en 2023 par un freelance, qui n’est plus joignable. Elle cible Android 13, n’a pas été publiée depuis dix-huit mois, et le compte Google Play est au nom de l’entreprise. L’audit, mené en deux jours, montre un code récupérable mais un SDK de paiement abandonné. Le plan chiffré prévoit le remplacement de ce SDK, l’adaptation de l’affichage bord à bord et du retour arrière, puis une publication sur les deux stores. L’application repart, avec un contrat de maintien pour que la prochaine échéance de Google ne la reprenne pas au dépourvu.

Il y a aussi un cas où la bonne décision est de ne rien faire. Si l’application n’a presque plus d’utilisateurs actifs et ne porte pas votre activité, la laisser gelée coûte moins cher que de la remettre à niveau. Si son usage est interne, une application web installable sur le téléphone, sans passer par les stores, peut la remplacer pour un budget plus faible. Payer une migration pour une application que personne n’ouvre est le pire des trois choix.

Pour situer votre projet avant d’en parler, le simulateur de budget donne une fourchette en 8 questions. Et si l’application vaut d’être sauvée, le maintien en conditions évite de revivre la même course chaque été, comme nous l’expliquons dans la maintenance d’un logiciel après la livraison.

Que faire avant le 1er novembre 2026 ?

Commencez par vérifier les comptes et le code source cette semaine : ce sont eux qui bloquent le plus souvent, bien avant la technique. Demandez ensuite le délai Google si vous en avez besoin, puis faites chiffrer la migration par une équipe qui publie elle-même des applications. Chez Krafter, ce sont les deux associés qui auditent le code et qui le reprennent, pour des applications mobiles en Flutter comme pour des applications natives.

Si votre application est en Flutter, notre pratique de Flutter détaille comment nous la faisons suivre chaque année. Dans tous les cas, parlez-nous de votre application : un associé vous répond sous 24 à 48 heures, avec un avis honnête sur ce qui vaut la peine d’être fait.