Surveiller la stabilité de la dernière version de votre application

Déployer une nouvelle version de votre application mobile en production est l'une des étapes les plus intéressantes du développement d'applications, mais elle peut aussi être l'une des plus stressantes. Votre équipe doit suivre l'adoption des versions, les nouveaux bugs et leur impact, les comparaisons avec les versions précédentes, et plus encore.

Cette page décrit plusieurs outils proposés par Firebase pour surveiller les données dont vous avez besoin pour être sûr de la publication de votre application mobile.

Utiliser le tableau de bord Surveillance des versions pour explorer les données liées à votre version

Le tableau de bord Surveillance de la release de la console Firebase est optimisé par Firebase Crashlytics. Il s'agit d'un tableau de bord unique permettant de surveiller votre dernière version de production. Le tableau de bord est mis à jour en temps quasi réel et vous offre une vue d'ensemble des métriques de version les plus importantes, y compris les métriques sans plantage, l'adoption des versions, les comparaisons avec les versions précédentes et tous les nouveaux problèmes liés à la version.

Ce nouveau tableau de bord améliore la page Dernière version de la console. Par rapport à cette page, le tableau de bord Surveillance de la release ajoute plus d'informations, affiche des données utiles sans nécessiter Google Analytics et se charge plus rapidement.

Fonctionnalités du tableau de bord

• Rapports en temps réel
  Tous les graphiques sont mis à jour en temps quasi réel. Peu de temps après le déploiement de votre dernière version, vous pouvez voir les utilisateurs commencer à interagir avec cette version. Si certains de ces utilisateurs rencontrent des plantages, vous en connaîtrez immédiatement l'impact grâce aux graphiques des métriques sans plantage.

• Comparaison et benchmarking basés sur les versions précédentes
  Vous pouvez afficher la stabilité de votre dernière version dans le contexte de vos versions précédentes. Le tableau de bord vous permet de comparer les métriques en direct de votre dernière version et jusqu'à deux de vos builds publiées précédemment.

• Principaux nouveaux problèmes
  Vous pouvez afficher les nouveaux plantages de votre dernière version à mesure qu'ils se produisent. Dans le tableau Principaux nouveaux problèmes, vous pouvez surveiller l'impact des problèmes détectés pour la première fois dans votre dernière version, ce qui vous permet de décider rapidement s'il convient d'arrêter ou d'annuler la version.

Exigences concernant le tableau de bord

Pour afficher votre dernière version dans le tableau de bord Surveillance des versions, procédez comme suit :

1. Assurez-vous que votre application utilise au minimum les versions suivantes du Crashlytics SDK :
   Plates-formes Apple : v10.8.0 ou version ultérieure | Android : v18.6.0 ou version ultérieure (BoM v32.6.0 ou version ultérieure) | Flutter : v3.4.5 ou version ultérieure | Unity : 11.7.0 ou version ultérieure

2. Publiez une nouvelle version de l'application en production afin de disposer d'un nombre suffisant d'utilisateurs engagés avec votre dernière version.

Questions fréquentes concernant le tableau de bord

Quelles sont les versions du SDK requises pour utiliser le tableau de bord Surveillance de la release ?

Pour qu'une build s'affiche dans le tableau de bord, elle doit utiliser au minimum les versions suivantes du Crashlytics SDK :
Plates-formes Apple : v10.8.0 ou version ultérieure | Android : v18.6.0 ou version ultérieure (BoM v32.6.0 ou version ultérieure) | Flutter : v3.4.5 ou version ultérieure | Unity : 11.7.0 ou version ultérieure

Notez que ces versions du SDK sont souvent appelées versions du SDK "compatibles avec les sessions", car elles sont capables d'envoyer des données de session à Crashlytics, ce qui est nécessaire pour de nombreuses nouvelles fonctionnalités de Crashlytics, comme le tableau de bord Surveillance de la release.

Pourquoi le tableau de bord Surveillance des versions indique-t-il "En attente de plus d'engagement utilisateur" ?

Pour qu'une build s'affiche dans le tableau de bord, elle doit répondre à toutes les exigences suivantes :

• La build utilise au minimum les versions suivantes du Crashlytics SDK :
  Plates-formes Apple : v10.8.0 ou version ultérieure | Android : v18.6.0 ou version ultérieure (BoM v32.6.0 ou version ultérieure) | Flutter : v3.4.5 ou version ultérieure | Unity : 11.7.0 ou version ultérieure

• La build compte un nombre suffisant d'utilisateurs au cours des trois derniers jours :

  • La build doit compter au moins 500 utilisateurs uniques OU

  • La build compte au moins 1% du nombre total d'utilisateurs ET au moins deux utilisateurs uniques.

Quelles builds peuvent être affichées dans le tableau de bord Surveillance de la release ?

Le tableau de bord Surveillance des versions vise à vous aider à gérer vos versions de production, c'est-à-dire les builds qui comptent un nombre important d'utilisateurs.

Pour qu'une build s'affiche dans le tableau de bord, elle doit répondre à toutes les exigences suivantes :

• La build utilise au minimum les versions suivantes du Crashlytics SDK :
  Plates-formes Apple : v10.8.0 ou version ultérieure | Android : v18.6.0 ou version ultérieure (BoM v32.6.0 ou version ultérieure) | Flutter : v3.4.5 ou version ultérieure | Unity : 11.7.0 ou version ultérieure

