Depuis le 1ᵉʳ mars 2026, Google a durci les règles imposées aux développeurs sur le Play Store. Les applications qui empêchent le smartphone de se mettre totalement en veille, via un mécanisme appelé « Wake Lock », ne doivent plus bloquer la mise en veille pendant plus de deux heures sur une journée entière écran éteint. Au-delà, le développeur s’expose à une double sanction : son application disparaît des recommandations, et un avertissement s’affiche directement sur sa fiche de téléchargement pour prévenir les utilisateurs.
Cette mesure cible un problème précis : des applications mal optimisées qui maintiennent le processeur actif sans raison alors que l’écran est éteint. Mais elle a aussi remis sur le devant de la scène un débat plus ancien, qui touche cette fois directement les utilisateurs : faut-il fermer ses applications soi-même pour économiser la batterie ?
Ce que répondent Apple et Google depuis des années
Sur ce point, la position est claire des deux côtés de l’écosystème mobile. La page d’assistance officielle d’Apple consacrée à la fermeture des applications est sans ambiguïté : une application ne doit être fermée que si elle ne répond plus. Aucune mention d’un quelconque bénéfice pour la batterie.
Du côté d’Android, la documentation pour les développeurs précise qu’un processus mis en cache, c’est-à-dire une application en arrière-plan, n’est plus considéré comme nécessaire par le système et doit cesser toute activité. La documentation du projet open source Android va plus loin et détaille la mécanique exacte de ce qui se passe concrètement une fois l’application en arrière-plan.
Pourquoi le geste aggrave ce qu’il est censé corriger
Cette documentation explique ce mécanisme avec précision. Lorsqu’une application passe en arrière-plan, elle devient un processus mis en cache : le système la considère comme non indispensable et peut la fermer si la mémoire vient à manquer, mais il n’y est pas obligé. Dans les faits, un processus en cache est gelé environ dix secondes après être passé dans cet état. Ses threads, autrement dit son activité interne, sont alors suspendus et ne peuvent plus consommer la moindre ressource processeur tant qu’un événement du système, comme une notification ou la réouverture par l’utilisateur, ne vient pas les réveiller.
Autrement dit, une application gelée ne coûte quasiment rien en énergie. Elle reste prête à reprendre instantanément là où l’utilisateur l’avait laissée.
Le problème survient quand l’utilisateur force la fermeture de cette application via le gestionnaire multitâche. Le processus gelé est alors entièrement détruit. À la prochaine ouverture, le système doit tout recharger depuis le stockage, réinitialiser les données en mémoire et rouvrir les connexions réseau nécessaires. Ce démarrage à froid sollicite bien davantage le processeur qu’une simple reprise depuis l’état suspendu, ce qui consomme mécaniquement plus de batterie que si l’application n’avait jamais été fermée.
À lire aussi : Les smartphones avec la meilleure autonomie en juin 2026
Une exception, et une bonne pratique à retenir
Ce principe ne s’applique qu’aux applications qui se comportent normalement. Une application figée, qui ne répond plus ou qui consomme manifestement trop de ressources en arrière-plan, peut justifier une fermeture forcée. C’est d’ailleurs précisément ce que la nouvelle politique de Google vise à corriger à la source, en sanctionnant les développeurs plutôt qu’en laissant les utilisateurs compenser le problème à coups de fermetures manuelles.
Pour les autres cas, la recommandation reste inchangée depuis des années des deux côtés de l’écosystème mobile : laisser iOS et Android gérer la mémoire et les processus en arrière-plan, sans intervenir.
👉🏻 Suivez l’actualité tech en temps réel : ajoutez 01net à vos sources sur Google, et abonnez-vous à notre canal WhatsApp.
