Trois scénarios de développement sont envisageables pour la conception d'applications mobiles. La programmation native propose de faire usage des langages spécifiques à chaque système d'exploitation, tels que l'Objective-C pour iOS, Java sur Android ou C# sur Windows Phone. La multiplication des forfaits de data a également donné naissance aux services web mobiles codés en HTML et pour lesquels le mobinaute devra pointer son navigateur mobile vers une URL spécifique. Il existe enfin les applications hybrides développées majoritairement en HTML mais au sein desquelles la partie native se différenciera selon les plateformes ciblées, par exemple pour accéder à l'appareil photo ou à la puce GPS.
Les applications « full web »
Pour Philippe Prados, chargé de la sécurité au sein du groupe Atos, l'avenir est d'ailleurs réellement tourné vers le web. Il ajoute que le modèle hybride n'aura bientôt plus lieu d'être grâce aux avancées du HTML5. Plusieurs standards sont effectivement en cours de réalisation au W3C pour l'accès aux composants des terminaux mobiles. Par ailleurs, « aujourd'hui il est tout à fait possible de développer une application web pouvant s'exécuter même en mode déconnecté », affirme-t-il.
Le mode « full web » est également soutenu par Romain Pellerin fondateur de la société Arrow Ubidreams qui perçoit une vrai tendance multi-écran pour laquelle un contenu est accessible non seulement sur smartphones mais également sur tablettes, téléviseurs connectés ou même sur des montres. Selon ce dernier, les couts de développement cumulés pour des applications natives seraient exorbitants.
Plusieurs problèmes sont cependant posés. Outre l'absence de visibilité des applications codées en HTML au sein des kiosques de téléchargement, Stevan Le Meur, responsable de projet au sein d'eXo Platform, pointe également le manque de fluidité . « Je pense que les utilisateurs préfèrent les applications natives car celles-ci sont plus réactives » déclare-t-il en ajoutant qu'une vingtaine de secondes devront suffire pour convaincre le mobinaute de conserver l'application. Concrètement, vais-je me contenter d'un site web si le concurrent propose une application native ?
Plusieurs limites peuvent également être observées pour le fonctionnement d'une application web capable de mettre en cache des données pour une consultation en mode déconnecté. En effet, cette méthode ne peut convenir à n'importe quel type d'usage puisque le cache, bien que constitué de 5 ou 6 niveaux, est limité à 5 Mo. Exit donc, les applications de photographie ou de vidéo. Enfin la compatibilité WebKit entre chacune des plateformes ne seraient pas au rendez-vous. Si Apple, Google et Nokia font bien usage du même moteur, leurs implémentations seraient cependant parfois très différentes.
Les applications natives
Une nouvelle question est cependant soulevée : quid des couts de développement ? Puisque les développeurs doivent faire usage des outils proposés par Apple, Google ou Microsoft, une même application demande alors plusieurs compétences.
Romain Pellerin explique qu'au travers de son expérience, la migration vers les technologies web lorsque cela est possible, se traduirait par une économie entre 65 et 85% par rapport à un développement natif. Michael Brard, responsable du développement mobile chez Smile et adepte du modèle hybride avec Phonegap, précise que pour une application déployée sur deux plateformes, les couts de développement sont identiques en web comme en natif ; l'usage des technologies web permettrait une légère baisse pour une application proposée sur au moins trois plateformes. Tous sont cependant d'accord sur un point : en publiant leurs applications payantes au sein de l'App Store ou de Google Play, les éditeurs reversent 30% sur chacune des transactions à Apple et à Google. Visibilité mise à part, une autre stratégie pourrait donc être plus profitable. M. Brard rappelle notamment que le Financial Time a décidé de se retirer de la boutique d'Apple pour concevoir sa liseuse web laquelle recueillerait 19 millions d'utilisateurs. « S'il y a des enjeux de compatibilité, il faut aussi penser au business et parfois c'est plus logique de vendre le contenu sur le web », conclut-il.
Compatibilité, rapidité, maintenance ou encore cout de développement permettront donc à l'éditeur d'orienter ses choix stratégiques. Le débat reste entier d'autant que d'autres facteurs sont à prendre en considération. La question de la sécurité a notamment été abordée. Si la communication entre applications natives, par exemple pour partager du contenu, est certes très importante elle reste potentiellement dangereuse. D'autre part, les connexions de type HTTPS sont jugées trop peu sécurisées pour prévenir d'une intrusion de type man-in-the-middle. Pour l'heure les deux modes de développement semblent donc plutôt complémentaires et liés à certains usages bien distincts. A l'avenir le web mobile pourrait afficher de nouvelles possibilités floutant un peu plus les avantages et les inconvénients des deux types de programmation.
