Je ne pense pas vous apprendre grand-chose si je vous dis que développer une application mobile ça prend du temps. Le développement à plein temps d’une application fonctionnelle peut prendre quinze jours comme un an, tout dépend évidemment de sa complexité. Imaginez maintenant que vous souhaitez lancer votre application mobile sur Android et iOS. Il faudra donc potentiellement compter le double de temps. Si vous souhaitez également que votre application soit présente sur Windows Phone et BlackBerry, il faudra là encore investir du temps et de l’argent.

Rentabiliser son application passe donc également par le choix d’une ou plusieurs plates-formes sur lesquelles vous souhaitez la lancer car potentiellement, plus vous visez de plates-formes plus vous dépenserez d’argent et plus il sera dur de rentrer dans vos frais. Dans ce chapitre, je vous propose de revenir sur les différentes possibilités qu’il existe pour développer et lancer votre future application mobile. Quelle plate-forme pouvez-vous viser ? Au sein d’une plate-forme, quelle rétro-compatibilité allez-vous mettre en place ?

Bref ! C’est le moment de comparer ce qu’on appelle les applications natives et les applications cross-platform.

Plan

• Concrétiser son idée d’application mobile (1/3) : Disséquer son idée d’application mobile
• Concrétiser son idée d’application mobile (2/3) : Applications natives, cross-platform et parts de marché
• Concrétiser son idée d’application mobile (3/3) : Développer son application mobile

Les applications natives

Une application native est une application qui est développée spécifiquement pour une et une seule plate-forme, grâce aux outils spécifiquement conçus pour celle-ci. Aussi, si vous souhaitez développer une application native pour Android et iOS, il convient en réalité de développer deux applications bien distinctes qui ne pourront pas partager la moindre ligne de code. Il n’est d’ailleurs pas rare que les entreprises fassent appel à des prestataires différents pour développer une même application sur plusieurs plates-formes tant les technologies utilisées sont différentes. Tous les développeurs ne possèdent malheureusement pas une double ou triple compétence.

Les applications Android

Pour développer une application sur la plate-forme de Google, historiquement on le Java comme langage de programmation. S’il était également possible d’utiliser le kotlin, le support de ce dernier n’est officiel que depuis la Google I/O 2017 (mai 2017). Les applications sont alors développées à l’aide du SDK Android. Suivant nos besoins, on pourra également utiliser le C++ comme langage de programmation et le NDK comme outil de développement.

Je ne vais pas spécialement revenir sur les langages de programmation que sont Java, kotlin et C++. Sachez juste qu’il s’agit de langages assez différents comme il en existe des centaines dans le monde de la programmation informatique.

SDK signifie Software Development Kit soit kit de développement logiciel en français. La notion de SDK n’est absolument pas liée à Android. Il s’agit d’un ensemble d’outils qui permettent d’aider les développeurs pendant le développement d’un site Internet, d’un logiciel ou encore d’une application mobile. Le SDK Android, comme son nom nous permet de le deviner, est donc un ensemble d’outils aidant les développeurs à créer des applications Android.

Le NDK est quant à lui un principe plus orienté Android. NDK signifie Native Development Kit. Bien que moins utilisé que le SDK, le NDK Android permet d’optimiser certaines parties complexes de vos applications comme un rendu 3D ou encore rendre plus difficile la rétro-ingénierie de votre application.

Enfin, sachez que pour programmer, on utilise généralement un IDE (Integrated Development Environment), c’est-à-dire un environnement de développement. Cet environnement de développement a pour objectif d’aider le développeur en lui proposant de nombreuses fonctionnalités comme par exemple la coloration syntaxique de son code, l’auto-complétion, un système de débuggage, etc. Pour Android, il convient d’utiliser Android Studio. Cet IDE est disponible gratuitement sur le site développeur d’Android.

Je sais très bien que ce cours n’a pas pour vocation à faire de vous des as de la programmation. Il n’a d’ailleurs pas vocation à être technique. Cependant, de mon point de vue de développeur, il me paraît important que vous compreniez la complexité que représente le développement d’une application mobile. En effet, c’est cette complexité qui justifie le temps, parfois très long, de développement d’une application. Comprendre ces concepts me semblent indispensable pour rentabiliser vos applications mobiles, car rentabiliser une application mobile commence dès la conception de celle-ci.

