Firebase Crashlytics — qu'est-ce que c'est, plantages et diagnostic des pannes

Qu'est-ce que Firebase Crashlytics

Firebase Crashlytics est un service gratuit Google de surveillance de la stabilité des applications mobiles, acquis par Google en 2017 avec la société Fabric. Crashlytics collecte automatiquement les informations sur chaque plantage d'application, regroupe les crashs identiques par signature de pile et les affiche dans la console Firebase avec une priorisation basée sur le nombre d'utilisateurs affectés.

Histoire et évolution

Crashlytics a été lancé en 2011 dans le cadre de la plateforme Fabric et est rapidement devenu le standard de facto pour le crash-reporting sur iOS. Après son acquisition par Google en 2017 pour environ 2 milliards de dollars (Fabric entière), Crashlytics a été intégré au SDK Firebase. La version 18.0.0 (2021) a ajouté la prise en charge de Kotlin Multiplatform, et la version 19.0.0 (2024) a introduit la collecte automatique des ANR sur Android sans configuration supplémentaire. Selon Google (2026), Crashlytics traite plus de 10 milliards de crashs par mois.

Limites gratuites de Crashlytics

Crashlytics est fourni gratuitement avec une limite de 500 mille sessions par jour par projet Firebase. Pour la plupart des applications, cela est suffisant — selon Google (2026), 95% des projets ne dépassent pas la limite. En cas de dépassement, la collecte des données ne s'arrête pas, mais les rapports cessent de se mettre à jour jusqu'au jour suivant. Pour les projets à forte charge, les forfaits Spark et Blaze de Firebase sont disponibles — Crashlytics reste gratuit sur les deux forfaits, et la limite de sessions est comptée séparément.

Comment Crashlytics détecte et collecte les plantages

Le mécanisme de collecte de Crashlytics est basé sur l'interception d'exceptions au niveau de la plateforme et du runtime. Sur Android, le SDK implémente UncaughtExceptionHandler, interceptant toutes les exceptions non capturées Kotlin et Java. Sur iOS, Crashlytics utilise NSSetUncaughtExceptionHandler pour Objective-C/Swift et son propre gestionnaire d'exceptions Mach pour les crashs de code natif.

Types de plantages interceptés

Crashlytics distingue cinq types de plantages : fatal (crashs fatals), non-fatal (exceptions non fatales transmises manuellement), ANR (Android — application ne répond pas), signal (signaux OS — SIGSEGV, SIGABRT) et OOM (out of memory sur iOS). Chaque type est traité par un mécanisme distinct et affiché dans la console avec l'étiquette correspondante.

Format du rapport de plantage

Chaque rapport Crashlytics contient des informations exhaustives : la trace de pile complète avec les noms de classes et les numéros de ligne, la version de l'application (versionName + versionCode), le modèle de l'appareil, la version de l'OS, la quantité de mémoire libre, l'orientation de l'écran et le temps écoulé depuis le lancement. Si Firebase Analytics est connecté, le rapport inclut également le parcours des 50 derniers événements utilisateur avant le plantage — ce qui est crucial pour reproduire le crash.

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

Intégration de Crashlytics dans un projet Android

La connexion de Crashlytics à une application Android nécessite l'ajout de deux dépendances dans build.gradle et la configuration du plugin Google Services. Le SDK connecte automatiquement le crash-reporting lors de l'initialisation de Firebase sans code supplémentaire. Pour un fonctionnement correct, le plugin google-services et le fichier google-services.json de la console Firebase sont également nécessaires.

// build.gradle (niveau projet)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (niveau application)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Configuration du plugin Crashlytics

Le plugin com.google.firebase.crashlytics effectue deux tâches : il génère un identifiant unique de build (build ID) pour le mapping des piles obfusquées et crée automatiquement les ressources pour le SDK Crashlytics. Sans le plugin, les crashs seront marqués comme « non mappés » — vous ne verrez que des noms de classes obfusqués (a.b.c) sans possibilité de trouver le code source. Le plugin est ajouté dans le build.gradle racine et dans le build.gradle du module applicatif.

Vérification de l'intégration

Pour tester l'intégration de Crashlytics, on utilise la méthode spéciale forceCrash() qui génère une exception de test. Dans les builds de production, cette méthode n'est pas disponible. Après le lancement d'un crash de test, le rapport apparaît dans la console Firebase sous 1 à 5 minutes. Si le rapport ne s'affiche pas, vérifiez que google-services.json correspond au package de l'application et que AndroidManifest ne contient pas de drapeaux désactivant la collecte de données.

Analyse des crashs et regroupement des rapports

La console Crashlytics offre deux niveaux de visualisation : la liste de tous les crashs (Issues) regroupés par type de plantage, et le rapport détaillé pour chaque Issue avec la trace, les statistiques et les données personnalisées. Chaque Issue regroupe tous les crashs ayant la même signature — le même type d'exception et la même trace de pile.

