Intervenants :
Olivier Martin - Directeur du pôle Mobilité
Cédric Pointel, Stéphane Prohaszka, Maxence Walbrou - Experts mobilité
Hervé Lourdin - Directeur d’OCTO Online
Agenda :
Vidéo du petit-déjeuner :
1) Pourquoi un petit-déjeuner sur le sujet ?
Nous avons constaté que les projets mobiles ont évolué chez nos clients. Il y a 4 ans, nous avons assisté à la révolution des Smartphones, une explosion des projets mobiles (un bon moyen pour innover à l’époque) et une volonté d’expérimentation (tous ces devices ont joué le rôle de plateforme de tests).
Depuis, les projets ont largement évolué, ils se sont enrichis avec plus de valeur ajoutée, avec une volonté de s’intégrer au SI et sont devenus multiplateformes.
Nous assistons aujourd'hui à une ère de professionnalisation et les applications mobiles sont devenues une commodité. Tout va plus vite et nous refaisons sur mobile ce que nous avons connu sur le web, en y intégrant une maturité technologique et une industrialisation des process.
Notre industrie est devenue mobile, tous les géants du web ont investi dans le mobile. Les ventes de PC diminuent alors que celles des mobiles augmentent ; des postes se créent en entreprise (Head of Mobile) et les équipes mobiles internes sont de plus en plus nombreuses.
2) Optez pour un écosystème et des outils professionnels :
Les plateformes Android et iOS ont vu leur écosystème s’enrichir avec de nouveaux outils pour adresser de nouveaux besoins.
Dans chaque étape du développement professionnel, il existe des outils pour :
Concevoir votre app : c’est la porte d’entrée de votre app et des outils permettent aujourd’hui d’obtenir un rendu visuel plus proche de la réalité escomptée (ex: ProtoIo ou Fluidui). Les développements vont s’appuyer sur ces préparations et si des erreurs sont identifiées, il faudra affiner les écrans avec les équipes créa et métier. Il existe également des outils pour réunir ces équipes afin d’améliorer, d’affiner, d’ajuster ces écrans directement depuis un appareil, et finalement obtenir le rendu souhaité.
Vous organiser : il s’agit ici d’utiliser des conventions, de structurer vos sources, vos ressources et de hiérarchiser vos données. Il faut planifier des revues de code (vérifier les conventions, que le développeur a bien implémenté la fonctionnalité comme imaginée et s’assurer de la diffusion du savoir au sein des équipes). Il faudra également extraire vos dépendances ; il existe des outils là aussi : maven, CocoaPods qui permettront de gérer les versions de vos librairies.
Documenter : il n’y a jamais assez de documentation. Pourtant, cette dernière vous permet de partager la connaissance. Il est essentiel de commenter afin d'expliquer le POURQUOI et non le COMMENT d'une implémentation. Une fois les commentaires rédigés, vous pouvez utiliser des outils pour générer la documentation comme Javadoc, Doxygen ou encore Appledoc.
Tester : c’est essentiel pour voir si ce qui a été produit se concrétise comme imaginé et reste maintenable et fiable dans le temps ! Quelques outils existent : pour Android : easy mock, Android JUnit, Mockito... ; pour iOS : ocunit, ocmockito, GTM... Ils vous permettront de vous assurer dans le temps qu’aucune régression n'apparaîtra, ce, grâce aux tests. De la même manière, les interfaces peuvent être testées. A minima, les chemins nominaux de votre app. Il vous faudra également vous assurer que votre app fonctionne en conditions réelles (ex : dans le métro lors de changements de réseau,...) vous permettant ainsi de prendre connaissance des problèmes. Il faudra également tester votre app sur tous les écrans, vous assurer des performances de votre terminal et garantir la sécurité de votre app.
Vous améliorer : il vous faudra vous imposer des critères de qualité, vous fixer des seuils et analyser la qualité de votre code (bien souvent aucun test unitaire n’est fait, ce qui n’est pas recommandé ; certaines apps partent en prod parfois avec des warnings encore présents...). Il est également conseillé de vous rendre aux évènements mobiles et de participer à la communauté (ex: stackoverflow, DevCon en mars à Amsterdam...).
Déployer : des outils vous permettent aujourd’hui de faciliter vos déploiements et de bien gérer vos apps et vos beta testeurs. (ex : Appaloosa).
Analyser : les applications vivent. Il faut donc analyser ce qui se passe, identifier les comportements des utilisateurs et être proactif sur les problèmes. Il n’est pas possible de tout tester. Il faut donc accepter l’erreur pour rebondir et prioriser les corrections.
Conclusion : on assiste à une similitude avec ce qui s’est passé pour le web. Tous les outils peuvent être automatisés : usine de développement (Jenkins) et ce qui fonctionne avec nos équipes peut également fonctionner avec nos partenaires : usine de livraison, pour garantir nos pratiques, nos processus et notre fiabilité.
3) Gérez plus vos Apps et moins vos devices !
Quelques constats :
Il fallait donc réagir !
1ere solution : le MDM : Mobile Device Management qui permet la gestion des devices et des utilisateurs.
Ce mode de management permet :
Les enjeux avec une plateforme de MDM sont les suivants :
Puis nous avons assisté à une montée du BYOD : Bring Your Own Device : tout le monde vient avec son device dans l’entreprise.
Le constat a donc changé :
Pour le moment les réponses sont souvent négatives mais il devient de plus en plus difficile de conserver le non, notamment avec la généralisation des tablettes qui envahissent le SI.
Le BYOD a donc secoué les mentalités et la question du contrôle est aujourd’hui posée.
Nous avons assisté à l’apparition du MAM : Mobile Application Management en parallèle au MDM. Il s’agit ici de gérer plutôt les apps et les utilisateurs (et non plus les devices).
L’approche MDM est plutôt une approche PUSH : j’envoie toutes les nouvelles applications sur tous les mobiles de ma flotte alors que l’approche MAM serait plutôt PULL : je mets à dispo pour mes utilisateurs les dernières versions de mes apps et eux, choisissent de les télécharger ou non (m’épargnant ainsi notamment un contrôle sur la flotte de devices).
Les enjeux avec une plateforme de MAM sont les suivants :
Conclusion : Le MAM sera moins compétent sur les devices mais mettra l’accent sur les utilisateurs et les apps.
Ces deux approches sont différentes, mais complémentaires (un mariage des deux peut être intéressant).
4) Faites vivre vos applications :
Constat : une application qui ne satisfait pas ses utilisateurs est une application morte !
Il est essentiel de :
Connaître ses utilisateurs, et cela passe par le fait de :
D’être trouvé par les utilisateurs : pour ce faire, il faut donc faire attention :
De grimper dans les classements ; deux indicateurs semblent être plus importants :
De mesurer l’engagement de l’utilisateur notamment en analysant :
A cela pourront s’ajouter des métriques internes que vous pourrez définir (et qui feront sens pour vous par rapport à vos objectifs).
Il ne faut pas tout mesurer mais choisir ce que l’on veut tester précisément pour ensuite valider par la mesure.
Il est aussi possible et recommander de mettre à contribution les utilisateurs PENDANT le développement de l’app (et pas uniquement post production). Il faudra donc trouver les populations pertinentes pour nos tests et mettre en place des pratiques pour améliorer l’app (feature flipping / A/B testing).
Des outils sont aussi disponibles pour recueillir le feedback utilisateur en direct depuis l’app : appsfire, uservoice for iOS...
Mais les outils ne suffisent pas, il est recommandé d’également se rendre sur le terrain, d’étudier les utilisateurs en conditions réelles (et par itérations successives améliorer l’app en fonction des retours) et de personnaliser l’expérience utilisateur.
D’assurer le meilleur time to market. Pour cela il est recommandé de :
Conclusion : Il vous faudra donc connaitre vos utilisateurs, les intégrer au plus tôt dans le développement produit et leur assurer la plus grande réactivité possible.
A vos applications mobiles donc !