Le développement d’applications mobiles ne s’arrête pas à la livraison du produit. Une fois lancée, votre application demande un certain suivi permettant de la mettre à jour ou même de prévenir d’éventuels bugs qu’elle pourrait rencontrer.

Afin d’éviter un nombre de crashs trop important, certaines étapes sont à prendre en compte pour réduire ces problèmes qui peuvent souvent compliquer l’expérience utilisateur sur laquelle vous avez tant travaillé. Avec un peu de chance, un crash peut être résolu en quelques minutes si vous l’avez identifié auparavant. Cela peut prendre plusieurs jours si le problème est plus important que prévu. Pour remédier à cette difficulté, il est nécessaire de prendre des dispositions adaptées.

‍

Identifier le crash

Un crash est un problème qui intervient pendant l’utilisation d’une application mobile. Il peut venir de plusieurs facteurs :

• Lors de l’utilisation directe
• En background (c’est-à-dire lorsque l’application n’est pas utilisée)
• Problème de gestion d’informations
• Problèmes de versions Android ou iOS
• Résolution du téléphone sur lequel l’utilisateur a rencontré un crash (images trop lourdes par exemple)

En effet, il existe de nombreuses raisons possibles qui peuvent causer l’apparition de crashs sur votre projet d’application mobile.

Les circonstances sont également nombreuses et ne doivent pas être négligées : l’application s’arrêtera instantanément. Le plus important ici est donc d’abord d’identifier le crash, découvrir comment il est apparu dans votre app et le fixer le plus rapidement possible.

Pour ce faire, il existe des outils techniques à relier à l'application mobile comme par exemple Sentry ou Firebase Crashlytics qui vous permettront d’identifier les crashs afin de les résoudre. Dans un premier temps, on utilise ces outils pendant la phase de développement pour éviter à tout prix l’apparition de crashs pendant l’utilisation de l’app, en production. Cette phase est gérée en pré-production. Chaque système d’exploitation mobile détient son propre IDE (Integrated Development Environment ou « environnement de développement » en français). Lorsque l’on développe sur Android, on utilise Android Studio. Apple propose le même type d’outil pour son développement iOS appelé Xcode. Ces principaux outils pour mobile permettent d’obtenir des retours de crashs lorsque l’application est en cours de création.

Lorsqu’un utilisateur rencontre un crash, celui-ci va être immédiatement remonté sur une console Fabric. Ne l’oublions pas, le plus crucial pour vous dans la construction de votre produit, c’est de comprendre les crashs, comprendre le message d’erreur qui vous indique l’apparition d’un crash et profiter de toutes ces informations pour le résoudre.

Parfois, nous pouvons manquer d’informations sur le crash. C’est pourquoi il est crucial de bien obtenir toutes les informations pour effectuer une résolution sans faille.
Parfois, le crash peut être ciblé par type de téléphone.
Certains messages d’erreur sont clairs et permettent une prise en charge du crash plus rapide. Cependant, le message d’erreur peut ne pas être explicite donc on va devoir chercher plus d’informations afin de résoudre le problème.

Il peut être parfois difficile d’identifier un crash sans pour autant disposer du téléphone qui a rencontré ce crash. Pour remédier à ce problème, vous pouvez bénéficier d’un intermédiaire comme Fabric pour élucider le mystère. C’est d’ailleurs l’un des outils que nous utilisons le plus chez Kreactive.

Anticiper les crashs 

Les raisons de l’apparition de crashs sur votre application mobile peuvent provenir de plusieurs facteurs : mauvaise manipulation de la gestion de l’app, manque de tests, présence d’éléments non compatibles etc… Nous ne cesserons de le dire : testez et re-testez votre produit autant qu’il le faudra !

Lors de l’étape de développement, les premiers tests de la part du développeur en charge du projet sont essentiels pour assurer la stabilité de l’application. Mettre en production un produit qui n’a pas suffisamment été testé apporte un risque supplémentaire d’apparition de crash. Dans cette situation, il est crucial d’anticiper et d’être proactif quant à la fréquence des tests effectués. Bien évidemment, moins le taux de crash est important, plus la stabilité de l’application mobile sera maintenue.

Les mots d’ordre sont les suivants : regarder, tester, fixer tout ce qu’il est possible de fixer.

Afin de réagir de manière proactive sur la résolution des problèmes, il faut prendre en compte le fait que le problème peut venir d’un développement interne comme des différents acteurs externes : publicités (tester les SDK car la quantité de SDK que vous utilisez peut impacter directement la stabilité de l’app), API (Application Programming Interface), montée de version des systèmes d’exploitation (iOS 13 par exemple) qui crée des différents entre les versions du téléphone et de l’application mobile que vous développez.

Pour rappel, un SDK - Software Development Kit (Kit de développement en français) - est un ensemble d’outils d’aide à la programmation pour concevoir des applications mobiles pour un terminal et/ou un système d’exploitation spécifique.

D’un point de vue organisationnel, il est décisif de comprendre d’où viennent les problèmes afin d’attribuer les tâches de résolution aux bonnes personnes, aux bons développeurs.

En amont des mises à jour des systèmes d’exploitation, faire des tests de non-régression est une action à ne pas oublier. Il faut être sûr que tout ce qui existait avant la mise à jour n’impacte pas le futur de l’application. 

Chez Kreactive, la clé, c’est la régularité. Tous les deux jours, nos équipes de développeurs inspectent la présence de crashs. Cette ponctualité nous vaut d’ailleurs un taux de crash-free user et crash-free session au-dessus des 99%. 

Problème interne à l’équipe de développement mobile

S’il manque quelque chose dans le code, on l’ajoute, on teste et on remet en production. Grâce à l’outil Fabric, vous serez en mesure de voir d’où vient le problème depuis la ligne de code remontée.
Chaque crash est unique, ce qui veut dire qu’un crash peut être résolu rapidement ou prendre plusieurs jours si le problème est plus important.
Les problèmes comme la fuite mémoire (liée aux images) vont causer un crash immédiat de l’app car les images prennent trop de place. Regarder la vue complète, comprendre les étapes et évaluer le crash sont les étapes à suivre dans ce genre de cas.

Problème externe à l’équipe de développement mobile

Si le problème vient d’un acteur externe, il est urgent de déterminer la source du crash pour pouvoir l’expliquer (SDK, web service par exemple) et le prouver : conserver ses logs, retester l’app en pré-production, prendre des vidéos, screenshots, récupérer les informations qu’on peut transmettre à l’acteur externe. C’est ici qu’entre en jeu un fort travail de communication entre tous les acteurs de la production.

Un crash peut causer une perte massive d’utilisateurs (comme nous l’avons expliqué dans notre article) car certains crashs sont trop impactants pour une utilisation sans faille. L’architecture impacte également le taux de crash. C’est pourquoi le travail d’équipe est une notion essentielle chez Kreactive. Nous mettons très régulièrement en place des Pull request : communication entre développeurs pour bénéficier d’un regard externe.

En résumé, il existe de nombreux moyens de faire face à un taux de crash trop important. Comme nous l’avons expliqué dans notre article intitulé Les raisons pour lesquelles les utilisateurs désinstallent les applications mobiles, les crashs peuvent provoquer une immense frustration de la part des utilisateurs. Chez Kreactive, nous avons affaire à ce genre de problème quotidiennement. C’est pourquoi nos développeurs se mettent à votre disposition pour vous accompagner dans le développement de votre application mobile.

Comment dépasser 99,5% de crash-free users ?

Nous vous dévoilons notre méthode gratuitement dans cette vidéo.