Mesurer la performance des applications mobiles : monitoring synthétique ou real user monitoring ?

Posted on by Olivier PHILIPPOT
Reading Time: 3 minutes

La « digitalisation » des entreprises et particulièrement l’offre de plus en plus importante d’applications numériques, rendent le critère de qualité des applications mobiles de plus en plus nécessaire. La performance est dans ce cadre un critère de contrôle obligatoire. Sans cela, les risques sont nombreux pour les concepteurs d’applications : désinstallations, taux d’attrition en hausse, échec de projet, chiffre d’affaires en baisse…

Mais le fait de tester la performance des applications mobiles n’est pas aussi simple que de tester une application classique comme en avait l’habitude les équipes des DSI. En effet de plus en plus, les applications mobiles sont d’une part exécutées dans un environnement contraint (en termes de batterie, ressources…) et d’autre part, elles intègrent des services tiers qui sont complexes à maîtriser. Au final, avec des serveurs répondant en moins de 200ms, on arrive très souvent à des temps de réponses des applications malheureusement supérieurs à 3s.

Pour répondre à ce problème, il est important de bien comprendre les méthodes utilisées par les outils de ce marché en constante évolution.

Outils de monitoring vs outils de développement

Tester la performance de son application reste possible et accessible, surtout avec les SDK et les IDE de développement (Xcode, Android Studio…). Pour aller plus loin, de nombreuses solutions sont disponibles en open source. Cependant, cette approche nécessite de lancer des tests manuels sur son téléphone.

Avantages :

  • Mesure de la performance pendant le développement
  • Analyse détaillée possible dès détection d’un problème

Inconvénients :

  • Mesure assez aléatoire et pas forcément reproductible
  • Nécessite un smartphone de test à disposition

Les outils de monitoring permettent d’industrialiser la démarche de mesure de la performance en se basant sur des agents qui prennent la place du développeur.

Outils de monitoring synthétique vs outil de monitoring en usage réel (Real User Monitoring)

Les outils de monitoring synthétique sont des outils qui testent la performance des solutions dans des cas d’usages proches de ceux d’un utilisateur. Pour cela, des agents extérieurs stimulent l’application dans un environnement soit simulé soit réel (Emulateurs ou fermes de devices). L’avantage de cette solution est de surveiller la performance en continu. Cette approche s’applique même avant la mise en production de la solution ou avant que les utilisateurs finaux soient présents.

Avantages :

  • Remontée de la performance avant la mise en production
  • Mesure en continue pour l’identification des problèmes

Inconvénients :

  • Simulation pas nécessairement représentative de l’usage réel de l’application par les utilisateurs finaux
  • Nécessité d’utiliser des devices en continu pour faire tourner le monitoring

Les outils RUM remontent la performance réelle des utilisateurs. Cela nécessite l’intégration d’un agent dans l’application. Cette intégration permet la remontée d’autres métriques : parcours utilisateur, usages de l’application…

Avantage :

  • Vision réelle de la performance des applications

Inconvénients :

  • Impact de l’agent sur la performance de l’application
  • Détection trop tardive des problèmes
  • Trop d’informations lors de l’analyse des problèmes

Tests techniques vs tests fonctionnels pour les outils de monitoring

La simulation de l’application dans les outils de monitoring nécessite des tests automatiques. La solution la plus simple à mettre en œuvre repose sur les tests techniques : Lancement de l’application, ouverture de pages…

Avantages :

  • Mise en œuvre immédiate
  • Tests standards permettent d’identifier facilement des problèmes ou de se comparer avec des applications concurrentes

Inconvénient :

  • Tests pas forcément adaptés aux spécificités et au fonctionnel de l’application
  • Certains outils proposent d’effectuer des tests fonctionnels pour suivre la consommation. Le parcours utilisateur est alors simulé ou réellement effectué. Cela nécessite de scripter les actions de l’utilisateur. Généralement les outils se basent sur des technologies de script standardisés.

Avantages :

  • Simulation proche du parcours réel de l’utilisateur
  • Mutualisation des tests développés pour d’autres usages (tests fonctionnels par exemple)

Inconvénient :

  • Nécessité de développer les tests automatiques au préalable

NB : Des outils permettent de simuler une suite de requête vers les serveurs. Cette pratique issue des technologies serveurs (par exemple Jmeter) permet de tester plus la partie serveur mais est peu adaptée à la mobilité. En effet, elle ne permet pas de prendre en compte la complexité des plateformes mobiles.

Environnement émulé ou physique

Les environnements émulés (ou virtuels) sont identiques aux émulateurs de développement.

Avantage :

  • Mise en place assez rapide

Inconvénient :

  • Performance ne correspondant pas à des devices réels

Les environnements réels sont des téléphones mis à disposition par les outils de monitoring.

Avantage :

  • Performance identique aux devices réels

Inconvénients :

  • Coûts plus importants
  • Difficulté d’être représentatif de l’ensemble des devices des utilisateurs.

Les conseils des experts GREENSPECTOR

La clé est de détecter au plus tôt les problèmes de performance avant qu’ils n’affectent vos utilisateurs finaux. Il est donc nécessaire d’utiliser des outils de monitoring synthétique. Les outils de développement permettront de compléter l’analyse des problèmes de performance. Afin d’être représentatif de l’usage final de l’application, il sera nécessaire de mettre en place la bonne stratégie : tests fonctionnels à minima, exécution sur un échantillon représentatif de devices réels d’utilisateurs, simulation de différentes conditions de communication… Les outils RUM permettront de confirmer et compléter les hypothèses.

Les utilisateurs de GREENSPECTOR ont la possibilité d’appliquer cette stratégie via différents modules :