Suivi des plantages et de la performance d'une appli mobile
Le suivi des plantages permet de voir les pannes avant les plaintes : quels indicateurs surveiller, quels outils choisir et comment hiérarchiser les alertes.
Équipe rabbitclipPublié: 7 min de lecture
En bref
Le suivi des plantages d'une application mobile est un dispositif qui, chaque fois que l'application se ferme sur le téléphone d'un utilisateur, recueille automatiquement l'endroit où la panne s'est produite, sur quel appareil et dans quelle version, puis vous la signale. Le suivi de la performance mesure de la même façon les problèmes plus diffus : temps de lancement, saccades et consommation de mémoire. Avec les deux, vous voyez la santé réelle de l'application entre les mains des utilisateurs. Sans eux, vous décidez uniquement d'après les avis des stores, et ces avis ne sont que la voix d'une petite part des personnes qui ont rencontré le problème.
Celui dont l'application plante ne vous écrit généralement pas. Il la ferme, réessaie une fois, puis la supprime. Une application qui tourne bien sur vos téléphones de test peut se comporter autrement sur un appareil de trois ans ou avec une connexion faible. Le suivi est le seul moyen de rendre visible ce groupe invisible.
Le suivi des plantages et celui de la performance sont-ils la même chose ?
Non, ils répondent à des questions différentes. Le suivi des plantages capture le moment où l'application se ferme : sur quelle ligne de code, sur quel appareil, sous quelle version du système et ce que faisait l'utilisateur à ce moment-là. Le suivi de la performance mesure ce qui se ressent mal même quand l'application ne se ferme pas : un écran lent, un défilement saccadé, une mémoire qui gonfle.
Sur Android, il existe un troisième type de panne, l'application qui ne répond plus, connue sous le nom d'ANR. L'application ne plante pas mais se fige, et le système propose à l'utilisateur de la fermer. Un bon dispositif de suivi présente séparément ces trois groupes : plantages, absence de réponse et lenteur.
Quels indicateurs faut-il surveiller ?
Quelques indicateurs significatifs valent mieux qu'un mur de graphiques. Le premier est le taux de sessions sans plantage : la probabilité qu'une session se termine sans panne une fois que l'utilisateur a ouvert l'application. Comparez-le d'une version à l'autre ; s'il baisse dans la nouvelle version, celle-ci a introduit une régression.
Le second groupe est celui des indicateurs de performance. Les tableaux de bord des stores proposent aussi leurs propres chiffres de santé. La Google Play Console et les outils pour développeurs d'Apple montrent gratuitement des données de plantage et d'absence de réponse recueillies auprès des utilisateurs, et pour la plupart des entreprises c'est le point de départ.
- Taux de sessions sans plantage, comparé version par version
- Temps de démarrage à froid : la rapidité d'ouverture de l'application quand elle était totalement fermée
- Fréquence des images lentes et figées : la fluidité ressentie du défilement et des transitions
- Événements d'absence de réponse (ANR) et modèles d'appareils concernés
Quels outils et quelles données faut-il recueillir ?
Il existe des services prêts à l'emploi largement utilisés pour le rapport de plantages ; Firebase Crashlytics et Sentry en sont des exemples connus. Le choix dépend de l'infrastructure que l'équipe utilise déjà et de ce que vous devez surveiller. Plus que le nom de l'outil, c'est l'exactitude de la mise en place qui fait la différence.
La partie de la mise en place la plus souvent sautée est celle qui rend le rapport lisible. Le code d'une application publiée est obscurci et dépouillé de ses noms ; pour rendre un rapport de plantage lisible, vous devez téléverser à chaque version les fichiers de symboles et de correspondance au service de suivi. Si vous ne le faites pas, le rapport n'est qu'une liste d'adresses sans signification, et personne ne peut dire où se trouve la panne.
Les rapports portent aussi du contexte : les dernières actions de l'utilisateur, le numéro de version, le modèle d'appareil, l'état du réseau. Veillez à ce que ce contexte ne contienne aucune donnée personnelle ; noms, adresses e-mail et données de carte ne doivent jamais entrer dans un rapport. La manière dont des données personnelles finissent dans les journaux mérite d'être discutée avec un juriste ou un délégué à la protection des données.
Comment hiérarchiser les pannes qui arrivent ?
Une fois le suivi en marche, la première semaine produit une liste de dizaines de pannes, et toutes les traiter est impossible. La priorité repose sur deux critères : combien d'utilisateurs sont touchés et à quel moment de leur parcours cela se produit. Un seul plantage pendant le paiement, la connexion ou l'inscription passe avant un plantage courant mais sans gravité sur l'écran des réglages.
Une panne qui apparaît avec une nouvelle version est traitée à part, car c'est une régression et, en général, le type le plus rapide à corriger. Lorsque c'est possible, déployer une nouvelle version par étapes auprès des utilisateurs permet d'arrêter la publication quand un problème apparaît.
- Nombre d'utilisateurs touchés et fréquence de répétition
- Le moment où cela survient : paiement, connexion et inscription en premier
- Si cela a commencé avec la nouvelle version, autrement dit si c'est une régression
- Le groupe d'appareils et de versions du système concerné
Quelles erreurs fréquentes dans le suivi des plantages et de la performance ?
L'erreur la plus courante est de mettre le suivi en place après le lancement, si bien que la première vague de plantages passe inaperçue. La deuxième est de recueillir des rapports que personne ne lit. Une personne ou un rôle doit examiner régulièrement les pannes et surveiller de près les premiers jours qui suivent chaque version.
La troisième est de tester uniquement sur les téléphones les plus récents. La base d'utilisateurs réelle comprend des appareils plus anciens et des connexions lentes, et c'est là que les problèmes de performance ont tendance à apparaître.
- Mettre le suivi en place après le lancement
- Ne pas téléverser les fichiers de symboles et de correspondance, laissant les rapports illisibles
- Recueillir des rapports sans que personne ne les examine régulièrement
- Écrire des données personnelles dans les rapports ou les journaux
Quand le suivi de la performance est-il inutile ou prématuré ?
Pour une application qui n'est pas encore lancée et n'a pas d'utilisateurs, un tableau de bord détaillé de la performance est prématuré ; il n'y a aucune donnée à interpréter. À ce stade, il suffit de mettre en place le rapport de plantages, car dès les premiers vrais utilisateurs il vous offre une protection presque gratuite qui demande peu d'entretien.
Un dispositif de suivi complexe est aussi superflu pour une application d'entreprise simple, avec peu d'utilisateurs, rarement ouverte ; les données de santé gratuites des tableaux de bord des stores peuvent suffire. Le critère est le suivant : si le suivi ne change aucune décision que vous prendriez, il est superflu.
Le suivi des plantages et de la performance est le moyen de voir l'application telle que les utilisateurs la vivent réellement, alors que les avis des stores ne montrent que la partie la plus bruyante du problème. Mettez le suivi en place avant le lancement, téléversez à chaque version les fichiers qui gardent les rapports lisibles, examinez régulièrement quelques indicateurs significatifs et classez les pannes selon le nombre d'utilisateurs qu'elles touchent. Si vous souhaitez de l'aide pour surveiller la santé de votre application, vous pouvez convenir d'un entretien de découverte avec rabbitclip.
Questions fréquentes
Qu'est-ce que le taux de sessions sans plantage ?
C'est la part des sessions qui vont du lancement de l'application à sa fermeture sans plantage. Comparé d'une version à l'autre, il donne une lecture rapide de la stabilité d'une nouvelle version.
Dois-je utiliser un outil prêt à l'emploi pour le suivi des plantages ?
Pour la plupart des entreprises, oui. Des services largement utilisés comme Firebase Crashlytics et Sentry offrent une solution toute prête, et construire la vôtre apporte rarement de la valeur. La vraie différence tient à la bonne mise en place et au téléversement des fichiers de symboles.
Les tableaux de bord des stores suffisent-ils à eux seuls ?
Ils suffisent souvent pour commencer, car ils montrent gratuitement des données de plantage et d'absence de réponse. Pour voir où et à quelle étape une panne se produit, et pour comparer les versions, il faut en général un outil de suivi distinct.
Les données de suivi comptent-elles comme des données personnelles ?
Elles peuvent l'être, si un rapport contient des informations qui identifient l'utilisateur. Veillez à ne pas ajouter de noms, d'adresses e-mail ou de données de paiement aux rapports, et interrogez un juriste sur la situation juridique de votre application.
