Pourquoi le tunnel tombe en arrière-plan sur Android

C'est l'un des angles morts les plus courants de la protection VPN sur mobile. L'utilisateur vérifie son adresse IP, tout est correct, il verrouille le téléphone — et pendant l'heure qui suit, l'application VPN est mise en veille par le système, le tunnel tombe, et les applications qui se réveillent en arrière-plan communiquent sans protection. Cette page explique les mécanismes d'Android qui produisent ce comportement et donne les correctifs dans l'ordre d'efficacité. Elle complète les critères d'évaluation d'un VPN gratuit pour Android : un service qui ne survit pas en arrière-plan n'offre une protection que pendant qu'on le regarde.

Le coût énergétique réel d'un VPN

Un tunnel VPN consomme de l'énergie pour quatre raisons. Le chiffrement et le déchiffrement continus, d'abord — coût faible quand le processeur dispose d'instructions AES, plus sensible sinon, comme expliqué dans la page sur les protocoles VPN sur Android. Ensuite, l'interface de tunnel empêche certaines optimisations de veille de la radio, qui ne peut plus se rendormir aussi agressivement. Troisièmement, les messages de maintien de session périodiques — de l'ordre d'un toutes les 25 secondes pour WireGuard, davantage pour compenser les délais d'expiration de traduction d'adresses — réveillent la radio à intervalle régulier. Enfin, sur un réseau instable, les reconnexions répétées coûtent cher. L'ordre de grandeur observé est une surconsommation de 5 à 15 % selon le protocole, le réseau et l'appareil.

Ce coût explique pourquoi le système et les constructeurs cherchent à limiter l'activité de fond d'une application VPN — et pourquoi, faute de configuration, ils finissent par la suspendre.

La consommation n'est pas uniforme. Écran allumé, le surcoût du VPN est noyé dans celui de l'affichage et devient négligeable. Écran éteint, en revanche, la moindre activité radio pèse proportionnellement beaucoup plus, car c'est précisément le moment où le téléphone devrait consommer presque rien. Le réseau compte aussi : en Wi-Fi avec bon signal, les messages de maintien de session coûtent peu ; en données mobiles avec un signal faible, chaque réveil de la radio pour émettre un keepalive consomme sensiblement plus, et une couverture instable qui force des reconnexions répétées est le pire cas.

Mesurer la consommation réelle sur son appareil

Les chiffres génériques valent peu : la surconsommation dépend du modèle de téléphone, de la puce, de la qualité du réseau et du protocole. La bonne méthode est empirique. Noter le niveau de batterie, utiliser le téléphone normalement pendant une demi-journée avec le VPN actif, relever la consommation attribuée à l'application VPN dans Paramètres → Batterie → utilisation par application, puis refaire la même demi-journée sans VPN. L'écart est la vraie surconsommation, propre à l'appareil. Faire le test avec WireGuard puis avec un autre protocole permet de choisir en connaissance de cause. Un écart supérieur à 20 % pointe soit un réseau très instable qui multiplie les reconnexions, soit un serveur lointain et saturé — deux problèmes que change le choix d'un serveur proche et dégagé, pas le protocole.

Le mode Doze

Introduit avec Android 6, le mode Doze s'active quand l'écran est éteint, l'appareil immobile et sur batterie. Par paliers successifs, le système suspend l'accès réseau des applications, diffère les tâches planifiées et les alarmes, et regroupe les traitements dans des fenêtres de maintenance de plus en plus espacées. Une application VPN correctement écrite s'exécute comme service de premier plan avec une notification persistante : à ce titre, elle est exemptée de Doze et son tunnel reste actif. Une application qui utilise un simple service d'arrière-plan, sans notification, est suspendue comme les autres — et le tunnel tombe silencieusement.

Les paliers d'App Standby

