Les applications natives sont développées et compilées pour le système cible où elles s’exécutent. Elles ne fonctionnent donc que sur un seul système. Elles sont généralement développées dans le langage de prédilection du système, qui diffère d’un système à l’autre. Les applications Web, ou Web apps, s’exécutent au sein d’un navigateur Internet. Ces navigateurs étant présents sur tous les systèmes, elles peuvent s’exécuter sur tous les systèmes.

Chacune des deux solutions a des avantages et des inconvénients. Selon le contexte et le type d’application, une solution sera plus adéquate que l’autre. Mais quels sont ces critères ? Comment faire le bon choix ? Analyse.

Les différents systèmes

Il existe deux familles de systèmes :

• Les systèmes traditionnels dits de bureautique (boitiers + écran, ordinateurs portables),
• Les systèmes nomades (smartphones, tablettes).

Dans la famille des systèmes traditionnels, deux grands systèmes s’affrontent :

• Microsoft Windows qui représente plus de 90 % du marché,
• Apple Mac OS X qui représente moins de 10 % du marché.

En challenger, Linux et les autres systèmes Unix qui représentent moins de 1 % du marché, mais qui sont très largement représentés sur les serveurs.

Dans la famille des systèmes nomades, l’utilisation varie fortement entre un smartphone et une tablette. Le smartphone s’utilise en déplacement, en toute situation, alors que la tablette garde un usage domestique et passif, au fond d’un canapé, chez soi, dans son salon.

Les principaux systèmes sont :

• Apple iOS qui représente 95 % du marché sur tablette et environ 50 % sur Smartphone,
• Google Android qui représente 5 % du marché sur tablette et environ 50 % sur Smartphone,
• Samsung Bada qui n’a jamais dépassé les 10 % sur Smartphone et qui est maintenant abandonné,
• Windows Phone qui est absent du marché des tablettes mais qui vient tout juste de faire une annonce à l’orée de Windows 8 et qui peine à dépasser les 2 % sur Smartphone malgré son partenariat avec Nokia et bientôt avec RIM, deux sociétés autrefois leaders dans leur segment, en pleine déconfiture maintenant,
• Blackberry OS, plébiscité historiquement par les entreprises, représentait la plus grosse part de marché des smarphones, mais depuis l’arrivée d’Apple, il ne cesse de baisser (-40 % à -50 % chaque trimestre, cela fait très mal).

Pourquoi les chiffres ci-dessus sont si approximatifs ? Car il existe un grand duel entre ces différents acteurs qui luttent pour leur survie, et les parts de marchés en nombre de terminaux sont bien différentes des parts de marchés en termes d’usage. Ainsi, bien qu’iOS n’a plus qu’un tiers de l’ensemble du parc des smartphones vendus, les terminaux iOS représentent 60 % du surf mondial et 90 % des applications payantes. En d’autres termes, les utilisateurs d’iOS, bien que dorénavant minoritaires en nombre, utilisent bien plus leurs appareils que les utilisateurs de tous les systèmes concurrents et ont tendance à acheter plus souvent avec.

Le business est surtout avec iOS. Android est le challenger. Les utilisateurs de Blackberry ne le sont que parce que leur entreprise le leur impose. S’ils avaient le choix, ils utiliseraient plutôt l’iPhone. D’ailleurs, de plus en plus d’entreprises migrent leur parc vers l’iPhone. Enfin, Windows Phone ne représente rien. Microsoft mise sur Windows 8 et son parc exceptionnel sur le marché traditionnel pour redresser la barre. Mais rien n’est gagné.

Sur tous ces systèmes, traditionnels et nomades, les mêmes navigateurs fonctionnent :

• Google Chrome, leader depuis peu de ce marché, est présent partout,
• Microsoft Internet Explorer, ancien leader, devenu challenger, ne fonctionne que sur les systèmes Windows,
• Mozilla Firefox, anciennement le premier challenger, il est maintenant le second challenger,
• Apple Safari, leader sur Mac OS et iOS, peu utilisé sur Windows et absent ailleurs, représente 5 % du marché,
• Opera, a toujours existé et a toujours représenté 1 % du marché.