Nous en avons terminé avec le côté technique de la plate-forme Android. Je vous propose maintenant de nous intéresser à la rétro-compatibilité que vous allez proposer dans votre application. Vous n’êtes pas sans savoir que de nouvelles versions des systèmes d’exploitation mobiles sortent régulièrement. Android n’échappe pas à la règle. Au moment où j’écris ces lignes, nous en sommes à Android 5.0.2. Malheureusement, tous les téléphones sous Android ne tournent pas sur cette version. L’éco-système Android est extrêmement fragmenté (source).

Comme vous pouvez le constater, au 2 octobre 2017, seulement 0.2% des téléphones Android tournent sous la dernière version.

Parce qu’ils ne peuvent tout simplement pas ! La particularité d’Android c’est que n’importe quel constructeur peut l’embarquer sur un téléphone de sa marque. C’est pourquoi on retrouve aujourd’hui Android sur des téléphones Samsung, Sony, HTC, Motorola, Wiko, etc. Le problème c’est que les constructeurs, avant de mettre Android sur un téléphone, le personnalise. La personnalisation peut être graphique, mais également logicielle comme l’ajout d’applications, de raccourcis, etc. On parle alors de ROM constructeurs.

Je vous propose ci-dessous un aperçu d’Android sur différents téléphones.

Android sur un Samsung Galaxy S II :

Android sur un HTC Desire C :

Android sur un LG Nexus 5 :

Imaginez un peu, vous êtes un constructeur, vous venez de passer des mois à personnaliser une version d’Android pour les téléphones de votre marque et là, Google vous annonce qu’une nouvelle version va sortir. Il faut tout recommencer et ça coûte de l’argent ! Les constructeurs délaissent alors leurs anciens modèles pour ne proposer des mises à jour que sur les terminaux récents. C’est pourquoi un Samsung Galaxy S3 pourtant sorti en 2012, ne se verra jamais aller plus loin qu’Android 4.3. À titre de comparaison, un LG Nexus 4, sorti pourtant la même année, a été mis à jour vers Android 5.0.

Aux personnalisations constructeurs, il faut également parfois ajouter les personnalisations opérateurs. Ces personnalisations permettent aux différents opérateurs téléphoniques, à savoir Bouygues Telecom, Orange, SFR et Free en France, de pré-installer des applications liées à leurs services.

Tout ça pour dire que toutes ces personnalisations coûtent de l’argent et sont, en partie, responsables de la non-mise à jour des terminaux, causant ainsi la fragmentation de la plate-forme.

Si je vous dis tout ça, c’est qu’assurer la rétro-compatibilité d’une application sur Android 2.3 par exemple, ça coûte du temps et donc de l’argent ! En effet, chaque nouvelle version d’Android propose son lot de nouveautés qui ne sont pas forcément utilisables de manière triviale dans une ancienne version du système. Avant de vous lancer dans le développement d’une application Android, il convient donc de se poser quelques questions. Est-ce vraiment pertinent de supporter Android 2.3 si cela rallonge le développement de mon application de plusieurs semaines ? Est-ce que les 0.6% d’utilisateurs sous Android 2.3 me permettront de rentabiliser les semaines de développement en plus ? Même question pour les 0.6% d’utilisateurs encore sous Android 4.0.

Aujourd’hui, beaucoup d’éditeurs assurent une rétro-compatibilité jusqu’à la version 4.1 d’Android. Mais il est important de noter, qu’en raison de problématiques technique, certains éditeurs n’hésitent plus à limiter leur rétro-compatibilité à Android 4.4. C’est par exemple le cas de l’application myCANAL.

Les applications iOS

Pour développer une application sur la plate-forme d’Apple, on utilise historiquement l’Objective-c. Depuis 2014, il est également possible d’utiliser Swift, un tout nouveau langage de programmation créé par la marque à la pomme.

