Deux familles de solutions existent pour diffuser des services sur les "smartphones" :
- une application développée spécifiquement pour un type de téléphone : iPhone, Android, Nokia, BlackBerry, Windows Mobile, etc... Cette approche correspond aux "Native apps" qui sont installées sur le téléphone, soit par le constructeurs, soit par l'utilisateur via l'iStore pour Apple par exemple.
- un site internet adapté à une utilisation sur un navigateur mobile. Cette approche correspond aux "web apps".
Voici quelques exemples dans les transports publics sont (sans viser l'exhaustivité) : Ma RATP dans la poche existe en web app ici, alors que RATP Premium (et lite) est une Native App disponible sur l'iStore ici. Transilien.mobi est une web app comme http://www.transpole.mobi mais le compagnon de voyages-sncf.com est une native app pour Android et en son temps, Mobiville était une Native App Windows Mobile...
Quelle solution privilégier pour l'information des voyageurs ? Le web regorge d'excellents articles analysant les forces et faiblesses des deux approches.
Quelle solution privilégier pour l'information des voyageurs ? Le web regorge d'excellents articles analysant les forces et faiblesses des deux approches.
Pour faire très simple, les Native Apps permettent de tirer parti de toutes les fonctionnalités du téléphone. Elles permettent de gérer les capteurs et périphériques du téléphone : GPS, accéléromètre, capteur de luminosité, appareil photo, bluetooth...
En revanche, la Native App est dépendante du système d'exploitation du téléphone. Une application iPhone ne fonctionne pas sur Android, ni sur Nokia, ni sur BlackBerry... Au sein d'une même marque de terminaux, des différences de version de l'OS peuvent persister. Mon HTC Hero est, par exemple, toujours en version 1.5 d'Android. Or la version "courante" est la 2.1. Je n'ai donc pas accès aux applications les plus récentes et cela est extrêmement frustrant ! On parle de fragmentation des OS pour décrire ce phénomène. Pour les développeurs d'application, cette fragmentation des OS, si elle n'a rien à voir avec une quelconque fracture, reste un véritable casse tête et une source de coûts.
Les Web Apps sont plus simples, mais plus universelles. Un seul site correctement optimisé permet une utilisation sur un grand nombre de mobiles. Par ailleurs, les navigateurs s'améliorent et les navigateurs de nouvelle génération intègrent des fonctions jusqu'ici réservées aux Native Apps. C'est notamment le cas de la localisation qui est maintenant accessible directement dans le navigateur (par exemple sous Chrome, ou Mozilla).
En ce qui concerne l'information des voyageurs nous nous trouvons, en général, dans le contexte suivant :
- la cible est généraliste, on vise un public large sans se limiter à un type de terminal particulier, ni à des utilisateurs technophiles (même si on s'adresse, quand même, à des possesseurs de smartphones),
- le modèle économique (l'information voyageurs est en général diffusée gratuitement), fait que la pression sur les coûts de l'application est importante. On cherchera, donc, à en limiter le nombre de versions.
- les fonctions doivent rester "simples" et le mode d'emploi doit être immédiat même pour un mobinaute débutant...
Dans ce contexte, une simple WebApp me semble parfaitement indiquée.
Les périphériques NFC qui se généraliseront (?) sur nos mobiles; nécessiteront, au moins initialement ,une gestion via une Native App. Les Native Apps resteront, donc, probablement indispensables pour les applications de billettique dans les transports publics.
Les périphériques NFC qui se généraliseront (?) sur nos mobiles; nécessiteront, au moins initialement ,une gestion via une Native App. Les Native Apps resteront, donc, probablement indispensables pour les applications de billettique dans les transports publics.
Bref, la mise en place d'une web app pour l'information semble une nécessité. Rien n'empêche les plus perfectionnistes de réaliser, ensuite, une Native App optimisée pour tel ou tel terminal et telle ou telle fonctions complémentaires.