Surveiller les plantages d'une application mobile après sa sortie

Le vrai test commence devant le portique

Une voyageuse ouvre son billet sur son téléphone. L'application se ferme avant d'afficher le code. Les tests internes ont peut-être tous réussi, mais ils ne changent rien à la situation de cette personne. La scène photographiée illustre un risque possible; elle ne représente pas un incident vécu par un client d'Appfyl.

Après une sortie, posez une question plus utile que « combien de plantages ? » : qui n'a pas pu terminer quoi, sur quelle version, et qui peut agir ? La liste de préparation au lancement traite de l'avant-publication. Ici, nous parlons des premières heures avec des utilisateurs et des appareils réels.

Trois défaillances, trois pistes différentes

Un plantage ferme l'application sans prévenir. Sous Android, une erreur ANR désigne une application qui ne répond plus; l'écran peut rester visible alors que l'utilisateur ne peut rien faire. Il existe aussi une panne silencieuse: l'écran annonce une réservation confirmée, mais le serveur ne l'a jamais enregistrée. Se fier uniquement aux plantages laisserait passer ce troisième cas.

Firebase distingue les utilisateurs et les sessions sans plantage. Ces mesures concernent les incidents fatals, pas toutes les actions ratées. Une bonne moyenne peut masquer une panne touchant un petit groupe de clients pour qui l'action est essentielle. Filtrez toujours la version de production avant de conclure.

Vérifier le signal avant de faire confiance au zéro

Demandez à l'équipe de provoquer un plantage contrôlé sur une version proche de celle qui sera publiée, puis de retrouver le rapport correspondant. On doit pouvoir lire la version, la plateforme, le modèle et une trace exploitable. Si les symboles iOS ou les fichiers de correspondance Android manquent, un rapport peut arriver sans permettre un diagnostic rapide. Refaites ce test lorsque la chaîne de compilation change.

La technique ne suffit pas si personne ne reçoit l'avertissement. Désignez un responsable, une personne de relais et celui ou celle qui peut interrompre la diffusion. La documentation Firebase sur les alertes précise que certains types d'alertes nécessitent la configuration explicite d'un canal. Une notification cachée dans une console peu consultée n'est pas une procédure d'incident.

Gardez des données de diagnostic proportionnées: numéro de version, identifiant d'incident et dernière étape non sensible. Les mots de passe, jetons, informations médicales et données de paiement n'ont pas leur place dans un rapport d'erreur. Si vous ajoutez un nouvel outil, revoyez aussi les déclarations de la politique de confidentialité.

Croiser la boutique, l'application et le service

Android vitals rend visibles certains problèmes de stabilité observés par Google Play. Crashlytics aide à regrouper les incidents et à comparer les versions. Sentry constitue une autre option lorsque l'équipe veut rapprocher erreurs et performance. Aucun de ces outils ne confirme, à lui seul, qu'un paiement a été validé côté serveur ou qu'un rendez-vous existe dans le planning.

Pour piloter le produit, un résumé court suffit: adoption de la version, incidents nouveaux ou revenus, nombre de personnes touchées et parcours bloqué. Le suivi des versions de Firebase apporte une comparaison utile aux équipes qui utilisent Crashlytics. Associez-le aux événements définis dans la méthode d'analyse de l'application; une baisse des inscriptions terminées doit se voir même si les plantages ne bougent pas.

Suspendre la diffusion quand le service ne tient plus sa promesse

Dans une salle de sport, la séance va commencer. L'application s'ouvre normalement, mais le pointage d'entrée ne se sauvegarde pas. Le personnel laisse passer les adhérents et note les présences à la main. L'enjeu immédiat est de maintenir l'accès et de pouvoir reconstituer la liste, pas de préserver un beau taux de stabilité.

Décidez avant la sortie ce qui impose une réaction immédiate: plantages nouveaux et répandus, connexion ou paiement impossible, perte d'enregistrements, problème de sécurité ou de confidentialité. Un défaut d'alignement visuel peut généralement attendre. Regardez à la fois le nombre de personnes concernées, la gravité du parcours et la version touchée. Il n'existe pas de pourcentage universel convenant aussi bien à une application de billets qu'à une application de loisirs.

Un déploiement progressif permet de suspendre l'élargissement de l'audience pendant l'enquête. Il ne restaure pas automatiquement des données modifiées sur le serveur. Préparez donc une procédure de reprise distincte. Après correction, ajoutez le scénario aux tests du prochain lancement.

Un rituel simple pour le premier jour

Avant la publication, indiquez qui surveille la sortie, où arrivent les alertes, quels parcours doivent rester disponibles et qui prend la décision d'arrêt. Au début, vérifiez que la nouvelle version compte des sessions; un écran vide n'est pas une preuve de stabilité. Comparez-la avec la précédente, effectuez le parcours principal sur un vrai appareil et contrôlez le résultat côté serveur ou dans l'analyse produit. Recommencez lorsque davantage de modèles de téléphone auront adopté la version.

Pour chaque incident, notez la première version concernée, le parcours touché, le contournement possible, le responsable et l'heure de la prochaine vérification. Donnez au support une réponse claire. Une correction n'est terminée que lorsqu'elle fonctionne dans la version distribuée et que l'incident cesse de revenir. C'est une part concrète de la maintenance après lancement.

Si une autre équipe doit reprendre une application instable, rassemblez les liens des boutiques, le numéro de version, le parcours défaillant, quelques retours du support et l'accès aux rapports. « Rendez-la stable » ne constitue pas encore un diagnostic. Appfyl peut recevoir ces éléments dans un court questionnaire projet avant de déterminer s'il faut réparer un point précis ou revoir une partie plus large du produit.

Questions fréquentes