Yvan Gravier (Neotilus) : "Une application mobile qui utilise des serveurs de contenus externes pose des problèmes de SLA"

Dans un contexte de segmentation de plus en plus fine des applications mobiles, les interfaces riches jouent un rôle moteur dans leur adoption. Code barres 2D, puces NFC et géolocalisation se révèlent être de puissants catalyseurs pour l'innovation.

En quoi un projet d'applicatif mobile diffère-t-il vraiment d'un autre projet IT traditionnel ?
Un projet mobile doit tenir compte des particularité de la plate-forme d'utilisation et du mode de connexion : la capacité de traitement de la machine (traitement graphique, parsing XML...), la bande passante du réseau (Wifi, 3G, GPRS, Tetra...), et le mode de rendu browsing ou client riche.

Quels sont les projets applicatifs mobiles les plus répandus ?
La première génération de services mobile a été lancée par le Wap pour le grand public, et les applications métiers sur PDA pour les professionnels (logistique, asset management...). Aujourd'hui, les applications sont plus segmentées : Wap, métiers , jeux java, événementiel sportif, TV mobile, ce qui les rend paradoxalement moins visibles

Comment bien mener son projet applicatif mobile tant d'un point de vue technologique que fonctionnel ?
La segmentation des plates formes et des players mobiles rend toute approche technologique très coûteuse ou exclusive (un site IPhone, un jeu Java...). Une approche marketing et fonctionnelle est donc souhaitable afin de décliner le projet sur plusieurs plates-formes en fonction des cibles.

Par exemple une version d'appel Wap, une version grand public Java J2ME, et une version VIP IPhone ou Bluestreak, le tout piloté par l'investissement. Cette approche nécessite une conception en amont qui la rend le plus agnostique possible de la plate forme.

Une application mobile doit être correctement découpée : couche connecteur, couche traitement et couche de présentation. L'ergonomie de l'application dépendra d'ailleurs autant de la rapidité de traitement que de la qualité de la navigation. Une même application pourra donc être rendue sur différents moteurs graphiques avec succès, à condition d'adapter la couche graphique associée et de mutualiser la conception des autres couches. Il s'agit donc de mettre en place une méthodologie de conception et de développement particulières.

Toutes les applications doivent-elles être pensées en mode connecté et déconnecté ?
Les deux si possible mon capitaine, c'est encore une fois dépendant de la technologie de rendu utilisée sur le mobile: le mode Wap nécessite une connexion, une mode riche peu être partiellement fonctionnel même déconnecté (jeux java, cartographie embarquée...).

Je préconise donc la même approche que précédemment: pilotage par le fonctionnel et l'investissement sachant que la technologie suivra.

Les applications riches sur mobiles, est-ce plutôt un rêve qui devient réalité ou une utopie ? Quels sont les atouts du RIA et des interfaces riches pour les applications mobiles ?
Une interface riche peut apporter deux choses: un graphisme et/ou des transitions riches auquel cas elle peut être réalisée en mode browsing type Web 2.0 (Webkit, Opera browser, Access browser...).

Elle peut également signifier une interaction avec son environnement local (code barre, GPS, Tag NFC, écran ou Set Top Box via Bluetooth...) auquel cas, cela implique le recours à une technologies embarquée (Flash, Java, .Net, code natif...). Encore une fois, le fonctionnel et la cible l'emportent et doivent être le point de départ de votre projet.

Que pensez vous de l'approche MDA/MDD en termes de méthodologie de conception ? Utilisez vous des approches comme celle-ci pour vos applicatifs mobiles ?
La segmentation des plate formes restreint l'industrialisation du code via des approche MDA /MDD à des éditeurs spécialisés (exemple: un éditeur de jeux mobiles Java). Pour un grand compte, ou un intégrateur tel que Neotilus, une telle approche est trop conceptuelle.

Une démarche plus pragmatique consiste encore une fois à piloter son projet par le couple fonctionnalité/cible et de concevoir une architecture dénominateur commun entre les technologies mobiles (Wap/web, Java, Flash, natif) sans rentrer dans les méthodes conceptuelles d'automatisation.

En termes économiques, le développement d'une application mobile se fait-il sur une base comparable à celle d'une application classique ? Le besoin du mode déconnecté n'est-il pas amené à disparaître avec l'avènement des forfaits web illimités et il suffira alors que tous les terminaux supportent le même navigateur et Ajax ?

Le coût de base d'une application mobile peut se réduire à un un serveur alimentant et à un client Wap, et est donc comparable à celui d'un modèle client/serveur classique pour ce qui est de la réalisation, de la maintenance et de l'exploitation. Mais attention au coût de connexion qui reste à la charge de l'utilisateur !

Le coût va croître lorsque vous allez choisir une application riche (Java, Flash..) car les développeurs compétents sont plus rares donc chers, et d'autre part la segmentation des mobiles implique la compilation de nombreuses versions.

Par exemple Yahoo GO Mobile a probablement du nécessiter la génération de certaines versions Java ! autrement dit retour à la case départ : pilotage par le fonctionnel, et choix de la technologie en fonction du couple cible/investissement.

La tendances est plutôt à la multiplication des browsers ou moteurs de rendu: Opera mini, Access Netfront, Pocket IE, Safari, Firefox mobile. et la standardisation de type Webkit très limitée. De plus, les usages liés à la convergence de type mobile Unik (Orange) rendent intéressant le mode application embarquée pour pouvoir interagir avec son environnement, par exemple piloter de la domotique sans avoir recours à un serveur déporté.

Quels facteurs externes ou internes à l'entreprise peuvent faire capoter un projet applicatif mobile ?
Un projet mobile requiert souvent des systèmes alimentant internes, et donc une connexion aux SI de l'entreprise (soit métiers, soit de contenus). Cette réalité engendre plusieurs écueils : le coté "intrusif" de l'application mobile et donc le rejet de la DSI et la résistance au changement, la sécurité par la traversée de réseaux locaux et des mauvais choix technologiques. Par exemple : réaliser un serveur mobile en .Net alors que toutes les équipes de la DSI sont formées à J2EE ce qui les handicapent d'un point de vue de la maintenance.

Enfin une application mobile requiert souvent des connexions à des serveurs de contenus externes, ce qui pose également des problèmes de SLA, de coût, de mode de connexion.. Afin d'éviter ces écueils, une bonne compréhension et réflexion en amont sont utiles, sans hésiter non plus à identifier des sponsors internes et des key users.

Que pensez vous de l'avenir des codes barres 2D et notamment du standard Flashcode ?
Les codes barres 2D sont représentatifs de l'avenir des applications mobiles: ce sont au même titre que le NFC et la géolocalisation des enablers permettant à l'application mobile d'orienter l'utilisateur vers de multiples usages : paiement, réservation, téléchargement, VoD, publicité, billettique...Peu importe la technologie, les usages seront les drivers du marché...

Yvan Gravier est fondateur et directeur général de la SSII de Neotilus depuis 2002, filiale du Groupe DEGETEL spécialisée dans les Télécoms, la mobilité et le Multimédia. Il a été directeur de GIST (Groupe Alten) de 1999 à 2002 et a également été ingénieur d'affaires chez Altran. Yvan Gravier est ingénieur diplômé de Sup'Aéro en 1992, avec une spécialisation Télécom Spatiales.