API 36 : mettre à jour une application Android sans casser la production

À compter du 31 août 2026, une nouvelle application ou une mise à jour envoyée sur Google Play devra cibler Android 16, soit le niveau d’API 36. Pour une application existante, la règle d’accessibilité est différente : elle doit au moins cibler l’API 35 pour rester proposée aux nouveaux utilisateurs équipés d’une version Android plus récente que sa cible. Google indique aussi qu’une extension pourra être demandée jusqu’au 1er novembre 2026.

La bonne réponse n’est donc ni de paniquer, ni de modifier seulement une valeur de configuration. Cibler l’API 36 active des comportements qui peuvent toucher la navigation, les zones système, les grands écrans, certaines tâches et des bibliothèques natives. Une mise à niveau fiable suit une chaîne simple : identifier l’exigence, localiser son impact, tester le parcours concerné, conserver une preuve et déployer progressivement.

Ce que Google Play exige réellement au 31 août 2026

La documentation officielle sur le niveau d’API cible distingue trois situations qu’il ne faut pas confondre.

Situation	Exigence générale au 31 août 2026	Conséquence opérationnelle
Nouvelle application Android	API 36 ou plus	l’envoi sur Google Play doit respecter la nouvelle cible
Mise à jour d’une application Android	API 36 ou plus	la prochaine version soumise doit avoir été migrée et recettée
Application existante sans nouvelle version	API 35 ou plus pour rester accessible à tous les nouveaux utilisateurs concernés	une cible API 34 ou antérieure limite la disponibilité sur les appareils plus récents

Wear OS, Android Automotive OS, Android TV et Android XR suivent des seuils spécifiques. Une application privée de manière permanente et limitée aux utilisateurs d’une organisation fait aussi partie des exceptions annoncées. Le premier travail consiste donc à qualifier le produit et son canal de distribution avant d’appliquer une règle générale.

Une application trop ancienne n’est pas nécessairement supprimée du téléphone de ses utilisateurs actuels. Le risque documenté porte notamment sur la soumission des nouvelles versions et sur la disponibilité auprès de nouveaux utilisateurs équipés d’un système plus récent. Cette nuance change le plan : il faut protéger la continuité de service, pas seulement obtenir un voyant vert dans la console.

Pourquoi changer targetSdk ne suffit pas

Le niveau cible n’indique pas seulement avec quelle version du kit l’application est compilée. Il déclare aussi que l’application est prête pour certains comportements plus récents du système. La page officielle des changements qui concernent les applications ciblant Android 16 doit donc devenir un inventaire de risques, pas une lecture réservée au développeur qui modifie le fichier de configuration.

Les zones système deviennent un sujet de recette visuelle

Sur Android 16, une application ciblant l’API 36 ne peut plus désactiver l’affichage bord à bord avec l’ancien mécanisme de retrait. Un écran peut techniquement s’ouvrir tout en plaçant une action sous la barre système, en masquant un champ derrière le clavier ou en rendant un message difficile à lire.

Le test utile ne consiste pas à vérifier une capture d’accueil. Il couvre les écrans avec en-tête, listes longues, feuilles modales, formulaires et clavier ouvert. La preuve attendue est une série courte de captures sur les parcours qui vendent, valident ou enregistrent une action importante.

Le retour prédictif peut révéler une navigation fragile

Pour les applications ciblant l’API 36 sur Android 16, le retour prédictif est activé par défaut. Les anciens mécanismes d’interception ne reçoivent plus toujours les événements attendus. Le problème visible peut être une sortie prématurée, un écran précédent incohérent ou la perte d’une saisie.

Il faut tester le retour depuis chaque étape critique : authentification, panier, paiement, brouillon, capture de média et confirmation. Un retrait temporaire existe dans certains cas, mais il doit rester une mesure de transition documentée, avec une date de suppression. Reporter silencieusement le comportement ne constitue pas une migration.

Les grands écrans ne respectent plus les mêmes verrous

Sur les affichages d’au moins 600 dp de largeur, Android 16 peut ignorer les restrictions d’orientation, de redimensionnement et de ratio d’une application ciblant l’API 36. Une interface conçue uniquement en portrait sur téléphone peut alors s’étirer, perdre son état pendant une rotation ou placer une animation hors écran.

La recette doit inclure au minimum une tablette ou un émulateur redimensionnable, le mode paysage et le multi-fenêtrage lorsque l’usage le permet. L’objectif n’est pas de reconstruire toute l’interface en urgence. Il est d’identifier les écrans qui deviennent inutilisables et de distinguer une correction nécessaire d’une amélioration différable.

Les dépendances natives et les changements transverses comptent aussi

Android 16 introduit également des changements qui peuvent affecter toutes les applications, indépendamment de leur niveau cible. La documentation sur les changements pour toutes les applications cite notamment l’environnement d’exécution, certaines annonces d’accessibilité et le mode de compatibilité avec les pages mémoire de 16 Ko.