Les trois premiers navigateurs se partagent environ un tiers du marché chacun.

Tous les navigateurs ont dorénavant une compatibilité similaire. Internet Explorer est en léger retrait, mais la version 8, dernière version fonctionnant sur Windows XP, est honnête, sauf pour HTML5 qu’il ne supporte absolument pas, et la version 9, fonctionnant sur Windows Vista, 7 et Phone, est acceptable, mais avec un support très partiel d’HTML5. Les versions antérieures ne devraient plus exister, puisque Microsoft a forcé la mise à jour des navigateurs vers les versions 8 ou 9 selon le système. Certaines grandes entreprises bloquent les mises à jour. Il reste donc encore quelques vieilles versions en circulation.

Ce qui va différencier les usages, c’est :

• la taille de l’écran, en général plus grande sur les postes traditionnels que les terminaux nomades, mais pas toujours avec les tablettes,
•  l’utilisation de la souris ou du doigt comme dispositif de pointage,
• la nécessité ou pas d’utiliser l’application en déplacement (via réseaux 3G et consorts).

Les marchés sont segmentés. Pour répondre à la question de cette analyse d’expert, il faudra donc étudier toutes les situations d’utilisation et les types de terminaux.

Les types d’application

Pour les besoins de cette analyse, je vais diviser les applications en trois grandes catégories.

La première est celle des applications nécessitant une carte graphique musclée, comme par exemple les jeux. Bien qu’il existe des accélérations matérielles avec les navigateurs Internet, et bien qu’en HTML5, avec le composant « Canvas », il soit possible de réaliser n’importe quel graphisme en 2D et en 3D, il y aura une large préférence à réaliser ces applications de manière native. Il existe certes un portage de Quake 2 en HTML5 qui fonctionne à merveille, mais cela reste un jeu qui a plus de dix ans. Les jeux modernes d’aujourd’hui fonctionneraient très certainement mal en HTML5.

La deuxième est celle des applications nécessitant l’utilisation des périphériques matériels du terminal (appareil photo, accéléromètre, disque dur, clé USB, imprimante…). HTML5 ouvre l’accès à certains de ces périphériques, mais on est loin de les supporter tous. Il existe une API pour récupérer les coordonnées GPS, une autre pour sauvegarder des données dans une base de données dite « Local Storage ». Mais il est impossible par exemple de lire ou écrire un fichier sur le disque dur ou la clé USB ou de prendre des photos. Le palliatif pour la sauvegarde des fichiers est d’utiliser le « cloud », c’est-à-dire un espace de stockage sur Internet. Certes, HTML5, qui est toujours en cours d’élaboration, va gommer un certain nombre de ces limitations, mais aujourd’hui, si votre application a besoin d’accéder aux périphériques du terminal, vous devrez passer par une application native.

La troisième est celle des applications manipulant des données. Cela concerne la majorité des applications existantes. Et là, l’application native et la web application sont en compétition.

Le stockage de la base de données

Une web application doit impérativement être interconnectée à un serveur distant. Une application native peut l’être, mais ce n’est pas obligatoire. Si l’ensemble des données de votre application ne sont pas trop nombreuses et s’il n’y a pas de besoin de mise à jour de ces données, alors vous pouvez omettre l’utilisation d’un serveur distant. Dans ce cas, vous préférerez une application native. Cela fait beaucoup de restrictions, cela concerne donc peu d’applications.

Dans tous les autres cas, vous aurez besoin d’un serveur distant qui sera chargé de vous fournir des données, de préférence au format JSON, qui est le plus compact et le plus universel, ou XML, qui est moins compact mais tout aussi universel. Oubliez les autres formats qui sont beaucoup moins interopérables. Préférez des services REST. Les autres techniques ont fait long feu.

Ce serveur pourra également fournir le contenu HTML, JavaScript, CSS et images si vous avez opté pour une Web application.

Les langages de développement

