Crash Reporting dans le développement mobile — ce que c'est, services et configuration

Qu'est-ce que le Crash Reporting ?

Le Crash Reporting est le processus de collecte automatique d'informations techniques sur les plantages de l'application et de leur transmission centralisée au serveur pour analyse. Contrairement à la journalisation, le crash-reporting capture spécifiquement les situations d'urgence — le moment où l'application a été arrêtée de force par le système ou le système d'exploitation.

Chaque rapport de plantage contient trois composants clés : le type d'exception (NullPointerException, SIGSEGV, NSInternalInconsistencyException), la pile d'appels complète avec les numéros de ligne, et les informations sur l'environnement — version du système d'exploitation, modèle de l'appareil, taille de la mémoire libre. Selon Sentry Engineering, 2024, la combinaison de ces trois éléments permet de reproduire et de corriger 85 % des erreurs critiques.

Les systèmes modernes de crash-reporting étendent leurs fonctionnalités au-delà des plantages ordinaires. Firebase Crashlytics regroupe automatiquement les plantages récurrents en issues, Sentry suit les régressions entre les versions, et Bugsnag montre le chemin de l'utilisateur jusqu'à l'erreur. Les trois services prennent en charge iOS, Android, React Native et Flutter.

Selon Google I/O 2024, les applications sans crash-reporting consacrent en moyenne 3 à 5 jours ouvrables au diagnostic d'une seule erreur critique, alors qu'avec Crashlytics, cela prend 15 à 30 minutes. L'économie de temps dépasse 90 % pour chaque incident.

Comment fonctionne le système de collecte de rapports de plantage

Architecture du système de crash-reporting se compose de trois couches : un SDK client installé dans l'application, une API serveur pour recevoir et traiter les rapports, et un tableau de bord web pour l'analyse. Le SDK client intercepte les exceptions non gérées, les sérialise en JSON et les envoie au serveur au prochain lancement de l'application.

L'envoi du rapport de plantage se fait de manière asynchrone après le redémarrage de l'application. C'est un point fondamental : au moment du plantage, l'application ne peut pas garantir la transmission réussie des données sur le réseau. Le SDK écrit le rapport dans le stockage local et, au prochain lancement, l'envoie via un thread d'arrière-plan. Selon Firebase Engineering, 2024, cette approche assure la livraison de 99,7 % des rapports de plantage.

Pour les exceptions non fatales (exceptions gérées dans un bloc try-catch), le SDK envoie le rapport immédiatement car l'application continue de fonctionner. Les rapports non fatals contiennent les mêmes données qu'un plantage mais n'interrompent pas la session de l'utilisateur. C'est particulièrement utile pour suivre les erreurs de requêtes API, la validation des données et la logique métier.

Regroupement des plantages — un algorithme serveur qui fusionne les plantages identiques sur la base d'un hachage des 5 à 10 dernières trames de la pile. Cela permet au développeur de voir non pas 1000 rapports individuels mais un issue avec 1000 occurrences sur différents appareils et versions du système d'exploitation.

Firebase Crashlytics : intégration et fonctionnalités

Firebase Crashlytics est le service de crash-reporting le plus populaire pour les applications mobiles, utilisé dans plus de 3 millions de projets dans le monde. Le forfait gratuit comprend des rapports illimités, une intégration avec Google Analytics et un regroupement automatique des plantages.

Intégration de Crashlytics sur Android

Connexion Crashlytics sur Android est minime : ajoutez la dépendance dans build.gradle et initialisez le SDK dans Application.onCreate. Crashlytics définit automatiquement son propre Thread.setDefaultUncaughtExceptionHandler, interceptant toutes les exceptions non gérées.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

Fonctionnalité clé de Crashlytics — les clés et journaux personnalisés. Le développeur peut ajouter jusqu'à 64 paires clé-valeur à chaque rapport de plantage : état de l'écran, forfait sélectionné, niveau de l'utilisateur. Des messages de journal personnalisés sont également disponibles, qui apparaissent dans le rapport dans l'ordre chronologique.

Velocity Alert — détection automatique des régressions

Velocity Alert est une fonctionnalité de Crashlytics qui surveille les augmentations brutales du nombre de plantages pour un issue spécifique. Si après une nouvelle version, le nombre de plantages dépasse un seuil, l'équipe reçoit une notification push et un e-mail 5 à 15 minutes avant les plaintes massives des utilisateurs.

Réglage du seuil de déclenchement : 2x en 1 heure pour les issues critiques. Selon Google, 2024, les équipes avec Velocity Alert activé publient les versions correctives en moyenne 40 % plus rapidement que les équipes qui comptent sur une surveillance manuelle du tableau de bord.

