Application qui plante : trouver la cause du crash et la corriger durablement
Une application qui plante se ferme brutalement, se fige ou redémarre en boucle. Sur mobile, l'utilisateur voit l'application disparaître ou un message « L'application s'est arrêtée » ; sur une application web ou un backend, ce sont des erreurs 500, des délais dépassés ou un service qui redémarre sans cesse dans Docker, Kubernetes ou PM2.
Les causes se regroupent en quelques familles : exceptions non gérées, mémoire épuisée, dépendances ou bibliothèques incompatibles après une mise à jour, changement de comportement d'un système d'exploitation (iOS, Android), données inattendues, et surcharge. Chacune laisse des traces exploitables dans les crash logs, les journaux serveur ou un outil de suivi d'erreurs.
Cette page vous explique où trouver ces traces selon le type d'application, comment reproduire le plantage, quelles sont les causes les plus fréquentes et comment les corriger de façon à ce que le problème ne revienne pas à la prochaine version.
Symptômes typiques
- L'application mobile se ferme dès le lancement ou sur une action précise, parfois seulement sur certains appareils ou versions d'OS.
- Les plantages ont commencé après une mise à jour de l'application, d'iOS, d'Android ou d'une bibliothèque.
- L'application web affiche une page blanche, une erreur 500 ou reste bloquée sur un chargement infini.
- Le backend redémarre en boucle (CrashLoopBackOff dans Kubernetes, restarts PM2 ou Docker en hausse), ou tombe sous charge.
- La consommation mémoire augmente progressivement jusqu'au crash (fuite mémoire).
- Firebase Crashlytics, Sentry, App Store Connect ou la Google Play Console signalent une hausse du taux de plantage.
Causes possibles
Exception non gérée
Valeur nulle inattendue, accès à un tableau hors limites, réponse API dans un format différent de celui prévu, division par zéro : l'erreur remonte jusqu'au processus principal et le tue.
Mémoire épuisée
Images chargées en pleine résolution, listes non recyclées, caches sans limite, fuites dans les abonnements ou les écouteurs d'événements. Sur mobile, le système tue l'application ; côté serveur, c'est l'OOM killer ou une erreur « heap out of memory » de Node ou Java.
Dépendances incompatibles
Bibliothèque mise à jour avec une rupture de compatibilité, versions natives (CocoaPods, Gradle) non alignées avec React Native ou Flutter, mise à jour partielle des paquets.
Mise à jour du système d'exploitation
Nouvelle version d'iOS ou d'Android qui restreint une permission, change une API ou un comportement (arrière-plan, notifications, stockage), ou nouvelle version de Node, Java ou Python côté serveur.
Données ou état inattendus
Un enregistrement mal formé, un cache local corrompu, un utilisateur avec une configuration rare : le plantage ne survient que pour certains comptes et est difficile à reproduire.
Surcharge ou ressource externe défaillante
Pic de trafic, service tiers qui ne répond plus sans délai d'expiration configuré, base de données saturée : les requêtes s'accumulent jusqu'à l'épuisement des ressources.
Erreur de configuration ou de déploiement
Variable d'environnement manquante, clé API expirée, fichier de configuration absent dans l'image Docker, migration de base de données non jouée.
Contrôles à effectuer
- 1
Récupérer les crash logs mobiles
iOS : Xcode > Window > Devices and Simulators > View Device Logs, ou Réglages > Confidentialité > Analyse sur l'appareil ; Console.app en temps réel. Android : adb logcat sur un appareil connecté, ou Android Studio > Logcat, filtrez sur « FATAL EXCEPTION » et le nom du paquet.
- 2
Consulter les outils de suivi
Firebase Crashlytics, Sentry, Bugsnag ou App Store Connect > Crashes et Google Play Console > Android vitals regroupent les plantages par version, appareil et OS, avec la pile d'appels. C'est le point de départ le plus efficace.
- 3
Lire les journaux serveur
docker logs conteneur, kubectl logs pod --previous pour le conteneur qui vient de mourir, pm2 logs, journalctl -u service, ou les journaux de l'application (Laravel, Symfony, Spring Boot). Cherchez la dernière trace avant le redémarrage.
- 4
Vérifier la mémoire
Mobile : Xcode Instruments (Allocations, Leaks) ou Android Studio Profiler pour observer une croissance continue. Serveur : docker stats, kubectl top pod, dmesg -T | grep -i oom, ou les métriques de l'APM pour repérer une fuite ou un pic.
- 5
Reproduire le plantage
Notez la version, l'appareil, l'OS, le compte utilisé et la suite d'actions. Testez sur un appareil physique et sur un émulateur avec la même version d'OS. Sur serveur, rejouez la requête identifiée dans les journaux.
- 6
Contrôler les dépendances et la configuration
Comparez les versions installées avec celles de la dernière version stable (package.json, Podfile.lock, build.gradle, requirements.txt, pom.xml). Vérifiez les variables d'environnement et les secrets dans l'environnement qui plante.
- 7
Examiner les événements Kubernetes ou l'orchestrateur
kubectl describe pod montre la raison du dernier arrêt (OOMKilled, Error, liveness probe failed) et le code de sortie, ce qui oriente immédiatement vers la mémoire, une exception ou un contrôle de santé trop strict.
Solutions
Corriger l'exception à la source
Traiter le cas qui déclenche l'erreur (valeur nulle, format inattendu), valider les données entrantes, ajouter une gestion d'erreur qui informe l'utilisateur sans tuer l'application.
Résoudre les problèmes de mémoire
Redimensionner les images, recycler les vues de listes, limiter les caches, libérer les abonnements et écouteurs, ajuster les limites mémoire des conteneurs et la taille du heap (Node --max-old-space-size, Java -Xmx) en cohérence.
Aligner les dépendances
Revenir à la version stable précédente le temps de corriger, puis mettre à jour de façon coordonnée en lisant les notes de version et en testant sur les OS ciblés.
Adapter l'application au nouvel OS
Mettre à jour les SDK, corriger les permissions et les API dépréciées, tester sur les versions bêta d'iOS et d'Android avant leur sortie publique.
Rendre le backend résilient
Délais d'expiration et nouvelles tentatives sur les appels externes, limitation de débit, files d'attente pour les tâches lourdes, contrôles de santé adaptés et mise à l'échelle automatique.
Déployer avec prudence
Déploiement progressif (pourcentage d'utilisateurs sur les stores, canary ou blue-green côté serveur), surveillance du taux de plantage après chaque version et possibilité de retour arrière immédiat.
Quand contacter un professionnel ?
- Le taux de plantage augmente sur une version publiée et vous devez publier un correctif rapidement.
- Les crash logs mentionnent du code natif, des bibliothèques tierces ou des traces que vous ne savez pas interpréter.
- Le plantage ne se produit qu'en production ou sur certains appareils et vous n'arrivez pas à le reproduire.
- L'application a été développée par un prestataire qui n'est plus disponible et vous n'avez pas de suivi d'erreurs en place.
- Le backend tombe sous charge et vous préparez une échéance à fort trafic.
L'intervention proposée par Agencei
- 1
Collecte des traces
Mise en place ou exploitation de Crashlytics, Sentry ou d'un APM, récupération des crash logs, symbolisation des traces natives (dSYM, mapping ProGuard).
- 2
Reproduction et diagnostic
Reproduction sur appareils physiques et environnements de test, analyse de la pile d'appels, de la mémoire et des dépendances, identification de la cause racine.
- 3
Correction
Correctif ciblé dans le code, mise à jour coordonnée des dépendances, ajustement de la configuration ou de l'infrastructure, tests de non-régression.
- 4
Publication
Livraison sur les stores ou déploiement serveur avec retour arrière possible, suivi du taux de plantage sur les premières heures.
- 5
Renforcement
Tests automatisés sur les scénarios critiques, surveillance continue, alertes, et recommandations pour fiabiliser les prochaines versions.
Questions fréquentes
Où trouver les crash logs d'une application mobile ?
Sur iOS, dans Xcode (Devices and Simulators > View Device Logs), dans Console.app ou dans App Store Connect. Sur Android, avec adb logcat, dans Android Studio (Logcat) ou dans Google Play Console > Android vitals. Un outil comme Crashlytics ou Sentry centralise tout cela.
Pourquoi l'application plante-t-elle seulement chez certains utilisateurs ?
À cause d'une combinaison particulière d'appareil, de version d'OS, de données ou de réglages (langue, permissions, mode économie d'énergie). Les outils de suivi permettent de regrouper les plantages par ces critères et de cibler la reproduction.
Faut-il republier une version corrigée sur les stores ?
Oui pour un correctif dans le code natif ou JavaScript embarqué. Certaines solutions de mise à jour à chaud (CodePush, Expo Updates) permettent de livrer une correction JavaScript sans passer par la validation des stores, dans les limites autorisées.
Qu'est-ce que CrashLoopBackOff ?
C'est l'état d'un pod Kubernetes dont le conteneur plante à chaque démarrage. kubectl logs --previous et kubectl describe pod montrent l'erreur et la raison de l'arrêt (OOMKilled, exception, probe en échec).
Combien de temps pour corriger un plantage ?
Une exception clairement identifiée dans les traces se corrige souvent en quelques heures. Un plantage intermittent lié à la mémoire, à des données rares ou à du code natif peut demander plusieurs jours de reproduction et d'analyse.
Services associés
Correction de bugs
Reproduction, cause racine et correctif testé sur vos applications web, mobiles, API et CMS.
Voir ce serviceApplication mobile
Applications iOS et Android natives ou React Native, du cadrage à la publication sur les stores.
Voir ce serviceSupport informatique
Assistance applicative et serveurs, gestion des incidents et engagements de service clairs.
Voir ce serviceReact Native
Applications iOS et Android à partir d'une base de code unique avec React Native et Expo.
Voir ce serviceAudit technique
Revue indépendante du code, de l'architecture et de l'infrastructure, avec un rapport priorisé.
Voir ce serviceParlez-nous de votre projet
Décrivez votre besoin en quelques lignes : nous revenons vers vous avec une première analyse et les prochaines étapes.