• La build compte un nombre suffisant d'utilisateurs au cours des trois derniers jours :

  • La build doit compter au moins 500 utilisateurs uniques OU

  • La build compte au moins 1% du nombre total d'utilisateurs ET au moins deux utilisateurs uniques.

(Pour les applications distribuées via Google Play) Si une application comporte un Google Play lien, le tableau de bord affiche toutes les builds listées dans le canal de production Play, même si Crashlytics n'a reçu aucun journal de session ni détecté d'utilisateurs actifs pour cette build.

Notez que pour afficher les données dans le tableau de bord à des fins de comparaison ou pour le pourcentage d'utilisateurs actifs, vous devez avoir publié au moins deux builds répondant aux exigences précédentes.

Comment les valeurs affichées dans le graphique Utilisateurs actifs sont-elles déterminées ou calculées ?

Tout d'abord, il est utile de comprendre certains termes liés au graphique Utilisateurs actifs :

• Une session est une période continue pendant laquelle un utilisateur interagit avec une application. Une nouvelle session démarre lorsque l'application est démarrée à froid ou lorsqu'elle est mise au premier plan après au moins 30 minutes en arrière-plan.

• Les utilisateurs actifs pour une build spécifique correspondent au nombre d'utilisateurs ayant démarré une session à l'aide de cette build, regroupés par heure.

• Les utilisateurs (actifs) totaux correspondent au nombre d'utilisateurs ayant démarré une session dans n'importe quelle build de l'application qui utilise une version du SDK compatible avec les sessions, regroupés par heure.

Dans le graphique Utilisateurs actifs , la valeur en pourcentage et le nombre d'utilisateurs actifs qui sont toujours affichés proviennent des 60 dernières minutes (ou, s'il n'y a pas eu d'utilisateurs actifs au cours des 60 dernières minutes, de la dernière période d'une heure pour laquelle des données sont disponibles). Par exemple, dans la capture d'écran, 90 utilisateurs actifs ont utilisé la build 6.0.0 (600) au cours des 60 dernières minutes, ce qui représente 22,1% du nombre total d'utilisateurs (actifs) de l'application.

Lorsque vous placez le curseur de la souris sur les lignes du graphique Utilisateurs actifs, le pourcentage d'utilisateurs actifs est calculé à partir du nombre d'utilisateurs actifs de la période d'une heure sur laquelle vous pointez.

Notez que pour afficher le pourcentage d'utilisateurs actifs, vous devez avoir publié au moins deux builds répondant aux exigences décrites dans la section "Quelles builds peuvent être affichées dans le tableau de bord Surveillance de la release ?" de la FAQ.

Pourquoi mon pourcentage d'utilisateurs actifs est-il de 0%?

Le pourcentage d'utilisateurs actifs est basé sur les données de session reçues, et non sur d'autres données (comme les données Google Play ou les rapports sur les plantages).

Pourquoi ne vois-je pas de comparaisons et/ou de pourcentage d'utilisateurs actifs ?

Si vous publiez votre application pour la première fois avec une version du SDK Crashlytics compatible, alors Crashlytics ne dispose d'aucune donnée de session précédente à comparer.

Configurer des alertes

Plusieurs produits Firebase, y compris Crashlytics, peuvent envoyer des alertes pour diverses raisons spécifiques à un produit. Pour recevoir des alertes, vous devez disposer des autorisations requises.

Pour surveiller la stabilité de votre dernière version, vous pouvez configurer des alertes à partir de Performance Monitoring et Crashlytics. Pour Crashlytics en particulier, vous pouvez configurer les alertes suivantes :

• Utilisez des alertes de vitesse pour avertir votre équipe si un problème spécifique de votre application dépasse un seuil que vous définissez dans la Firebase console.

• Envoyez des alertes concernant les problèmes nouveaux ou régressifs à votre canal de notification préféré :

  • Utilisez les intégrations d'alertes configurées dans la console Firebase pour Slack, Jira, et PagerDuty.

  • Configurez des alertes avancées pour les services tiers à l'aide de Cloud Functions for Firebase.

Assurer une publication fluide avant de publier

Avant de publier votre dernière version, envisagez d'utiliser certains des services et fonctionnalités suivants pour assurer une publication fluide.

Utiliser des services de test avant publication

Firebase propose deux produits qui peuvent vous aider à effectuer des tests avant publication : Test Lab et App Distribution. Ces deux services peuvent être intégrés à vos flux CI/CD.

Firebase Test Lab est une infrastructure cloud qui vous permet de tester votre application sur différents appareils et configurations, afin de mieux comprendre comment elle se comportera dans les mains d'utilisateurs réels.

Lorsque vous êtes prêt à confier votre dernière build à des testeurs humains de confiance, utilisez Firebase App Distribution. Vous pouvez gérer vos distributions avant publication pour les plates-formes Apple et Android au même endroit.

Utiliser des services de déploiement et de test limité

Utilisez Firebase Remote Config pour lancer de nouvelles fonctionnalités avec un mécanisme de déploiement en pourcentage ou pour tester ces fonctionnalités sur un groupe de test limité.

Firebase propose également A/B Testingdes tests A/B pour vous permettre de tester les modifications apportées à l'UI, aux fonctionnalités ou aux campagnes d'engagement de votre application afin de déterminer leur impact sur vos métriques clés (comme les revenus et la rétention) avant de les déployer à grande échelle.