Toutes les études convergent : les terminaux mobiles (smartphones et tablettes) sont en passe de devenir les principaux points d’accès à Internet. Proposer des applications mobiles devient un enjeu stratégique pour les entreprises. Encore faut-il adopter la bonne stratégie... Par Rémy Dujardin, Responsable de l’offre Test, et Florian Lorence, Architecte technique JEE et mobile, Groupe Hardis.

Quel “type” d’application mobile proposer ? Application native propre à chaque système d’exploitation (OS) et téléchargeable depuis un app store ? Site web mobile (ou encore web app) accessible depuis n’importe quel navigateur Internet ? Ou application hybride, développée comme une application web mais rendue disponible via un app store ? Aucune solution n’est a priori meilleure qu’une autre, chacune présentant des avantages et des inconvénients. En matière de mobilité, comme dans tout projet informatique, le choix dépend du contexte, des objectifs, des contraintes business, fonctionnelles, techniques et budgétaires. 6 points-clés pour faire le bon choix.

1. Définir les fonctionnalités attendues et les usages

La première question à se poser concerne les usages et les besoins. Une application native permet de tirer pleinement parti des fonctions du terminal (agenda, contacts, photo, vidéo, stockage, géolocalisation...), pour proposer une expérience utilisateur plus riche qu’un site web mobile. Toutefois, l’interface de l’application native est conçue pour un support spécifique. A l’inverse, avec un site web conçu en “Responsive Web Design", l’affichage pourra être optimisé pour s'adapter en fonction de la taille de l’écran sur lequel il est consulté, ce qui évite à l’entreprise de créer (et de maintenir) plusieurs interfaces pour chaque terminal (smartphone, tablette, PC, TV connectée…). L’application hybride offre, de son côté, un accès presque complet aux fonctions natives du terminal, tout en proposant une interface adaptive.

En outre, l’application native ou hybride peut éventuellement fonctionner sans connexion internet, contrairement au site web mobile. Une nuance qui a son importance selon le contexte d’utilisation de l’application (à la maison, au bureau, dans les transports en commun…) et la qualité de la connexion.

2. Adapter son offre au parc mobile adressé

Le parc mobile des utilisateurs est-il homogène ? Comme, par exemple dans une entreprise dont les salariés sont équipés du même type de mobile, ou au moins du même OS. Ou au contraire, l'application est-elle destinée au grand public, qui par nature dispose d'un parc hétérogène ?

Une application native n’est compatible qu’avec le système d’exploitation pour laquelle elle a été conçue : iOS, Android, Windows Phone, Blackberry, Symbian, etc. Les coûts de développement sont donc directement liés au nombre de plateformes cibles. A l'opposé, une web app ou une application hybride n'est pas dépendante de l’OS, et s'adaptera à la plupart des terminaux.

3. Évaluer les compétences techniques nécessaires

Pour les sites web mobiles ou les applications hybrides, la maitrise des langages de programmation web classiques (HTML5, CSS, JavaScript) suffit. Les applications natives nécessitent des compétences plus spécifiques, et propres à chaque OS : Objective-C pour iOS, Java et XML pour Android, C/C++ ou Java pour Blackberry OS et C#/VB.Net ou C++ pour Windows Phone… Et aucun élément ne peut être réutilisé d’un OS à l’autre.

Avant de se lancer, il est donc indispensable de se poser les questions suivantes : quelles compétences sont nécessaires en phase de développement, de test, de maintenance corrective ou évolutive ? Quelles sont celles qui seront sollicitées en externe ? Et pour quels coûts et sous quels délais ? Car les réponses ont des conséquences qui sont loin d'être anodines…

4. Anticiper les tests adéquats pour chaque type d’applications

Quelle que soit l’option choisie, les tests vont permettre de vérifier la qualité de l’affichage, l’intuitivité de la navigation, la cinématique des écrans, le fonctionnement attendu des services, etc. Mais également, le bon comportement de l’application quelle que soit la qualité de la connexion (Internet haut débit, 3G, Edge…) : encore plus que pour d’autres applications, le nombre et le poids des requêtes (et donc des échanges avec le reste du système d’information) doit être limité au maximum.

Pour les applications natives, chaque éditeur d’OS fournit un émulateur pour simuler ces tests sans avoir à installer les applications sur un terminal. Mais les tests en situation réelle restent malgré tout indispensables, pour vérifier le comportement de l’application. Des vérifications qui nécessitent des compétences techniques spécifiques, et qui peuvent s’avérer longues pour des parcs de terminaux physiques hétérogènes.

De leur côté, les applications web et hybrides doivent être testées pour chaque navigateur, résolution et taille d’écran, à l’instar de n’importe quel site web. Si des automates existent, ils ne remplacent pas complètement le test en situation réelle. Ainsi, contrairement à ce que l’on pourrait penser, si le développement et les tests d’un site web mobile ne multiplient pas les coûts par n systèmes d’exploitation comme les applications natives, ils n’en sont pas pour autant n fois moins coûteux…

5. Penser au déploiement et à ses incidences sur le time-to-market

Le site web mobile est, sans aucun doute, la solution qui permet de mettre l’application à la disposition de sa cible le plus rapidement possible. En effet, il est accessible immédiatement depuis une URL classique. A l’inverse, la publication des applications natives ou hybrides est soumise à une phase de validation auprès des app store publics (Apple Store, Google Play, Blackberry AppWorld, Windows Phone Marketplace…). Cette phase de soumission peut durer plusieurs semaines, ce qui retarde d’autant leur disponibilité auprès des utilisateurs. Il est en outre indispensable de prévoir la bascule automatique de l’environnement de tests vers l’environnement de production, sans relivraison de l’application native ou hybride, sous peine de devoir relancer le processus de validation et donc le délai de mise à disposition de l’application auprès des utilisateurs finaux.

A noter, le cas particulier des applications internes à l’entreprise. Elles peuvent être déployées dans des stores privés, et sont ainsi affranchies du cycle de validation. Et grâce aux outils de Mobile Device Management (MDM), qui permettent de gérer et mettre à jour les flottes de terminaux mobiles, leur déploiement est accéléré… et contrôlé.

6. Anticiper les mises à jour pour optimiser la satisfaction des utilisateurs

Quelle que soit la solution retenue, maintenance et mises à jour sont sensiblement soumises aux mêmes contraintes que le développement. Une simple mise à jour du serveur de production pour les sites web mobiles. Un nouveau cycle de soumission et de validation par le store pour les applications natives et hybrides, avec les mêmes contraintes d’environnement de test à gérer. Dans le premier cas, la mise à jour est automatique et transparente pour l’utilisateur, qui a toujours accès à la version la plus récente du site web mobile. Dans le second cas, il est nécessaire de prévoir un mécanisme pour que l’utilisateur soit informé qu’une mise à jour est disponible, afin qu’il puisse l’installer. Les stores permettent, en revanche, de récolter plus facilement les retours des utilisateurs – via des systèmes de notation et de commentaires – qui en font un précieux outil d’amélioration continue des applications natives et hybrides.

Rémy Dujardin, Responsable de l’offre Test, et Florian Lorence, Architecte technique JEE et mobile, Groupe Hardis