Bien entendu, quelle que soit la solution choisie, vous devrez programmer votre application, et cela nécessite des compétences en développement. Chaque solution fait intervenir des langages de programmation différents et donc des compétences différentes. Vous ne travaillerez probablement pas avec les mêmes développeurs selon le langage choisi.

Ainsi, les développeurs Java vont préférer les développements natifs sur Android ou Blackberry ou une web application HTML classique en J2E avec Tomcat. Les développeurs Objective C ne jureront que par iOS et Mac OS X. Normal, ce langage n’est utilisé que sur ces systèmes. De la même manière, les développeurs .Net préfèreront Windows ou Windows Phone. Là encore, ce langage n’est utilisé que sur ces systèmes. Enfin, les développeurs JavaScript vont préférer une Web Application RIA (Rich Internet Application), c’est-à-dire entièrement pilotée par le JavaScript, le serveur ne fournissant que des données et du contenu statique.

Il n’existe pas d’interopérabilité entre ces différents langages. Si vous choisissez plusieurs solutions, il faudra développer autant de fois vos écrans. En revanche, côté serveur, vous êtes libres de vos choix. En proposant une API REST qui renvoie du JSON ou du XML, cette partie pourra être mutualisée pour toutes vos applications. Il ne restera plus qu’à développer spécifiquement les écrans.

En choisissant bien votre découpage entre les traitements partie serveur et les traitements partie client, vous pouvez fortement réduire vos temps de développement, et donc votre coût.

Les animations

Tout le monde vous le dira : si vous voulez faire des animations dans votre application, ce n’est possible qu’avec un développement natif. C’est en partie vrai. Les développements natifs vous offrent une plus grande souplesse. Il existe pourtant en JavaScript des bibliothèques, comme Jquery pour n’en citer qu’une, permettant de faire facilement des animations tout à fait honorables. Vous pouvez ensuite développer vos propres animations si vous le souhaitez. Et avec le tag « canvas », vous avez la possibilité de dessiner tout ce que vous souhaitez, en 2D et en 3D. Il existe encore toutefois des limites qui sont en train d’être levées, notamment sur les performances d’exécution pour les animations les plus complexes. Si votre besoin est fort sur ce point, vous ferez peut-être le choix des applications natives.

La réactivité

Vous avez considéré pendant de nombreuses années qu’à chaque clic sur un lien d’une page HTML, une nouvelle page se chargeait. Ce traitement est un peu long et disgracieux, car il faut recharger toute la page et entre les deux pages affichées, on passe par un écran blanc. Cela est encore vrai pour bon nombre de sites Internet dits « Web 1.0 ».

En adoptant le développement « RIA », ou « Rich Internet Application » autrement dit « Web 2.0 », c’est-à-dire un développement où l’application est pilotée par le JavaScript, il n’y a pas, ou peu, de rechargement de page. L’HTML, le JavaScript, le CSS et les images sont chargées une fois pour toutes au démarrage de l’application. Il ne reste plus au JavaScript qu’à animer les différents écrans et récupérer les données sur le serveur distant via des requêtes Ajax.

Pour vous en convaincre, je vous invite à tester avec un navigateur sur tablette 10 pouces (iPad, Galaxy Tab…), la web application PMU.fr développée par mes équipes, accessible directement à l’adresse http://tab.pmu.fr.

Le réseau

Ce point est à considérer lorsqu’on est en situation nomade. Bien que nous ayons quatre opérateurs en France proposant des accès 3G soi-disant performants, il faut l’avouer, il existe bien des situations où ce réseau est très lent voire inexistant.

Il existe des solutions pour rendre ses web applications accessibles offline, mais ceci est aujourd’hui encore assez peu développé. L’avantage d’une application native, c’est que l’application est entièrement chargée sur le terminal. Les connexions au serveur distant sont donc limitées uniquement aux échanges de données. Elles sont par conséquent moins nombreuses qu’avec une web application.

