Plantage d'application : ce que c'est, causes des fermetures inattendues et méthodes de détection

Qu'est-ce qu'un plantage d'application

Plantage — une terminaison inattendue du programme causée par une situation exceptionnelle que le code n'a pas traitée. Dans les systèmes d'exploitation mobiles, un plantage entraîne la fermeture immédiate de l'application et affiche un écran « Application arrêtée » ou retourne à l'écran d'accueil.

Les plantages sont divisés en deux grandes classes. Erreurs traitées — les blocs try/catch capturent l'exception, l'application continue de fonctionner, éventuellement avec une perte de fonctionnalité. Plantages non traités — l'exception remonte jusqu'au niveau du système d'exploitation et le système tue le processus. Le deuxième type est particulièrement dangereux car l'utilisateur ne peut pas sauvegarder ses données.

Un système avec deux millions d'utilisateurs et un taux de plantage de 0,1% perd 2 000 utilisateurs à chaque version. Selon Google Play Console (2024), les applications avec un taux de plantage supérieur à 1,5% sont exclues des recommandations et perdent jusqu'à 30% du trafic organique.

Principales causes de plantages dans les applications mobiles

NullPointerException (NPE) — le roi des plantages en Java/Kotlin. Tentative d'appel d'une méthode sur un objet null. En Kotlin, NPE est moins courant grâce à la sécurité contre les nullités, mais il est toujours possible lors de l'utilisation de l'opérateur !! ou de l'interaction avec du code Java. Google (2024) estime que NPE représente 25% de tous les plantages d'applications Android.

IndexOutOfBoundsException — accès à un élément de liste avec un index inexistant. Cause fréquente : les données arrivent du serveur dans un format inattendu et l'interface tente d'afficher une position qui n'existe pas. Solution — vérifie toujours la taille de la collection avant d'accéder par index.

ANR (Application Not Responding) — un problème spécifique à Android. Le thread de l'interface utilisateur est bloqué pendant plus de 5 secondes. Causes principales : requêtes réseau sur le thread principal, calculs lourds, synchronisation avec la base de données. StrictMode sur Android aide à détecter le blocage du thread de l'interface pendant le développement.

OutOfMemoryError (OOM) — l'application a dépassé la limite de mémoire. Sur les appareils mobiles avec 2–4 Go de RAM, OOM est un problème courant lors du travail avec de grandes images ou des listes infinies sans pagination. Solution — Glide/Coil pour le chargement d'images, LruCache pour la mise en cache, ViewHolder dans RecyclerView.

Exceptions d'exécution et erreurs fatales

Exceptions d'exécution — erreurs que le compilateur ne vérifie pas lors de la compilation. Elles n'apparaissent que lorsque le code s'exécute sur un appareil spécifique avec des données spécifiques. En Java, ce sont RuntimeException et ses sous-classes : NullPointerException, IllegalArgumentException, ArithmeticException.

Erreurs fatales (FATAL) — ce ne sont pas des erreurs d'exécution, mais des défaillances système. Signal 11 (SIGSEGV) — violation de segmentation mémoire dans le code natif. Signal 6 (SIGABRT) — terminaison anormale déclenchée par l'application elle-même via abort(). Ces plantages sont difficiles à diagnostiquer car la stack trace ne montre souvent pas de contexte clair.

Sous iOS, les principales causes sont NSInvalidArgumentException (nil inattendu dans un paramètre) et EXC_BAD_ACCESS (accès à une mémoire libérée). Swift a réduit le nombre de plantages par rapport à Objective-C, mais les erreurs dans l'exécution ObjC et les bibliothèques C entraînent encore des plantages.

Surveillance et collecte de logs de plantages

Firebase Crashlytics — la norme pour les applications mobiles. Il collecte automatiquement les stack traces, ajoute des logs, des identifiants utilisateur et des métadonnées d'appareil. Il regroupe les plantages par signature (classe d'erreur + ligne). Alertes en temps réel — notifications lorsque le taux de plantage dépasse un seuil défini (par exemple, >0,1% par heure).

Sentry — une alternative avec des capacités plus flexibles. Il permet de créer des contextes personnalisés, d'ajouter des breadcrumbs (événements précédents), de configurer le filtrage dans l'application pour exclure les erreurs sans importance. Les source maps pour Kotlin et Swift permettent de voir le code source au lieu de noms obscurcis.

Bonnes pratiques pour les logs : envoie les métadonnées clés avant d'effectuer une opération dangereuse — ainsi le log montrera ce que l'utilisateur faisait avant le plantage. Ajoute des clés personnalisées (numéro de version de l'API, dernier écran, taille des données d'entrée). Cela transforme une stack trace inutile en informations exploitables.

Exemple : configuration de Crashlytics sur Android

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

Stratégies de prévention des plantages

Liaison optionnelle et sécurité contre les nullités — en Kotlin, utilise `?` pour les types nullables, `let` et `?:` pour le traitement sécurisé de null. En Swift — optionals et guard let. Kotlin moderne (2024) a ajouté des annotations Contract : `@ContractsDsl` permet de déclarer qu'une fonction ne retourne pas null, et le compilateur le vérifie.

Gestion des erreurs réseau — chaque requête réseau doit gérer le timeout, les erreurs d'analyse et les échecs du serveur. Retrofit avec le type Result — une classe scellée qui garantit que l'erreur sera traitée. Style sans exception : au lieu de try/catch, utilise Result scellé pour le traitement explicite du succès et de l'erreur.

Feature flags — désactive les fonctionnalités problématiques à distance sans publier une nouvelle version. Si une opération serveur provoque un plantage sur les anciens appareils, le flag la désactive pour ce groupe. Firebase Remote Config permet de modifier le comportement de l'application sans publication dans le magasin.

Déploiement progressif — publie une nouvelle version sur 5% de l'audience et surveille le taux de plantage. Si le taux reste inférieur à l'objectif (généralement <0,1%), étends à 25%, puis 50%, puis 100%. Google Play Console et App Store Connect prennent en charge les déploiements progressifs pour l'arrêt automatique en cas de dépassement du seuil.

Plan d'action lors de la détection d'une erreur

Étape 1 : Classification — détermine la gravité : Critique (plantage chez >1% des utilisateurs), Élevée (0,1–1%), Moyenne (<0,1%). Pour les plantages critiques — réponse immédiate. Pour les autres — processus standard de correction de bugs dans le sprint actuel. Google Play Console classe automatiquement les plantages par nombre d'utilisateurs affectés.

Étape 2 : Analyse de la stack trace — ouvre le log dans Crashlytics, vérifie l'emplacement exact du plantage. Vérifie les clés personnalisées : quel écran, quelles données, version de l'OS. Corrèle avec le dernier déploiement — souvent un plantage est causé par une modification récente du code qui a affecté un scénario d'utilisation inattendu.

Étape 3 : Reproduction — essaie de reproduire le plantage sur un appareil ou un émulateur avec des paramètres similaires. Si cela échoue, vérifie le log de plantage pour des motifs : modèles spécifiques (Samsung A10), versions Android (API < 26), locales. Solution — ajoute une condition défensive qui couvre le scénario.

Étape 4 : Correction et surveillance — publie un correctif prioritaire. Après la publication, assure-toi que le taux de plantage pour ce type tombe à zéro. Écris un test de régression qui couvre le scénario de plantage. Sans test, le même bug peut revenir lors du prochain refactoring.