Depuis Android 9, chaque application est classée dans un palier selon sa fréquence d'utilisation : active, ensemble de travail, fréquent, rare, restreint. Plus une application est utilisée rarement, plus ses quotas d'accès réseau en arrière-plan et de tâches planifiées sont réduits ; le palier « restreint » est très contraignant. Un client VPN qu'on ouvre une fois par semaine peut se retrouver classé « rare », ce qui limite sa capacité à se reconnecter et à se maintenir quand l'écran est éteint. Le simple fait d'ouvrir l'application régulièrement la maintient dans un palier favorable, mais ce n'est pas une solution fiable.

La gestion agressive des constructeurs

Au-delà d'Android « pur », les surcouches des fabricants ajoutent leurs propres gestionnaires de mémoire et d'énergie, avec des listes blanches d'applications « protégées » et des « nettoyeurs » qui ferment les applications de fond. Le projet communautaire Don't Kill My App documente depuis des années le fait que ces mécanismes ferment aussi des applications pourtant déclarées en premier plan, en violation du comportement attendu d'Android. Concrètement, sur beaucoup de téléphones, une application VPN n'est maintenue en vie que si elle a été explicitement ajoutée à la liste des applications protégées de la surcouche, autorisée au démarrage automatique, et verrouillée dans l'écran des applications récentes.

Les correctifs, dans l'ordre

1. Activer le kill switch système. Paramètres → Réseau et Internet → VPN → (roue crantée) → « VPN permanent » et « Bloquer les connexions sans VPN ». Ce blocage est appris par le noyau : il tient même si l'application VPN est suspendue. C'est le correctif le plus important, car il rend l'étanchéité indépendante de la survie de l'application. Détail dans la page sur le kill switch et les fuites.
2. Exclure l'application de l'optimisation de batterie. Paramètres → Applications → [application VPN] → Batterie → « Sans restriction » (ou « Autoriser l'activité en arrière-plan »). Cela empêche le système de la mettre en veille prolongée.
3. Sur surcouche constructeur : la déclarer protégée. Ajouter l'application à la liste des applications « protégées » ou « à démarrage automatique » de la surcouche, et la verrouiller dans le multitâche. L'emplacement de ce réglage varie d'un fabricant à l'autre ; Don't Kill My App recense les procédures par marque.
4. Garder la notification persistante visible. Ne pas la masquer ni la ranger dans une catégorie silencieuse : elle est ce qui signale au système que l'application est un service de premier plan légitime.
5. Choisir WireGuard. Moins de réveils radio, reprise instantanée après une mise en veille, donc moins de raisons pour le système de considérer l'application comme gourmande.

Le compromis étanchéité / autonomie

« Bloquer les connexions sans VPN » signifie qu'aucun trafic ne passe tant que le tunnel n'est pas rétabli. En contrepartie de l'étanchéité, certains services peuvent échouer temporairement pendant une reconnexion — synchronisation, notifications, mise à l'heure. Pour un usage d'appoint sur un palier gratuit, ce compromis est acceptable. Pour une protection permanente sur tous les usages, un client conçu pour survivre proprement en arrière-plan — ce qui suppose un travail d'ingénierie que les paliers gratuits financent rarement — a un intérêt concret.

Il existe aussi un réglage intermédiaire : autoriser le VPN permanent sans cocher le blocage strict. Le tunnel se relance automatiquement, mais le trafic n'est pas bloqué pendant la reconnexion. C'est un compromis en faveur de la disponibilité, au prix d'une petite fenêtre de fuite à chaque reprise. Le bon choix dépend de la sensibilité de l'usage.

Vérifier que le tunnel tient

Après avoir appliqué les correctifs, laisser le téléphone verrouillé et immobile pendant une à deux heures, puis rouvrir le client VPN et consulter son journal ou son indicateur de durée de connexion. Si la session est ininterrompue, la configuration est bonne. Si le client indique une ou plusieurs déconnexions, il reste un mécanisme d'économie d'énergie à neutraliser — le plus souvent côté surcouche constructeur. Ce test rejoint le test d'arrière-plan de la grille d'évaluation.