Le ressenti final de l’utilisateur, c’est qu’une application native sera plus fluide qu’une web application. Pour vous en convaincre, testez l’application pmu.fr développée par mes équipes sur un smartphone (iPhone, Android, Bada, Windows Phone, Blackberry tactile…). La Web application est accessible directement à l’adresse http://mobile.parier.pmu.fr. Il existe également une application native iPhone qui est hybride, téléchargeable dans le store d’Apple. Une partie est entièrement native, alors que l’autre accède à la web application. Faites la comparaison et vous comprendrez la différence…

Les formulaires

Le développement d’un formulaire est ennuyeux, car c’est toujours la même chose. Toujours les mêmes types de données à saisir et les mêmes contrôles. Il faut avouer que la création d’un formulaire sur une application native, notamment iOS, se fait très simplement. L’effort à réaliser sur une web application, même s’il n’y a rien de complexe, est plus important.

Le son et la vidéo

Pendant très longtemps, pour jouer du son ou une vidéo sur une web application, il fallait impérativement un plugin. Et c’est le plugin Flash qui a réussi à conquérir ce marché de manière quasi-hégémonique.

Avec HTML5, il est possible de lire des flux audio et vidéo. Les principaux acteurs du marché s’y sont adaptés en proposant la lecture au choix via Flash ou via HTML5. Les acteurs secondaires n’ont pas tous fait cette transition, mais elle est en cours.

Sur les appareils mobiles, il n’est pas possible de lire du Flash. Il n’était supporté jusqu’alors que sur Android, mais Adobe, le propriétaire de Flash, vient de le retirer du marché. Avec HTML5, tous les terminaux ont accès aux flux audio et vidéo.

La visibilité

Pour être visible, rien de mieux que d’apparaître dans un store et donc, dans la majorité des cas, être une application native. C’est le cas pour iOS, Android, Bada, BlackBerry OS et Mac OS X. Seule exception notable : Windows. Microsoft n’a jamais ouvert de store et ne va corriger le tir qu’à la fin de l’année 2012 avec la sortie de Windows 8. Toujours un temps de retard. Autre exception : Chrome Web Store est l’unique store qui fonctionne avec des Web applications. Mais pour y accéder, il faut impérativement passer par Chrome. Les utilisateurs de Firefox, Internet Explorer, Safari et Opera n’y ont donc pas accès. Un choix très limitatif.

Le store est quelque chose d’important, et il est sidérant que Microsoft n’ait pas réagi plus rapidement alors que cela fait plus de cinq ans que les concurrents s’y sont tous mis. Car, en plus d’être visibles, les applications des stores peuvent être monétisées.

Monétiser son application

Il existe trois méthodes pour monétiser son application :

• En la rendant payante,
• En rendant certaines options accessibles de manière payante,
• En proposant un système d’abonnement.

Bien que cela paraisse bizarre, il est difficile de gagner de l’argent avec une application payante. En effet, l’utilisateur doit décider d’acheter ou pas l’application sur la base d’un bref descriptif et de quelques copies d’écran visibles dans le store. Ce dilemme est souvent fatal à l’achat vu qu’il existe des milliers d’autres applications. Moins l’application est chère, plus elle sera facilement achetable. Mais le mieux est qu’elle reste gratuite. Comment gagner de l’argent dans ce cas ? En utilisant les autres méthodes.

Vous pouvez avoir une application payante et une version lite, gratuite. La version lite est limitée. Elle permet de tester si l’application convient et incite à acheter la version payante. L’avantage d’une telle solution est qu’il existe un classement instantané des applications les plus téléchargées et que ce classement existe séparément pour les applications gratuites et les applications payantes. Pour un jeu, cela consiste à ne proposer que les premiers niveaux (Angry Birds a basé tout son business là-dessus) et pour une application manipulant des données, limiter le nombre de données manipulables ou la durée d’utilisation.