La compatibilité 16 Ko est déjà une exigence Google Play pour les nouvelles applications et mises à jour concernées ciblant Android 15 ou plus. Elle mérite une vérification particulière lorsque l’application embarque des bibliothèques natives, des moteurs, des SDK vidéo, de paiement, de cartographie ou d’analyse. Une dépendance qui compile n’est pas nécessairement une dépendance prête pour tous les appareils visés.

La matrice Zence pour cadrer une mise à niveau API 36

Une liste de tâches techniques devient pilotable lorsqu’elle relie chaque changement à une situation utilisateur, un test et un responsable. Cette matrice permet de préparer la version sans transformer toute la documentation Android en backlog.

Exigence ou changement	Surface à inspecter	Test décisif	Preuve à conserver	Responsable
Cible API 36	configuration, build et artefact soumis	contrôler la cible effective du bundle final	rapport de build et bundle identifié	développement
Affichage bord à bord	barres système, clavier, modales, actions fixes	terminer les parcours avec différentes tailles et le clavier ouvert	captures annotées par parcours	design et QA
Retour prédictif	navigation, brouillons, confirmations	revenir depuis chaque étape sans perte ni sortie inattendue	scénarios de recette signés	produit et QA
Grands écrans	tablette, paysage, multi-fenêtrage	redimensionner et faire pivoter sans contenu inaccessible	grille appareils-écrans-résultats	design et développement
Dépendances	SDK natifs et bibliothèques sensibles	construire, installer et exécuter les fonctions qui les utilisent	versions, licences et résultats	développement
Pages mémoire 16 Ko	bibliothèques et code natifs	analyser puis lancer sur un environnement compatible	rapport de compatibilité	développement
Publication	pistes de test et production	installer une mise à jour depuis la version réellement publiée	journal de version et critères de passage	exploitation
Surveillance	stabilité et parcours prioritaires	observer la version par étape de diffusion	tableau de bord et règle d’arrêt	produit et exploitation

Chaque ligne doit produire une décision. Si aucun parcours n’utilise une caméra, un SDK de capture n’a pas la même priorité qu’une navigation arrière défaillante au moment du paiement. La migration devient alors proportionnée au risque réel de l’application.

Définir le périmètre de la version avant de commencer

Une échéance de store invite facilement à regrouper les travaux en attente : nouvelle identité visuelle, remplacement de l’analytics, montée de version du framework, évolution du paiement et correction d’anciens défauts. Cette accumulation donne l’impression d’économiser une publication. Elle augmente surtout le nombre de causes possibles si la version devient instable.

Commencez par figer une référence reproductible : commit ou archive de la version en production, artefact distribué, configuration des environnements, dépendances résolues et procédure de signature. Notez ensuite ce que la mise à niveau exige réellement. Une bibliothèque doit-elle changer parce qu’elle bloque la compilation ou la compatibilité ? Un parcours doit-il évoluer parce qu’un comportement Android 16 le casse ? Tout le reste devient un candidat au report, pas une dette automatiquement incluse.

Cette retenue ne signifie pas ignorer un défaut déjà connu. Elle oblige à nommer sa relation avec la version. Trois décisions suffisent :

• inclure, si le défaut empêche la conformité, la recette ou la continuité d’un parcours critique ;
• isoler, si une mise à jour de dépendance est nécessaire mais peut être validée dans un changement séparé ;
• reporter, si l’amélioration n’aide ni la compatibilité, ni le diagnostic, ni la capacité de diffusion.

Le périmètre final doit tenir en une phrase compréhensible par le produit, la technique et l’exploitation : « rendre la version actuellement publiée compatible avec la cible API 36, sans modifier le service rendu, puis la diffuser par paliers ». Si cette phrase contient plusieurs nouvelles promesses produit, la migration n’est plus isolée. Il faut alors accepter un calendrier de recette plus large ou séparer les versions.

Tester les changements avant d’activer la nouvelle cible

Android fournit un framework de compatibilité capable d’activer certains changements séparément. Il permet d’observer un comportement ciblé avant de modifier définitivement le niveau d’API, puis d’isoler plus vite la cause d’une régression.

Une séquence de travail prudente suit quatre étapes.

1. Établir la référence. Installer la version de production, noter la cible actuelle, les versions des dépendances et les parcours qui doivent rester complets.
2. Préparer l’environnement. Mettre à niveau le socle de compilation nécessaire, sans modifier en même temps toutes les bibliothèques par réflexe.
3. Activer les changements par familles. Tester séparément l’interface, la navigation, les grands écrans, les tâches et les composants natifs lorsque les outils de compatibilité le permettent.
4. Cibler l’API 36 et rejouer la recette. Le bundle final doit être testé comme une mise à jour de la version réellement distribuée, pas seulement comme une installation neuve.

Cette séparation raccourcit le diagnostic. Si la cible, le framework mobile, les SDK de paiement et le système d’analytics changent dans le même build, un défaut simple peut devenir une enquête coûteuse. Aller vite consiste ici à réduire le nombre de causes simultanées.

Huit scénarios de recette avant l’envoi sur Google Play

La recette doit partir des actions importantes plutôt que d’une liste de composants. Adaptez ces scénarios à l’application ; ne conservez pas ceux qui n’ont aucun rapport avec son usage.