Issues et regroupement

Le regroupement des crashs est une fonctionnalité clé de Crashlytics. Au lieu d'afficher des milliers de crashs individuels, le service les regroupe en Issues sur la base d'une empreinte (fingerprint) — somme de contrôle de la trace de pile. Un Issue peut contenir de 1 à plusieurs millions de crashs. Pour chaque Issue sont affichés : le nombre de cas fatals, le nombre d'utilisateurs uniques, la version de l'application dans laquelle le crash est apparu, et le pourcentage d'utilisateurs ayant rencontré le problème.

Selon Google (2026), en moyenne 20% des Issues représentent 80% de tous les crashs fatals d'une application (principe de Pareto). Crashlytics trie automatiquement les Issues par sévérité — plus il y a d'utilisateurs affectés, plus la priorité est élevée. Cela permet au développeur de corriger en priorité les problèmes les plus massifs.

Statistiques par version

Crashlytics suit la stabilité de chaque version d'application séparément. Le graphique crash-free users montre le pourcentage d'utilisateurs n'ayant pas rencontré de crash fatal dans chaque version. Si lors d'une mise à jour le pourcentage tombe en dessous du seuil (par défaut 99%), Crashlytics envoie une notification par email et dans la Firebase Console. Cela permet de revenir rapidement à une version stable ou de publier un correctif.

Clés personnalisées, journaux et Breadcrumbs

Crashlytics fournit trois mécanismes pour enrichir les rapports avec du contexte : les clés personnalisées (keys) pour les données structurées, les journaux (logs) pour la trace textuelle et les Breadcrumbs d'Analytics pour le parcours utilisateur. Ces trois types de données sont liés au rapport de crash et visibles dans sa fiche détaillée.

Clés personnalisées

Les Custom Keys sont des paires « clé-valeur » transmises avec chaque crash. Maximum 64 clés par application, chaque clé est une chaîne de 1024 caractères maximum. Les clés sont utiles pour marquer l'état de l'application : niveau d'abonnement, statut d'authentification, dernier écran, VPN activé ou non. Les valeurs sont écrasées — une nouvelle clé avec le même nom remplace l'ancienne.

Journalisation des événements

Les Custom Logs sont des messages textuels que Crashlytics conserve dans un tampon circulaire de 64 Ko. Les journaux sont automatiquement attachés au prochain crash. Si aucun crash ne se produit, les journaux ne sont pas transmis au serveur (aucune consommation de bande passante). La journalisation est utilisée pour enregistrer les étapes de l'utilisateur avant le plantage : « payment_processing_started », « api_call_initiated », « response_received_200 ».

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Breadcrumbs d'Analytics

Si Firebase Analytics est connecté au projet, Crashlytics reçoit automatiquement les Breadcrumbs — les 50 derniers événements d'analyse avant le crash. Chaque breadcrumb contient le nom de l'événement et ses paramètres. Cela permet de reconstituer la séquence exacte d'actions ayant conduit au plantage : l'utilisateur a ouvert l'écran → ajouté un produit → est passé au paiement → le crash s'est produit. Les Breadcrumbs sont affichés dans la fiche Issue dans l'onglet « Logs ».

Bonnes pratiques de gestion des plantages

Crashlytics est le plus efficace avec une configuration correcte du contexte et un processus de traitement des Issues. La pratique montre que les équipes ayant mis en place un règlement de gestion des crashs réduisent le temps de correction des bogues critiques de 60% (données Google, 2026).

Priorisation des Issues

Tous les crashs ne sont pas également importants. La priorisation par nombre d'utilisateurs et fréquence de déclenchement aide à se concentrer sur les problèmes les plus critiques. Règle : corriger les Issues affectant plus de 0,1% des utilisateurs dans les 24 heures. Les Issues à occurrences uniques (< 0,01%) peuvent être reportées à la prochaine version planifiée. Crashlytics marque automatiquement les régressions — les Issues qui ont été corrigées mais réapparaissent dans une nouvelle version.

Intégration avec CI/CD

L'API Crashlytics permet d'intégrer les rapports de crashs dans le pipeline CI/CD via l'API REST ou Firebase CLI. À chaque nouvelle version, vous pouvez vérifier automatiquement si le pourcentage d'utilisateurs sans crash ne dépasse pas le seuil. Si le seuil est dépassé, le CI/CD bloque le déploiement et envoie une notification à l'équipe. Firebase CLI prend en charge la commande firebase crashlytics:builds:upload pour le téléchargement des fichiers de mapping ProGuard/R8 — sans eux, les piles seront illisibles.

Selon Google (2026), les applications utilisant la vérification automatique des seuils crash-free dans le CI/CD publient 40% de régressions en moins en production. Seuil recommandé : crash-free users >= 99,5% pour les versions critiques et >= 99,0% pour les versions normales.