Autre méthode, rendre certaines options de l’application accessibles de manière payante. Par exemple, pour un jeu, les premiers niveaux sont gratuits, et pour accéder aux suivants, il faut payer directement dans l’application, sans en télécharger une nouvelle. Et si vous voulez avoir des super-pouvoirs supplémentaires, il faut payer. Le jeu de football de Gameloft est entièrement gratuit, mais pour faire un match, il vous faut des points de santé. Les points se régénèrent tout seul, mais lentement. Vous ne pouvez faire qu’un match par jour. Si vous voulez avoir plus de points de santé pour faire plus de matches, vous pouvez en acheter dans l’application. Cette méthode est très lucrative, car l’acte d’achat, qui se fait en deux clics, est impulsif. L’utilisateur est dans l’action, et il lui suffit de faire deux clics pour continuer. Il se rend à peine compte de sa dépense. La carte bleue n’est enregistrée qu’une seule fois dans le store et est utilisée de manière transparente pour toutes les applications.

Enfin, il existe des systèmes d’abonnement, journaliers, hebdomadaires, mensuels. Ils sont utilisés par exemple par les journaux périodiques… et d’autres applications bien peu intéressantes qui parient sur le fait que la personne va s’abonner pour utiliser l’application et oublier de se désabonner alors qu’elle ne l’utilise plus… C’est autant d’argent de gagné, jusqu’à ce qu’elle s’en rende compte et se désabonne…

Avec une web application, on est un peu à poil coté facturation, car tout cela n’existe pas et il faut se débrouiller tout seul. Peu de solutions satisfaisantes existent.

Utilisation unique ou multiple ?

Si votre application n’est que pour une utilisation unique, comme répondre à un sondage ou afficher une campagne promotionnelle, alors il sera préférable d’avoir une web application. L’acte de téléchargement dans le store est un peu contraignant car il faut passer par l’application adéquate et saisir son mot de passe pour autoriser le téléchargement. L’utilisateur ne le fera que s’il est motivé, c’est-à-dire qu’il pense l’utiliser plusieurs fois. Si l’intérêt de l’application ne saute pas aux yeux, elle ne sera pas téléchargée, même si elle est gratuite.

Le contrôle de l’application

Autre point négatif du store, la censure… ou le contrôle de l’application. Votre application doit répondre à certains critères, et si ceux-ci ne sont pas respectés, elle est retirée du store. Parmi les critères : la qualité de l’application, ses accès à certaines ressources, si elle plante ou pas, le langage dans lequel il a été développé (c’est ainsi que Adobe s’est fait interdire Flash) et le type d’application. Pour ne donner que quelques exemples, Google interdit par exemple les logiciels de jeux d’argent, même s’ils sont réalisées par des sociétés agréées par l’ARJEL, l’autorité de régulation des jeux en ligne, et Apple interdit les applications érotiques et pornographiques.

Apple contrôle les applications avant sa diffusion. Cela peut prendre plusieurs jours et jusqu’à deux semaines. Il est difficile de garantir la date de mise en ligne de l’application, sauf en s’y prenant longtemps à l’avance. L’application peut être refusée, parfois pour des motifs litigieux. Il faut alors la corriger en conséquence et la resoumettre, ce qui nécessite un délai supplémentaire. Pendant ce temps là, l’application n’est pas disponible. Dans le cas d’une version corrective, même combat. La correction d’un bug prend toujours plusieurs jours. Apple a droit de vie et de mort sur l’application. Si Apple décide qu’elle ne sera jamais mise en ligne, il n’existe aucun recours contre cela.

Avec Google, le contrôle est à posteriori. La version est ainsi mise en ligne plus rapidement. Mais elle peut être supprimée par la suite, quelques semaines après. Ou jamais, car Google ne contrôle que les applications qui ont eu des réclamations. Cette approche est avantageuse pour le délai de mise en ligne, mais elle laisse passer des applications malveillantes qui ne seront supprimées qu’après que certains utilisateurs en ont fait les frais.

Si le type d’application contrevient à la politique du store dans lequel vous voulez qu’il soit diffusé, il existe des stores alternatifs, mais ils ne sont connus que des spécialistes. Ce n’est pas ainsi que vous vous ferez facilement un nom auprès du grand public. L’alternative ? Faire une web application. Elle est en ligne immédiatement et ne sera jamais contrôlée. C’est le choix qu’a fait Playboy.