Pour développer des applications iOS, il convient également d’utiliser un IDE. Il s’agit de Xcode. Si l’IDE Android Studio est disponible sur les différents systèmes d’exploitation, à savoir Windows, Linux et Mac OS X, ce n’est pas le cas de Xcode. Pour développer des applications iOS, il est obligatoire de posséder un Mac et le système d’exploitation Mac OS X !

Qu’en est-il de la rétro-compatibilité des applications iOS et la fragmentation de l’écosystème ? Sachez qu’iOS ne ressemble absolument pas à son frère ennemi Android ! En effet, contrairement à Android qui est proposé sur les téléphones de nombreuses marques, iOS, lui, n’est disponible que sur les terminaux d’Apple à savoir l’iPhone, l’iPad et les iPod. C’est donc la même société qui gère de bout en bout le terminal et son système d’exploitation. Il est donc bien plus facile de proposer et déployer les mises à jour. Les conséquences de cette politique sont immédiates : l’écosystème est bien moins fragmenté ! Alors que fin 2017 on trouve sur le marché pas moins de sept versions différentes d’Android et seulement 0,2% d’adoption de la dernière version de l’OS, chez iOS, la dernière version du système d’exploitation a dépassé les 10% d’adoption seulement 24h après sa mise à disposition.

Au vu de la segmentation du marché chez iOS, on peut donc se permettre de se limiter au support des deux dernières versions sans prendre trop de risques aussi bien au niveau du développement de l’application qu’au niveau des futurs utilisateurs.

Les applications UWP (Universal Windows Platform)

Terminons notre tour des acteurs du mobile avec Microsoft. Si les principaux concurrents de la firme de Redmond proposent un système d’exploitation différent entre leurs téléphones/tablettes et leurs ordinateurs, Microsoft propose quand à lui le même système d’exploitation : Windows 10.

Pour développer une application UWP, c’est-à-dire une application destinée à Windows 10 Desktop ou mobile, on utilise les langages de la famille .NET et plus généralement le C#..

Pour développer des applications Windows, il convient toujours d’utiliser un IDE. Il s’agit de Visual Studio. Si cet IDE a longtemps été réservé à Windows, il est aujourd’hui également disponible sous MAC. La version complète du logiciel est assez onéreuse, mais sachez qu’il existe des versions dites community gratuites.

Qu’en est-il de la rétro-compatibilité des applications Windows et la fragmentation de ces deux écosystèmes ? Il est important de souligner que Microsoft adopte une politique assez agressive pour obliger les utilisateurs à mettre à jour leur système d’exploitation.

La première version de Windows Phone portait le simple nom de Windows Phone 7. Ce tout nouveau système d’exploitation, très jeune, a rapidement été remplacé par Windows Phone 7.5, surnommé Mango. Tous les téléphones originellement sous Windows Phone 7 se sont vus proposer la mise à jour vers Windows Phone 7.5 et, pour obliger les utilisateurs à faire cette mise à jour, Microsoft a tout simplement bloqué l’accès au Windows Phone Store à tous les terminaux qui n’étaient pas à jour. Je vous accorde le fait que c’est un peu radical…

Suite à la sortie de Windows 8, la déclinaison mobile, Windows Phone 8, a également été annoncée. Cette nouvelle version n’a pas vocation à être proposée sur les anciens terminaux. Aussi, les terminaux sous Windows Phone 7.5 ne se verront jamais proposés la mise à jour. Au mieux, ils peuvent bénéficier de Windows Phone 7.8 qui leur propose quelques fonctionnalités empruntées à Windows Phone 8. Depuis, Windows 8.1 et Windows Phone 8.1 sont sortis et ont été proposés à tous les terminaux sous Windows Phone 8. La dernière version en date est Windows 10.

Il faut malheureusement accepter le fait que pour le moment cet OS est très peu adopté par les possesseurs de téléphone portables et ce pour une raison très simple : Microsoft ne propose plus de téléphone sous cet OS. Vous avez encore la possibilité de proposer vos applications pour la version desktop de l’OS mais une fois de plus les utilisateurs ont plutôt tendance à utiliser les sites web. Le taux de conversion vers les applications UWP est finalement assez faible.