Intégration de Crashlytics sur iOS

Sur iOS le SDK Crashlytics s'intègre via CocoaPods ou Swift Package Manager. Le SDK intercepte à la fois les exceptions Objective-C (via NSSetUncaughtExceptionHandler) et les signaux du système d'exploitation (SIGSEGV, SIGABRT) via son propre gestionnaire d'exceptions mach.

Selon Apple Developer, 2024, Crashlytics pour iOS traite jusqu'à 98 % de tous les types de plantages, y compris les erreurs mémoire de bas niveau qui ne sont pas détectées par les outils standards. Cela fait de Crashlytics la norme de facto pour le développement iOS.

Sentry et Bugsnag : plateformes alternatives

Sentry est une plateforme open-source de surveillance des erreurs prenant en charge 80+ langages et frameworks. Contrairement à Crashlytics, Sentry cible les développeurs backend mais fournit des SDK complets pour iOS, Android, React Native et Flutter.

L'avantage clé de Sentry est le Performance Monitoring dans un seul tableau de bord. Les développeurs voient non seulement les plantages mais aussi les transactions qui y ont conduit : requêtes réseau lentes, blocages de l'interface utilisateur, opérations longues sur la base de données. Selon Sentry, 2024, 40 % des plantages ont des problèmes de performance préexistants qui passent inaperçus sans cette approche.

Bugsnag se distingue par son approche du regroupement des erreurs — au lieu de la pile d'appels, il analyse le parcours utilisateur. Chaque rapport de plantage contient la séquence d'écrans et d'actions de l'utilisateur qui ont conduit à l'erreur. C'est particulièrement utile pour les processus métier complexes : passage de commande, inscription, paiement.

Les coûts des services varient : Crashlytics est gratuit dans Firebase, Sentry propose un forfait gratuit pour 5000 événements par mois, Bugsnag à partir de 29 $ par mois. Les trois plateformes fournissent des SDK open-source. Le choix du service dépend de la taille de l'équipe, du budget et des exigences de sécurité des données.

Crash Reporting sur iOS : caractéristiques et NSException

Spécificité d'iOS — une architecture de gestion des erreurs multicouche. Les SDK de crash-reporting doivent intercepter les exceptions Objective-C (NSException), les erreurs Swift (Error), les signaux POSIX (SIGSEGV, SIGBUS) et les exceptions mach. Chaque type nécessite un mécanisme d'interception distinct.

NSException est le type le plus simple à intercepter via NSSetUncaughtExceptionHandler. Cependant, selon Apple, 2024, seulement 30 % des plantages dans les applications Swift modernes sont des NSException. Les 70 % restants sont des signaux du système d'exploitation et des erreurs d'exécution Swift, qui nécessitent un mécanisme de gestionnaire d'exceptions mach.

Les développeurs iOS doivent tester le crash-reporting via une génération locale de plantages de différents types : __builtin_trap() pour les signaux, [NSException raise:...] pour les exceptions, fatalError() pour Swift. C'est le seul moyen de s'assurer que le SDK couvre tous les types de plantages.

Crash Reporting sur Android : ANR et plantages natifs

Android ajoute deux types spécifiques de plantages qui n'existent pas sur iOS : ANR (Application Not Responding) et plantage natif dans le code C/C++. L'ANR se produit lorsque le thread de l'interface utilisateur est bloqué pendant plus de 5 secondes — le système affiche une boîte de dialogue « L'application ne répond pas » et propose de la fermer.

Le Thread.setDefaultUncaughtExceptionHandler standard n'intercepte pas l'ANR, car ce n'est pas une exception mais un signal du ActivityManager. Pour suivre l'ANR, Crashlytics et Sentry utilisent un thread watchdog d'arrière-plan qui vérifie la réactivité du thread UI toutes les 5 secondes. Selon Firebase, 2024, 15 % de tous les problèmes sur Android sont des ANR, pas des plantages.

Les plantages natifs sur Android surviennent dans le code C/C++ exécuté via JNI (Java Native Interface). Ces plantages ne sont pas des exceptions Java et ne sont pas interceptés par Thread.setDefaultUncaughtExceptionHandler. Pour les traiter, on utilise Google Breakpad ou Crashpad, qui installent des gestionnaires sigaction pour les signaux SIGSEGV, SIGABRT, SIGBUS.

Selon Google I/O 2024, le nombre de plantages natifs augmente avec la propagation des moteurs de jeu (Unity, Unreal Engine) et des bibliothèques de vision par ordinateur (ML Kit, OpenCV). Il est recommandé aux développeurs d'applications hybrides de toujours activer le crash-reporting natif.