Le réflexe des utilisateurs

Autant sur un ordinateur classique, les utilisateurs ont l’habitude d’utiliser un moteur de recherche pour trouver le site Internet d’une marque, autant sur un support nomade, ils vont plutôt avoir tendance à chercher cette marque sur le store.

Cela n’a d’ailleurs rien de surprenant. Sur un ordinateur, il n’y a pas de store, sauf sur Mac. C’est donc logiquement le navigateur Internet qui est principalement utilisé. Sur un appareil nomade, l’expérience des web applications est tellement négative, que l’utilisateur va chercher en priorité via le store qui a une expérience utilisateur bien meilleure. Peu de sites Internet font l’effort d’avoir une version adaptée aux appareils nomades, notamment les téléphones. L’écran étant trop petit et les pages trop lourdes, car elles ont été conçues pour être affichées avec un ordinateur muni d’une connexion haut débit, l’expérience utilisateur des web applications est très négative sur les smartphones. Certes, quelques sites font des efforts, mais comme ils sont minoritaires, on tombe généralement dessus par hasard plutôt que volontairement.

L’installation

Une application native nécessite un téléchargement et une installation là où une web application est immédiatement utilisable. Ceci entraîne un délai qui est parfois préjudiciable. Vous préférerez accéder à une news via une web application pour pouvoir la lire tout de suite. Mais si vous êtes fidèle à un média, vous serez tenté de télécharger son application.

L’installation d’une application ne pose généralement pas de problème, sauf lorsqu’il s’agit d’une application de bureau, surtout sous Windows. Les administrateurs des entreprises ont en effet la fâcheuse tendance de bloquer l’installation des logiciels. L’expérience a en effet montré que l’installation de logiciels sous Windows nuisait au bon fonctionnement de Windows. Ils peuvent introduire des virus ou tout simplement pourrir le système par leur mauvaise conception. Ceci est entièrement dû à Windows lui-même, un système qui n’est pas adapté à faire tourner des applications. Un comble ! Mais comme Windows représente 95 % du marché traditionnel, on ne peut l’ignorer.

Ainsi, au sein d’une entreprise, il est préférable d’éviter toute installation de logiciel. C’est anti-productif pour de mauvaises raisons, mais c’est ainsi. Une web application est donc préférable en entreprise. Non contents d’interdire les installations de logiciels, ils interdisent également leurs mises à jour. C’est ainsi que beaucoup d’entre elles sont restées avec Internet Explorer 6, un navigateur du début du siècle, d’un autre âge, obligeant ainsi les développeurs à réaliser des développements compatibles avec cette version. En 2010, j’ai été contraint de travailler sur une web application qui devait impérativement fonctionner sur Internet Explorer 6. Autant vous dire qu’elle a du être fonctionnellement limitée.

En 2012, cette version est quasiment abandonnée par tous. Il reste à se séparer de la version 7 qui est encore présente, bien que Microsoft ait forcé la mise à jour vers les versions 8, la dernière version utilisée sur Windows XP, et 9 pour Windows Vista et Windows 7.

Il est toujours possible de passer à d’autres navigateurs. Mais là encore, certaines entreprises l’interdisent. Pour pouvoir travailler chez un client, j’ai dû signer une attestation comme quoi je m’interdisais d’installer Firefox sous peine d’être viré immédiatement. Soi-disant parce que Firefox a des trous de sécurité. Un comble pour cette entreprise qui plébiscitait Internet Explorer 6, réputé pour être la plus grosse passoire du monde. Une autre m’a interdit l’installation de Chrome, car ce logiciel envoyait des données à Google, et me limitait l’accès à Internet Explorer 7 ou Firefox 3.6 qui étaient les dernières versions qu’ils avaient validées.

L’installation et la mise à jour de logiciels dans une entreprise est un vrai problème. Une web application sera plus facile à faire fonctionner qu’une application native car il n’y a pas d’installation à faire.

Les mises à jour

Je parlais à l’instant de mises à jour de navigateurs. Mais la mise à jour de votre application est aussi à prendre en compte.