Les autres plates-formes

Je me suis limité à une description détaillée des trois plus gros acteurs, mais sachez qu’il existe des dizaines d’autres systèmes d’exploitation capables de tourner sur votre téléphone, tablette ou vos objets connectés. Tous ne sont plus forcément des projets actifs, mais l’on peut citer les projets suivants :

• Tizen
• BlackBerry OS
• Firefox OS
• Sailfish OS
• Ubuntu Touch

Les applications cross-platform

Dans la section précédente, nous avons vu le concept d’application native. Nous avons également vu qu’il était important de faire des choix stratégiques quant aux plates-formes et aux versions des systèmes d’exploitation à viser tant ils sont nombreux. Nous allons maintenant nous attaquer aux applications dites cross-platform.

Une application cross-platform, en opposition à une application native, est une application qui une fois développée est capable de s’exécuter sur plusieurs plateformes comme Android, iOS, BlackBerry ou encore Windows Phone. On ne développe qu’une seule fois et on exécute partout. De loin, ça semble être la solution idéale !

Les applications cross-platforms sont généralement développées à l’aide des technologies web, à savoir le HTML, le CSS et le JavaScript.

Comme je le disais un peu plus haut, le grand avantage des applications cross-platform est donc qu’on ne développe qu’une application que l’on est ensuite capable de déployer partout. Vous pouvez facilement imaginer les économies de temps et d’argent que vous faites si vous décidez de lancer votre application sur Android, iOS et Windows Phone. Dans un cas, vous développez une seule application alors que dans l’autre, vous développez trois applications qui ne partageront pas une seule ligne de code…

Effectivement, de loin c’est le rêve, mais quand on y regarde de plus près, on est capable de mettre en avant plusieurs défauts.

Tout d’abord, on reproche souvent aux applications cross-platform, bien que ça soit de moins en moins vrai, d’être moins performantes que les applications natives. En réalité, tout dépend de la complexité et des fonctionnalités de votre application. Sur une application basique qui ne fait qu’afficher quelques informations textuelles à l’écran, la différence de performances entre une application native et une application cross-platform sera complètement transparente pour celui qui l’utilise. En revanche, si votre application possède une dizaine d’écrans différents et qu’elle doit gérer des choses compliquées comme des DRM (gestion de droits numériques), la différence de performance se fera automatiquement ressentir auprès de vos utilisateurs, si tant est que vous ayez réussi à développer toutes les fonctionnalités de votre application.

L’autre chose que l’on reproche souvent aux applications cross-platform, c’est d’être moins immersives d’un point de vue purement graphique. Vous n’êtes pas sans savoir que les guidelines graphiques d’une application Android, iOS et Windows Phone sont très différentes. En un coup d’oeil à une maquette d’une application, on est capable de déterminer la plate-forme à laquelle elle se destine. Quand on développe des applications natives, on a naturellement tendance à respecter les guidelines graphiques de la plate-forme visée car celle-ci nous propose des thèmes par défaut. Dans le cas d’une application cross-platform, on a souvent tendance à créer un design standard qui sera exactement le même pour toutes les plates-formes. Bien qu’il soit possible de personnaliser les différents éléments grâce au CSS, on arrive très rarement à rivaliser avec l’intégration graphique d’une application native.

Pour illustrer mes propos, voici quelques captures d’écran d’applications natives et d’applications cross-platform.

L’application​ ​Android​ ​Google​ ​Play​ ​Music :

L’application​ ​Windows MSN Actualités :

L’application​ ​iOS myCANAL :

L’application​ ​cross-platform​ TripCase​ Travel​ Alerts :

Les solutions hybrides

Nous venons de parler des applications natives que nous avons opposées aux applications cross-platform. Sachez également qu’il existe un troisième type d’application : les applications hybrides.

Mixer le natif et web

