Surveillance des performances — définition, métriques et collecte de données

Qu'est-ce que la surveillance des performances

La surveillance des performances est la pratique consistant à quantifier le comportement de l'application en collectant des métriques d'exécution, d'utilisation de la mémoire, de fréquence d'images et de consommation d'énergie. Contrairement au crash reporting qui ne capture que les défaillances fatales, la surveillance des performances suit la dégradation progressive : l'application fonctionne mais est plus lente qu'elle ne devrait l'être.

Selon Google (2024), 53 % des utilisateurs ferment une application si elle met plus de 3 secondes à charger. Chaque seconde supplémentaire de retard réduit la conversion de 20 % en moyenne toutes catégories confondues. Cela fait de la surveillance des performances non seulement une pratique technique, mais une nécessité commerciale pour les produits mobiles.

La surveillance moderne des performances couvre quatre niveaux : client (iOS, Android), réseau (requêtes API, WebSocket), services backend et infrastructure. Dans le développement mobile, l'accent est mis sur les métriques côté client, car la plupart des problèmes de performance surviennent sur l'appareil de l'utilisateur.

Métriques clés d'une application mobile

Pour une surveillance complète, cinq groupes de métriques doivent être suivis, chacun responsable d'un aspect différent de l'expérience utilisateur. FPS (images par seconde) montre la fluidité des animations et du défilement — les valeurs inférieures à 30 images par seconde sont perçues comme un ralentissement par l'œil.

Métriques temporelles

Temps de démarrage à froid — du moment où l'on tape sur l'icône jusqu'à la préparation complète de l'interface. Temps de démarrage à chaud — retour depuis l'arrière-plan. Temps de réponse à une action utilisateur (tap-to-response). Le temps de démarrage pour Android est mesuré via ActivityManager, pour iOS — via dyld et le temps premain. Selon Firebase Performance, le temps médian de démarrage à froid pour les 100 meilleures applications est de 1,8 seconde.

Métriques mémoire et CPU

La consommation de RAM ne doit pas dépasser 80 % de la capacité disponible sur l'appareil, sinon le système commence à décharger l'application de l'arrière-plan. L'empreinte mémoire est suivie via Xcode Instruments (iOS) et Android Profiler. Les fuites de mémoire sont détectées par l'augmentation de la consommation lors d'opérations répétées — par exemple, lors du changement d'écrans.

Métriques réseau

Temps d'exécution de la requête HTTP, taille de la réponse, fréquence des timeouts et des erreurs. La latence réseau est particulièrement critique pour les applications mobiles fonctionnant dans des conditions de connexion instables (3G, métro, ascenseur, itinérance). Il est recommandé de suivre le temps de réponse p95 — il montre l'expérience des utilisateurs les plus « lourds » dans les pires conditions réseau.

Real User Monitoring et Synthetic Monitoring

Real User Monitoring (RUM) collecte les données des appareils réels des utilisateurs dans l'environnement de production. Cette méthode montre les latences réelles que les utilisateurs subissent en tenant compte de leurs appareils, versions de l'OS, réseau et géolocalisation. Le RUM fournit l'image de performance la plus précise mais dépend des utilisateurs inclus dans l'échantillon.

Synthetic Monitoring, quant à lui, exécute des scénarios prédéfinis sur des appareils de test dans des conditions contrôlées. Il permet de détecter les régressions avant qu'elles n'atteignent les utilisateurs et de reproduire les problèmes dans un environnement cohérent. Firebase Test Lab et BrowserStack fournissent des tests synthétiques sur des appareils réels sans exécution manuelle.

La stratégie optimale est une combinaison des deux approches : les tests synthétiques détectent les régressions à l'étape CI, tandis que le RUM fournit l'image réelle en production. Selon Datadog (2024), les équipes utilisant les deux méthodes découvrent 35 % de problèmes de performance supplémentaires avant qu'ils ne deviennent des incidents.

Configuration de Firebase Performance Monitoring