Avec une web application, il suffit de faire la mise à jour sur le serveur et instantanément, tout le monde bénéficie de la mise à jour. C’est simple, rapide et efficace. Il n’y a qu’une seule version à supporter.

Avec une application native, c’est tout autre chose. Les problèmes d’installation de logiciels que je citais tout à l’heure s’appliquent également à votre application. Il faudra donc passer par l’administrateur pour mettre à jour votre application. Il faudra faire cette intervention sur chacun des postes où cette application est installée. Et certains bloquent les mises à jour.

Autant vous dire qu’avec une application native, vous serez contraint de supporter plusieurs versions de votre application. Les anciennes qui n’ont pas été mises à jour, et la dernière. Pour pallier cela, certaines applications sont radicales. Elles cessent tout simplement de fonctionner dès qu’une mise à jour est à réaliser. Cela force les utilisateurs à faire les mises à jour, mais crée un sentiment de frustration. Surtout si les mises à jour sont régulières.

Autre point important à considérer : les bugs. Qui n’a jamais mis d’application en production sans bug ? Si un bug est trouvé en production, sa correction ne pourra être faite que par la publication d’une mise à jour qui devra être installée. Sur les environnements nomades qui permettent l’installation de dizaines de logiciels, c’est assez ennuyeux de voir chaque jour des mises à jour disponibles avec comme descriptif « correction de bugs ». De plus, cela ne fait pas sérieux. Donc, en général, on essaye de cumuler plusieurs correctifs pour limiter le nombre de mises à jour. Les bugs restent donc en ligne plus longtemps.

Alors qu’avec une web application, une simple mise à jour sur le serveur, et le tour est joué.

Les coûts

Développer une web application est beaucoup moins cher, car cela fait de nombreuses années que l’on fait des sites. Oui, c’est vrai. Mais aujourd’hui, une web application classique n’est plus suffisante. Il faut rajouter du RIA et des effets graphiques, voire développer l’application en HTML5. Et là, le coût est forcément plus élevé car les compétences sont plus rares. Il est en effet difficile de trouver de bons développeurs JavaScript réellement compétents. Et pourtant, ce langage est né avec HTML, il y a quinze ans. Mais il a été si longtemps négligé, et dans le même temps il a tellement évolué, qu’aujourd’hui, les compétences JavaScript sont rares.

Pour ce qui est des développements natifs, côté Android, les développeurs Java existent à foison et côté iOS, bien qu’Objective-C ne soit utilisé que depuis 5 ans, les développeurs sont maintenant très nombreux. Du côté de Windows, la population de développeurs est là encore assez importante.

On peut donc considérer que, grosso modo, chaque développement a un coût équivalent si l’on est entouré des bonnes compétences. Mais bien entendu, si l’on considère que chaque développement a sensiblement le même coût, développer plusieurs applications natives coûte plus cher que de développer une seule web application.

Les solutions hybrides

Les solutions hybrides consistent à utiliser des frameworks de développement spécifiques qui permettent de générer automatiquement le code pour tous les systèmes cible… enfin, les principaux. Il y a par exemple Titanium, PhoneGAP et les solutions d’Adobe basées sur Flex.

Ces solutions peuvent être utilisées pour certaines applications relativement simples, mais il faut comprendre qu’en proposant une compatibilité multi-OS, on fait un nivellement par le bas en ne permettant d’utiliser que les fonctionnalités qui sont communes à tous les OS.

Je vous invite à lire l’analyse d’expert « Titanium studio 2 : les développements natifs nomades multiplateformes » pour en savoir plus sur les deux premier frameworks.

L’opinion de Valtech

Le 5 avril 2012, j’ai eu la chance de participer à une conférence de Valtech sur le même thème que cette analyse d’expert. Ils ont, tout comme moi, dit que la solution était plutôt du 50/50, mais pour des raisons différentes. J’ai trouvé leur argumentaire un peu léger : ils ne sont pas allés assez loin dans leur réflexion. Mais le public, composé pour moitié de personnes ayant déjà travaillé sur les nomades, devait malgré tout être satisfait de cette première approche. Je vous invite à lire le support « Valtech : Best of Mobile – App vs. WebApp » qui a servi à la présentation. Le support est assez succinct mais il y a les grandes idées.