1. Mettre à jour sans perdre la session ni les données locales. Installer la version cible au-dessus de la version de production et reprendre une tâche en cours.
2. Ouvrir, naviguer et revenir. Tester les retours dans les parcours contenant un brouillon, une confirmation ou une transaction.
3. Afficher et valider un formulaire avec le clavier ouvert. Contrôler les zones système, les messages d’erreur et l’action principale.
4. Passer du téléphone à un grand écran. Vérifier portrait, paysage, rotation et redimensionnement sans élément inaccessible ni état perdu.
5. Refuser puis accorder une permission. Confirmer que la fonction explique la conséquence et reste récupérable.
6. Interrompre une action réseau. Couper la connexion pendant un envoi, relancer l’application et vérifier qu’aucun doublon ni faux succès n’apparaît.
7. Exécuter une fonction fournie par un SDK sensible. Paiement, caméra, vidéo, cartographie, authentification ou autre dépendance native doivent être testés sur l’artefact final.
8. Installer depuis une piste Google Play. Vérifier signature, configuration d’environnement, liens profonds, notifications et achat intégré lorsque ces fonctions existent.

Un scénario est terminé lorsque son résultat est explicite : passé, bloqué avec responsable, ou non applicable avec justification. « Testé rapidement » ne permet ni de décider, ni de reprendre le travail après un incident.

Déployer progressivement et savoir s’arrêter

Une validation en interne ne reproduit pas tout le parc réel. La mise à niveau doit passer par les pistes de test pertinentes, puis par une diffusion progressive en production. Google Play permet d’envoyer une mise à jour à un pourcentage limité d’utilisateurs et d’augmenter ce pourcentage manuellement.

Avant le premier palier, choisissez peu de signaux : taux de plantage, applications sans réponse, réussite des deux ou trois parcours principaux, erreurs serveur et volume de demandes d’assistance. Pour chacun, définissez qui regarde, à quel moment et quel seuil provoque un arrêt.

La documentation Google sur les déploiements progressifs précise qu’un arrêt empêche de nouveaux utilisateurs de recevoir la version, mais ne ramène pas automatiquement les personnes déjà mises à jour à l’ancienne. En cas de défaut confirmé, il faut préparer et diffuser une nouvelle version corrigée. Le plan de repli est donc une capacité à corriger vite, pas la promesse d’un bouton de retour universel.

Faut-il demander l’extension jusqu’au 1er novembre ?

L’extension annoncée par Google donne du temps ; elle ne remplace pas une décision. Elle peut être raisonnable si un comportement critique reste non recetté, si une dépendance essentielle n’est pas compatible ou si l’application n’a plus de chaîne de publication reproductible.

Avant de la demander, formalisez quatre éléments : la cause du retard, le propriétaire de la correction, la date de la prochaine version testable et la condition de sortie de l’extension. Sans cela, deux mois supplémentaires déplacent seulement le risque.

À l’inverse, une petite application dont les dépendances sont maintenues et les parcours couverts ne gagne rien à retarder mécaniquement la mise à niveau. La décision dépend de la qualité de la preuve, pas de la proximité de l’échéance.

Transformer l’échéance API 36 en maintenance durable

Une application publiée n’est pas un livrable figé. Elle dépend des systèmes mobiles, des règles des stores, de bibliothèques, de services distants et d’appareils qui évoluent. L’échéance API 36 rend simplement ce coût du changement visible.

Le livrable utile dépasse donc le nouveau bundle. Il comprend l’inventaire des dépendances, la matrice d’impact, les scénarios rejouables, les preuves de compatibilité, la procédure de diffusion et les responsables. Ce dossier réduira le coût de la prochaine version Android, d’un remplacement de SDK ou d’une reprise par une nouvelle équipe.

Zence accompagne la conception et l’exploitation d’applications iOS et Android en reliant expérience, dépendances, qualité et publication. Pour replacer cette mise à niveau dans le cycle de vie complet, consultez le guide d’un projet mobile durable, la méthode pour choisir une équipe capable de maintenir l’application et les critères de dette technique liés au coût du changement.

Sources officielles

• Google Play — exigences de niveau d’API cible, échéances et distinctions par type d’application, consulté le 12 août 2026.
• Android Developers — configurer le SDK Android 16, préparation du projet et activation de la cible API 36.
• Android Developers — changements pour les applications ciblant Android 16, interface, navigation, tâches et grands écrans.
• Android Developers — changements Android 16 pour toutes les applications, environnement d’exécution, accessibilité et compatibilité.
• Android Developers — prise en charge des pages mémoire de 16 Ko, exigence Google Play et méthode de vérification.
• Google Play Console — publier une mise à jour progressivement, paliers, arrêt et reprise d’un déploiement.

La cible API 36 est un seuil de publication. La qualité de la mise à niveau se juge ailleurs : l’utilisateur retrouve son parcours, l’équipe sait détecter une régression et le produit peut recevoir la prochaine évolution sans recommencer l’enquête.