Quand on pense à l'empreinte environnementale d'un service numérique, on imagine souvent les centres de données ou la fabrication des appareils. Pourtant, une part significative de cette empreinte vient aussi des applications mobiles en production : consommation CPU, réseau, utilisation d'APIs, stockage et comportements de fond peuvent accélérer la décharge de la batterie, augmenter le trafic réseau et solliciter davantage l'infrastructure serveur. J'ai travaillé sur plusieurs apps et expérimenté des optimisations mesurables — voici un guide pratique, centré sur les mesures et les optimisations concrètes que j'applique systématiquement.
Mesurer avant d'optimiser : les indicateurs à suivre
On commence toujours par des métriques. Sans mesure, on devine. Voici ce que je surveille régulièrement :
Consommation CPU et GPU : impact direct sur la batterie et la génération de chaleur.Utilisation réseau (up/down) : volume de données et nombre de requêtes, qui influent sur le coût serveur et la latence.Durée d'exécution en tâche de fond : wakeups, alarmes et jobs périodiques.Wake locks / état du téléphone (idle vs active) : réveils inutiles tuent la batterie.Taux de crashs liés à la mémoire : fuites ou allocations excessives augmentent la consommation.Taille binaire et ressources : APK/IPA plus lourds augmentent l'empreinte lors des téléchargements.Outils que j'utilise pour collecter ces métriques :
Android : Android Profiler, Battery Historian, adb shell dumpsys battery, Network Profiler.iOS : Instruments (Energy, Time Profiler), Xcode Energy Gauge, os_signpost.Cross-platform : Firebase Performance Monitoring, Sentry (pour la télémétrie d'erreurs), des scripts de CI pour mesurer la taille des builds.Optimisations côté client (app)
Voici des actions concrètes et vérifiables que j'applique dans l'ordre : mesurer, modifier, mesurer à nouveau.
Réduire les wakeups et work en background : remplacez les timers fréquents par des triggers basés sur événements (push, géofencing, changements réseau). Sur Android, préférez WorkManager avec des contraintes raisonnables ; sur iOS, utilisez BackgroundTasks et privilégiez les refresh minimal. Chaque minute de moins d'activité background peut réduire la consommation notablement.Batcher les requêtes network : regrouper des appels HTTP, utiliser HTTP/2 multiplexing et gRPC si pertinent. Moins de connexions TCP/TLS = moins d'empreinte côté réseau et CPU.Mettre en cache intelligemment : cache en mémoire pour éviter des rechargements répétés, mais contrôlez la taille pour éviter les OOM. Sur mobile, un cache disque bien géré (ex : OkHttp cache, URLCache) réduit les transferts réseau et l'utilisation CPU.Adapter la qualité des payloads : livrer des images et vidéos adaptatives (WebP/AVIF, plusieurs résolutions). J'utilise souvent Cloudflare Images ou imgix pour servir les formats optimisés selon l'User-Agent.Minimiser l'usage du GPS : demander la localisation approximative quand elle suffit, utiliser des stratégies à événement (géofence) plutôt que des sondages continus.Optimiser le rendu : éviter les overdraws, limiter les animations coûteuses, utiliser des couches matérielles quand c'est pertinent. Sur Android, Profile GPU Rendering ; sur iOS, Core Animation Instruments.Diminuer la fréquence de polling : préférez push notifications ou server-sent events. Un poll toutes les 30s vs 5min : la différence est immédiate sur les statistiques énergie et réseau.Optimisations côté serveur et réseau
Le backend influence directement l'empreinte côté client. Voici ce que j'optimise côté infra :
Réduire la latence : plus la réponse est rapide, plus l'app finit vite ses traitements (CPU et réseau). Utilisez CDN, edge functions, et mettez en cache les réponses immuables.Compresser et sérialiser efficacement : JSON minifié, ou formats binaires comme Protobuf/gRPC pour les échanges fréquents ou volumineux.Mise en cache côté edge : réduire les hits sur les serveurs principaux et le besoin de calculs répétés.Adapter les API aux besoins : endpoints spécifiques fournissant uniquement les champs nécessaires réduisent la taille des payloads (graphQL avec care pour éviter les overfetching ou REST bien découpé).Contrôler le fallback offline : proposer une UX offline évite des tentatives répétées de réseau quand la connexion est mauvaise.Pratiques de build et packaging
La façon dont vous construisez et empaquetez votre app a un impact — pas seulement sur le téléchargement, mais sur l'utilisation en production :
Code splitting et feature flags : charger les modules à la demande plutôt que tout embarquer, réduirez la mémoire et les initialisations inutiles.Enlever les dépendances inutiles : certaines bibliothèques ajoutent du code lourd ou des services en background. Analysez l'APK/IPA avec des outils comme apktool ou app size report et supprimez le superflu.Activer la compression des assets : images WebP/AVIF, SVG quand possible, et minification JS/TS/Swift/Java/Kotlin.Mesurer l'impact : protocole que j'applique
Chaque optimisation doit être mesurée. Mon protocole simple :
Choisir un ensemble d'appareils représentatifs (bas, moyen, haut de gamme).Exécuter un scénario utilisateur standardisé (ouverture, navigation, action clé) avec et sans optimisation.Mesurer : consommation batterie (Battery Historian / Instruments), trafic réseau total, CPU time, et latence des appels.Répéter plusieurs fois et faire une moyenne. | Indicateur | Avant | Après | Objectif |
| Consommation CPU (joules/min) | 100 | 75 | -20 à -30% |
| Volume réseau (Mo) | 5.2 | 2.1 | -50% |
| Wakeups / heure | 120 | 20 | <30 |
Ces valeurs sont indicatives — mais dans mes projets, le batching + cache + réduction des wakeups a souvent donné des réductions de 30 à 60% sur le trafic et la consommation énergie pour certains scénarios.
Bonnes pratiques organisationnelles
Enfin, pour que ces optimisations persistent :
Intégrez des checks de performance dans la CI (taille d'APK/IPA, tests d'API, temps de cold start).Documentez les patterns à éviter (polling excessif, wake locks non gérés) et créez une checklist d'audit avant release.Éduquez les équipes produit : prioriser une feature "always-on" coûte en énergie et infrastructure ; parfois la meilleure expérience est celle qui épargne l'utilisateur.Réduire l'empreinte énergétique d'une app en production, c'est un mélange de discipline de mesure, d'optimisations techniques et de choix produit éclairés. En appliquant des méthodes rigoureuses — mesurer, itérer, monitorer en production — on obtient des gains concrets qui bénéficient aux utilisateurs (autonomie), à la planète (moins d'énergie consommée) et à votre économiseur de coûts d'infrastructure.