La seconde partie de la conférence était en revanche plus intéressante, car quatre responsables d’entreprise étaient invités pour parler de la manière dont la mobilité avait été déployée chez eux. Et justement, ces quatre intervenants ont présenté quatre approches bien différentes, ce qui montre bien que la réponse n’est pas toute faite.

En conclusion

En conclusion, pour ceux qui n’ont pas eu le courage de lire toute l’analyse, il n’y a pas vraiment de vainqueur. C’est plutôt du 50/50, et le choix se fait en fonction du contexte.

Pour les applications nécessitant impérativement l’accélération matérielle ou l’utilisation de périphériques, l’application native s’impose. Pour les applications manipulant des données, selon le contexte, le match est disputé. Tout dépend des critères que l’on privilégie.

Pour récapituler, voici une table de critères qui vous permettra de faire votre choix :

0 : n’est pas du tout approprié, 1 : l’est un peu, 2 : une bonne solution, 3 : excelle dans son domaine.

Critère	App Native	Web App
Nécessite l’accélération matérielle sur la carte graphique	3	0
Accès aux périphériques matériels du terminal	3	0
Fonctionnement offline	2	1
Manipulation de beaucoup de données nécessitant un serveur	2	2
Un développement disponible sur tous les systèmes	0	3
Environnement de développement	2	1
Animations graphiques	2	2
Réactivité de l’application	3	2
Expérience utilisateur	3	1
Limiter au maximum les connexions réseau	2	1
Création de formulaires rapidement	2	1
Visualisation de vidéos et écoute d’audio	2	2
Visibilité sur un store	3	1
Monétisation de l’application	3	1
Ce que l’utilisateur imagine / réputation de ce type de solution	2	1
Contrôle de l’application / censure	1	3
Installation de l’application sur un appareil nomade	2	3
Installation de l’application sur un ordinateur en entreprise	1	3
Mises à jour de l’application	1	3
Nécessité de supporter plusieurs versions de l’application	0	3
Correction rapide des bugs	1	3
Coûts de développement pour une seule cible	2	2
Coûts de développement pour plusieurs cibles	0	3

Avec tous ces éléments, avez-vous pu faire votre choix ? Pour information, la somme de chacune des deux colonnes est de 42. Quand je vous disais que c’est du 50/50…

Nota : la somme n’a pas été choisie par hasard 😉 Bonjour aux connaisseurs.

L’ère du temps

En matière d’applications manipulant des données, l’ère du temps n’est plus aux applications natives sur Windows et Mac OS, c’est-à-dire sur PC. Cela fait bien longtemps que les web applications ont pris le dessus, y compris pour les applications qui correspondaient au pré carré des applications de bureau (mail, traitement de texte, tableur, présentation…).

Les web applications ont encore de longues années devant elles, car elles sont universelles. Elles fonctionnent sur tous les types de terminaux, et la tendance est d’adapter les applications aux différentes tailles de terminaux plutôt qu’à faire autant d’applications que de tailles de terminaux.

Les applications natives sur terminaux nomades ont eux aussi de beaux jours devant elles car les téléphones et les tablettes vont représenter la majorité des usages de l’informatique au détriment des PC, et ces applications offrent en général une expérience utilisateur supérieure aux web applications.

D’ailleurs, Microsoft ne s’y est pas trompé. Alors qu’il arrive avec cinq années de retard sur le marché nomade, il a décidé de rattraper son retard avec un système d’exploitation permettant à la fois de faire du nomade et du PC de bureau.

En conclusion, oublions les applications natives sur PC, privilégions les web applications pour cibler un public le plus large possible et investissons dans les applications natives nomades pour améliorer l’expérience utilisateur.

Franck Beulé
Chef de projet Agile, expert des technologies de l’Internet et en ergonomie du Web