Les applications hybrides sont des applications natives qui, sur un ou plusieurs de leurs écrans, vont utiliser des technologies web. L’avantage de ce genre d’applications c’est qu’on bénéficie des performances du natif tout en mutualisant du code entre les applications des différentes plates-formes.

Ce genre d’applications est très utilisée notamment pour les applications de presse qui peuvent ainsi afficher au format web des articles complexes dont la mise en page est facilitée grâce au CSS tout en bénéficiant des fonctionnalités natives du système comme le partage de l’article. Tout la partie permettant d’afficher et mettre en page un article peut ainsi être mutualisée et réutilisée sur les différentes plates-formes.

Par exemple, dans la capture d’écran ci-dessous de l’application BFMTV sous Android, la barre bleue est native et les contrôles qui y sont présents également (zoom, dézoom et partage). Pourtant, toute la partie sur fond blanc qui correspond à l’article est en réalité du HTML :

D’autres solutions ?

Enfin, sachez qu’il existe encore d’autres solutions qui permettent d’écrire et produire des applications natives tout en mutualisant du code entre les différentes plates-formes. Les technologies utilisées ne sont alors pas nécessairement celles que l’on utilise pour faire du développement natif. J’ai volontairement passé sous silence leurs noms, je vous les révèlerai dans le prochain chapitre. ;)

Le cas particulier des jeux vidéos

Je n’ai pas encore parlé des jeux vidéos qui sont vraiment un cas à part. Sachez qu’ils existent des dizaines voire des centaines de technologies pour développer des jeux vidéos. Certaines ne sont compatibles qu’avec un nombre limité de plates-formes tandis que d’autres permettent de ne développer le jeu qu’une seule fois et de le rendre compatible partout.

Une fois de plus, je passe volontairement sous silence le nom des technologies qu’il est possible d’utiliser pour développer des jeux vidéos pour vous le révéler dans le prochain chapitre.

Les parts de marché

Maintenant que vous en savez plus sur les différents types d’applications mobiles qu’il est possible de faire, il convient d’étudier les parts de marché de chacune des plates-formes. En effet, avant de lancer le développement de votre application mobile, il est important de choisir les plates-formes que vous allez viser et pour ça il faut bien connaître les parts de marché pour se poser les bonnes questions. Ai-je une chance de rentrer dans mes frais si je lance mon application sur une plate-forme qui représente moins de 1% des utilisateurs de téléphones et tablettes ?

Je vous propose donc de faire le tour des parts de marché des différentes plates-formes dans quelques pays. Ces chiffres évoluant en permanence, ce n’est pas pertinent de vous les exposer ici mais je vous invite à regarder ce site très bien fait qui regroupe les parts de marchés pour :

• L’europe (France, Allemagne, Espagne, Royaume-Uni)
• USA
• Asie (Chine, Japon)

À la vue des chiffres, il se dégage des tendances. Il semble donc assez logique de privilégier Android et iOS quand on souhaite lancer une application mobile. On peut même penser que dans certains pays, on pourrait se contenter de la plate-forme Android. Malheureusement, ce raisonnement est un peu naïf.

Ce n’est pas parce que vous lancez une application sur une plate-forme très fréquentée qu’elle vous rapportera plus d’argent qu’une plate-forme moins fréquentée. En effet, les profils des personnes qui utilisent Android et iOS sont très différents. Les téléphones sous Android étant généralement plus accessibles que les téléphones sous iOS, les utilisateurs de la marque à la pomme ont généralement un pouvoir d’achat supérieur. Aussi, pour une application proposant par exemple des fonctionnalités payantes, c’est souvent l’application iOS qui rapportera plus d’argent malgré une audience moins importante !

Aussi, suivant le business model qui vous allez mettre en place dans votre application, la plate-forme la plus utilisée ne sera pas nécessairement la plus adaptée à votre application.

En résumé

• Rentabiliser son application mobile c’est aussi rentabiliser le temps de développement de celle-ci.
• Il convient de se poser les bonnes questions quant au type de l’application que vous allez développer : application native, hybride ou cross-platform ?
• Il convient de choisir une ou plusieurs plates-formes sur lesquelles lancer son application en fonction de son business model.