Firebase Performance Monitoring est un outil gratuit de Google pour collecter des métriques de performance sur iOS et Android. Il mesure automatiquement le temps de démarrage de l'application, les requêtes HTTP et le rendu des écrans sans écrire de code. Pour le configurer, ajoutez simplement le SDK à votre projet et activez le module Performance dans la console Firebase.

Collecte automatique des métriques

Après l'intégration du SDK, Firebase Performance crée automatiquement une trace pour chaque requête HTTP via URLSession (iOS) ou OkHttp (Android). Le rendu d'écran est mesuré pour UIViewController et Activity, capturant le temps entre onCreate/viewDidLoad et la fin du premier rendu. Toutes les métriques sont agrégées dans la console Firebase, ventilées par version d'application, appareil et pays.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // exécution du paiement
        trace.stop()
    }
}

Le code crée une trace personnalisée pour le scénario de paiement avec un attribut de montant. Grâce à cette trace dans la console Firebase, vous pouvez voir le temps d'exécution médian et p95 du paiement, groupé par version d'application et appareil.

Surveillance HTTP

Firebase intercepte automatiquement les requêtes réseau et enregistre l'URL, le code de réponse, la taille du payload et le temps d'exécution. Pour OkHttp sur Android, l'instrumentation automatique fonctionne sans configuration supplémentaire. Les requêtes réseau sont affichées dans la console groupées par endpoint, ce qui permet d'identifier rapidement le ralentissement d'une API spécifique.

Traces personnalisées pour la logique métier

Les métriques standard couvrent les performances générales, mais pour diagnostiquer les processus métier, il est nécessaire d'instrumenter des scénarios spécifiques. Les traces personnalisées permettent de mesurer le temps d'exécution de l'authentification, du chargement du fil d'actualités, du traitement d'image ou de la synchronisation de données.

Chaque trace personnalisée doit avoir un nom significatif au format « scénario-action » et contenir des attributs pour le filtrage. Par exemple, une trace « image-upload » avec les attributs « file_size » et « compression_quality » aidera à identifier la dépendance du temps d'upload par rapport à la taille de l'image. Il est recommandé de ne pas créer plus de 20 traces personnalisées par écran — une instrumentation excessive crée du bruit et complique l'analyse.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // chargement de l'image
    trace?.stop()
}

L'exemple en Swift crée une trace pour le chargement d'image avec des attributs de taille de fichier et de niveau de compression. Dans la console Firebase, ces attributs deviennent des champs pour regrouper et filtrer les métriques.

Seuils et alertes

Collecter des métriques sans système d'alerte est inutile. Les alertes doivent notifier l'équipe lorsque les métriques dépassent les limites acceptables, avec des seuils divisés en trois niveaux : avertissement, critique et indisponibilité. Chaque niveau détermine le canal de notification : avertissement — sur le canal Slack de l'équipe, critique — sur PagerDuty pour l'ingénieur de garde, indisponibilité — notification de masse à toutes les parties prenantes.

Pour les métriques mobiles, il est recommandé d'utiliser des seuils dynamiques basés sur les percentiles : le temps de démarrage à froid p95 dépasse 4 secondes — alerte critique. Les seuils statiques (par exemple, CPU > 90 %) fonctionnent moins bien car ils ne tiennent pas compte des fluctuations normales de charge selon l'heure de la journée et le jour de la semaine. Firebase Performance prend en charge la configuration d'alertes via la console Firebase avec des notifications vers Slack, PagerDuty et par e-mail, avec des options d'escalade en cas d'absence de confirmation.

Selon l'enquête sur la gestion des incidents (2024), les équipes qui configurent des alertes basées sur les percentiles plutôt que sur les moyennes manquent 45 % moins d'incidents. La valeur moyenne lisse les valeurs aberrantes — le p95 garantit d'afficher le pire scénario pour les utilisateurs, indépendamment de l'heure de la journée et des fluctuations saisonnières de charge.