Pourquoi se focaliser que la performance utilisateur ? Le sujet est bien maîtrisé au niveau des temps serveur mais est difficile à suivre du point de vue utilisateur à cause de l’impact des réseaux et de leurs fluctuations. C’est pourquoi, nous avons mis au point un protocole qui permet de tester le comportement d’une application mobile dans différentes conditions réseaux en modulant le débit, la latence et le taux d’erreur. Le but de cette présentation est d’évoquer le processus de mise au point du protocole à sa mise en œuvre, d’abord manuelle puis automatisée, schéma technique à l’appui. Comment ce processus imaginé pour iPhone est finalement rendu commun pour toutes les applications mobiles tant applicatives qu’en web mobile ?

1. COMMENT VÉRIFIER LES PERFORMANCES
RESSENTIES PAR L’UTILISATEUR D’UNE
APPLICATION MOBILE
JANV 2015
1Date • Titre de la présentation
Cédric GAUTIER

2. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
SOMMAIRE
• Contexte
• Objectifs
• Problématique
• Démarche
• Mise en œuvre ( Réalisé et à venir)
• Résultats
• Bénéfices

3. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Suite à la refonte de l’application PagesJaunes pour iPhone, nous avons constaté des problèmes
d’accès à nos services en interne et en externe par les stores
La supervision serveur n’ayant rien montré de significatif, nous avons décidé de mener un audit
de notre application iPhone sur la performance applicative sur :
- Différents réseaux (2G/3G/Wifi)
- Différentes combinaisons mobiles (terminal/OS/browser)
La problématique de la performance utilisateur étant globale, il faut étendre cet audit à toutes les
applications mobiles.
Contexte

4. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Objectifs
• Réaliser un benchmark comparatif entre la concurrence, notre application
refondue et l’ancienne version iPhone
• KPI : Mettre au point des KPI reproductibles sur nos futures versions
• Mesurer les performances (côté terminal) des nouvelles versions iPhone
• Comparer ces mesures avec les anciennes versions iPhone
Identification d’amélioration ou de dégradation de performance
• Porter ce protocole de KPI sur les autres plateformes mobiles
• Automatiser ces mesures en Intégration Continue
• Prendre en compte ces mesures automatisées dans le socle de
Continuous Delivery

5. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Résultats
Exemples de graphiques comparatifs de données mesurées :
-Sur une même version
-Sur une la vie d’un produit
-
5.00
10.00
15.00
20.00
25.00
PJ5.6.0.7
PJ6.2
PJ6.3
PJ6.4.5
PJ6.5
PJ6.6
PJ6.7
PJ6.8
nov-
13
mars-
14
mai-
14
juin-
14
Aout
2014
sept-
14
nov-
14
déc-
14
UEM iPhone EDGE
T0-Fin d’affichage du splash
screen
T1-Fin d’affichage complet
de la HP
T3-Affichage du premier
bloc de la LR
T7-Début d’affichage de la
FD
Seuil
0
1
2
3
4
5
6
7
iPhone 5S - iOS 7.1
3G
Wifi
Edge Deg
iPhone v6.7 - T3
iPhone 4s – iOS 6

6. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Résultats
Exemples de graphiques comparatifs de données prises en production :
- Moyenne sur iPhone
- Comparaison entre 2 iPhone

7. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Résultats
Exemples de graphiques de production présentant la répartition du temps de réponse

8. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Mise en oeuvre - Limitations
•Limites du protocole de mesure actuel
• Mesures manuelles
 Incertitude des mesures de temps souvent inférieurs à 1 seconde
 Coût du test important
 techno uniquement sur MacOS
• Temps serveur : Les temps mesurés peuvent être impactés par des temps serveurs
 Corréler les temps obtenus à une mesure serveur (Ex : recherche, Carto)
• Temps Carto : Dépendance forte de services externes.
 Comment dissocier le temps interne du temps externe? Bouchons?
 Déprioristaion de l’indicateur en terme d’alerting
• Nouveaux OS et terminaux :
 Quand et comment intégrer une nouvelle combinatoire dans les mesures?
 Double run, impact sur l’indicateur
• Fréquence : 1 fois par version
Fréquence faible : mise en place de la chaine d’intégration continue

9. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Bénéfices
Eviter de mettre en production plusieurs défauts importants fonctionnels et techniques
•Sur iPhone,
• Mise en évidence d’un timeout de 30sec en Edge Dégradé
• Chantier d’optimisation de l’application (lancement, Autocomplétion, gestion des vues)
•Sur le Responsive Design,
• Adaptation du protocole pour mesurer avec et sans cache
• optimisation de la mise en cache
• Mise en évidence des difficultés de chargement des pages sur des navigateurs natifs
• Détection de régression sur le chargement de la Homepage
•Sur Android,
• report des corrections détectées sur iPhone
• Pas d’alerte à ce jour.

10. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Plus values
• Nouveau Protocole de mesure
• Mesures manuelles
 Adaptation du protocole selon la stratégie (réseau dégradé ou pas? Wifi uniquement pour
les tablettes?) et la charge
 Mesure en avance de phase, avant la supervision, reproductible
• Conception générique :
 Couvrir les besoins de benchmark
 protocole de mesures compatibles sur toutes nos plateformes (iPhone/Android/RWD)
• Technique :
 Interconnexion avec notre chaîne d’Intégration Continue
 Automatisation
 Définition et réalisation d’un protocole de mesure générique
• Confiance
 L’équipe Collaborative donne de la visibilité sur la qualité de son livrable avant son
déploiement
 Plus de confiance générale dans nos applis (Marketing et Technique)

11. PERFORMANCES RESSENTIES PAR
L’UTILISATEUR D’UNE APPLICATION MOBILE
Conclusion
• Le protocole est intégré à chaque release de produit mobile
• Prise en compte de ces besoins pour le passage du site fixe en Responsive mobile
• la Performance utilisateur est maintenant au cœur de nos développements

12. MERCI À TOUS
ET MAINTENANT À VOS QUESTIONS…