Le taux sans plantage est la métrique principale de stabilité des applications : le pourcentage de sessions (ou d'utilisateurs) n'ayant PAS subi de plantage. Les plantages sont des événements UX catastrophiques — l'application se ferme brutalement, l'utilisateur perd son état et la confiance dans l'application s'érode. Les applications avec un taux de plantage élevé perdent des utilisateurs au profit de désinstallations plus vite que l'acquisition peut les remplacer, indépendamment de la qualité du reste du produit.
Deux variantes
- Sessions sans plantage : pourcentage de toutes les sessions qui se sont terminées sans plantage. Utilisé pour le reporting de stabilité agrégé. Métrique plancher — si une seule session plante pour un utilisateur, il a « subi un plantage » même si ses autres sessions se passent bien.
- Utilisateurs sans plantage : pourcentage d'utilisateurs n'ayant subi AUCUN plantage dans une fenêtre définie (généralement les 7 ou 30 derniers jours). Seuil plus exigeant — dès qu'un utilisateur subit un plantage, il est « affecté par un plantage » jusqu'à ce que la fenêtre se réinitialise.
Suivez les deux ; ils racontent des histoires différentes. Les sessions sans plantage sont la métrique opérationnelle quotidienne ; les utilisateurs sans plantage sont la métrique d'expérience utilisateur.
Benchmarks modernes
- Applications grand public : 99,5 %+ de taux sans plantage est le seuil opérationnel de référence. Les applications de premier rang atteignent 99,9 %+.
- Banque / santé / applications critiques : minimum 99,9 %+ ; les utilisateurs ont zéro tolérance pour l'instabilité dans les flux de travail critiques.
- Jeux hyper-casual : 98-99 % est plus courant (itération rapide, moins de QA). Compromis acceptable compte tenu de la forme du produit à courtes sessions.
- En dessous de 99 % : problème sérieux. Investiguer immédiatement, livrer des correctifs urgents quotidiennement jusqu'à résolution.
- En dessous de 97 % : existentiel. Suspendre les nouvelles fonctionnalités, concentrer l'ingénierie sur la stabilité jusqu'au rétablissement.
Un taux de plantage de 1 % n'est pas « juste 1 % » — c'est catastrophique. Si 1 session sur 100 plante et que l'utilisateur moyen fait 5 sessions par semaine, environ 5 % des utilisateurs subiront un plantage dans n'importe quelle semaine donnée, 20 %+ sur un mois. Chaque événement de plantage augmente significativement la probabilité de désinstallation — impact typique : un taux de plantage de 1 % (99 % sans plantage) fait chuter la rétention D7 de 10-20 % et augmente le taux de désinstallation D30 de 15-30 % par rapport à un seuil de 99,5 %+. Petit chiffre absolu, énorme impact sur le modèle économique.
Outils de suivi des plantages
- Firebase Crashlytics — suivi des plantages gratuit de Google. Le leader du marché en adoption (estimé à ~70 % des applications Android ; part substantielle sur iOS). Symbolisation robuste des stack traces, alertes en temps réel, intégration BigQuery pour une analyse plus approfondie.
- Sentry — solide surveillance cross-platform des plantages et des erreurs avec une portée plus large (pas seulement les plantages, aussi les erreurs non fatales). Populaire auprès des équipes à orientation technique.
- Bugsnag (désormais SmartBear) — fonctionnellement comparable à Sentry, courant en entreprise.
- Apple App Store Connect / Google Play Console — tableaux de bord natifs des stores. À utiliser en vérification croisée ; ne pas s'y fier exclusivement (détail limité des stack traces, agrégation plus lente).
Discipline de processus : chaque publication devrait comporter un critère documenté de taux sans plantage avant un déploiement large. Les déploiements progressifs (déploiement par étapes Google Play, publication progressive App Store) permettent de détecter une régression de stabilité sur 1-5 % des utilisateurs avant qu'elle n'affecte 100 %. Définissez un seuil clair (par ex. « suspendre le déploiement si le taux sans plantage descend en dessous de 99,3 % sur les premiers 1 % des utilisateurs ») et respectez-le.