mobile 53

# 204

Développement mobile :
choisir, et si possible bien choisir
En 10 ans, le !"#$$%%&'($$&
&)*++$
développement
mobile a totalement
changé que ce soient
les matériels, les !"#",+-*.(/"01($2$
!"#",+-*.(/"01($2$ !4-7+-*.(/"01($2$
!4-7+-*.(/"01($2$
3#&0"%&$"4$%56$
3#&0"%&$"4$%56$ 3#&0"%&8$%568$(.9:$
3#&0"%&8$%568$(.9:$
systèmes et les outils
de développement.
Au début, nous étions ;'<(-"++(1(#.$$
;'<(-"++(1(#.$$ ;'<(-"++(1(#.$$
1(#.$$
;'<(-"++(1(#.$$
;'<(-"++(1(#.$$ ;'<(-"++(1(#.$$
; '<(-"++(1((#.$$ =>?0%&($@(?$$
en natif, natif et #*7/$
#*7/$
=>?0%&($@(?$$
=>?0%&($@(?$$
#*7/$
# *7/$
=>?0%&($@(?$$
encore natif. Puis nous
sommes passés à
l’hésitation
5?A(97<(,B$C$6@%D$
5?A(97<(,B$C$
,B$C$6@%D$$ B"0&"<*$
B"0&"<*$ H*1*0%#$GBFI$
H*1 *0%#$GBFI$ B"0&"<*$
B "0&"<*$
multiplateforme avec E*<*$
E*<*$ E*<*690%+.$
E*<*690%+.$ BMM$
B MM$ E*<*690%+.$
E*<*690%+.$
des outils plus ou BF$G<%*$H*1*0%#I$
BF$G<%*$H*1*0%#I$ J(*9.$
J(*9.$ N%#;(<$
N% #;(<$ J(*9.$
J( *9.$
moins fiables, et aux 34.0($
34.0($ K*7<(E6$
K*7<(E6$ K*7<(E6$
K*7<(E6$
apps Web. L.9:$$$$ L.9:$$
L.9:$$
Aujourd’hui, où en
est-on ? A !"#$$3
3++$

L
e développeur, qu’il soit débutant ou ex- Dans ce cas, quelle gestion de projets faut-il Des coûts à considérer
pert, n’a que l’embarras du choix, et c’est mettre en place ? Tout développement a un coût, un budget. Par
bien là le problème. Quel outil choisir ? • Quels sont les tests terminaux à faire ? Et exemple, si une société Y fait développer une
Schématiquement, nous pouvons résumer le avec quels outils ? app mobile, elle doit considérer le salaire du dé-
premier niveau de réflexion à un diagramme • L’app aura-t-elle un cycle de vie régulier (mise veloppeur (qu’il soit interne ou externe). Et
très simple : [A] à jour, maintenance, etc.) ? selon le profil du développeur, et des outils uti-
En y réfléchissant un peu, nous allons vite nous • Me faut-il un backend et des services backend lisés, la facture ne sera pas la même. Après,
apercevoir que de nombreuses questions se spécifiques (bases de données, stockage, gé- attention aussi : un profil performant a un coût
posent derrière et qu’elles sont tout aussi fon- nération 3D, authentification, etc.) ? généralement supérieur à la moyenne mais
damentales : Ça va ? Pas trop mal à la tête ? Nous n’aborde- vous pouvez gagner en temps de développe-
• Est-ce un développement “loisir” ou un projet rons pas dans ce dossier tous les services et ment…
de grande envergure ? fonctions backend qui nécessitent souvent d’in- Cet article détaille le coût du développement
• Est-ce une app déployée sur les Apps Stores tégrer des services externes (typiquement en même si l’étude est centrée sur les USA ; cela
pour tout le monde ou une app plutôt inter- mode Cloud) comme pour l’authentification peut donner une bonne idée : http://www.comen-
ne à l’entreprise ? (ex. : authentification Facebook), stockage via tum.com/mobile-app-development-cost.html
• Quelles sont mes compétences ? un stockage Web, un traitement d’analyse en
• Quel budget ai-je à ma disposition ? Faut-il mode Cloud, calcul et affichage d’une interface Sur les salaires des développeurs mobiles, les
investir dans des formations, des pro- dynamique (ex. : jeux mobiles). profils Android et iOS ont toujours une majora-
grammes développeurs ou dans les outils ? Après il faut raison garder. On ne va pas coder tion. Ainsi un profil débutant peut espérer
• De quelles fonctions ai-je besoin dans l’app ? une “simple” app de gestion d’une entreprise +35 k€, voire, 40 k€ / an. Mais nous trouvons
Est-ce que je dois beaucoup utiliser le maté- avec les fonctions les plus avancées d’interface certaines fourchettes salariales trop extrèmes :
riel ou non ? (ex. : WebGL, Unity3D) ou coder en C++ une 42-45 k€ en profil 0-2 ans expérience. La ten-
• L’interface est-elle très spécifique ou très gé- simple app avec une base de données, ni utili- dance actuelle est clairement d’avoir un profil
néraliste ? ser SQL Server ou Oracle Database quand multiplateforme et non plus sur une seule pla-
• Mon app est-elle monolangue ou multilangue ? MySQL ou SQL Lite suffit largement. Bref, teforme. •
• Est-ce que je travaille seul ou en équipe ? n’utilisez pas un tank quand un vélo suffira.

programmez! - février 2017

54 mobile
# 204

Développement mobile :
quelles solutions, comment choisir,
quel outil pour quel développement ?
Arnaud Piroelle
@ArnaudPiroelle Maxime Fontanier Sylvain Teodomante
Consultant Florent Capon [email protected] [email protected]
Android, Consultant iOS, Service DNO/DA/AQ Service DNO/DA/AQ
Xebia Xebia CNES CNES

Alors qu'il y a quelques années, nous pouvions encore nous poser la question, aujourd’hui c’est bien une
réalité : le monde est mobile. Une donnée le prouve : en 2014, les ventes de terminaux mobiles ont
dépassé celles des PC. Les utilisateurs naviguent davantage sur leurs smartphones et tablettes, et
deviennent de plus en plus exigeants sur les performances, le temps de réactivité, l’ergonomie de l’interface,
etc. Il devient indispensable d’intégrer cette évolution et de développer des applications de qualité.
Pour ce faire, il existe deux approches : dans une application « coquille » native, afin de faciliter l’accès aux com-
• Le web mobile : il s’agit de développer un site Web adapté au mobile, posants du dispositif à partir du code Web.
plus connu sous le nom de « responsive ». On parle également de • Les technologies transcompilées : elles permettent de développer une
« progressive WebApp » permettant d’optimiser le chargement des seule application à l’aide d’un langage unique qui sera transformée en
écrans mais aussi la gestion du mode offline. applications natives, pour chaque plateforme cible.
• L’application mobile : l’application, spécifique au mobile, n’a pour cible
que le smartphone, la tablette et la montre connectée. Son avantage Quelle solution pour quel besoin ?
est de proposer une interaction forte avec toutes les possibilités offertes Choisir une solution technique pour le développement d’une application
par le hardware (appareil photo, gyroscope, etc.) et d’être présent dans mobile n’est pas simple. De nombreux paramètres entrent en jeu, que ce
les stores de chaque plateforme choisie (au contraire d’un site Web soit le mode de distribution de votre application, les plateformes ciblées
mobile). ou même les ressources disponibles pour le développement.
Dans le cadre d’une approche Web Mobile, le choix de la technologie est Dans le cas d’un déploiement multiplateforme, il n’existe pas de solution
large puisque identique au développement Web « traditionnel ». Il existe miracle, car chacune des technologies a ses forces et faiblesses. Le choix
aujourd’hui de nombreux frameworks HTML / CSS / JS (dont notam- est plutôt une question d’équilibre, entre le temps consacré aux dévelop-
ment Angular, React.js ou Vue.js) pour développer un site mobile ; la pements, les coûts engendrés, la pérennité de l’application, sa
plupart proposant des outils pour faciliter l’affichage responsive et les in- maintenance et la qualité souhaitée.
teractions avec le hardware. Ces réalisations ne représentant pas un Pour des réalisations plus petites ou dites « jetables », l’hybride semble
« développement mobile » en tant que tel nous ne l’aborderons pas être une bonne option. Dans le cas inverse, pour une application plus
davantage au cours de cet article. complexe ayant pour vocation de durer dans le temps, le natif s’impose
Dans la seconde approche, le choix de la technologie peut être plus déli- naturellement.
cat car les solutions possibles (native, hybride, transcompilée) présentent
des orientations de développements très différentes avec des avantages Pourquoi choisir le natif ?
et inconvénients marqués. Ce choix crucial impactera par la suite la per- Le développement natif consiste à développer une application pour
formance, la maintenabilité, la pérennité, le coût, etc. chaque plateforme cible. Il est ainsi supporté officiellement par l’éditeur
de la plateforme cible : Apple pour iOS, Google pour Android et
Développement Microsoft pour Windows Phone. Il est alors aisé de suivre les évolutions
Trois solutions : native, hybride, transcompilée de chaque constructeur, OS et API proposés.
Pour réaliser une application mobile qui a pour objectif d’être déployée Un second avantage et non des moindres, ce sont les communautés de
sur un store (qu’il soit public ou d’entreprise), trois solutions techniques développeurs actives sur ces plateformes (surtout pour iOS et Android). Il
sont possibles : est alors facile de trouver des réponses aux problèmes que l’on peut ren-
• Les technologies natives : elles permettent de développer une applica- contrer. On trouvera aussi des milliers de librairies tierces pour tout type
tion spécifique pour chaque plateforme (iOS, Android, Windows de besoin.
Phone), dans un langage supporté officiellement par l’éditeur de la pla- Le développement natif permet aussi de proposer la meilleure expérien-
teforme. ce utilisateur possible avec des performances optimales : il assure une
• Les technologies hybrides : elles permettent d’encapsuler un site Web pleine exploitation de toutes les capacités et ressources proposées par le

programmez! - février 2017

 mobile 55
# 204

device, sans aucune couche intermédiaire venant réduire la mémoire ou 1

les temps de calcul. Dans le cas d’applications à forte sollicitation du CPU
ou GPU, la différence entre une application native ou hybride peut être
très marquée : scrolling saccadé, freeze ou même crash si la mémoire
n’est pas gérée correctement.
Autre grande force du natif : la gestion de l’affichage de listes de plu-
sieurs centaines ou milliers d’éléments ; grâce à des composants dédiés
avec un système de recyclage des cellules limitant la sollicitation CPU et
mémoire, ce type d’affichage, devenu presque incontournable aujour-
d’hui, est facile à intégrer.
Nous parlions précédemment d’expérience utilisateur. La performance et
la réactivité sont certes des points importants dans ce domaine, mais une
autre composante est essentielle : l’ergonomie. En effet, chaque système
d’exploitation et device dispose des codes ergonomiques qui lui sont
propres. Ainsi, le respect de ces codes décrits par Apple, Google ou
Microsoft au travers de documentations, est facilité par l’ensemble des
outils natifs mis à la disposition du développeur. Leurs évolutions créent
très peu d’impact en termes de temps de développement car sont antici-
pés par le constructeur.
Enfin, dernier point non négligeable, notamment dans la réalisation d’ap-
plications d’envergure visant à être pérennes : la maintenabilité, accrue À gauche : développement natif ; à droite : développement hybride
grâce à une base de code saine écrite et développée spécifiquement pour A : La couche OS
une plateforme. Le code n’est alors pas pollué par des instructions qui B : La couche hybride (webview)
pourraient être différentes d’une plateforme à une autre, contrairement à C : La couche physique (l’écran tactile)
un développement hybride. Les risques de régression sont ainsi réduits
puisqu’un correctif spécifique à une technologie n’aura aucun impact sur qui sera transformée par la suite en code natif. Elles proposent un sup-
les autres plateformes. Les phases de recette et test s’en trouvent aussi al- port au plus proche des plateformes, facilitant ainsi l’optimisation des
légées. [1] performances et le respect de l'expérience utilisateur. Toutefois, ce sup-
port n’est pas magique, il faut garder en tête que chaque mise à jour de
Pourquoi choisir l’hybride ? la plateforme implique une mise à jour du framework. Il faut donc un mi-
Un développement hybride implique une base de code unique qui sera nimum de temps afin de bénéficier des nouveautés de chaque
la même d’une plateforme à une autre. Avantage considérable par rap- plateforme.
port à un développement natif, cette base de code unique permettra un
développement multiplateforme très rapide. Ceci permet de garantir l’en- Et des webviews dans du natif ?
semble des fonctionnalités et la maintenance de manière indépendante Impossible de ne pas avoir entendu parler de « webview dans du natif ».
de la plateforme. Oui c’est possible, oui, ça se fait souvent. Néanmoins, il faut veiller à utili-
De plus, le développement hybride bénéficie d’un bon nombre de solu- ser cette solution avec parcimonie car elle représente dans bien des cas
tions techniques. Il y en a pour tous les goûts. Les technologies venant une « roue de secours » ou un palliatif à un développement trop coû-
du monde du Web sont les plus utilisées. Depuis des dizaines d’années, teux.
les développeurs du monde entier utilisent HTML, CSS et JS afin d’offrir Même si cela peut présenter des avantages (délai, coût, etc.), les utilisa-
des sites Web de qualité aux utilisateurs. Rien d’étonnant à ce que ces teurs de votre application ne sont pas dupes et constateront un décalage
technologies soient utilisées dans des solutions hybrides sur mobile. ergonomique et souvent graphique entre vos parties développées en
Représentant une très grande partie des développeurs sur le marché, il natif et les écrans affichés dans une webview. Si votre projet ressemble à
est plutôt aisé de trouver des profils qualifiés sur ces technologies pour un patchwork de technologies, vos utilisateurs risquent d’être déçus : la
réaliser un projet hybride. notation de votre application dans le store pourrait en pâtir.
Cependant, ce type de développement a des limites. Que ce soit en
termes de performances, de fonctionnalités liées aux hardwares ou de Quel langage utiliser ?
respect de l’expérience utilisateur, une solution hybride ne peut arriver Même s’il ne sera pas nécessairement un critère de choix, il peut-être im-
au niveau d’un développement natif. portant de prendre en compte quel langage est possible pour chaque
solution technique.
Pourquoi choisir le transcompilé ? Dans le cadre d’un développement natif, plusieurs solutions sont pos-
Au vu des avantages et inconvénients des 2 modes de développement sibles selon les plateformes :
proposés précédemment, de nouvelles solutions visent à garder le • iOS (Apple) : Swift remplace désormais le vieillissant Objective-C,
meilleur des deux mondes, à savoir une base de code unique avec les même si ce dernier est toujours possible mais non recommandé. À
performances et les fonctionnalités des différentes plateformes. Parmi noter que contrairement à l’Objective-C, Swift est open source et per-
elles, on retrouve par exemple Xamarin ou encore AppCelerator. met de développer des applications serveurs.
Ces solutions permettent le développement d’une base de code unique • Android (Google) : Java est le langage officiellement supporté par

programmez! - février 2017

56 mobile
# 204

Google mais d’autres sont possibles, comme Groovy ou même Scala… Quelle solution pour quel coût ?
Néanmoins, ils ne sont que très anecdotiques car lourds à mettre en Nous venons d’analyser, pour chaque technologie, les points forts et cri-
place et peu adaptés au développement mobile. Mais un nouveau lan- tères importants qui doivent aider à choisir une technologie plutôt qu’une
gage a fait son apparition et peut changer la donne : Kotlin. Conçu par autre. Néanmoins, la question du budget consacré au développement
JetBrains en 2014, il est pensé comme un langage fonctionnel permet- d’application peut contredire ce choix. Là où le natif paraît être la solution
tant de simplifier au maximum le code et de rendre la maintenance garantissant les meilleures performances et la maintenance la plus fiable,
plus facile. Bien qu’assez jeune, Kotlin est parfaitement adapté au déve- elle présente en revanche des coûts souvent plus élevés que ses concur-
loppement mobile sur Android. rents. En effet, dans le cas d’une réalisation multiplateformes, le natif
• Windows Phone (Microsoft) : nativement, Microsoft propose trois lan- oblige l’équipe à développer une version de l’application pour chaque
gages différents. Chacun sera libre de choisir selon ses préférences : technologie supportée. Le coût de réalisation est alors multiplié par le
- C# / XAML : langage très proche de Java, le C# est très reconnu nombre de plateformes souhaitées. Chaque technologie ayant son
dans le monde du développement embarqué. propre langage et ses codes ergonomiques, il sera difficile de capitaliser
- JS / HTML : JS et HTML sont très populaires dans le monde du d’une plateforme à une autre. De même, les profils intégrés dans les
Web. L’intégration de ces langages dans le développement mobile équipes seront spécialisés sur une plateforme mobile alors que du côté
est un moyen d’attirer une nouvelle population de développeurs. hybride, il est possible pour un développeur full stack de travailler sur des
- C++ / XAML : langage de programmation très populaire pour ses projets desktop et mobiles.
performances et son approche très bas niveau. Outre ceci, il faut aussi prendre en considération le coût des IDE, réel
Dans le cas d’une solution hybride, le développeur pourra choisir le fra- avantage budgétaire pour un développement natif. En effet, chaque
mework HTML / JS / CSS de son choix. constructeur propose gratuitement son propre IDE, alors que certaines
Pour les technologies transcompilées, le langage dépendra de la solution solutions hybrides ou transcompilées sont payantes pour un usage com-
choisie. Par exemple, une application AppCelerator s’écrit en JavaScript mercial comme Xamarin ou AppCelerator.
alors qu’une application Xamarin se développe en C#. Le coût des licences pour déployer son application sur les stores est quant
à lui identique pour chaque type de développement. Pour distribuer une
Quelle stack technique choisir ? application dans un store (public ou privé), il est nécessaire de souscrire à
Le monde de la mobilité évolue très vite et il n’est pas rare de voir une une licence de développement qu’il s’agisse d’un développement natif,
stack technique devenir obsolète en quelques mois seulement. Au risque hybride ou transcompilé. À noter qu’Apple présente les tarifs les plus éle-
donc d’être dépassés dans les prochains mois, nous avons souhaité vous vés : 99€ / an pour l’App Store à 299€ / an pour un store d’entreprise,
présenter les stacks techniques recommandées à l’heure actuelle : contre 25$USD à vie pour Google (soit environ 24€) et de 14€ à 75€ à
vie pour Microsoft.
iOS Android Windows
Client HTTP URLSession OkHttp Restsharp CONCLUSION
ou Alamofire De nombreux critères entrent en jeu pour choisir la solution la plus adap-
Client API REST URLSession Retrofit Restsharp
tée à son besoin. Or, il n’existe pas de solution miracle. Tout est question
ou Alamofire
d’équilibre entre les différents critères pour pondérer votre choix. Le plus
Sérialisation / Unbox Gson ou Newtonsoft
Désérialisation JSON Moshi json simple reste de synthétiser tous ces éléments dans un tableau :
Gestion des images AlamofireImage Glide Imaging SDK •
Programmation RxSwift RxJava
réactive
Gestion des logs CocoaLumberjack Timber Log4Net
Base de données
locale Realm SQLBrite SQLite
Injection
de dépendances Swinject Dagger MvvmLight
Crash reporting Crashlytics Crashlytics HockeyApp
Tracking utilisateur Fabric Fabric Application
Insights

Ces stacks techniques doivent être maintenues à jour et modifiées régu-

lièrement afin de suivre l’évolution de chaque plateforme.
Pour un développement hybride, c’est différent. Nous parlerons davanta-
ge de frameworks regroupant tous les outils nécessaires à la bonne
réalisation d’une WebApp. Chacun ayant ses spécificités, patterns et ar-
chitectures, le développeur pourra choisir celui avec lequel il se sent le
plus à l’aise. Les plus connus aujourd’hui sont :
• AngularJS
• EmberJS
• React
• Vue.js

programmez! - février 2017