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

Le déploiement en production d'une nouvelle version de votre application mobile est l'une des étapes les plus excitantes du développement d'applications, mais elle peut aussi être l'une des plus stressantes. Votre équipe doit suivre l'adoption de la version, les nouveaux bugs et leur impact, une comparaison avec les versions précédentes, etc.

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 vos données liées aux versions

Le tableau de bord Surveillance des versions de la console Firebase est optimisé par Firebase Crashlytics. Il s'agit d'un tableau de bord unique pour surveiller votre dernière version de production. Le tableau de bord se met à jour presque en temps 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 de la version, les comparaisons avec les versions précédentes et 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 des versions ajoute plus d'informations, affiche des données utiles sans avoir besoin de Google Analytics et se charge plus rapidement.

Fonctionnalités du tableau de bord

  • Rapports en temps réel
    Tous les graphiques sont mis à jour presque en temps réel. Peu de temps après avoir déployé 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 analyse comparative basées sur les versions précédentes
    Vous pouvez consulter la stabilité de votre dernière version par rapport à vos versions précédentes. Le tableau de bord vous permet de comparer les métriques en direct de votre dernière version et de deux de vos versions précédentes.

  • Nouveaux problèmes importants
    Vous pouvez consulter les nouveaux plantages de votre dernière version au fur et à mesure qu'ils arrivent. Dans le tableau Principals nouveaux problèmes, vous pouvez surveiller l'impact des problèmes détectés en premier dans votre dernière version, ce qui vous permet de décider rapidement de suspendre ou de revenir à la version précédente.

Conditions requises pour 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 moins les versions suivantes du SDK Crashlytics:
    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 sur le tableau de bord

Pour qu'un build s'affiche dans le tableau de bord, il doit utiliser au moins les versions suivantes du SDK Crashlytics:
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 peuvent 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 des versions.

Pour qu'un build s'affiche dans le tableau de bord, il doit respecter toutes les exigences suivantes:

  • Le build utilise au moins les versions suivantes du SDK Crashlytics:
    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 version a été utilisée par un nombre suffisant d'utilisateurs au cours des trois derniers jours:

    • La version doit compter au moins 500 utilisateurs uniques OU

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

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

Pour qu'un build s'affiche dans le tableau de bord, il doit respecter toutes les exigences suivantes:

  • Le build utilise au moins les versions suivantes du SDK Crashlytics:
    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 version a été utilisée par un nombre suffisant d'utilisateurs au cours des trois derniers jours:

    • La version doit compter au moins 500 utilisateurs uniques OU

    • La version 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 dispose d'un lien Google Play, le tableau de bord affiche tous les builds listés 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 ce build.

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

Tout d'abord, il est utile de comprendre certains des termes utilisés dans le graphique Utilisateurs actifs:

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

  • Les utilisateurs actifs d'une version spécifique correspondent au nombre d'utilisateurs ayant démarré une session avec cette version, regroupés par heure.

  • Nombre total d'utilisateurs (actifs) : nombre d'utilisateurs ayant démarré une session dans n'importe quelle version de l'application qui utilise une version de SDK compatible avec les sessions, regroupés par heure.

Dans le graphique Utilisateurs actifs, la valeur du pourcentage et le nombre d'utilisateurs actifs qui sont toujours affichés dans le graphique correspondent aux 60 dernières minutes (ou à la dernière heure pour laquelle des données sont disponibles si aucun utilisateur actif n'a été enregistré au cours des 60 dernières minutes). Par exemple, dans la capture d'écran ci-dessous, il y avait 90 utilisateurs actifs pour le 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.

capture d&#39;écran d&#39;un exemple de graphique &quot;Utilisateurs actifs&quot; du tableau de bord <i>Surveillance des versions</i>

Lorsque vous pointez 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 qui répondent aux exigences décrites dans la FAQ "Quels builds peuvent être affichés dans le tableau de bord Surveillance des versions ?".

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

Si vous publiez votre application pour la première fois avec une version compatible du SDK Crashlytics, 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 propres à chaque 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 de Crashlytics. Pour Crashlytics plus précisément, 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 console Firebase.

  • Envoyez des alertes sur les nouveaux problèmes ou les problèmes régressifs sur le canal de notification de votre choix:

Assurez-vous que votre application est prête à être publiée

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 en version préliminaire

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

Firebase Test Lab est une infrastructure de test d'applications dans le cloud qui vous permet de tester votre application sur différents appareils et configurations. Vous pouvez ainsi avoir une idée rapide de ses performances auprès d'utilisateurs réels.

Et lorsque vous êtes prêt à confier votre dernier build à des testeurs humains de confiance, utilisez Firebase App Distribution. Vous pouvez gérer à la fois votre plate-forme Apple et vos distributions Android en version préliminaire depuis le même endroit.

Utiliser les services de déploiement et de test limités

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

Firebase propose également A/B Testing pour que vous puissiez tester les modifications apportées à l'interface utilisateur, aux fonctionnalités ou aux campagnes axées sur l'engagement de votre application afin de voir comment elles ont un impact sur vos métriques clés (comme les revenus et la fidélisation) avant de les déployer à grande échelle.