Les applications hybrides : ce monstre congénital du développement mobile
Depuis plusieurs années, les applications hybrides font de belles promesses. Pourquoi veut-on encore croire à ces promesses ? Petite rétrospective…
À propos de votre serviteur
Depuis 2008, je suis développeur freelance. J’ai pu participer à de nombreux projets mobiles, dont certains ont été au top de l’App Store. Surtout sur iOS, mais aussi quelques-uns sur Android. Toujours en natif, sauf qu’en j’ai du reprendre des projets existants. J’ai également une bonne expérience du web, avec de nombreux projets de sites et services web à mon actif.
Avant le mobile : le web
La tendance depuis les années 90–2000, c’est le web. Le HTML, le Javascript, le CSS : c’est facile, c’est magique.
Le web permet de concevoir des solutions sans connaissances techniques liées aux couches basses. Inutile de connaître le fonctionnement d’un ordinateur ou du réseau HTTP pour concevoir un site sympa.
Puis est arrivé le mobile
Tout a commencé avec les jeux Java (J2ME, une version allégée de Java optimisée pour l’embarqué).
Nokia a pris ensuite le relais avec Symbian, qui permettait d’avoir des applications natives. GPS, jeux mobiles.
C’était réservé à quelques experts du développement, mais c’était un premier pas prometteur.
29 juin 2007 : arrivée de l’iPhone
L’iPhone a été présenté il y a 10 ans par Steve Jobs. Avec un vrai navigateur mobile. Des applications sympathiques. Une ergonomie agréable.
11 juillet 2008 : lancement de l’App Store
Au moment du lancement de l’iPhone OS 2.0, Apple en a profité pour lancer son magasin d’applications mobiles : l’App Store.
Ce fut l’occasion rêvée pour les développeurs du monde entier de concevoir des applications de qualité.
23 septembre 2008 : arrivée d’Android
Le succès de l’iPhone a fait des envieux : Google a suivi cette tendance pour créer un smartphone approchant. Le premier Android était né.
22 octobre 2008 : lancement de l’Android Market
Les développeurs Java ont pu lancer eux aussi des applications mobiles sur le magasin d’applications mobiles Android.
Le développement mobile : le retour du natif
Les premiers smartphones n’avaient pas les performances des smartphones actuels, sans parler des limites liées aux réseaux 2G : une connaissance parfaite de l’OS était nécessaire pour concevoir des applications efficaces.
Un retard immédiat pour les grandes entreprises
Les grandes entreprises ont mis du temps à comprendre les enjeux du mobile.
Au mieux, le mobile était considéré comme un outil marketing tendance.
Mais rares étaient ceux qui comprenaient que le mobile allait faire partie intégrante de leur produit. D’ailleurs, de nombreuses entreprises ne l’ont toujours par compris.
Le mobile coûte cher, le web suffit (en apparence)
Les compétences en interne étant surtout orientées vers le web, la technologie la plus moderne de l’époque (moins de 20 ans !). Inutile d’investir dans le mobile qui représente un coup supplémentaire.
Seulement, les clients et consommateurs en ont décidé autrement…
Et là, c’est le drame
Contrairement à toutes les prédictions, les smartphones se sont développées à vitesse grand V.
Les consommateurs ont souhaité avoir des applications mobiles pour les services.
Bref. En quelques années, les plateformes mobiles se sont développées dans une proportion incroyable. Les outils de développement ont évolué.
Et personne n’était prêt dans les grandes structures.
Puis vint le miracle de l’hybride
En 2011, le monde du développement découvrait PhoneGap.
Aucune compétence mobile nécessaire
Un miracle pour le budget des grandes entreprises : inutile de former ses développeurs ou recruter de nouvelles compétences.
Cet outil miraculeux permet d’avoir le même résultat qu’une app native sans compétence mobile.
Un développement pour plusieurs plateformes
iOS, Android ? Aucun soucis. Il suffit de réaliser un seul code dans le même langage qu’autrefois et on peut concevoir une app qui fonctionne partout.
Un plugin pour tout
Besoin d’accéder au GPS ? Il y a un plugin pour ça !
Besoin d’accéder aux SMS ? Il y a un plugin pour ça !
Dès qu’une fonctionnalité n’existe pas sur du web, un plugin est conçu par un développeur pour accéder à cette fonctionnalité. C’est magique. Ces petites rustines permettent de combler sans fatigue les lacunes technologiques.
La douche froide
Au bout de quelques années, la réalité est revenue en pleine face aux équipes de développement.
Cette solution était un recul pour mieux sauter.
Des performances en retrait
Les solutions hybrides utilisent le moteur de rendu web du système hôte. Avec des performances de fait inférieures aux performances natives. Et donc une expérience utilisateur qui en pâtit.
Des plugins vite abandonnés
Les plugins étaient conçus pour être utilisés ponctuellement. Puis une bonne partie d’entre eux a rejoint le cimetière des plugins.
Sauf que les OS ont évolué. Aussi bien concernant ces fonctionnalités que les nouvelles fonctionnalités et nouveaux usages.
Une expérience utilisateur (UX) en décalage
Les utilisateurs iOS ont des réflexes sur iOS. Et les utilisateurs Android ont d’autres réflexes propres à leur mobile.
Sans connaissance de ces guidelines, les applications hybrides sont en décalage avec l’environnement habituel de l’utilisateur.
L’effet est alors dramatique : l’utilisateur se rend immédiatement compte qu’il a affaire à un outil très technique. La supercherie ne fonctionne pas.
Une chaine de dépendances infernale
Au-delà des plugins, les solutions hybrides dépendent indirectement des outils natifs.
Un exemple concret vaut mieux qu’un long discours. J’ai simplement mis à jour le SDK Android. Et là, tout est cassé sur Cordova. Je suis bloqué.
Des compétences nécessaires multipliées
On pourrait croire qu’il suffit de connaître les technologies web pour s’en sortir avec les solutions hybrides. Malheureusement, ce n’est pas le cas.
Il faut aussi connaître :
- la plateforme hôte (Android et/ou iOS), ne serait-ce que pour pouvoir compiler l’app sur toutes les plateformes et s’approprier les impératifs de chacune
- le framework intermédiaire (Cordova ou autre), qui fait le lien entre le web et le natif
- les différents plugins qui permettent d’accéder aux fonctionnalités natives
- éventuellement, les bases du natif, si a besoin de concevoir des plugins pour des besoins spécifiques (ce qui induit la connaissance des outils de conception de plugins)
- et les différents frameworks permettant d’imiter les interfaces natives en web.
Un coût de maintenance qui explose
Dans la plupart des cas, la méconnaissance de l’OS natif a un effet de bord pervers : le moindre changement lié à une mise à jour iOS ou Android devient une usine à gaz à maintenir.
Google et Apple n’ont pas conçu leurs OS pour du web ou du pseudo-code bricolé : leurs OS sont conçus pour faire fonctionner des apps native.
Une décadence qui s’accélère
Alors que vous vous acharniez à maintenir une application hybride, en montant en compétences sur les différentes technologies web et hybrides, le monde mobile a évolué.
Et les technologies mobiles ont dépassé le cadre du smartphone.
La sécurité
Aujourd’hui, la sécurité est un problème majeur. Tout s’accélère. Et, malheureusement, rien n’est plus simple à pirater qu’une app hybride.
Surtout au travers des attaques Man-in-the-Middle. En quelques lignes de commande, on peut faire sauter la sécurité HTTPS et injecter du code Javascript… exécuté par l’app. ( Essayez vous-même avec Kali et MITMf : c’est vraiment simple )
En parallèle, les systèmes natifs renforcent leur sécurité et simplifient la sécurisation. Que ce soit sur iOS ou Android.
L’expérience utilisateur
Le passage de iOS 6 à iOS 7 (Flat Design) ou le passage de Android 4 à Android 5 (Material Design) auraient du mettre la puce à l’oreille.
Et pourtant, rien n’a été fait. Chacun a conservé une UX désastreuse liée en partie à une UI native non respectée.
De nouveaux usages
Que ce soit les extensions d’apps (iMessage, photo, widgets, documents externes, notifications enrichies, intégrations à Siri / Google Assistant) ou la diversité des supports (smartphone, tablette, boîtier TV, ordinateur, montre connectée, réalité virtuelle, réalité augmentée, assistant intelligent, moteurs de recherche intégrés) : rien de tout cela n’est considéré pour un usage hybride.
Pour Apple comme Google, chacun propose une approche similaire :
- du natif pour les interfaces graphiques
- du service web pour les données externes
- du web… pour le web.
Ce sont autant de cas qui paraissent aujourd’hui marginaux et qui seront demain le standard de l’usage numérique.
React Native : hybride 2.0
React Native se veut comme étant une technologie formidable qui propose les performances du natif tout en conservant une ergonomie cohérente par rapport à l’OS (iOS / Android).
Évidemment, c’est de nouveau une illusion. La chaîne de dépendances reste horrible. La méconnaissance des interfaces propres aux OS apporte des résultats médiocres.
Au final, ce n’est utile que dans 2 cas :
- si vous devez construire une app éphémère et que vous ne connaissez vraiment rien au natif
- si vous avez une énorme équipe mobile et que vous souhaitez gagner du temps.
Pour le reste, ce n’est pas judicieux. C’est de l’économie de bout de chandelle qui risque au final de coûter très cher.
Et maintenant, on fait quoi ?
Comme tout le monde, vous vous êtes laissé séduire par le modèle hybride.
Chacun a droit à l’erreur
Ne vous blâmez pas : la présentation est séduisante. Quand on ne connait pas une technologie, on préfère en général rester dans son domaine de compétences.
Écoutez vos développeurs
Si vous êtes un décideur, vous auriez peut-être du écouter vos développeurs en amont. Ce sont eux qui sont au coeur du métier.
Vous n’imposez pas vos outils à votre maçon, votre jardinier, votre restaurateur ou votre assistante ? Pourquoi le faire avec les développeurs ?
Arrêtez tout
Inutile de courir après de nouvelles fonctionnalités.
Arrêtez les développements et focalisez-vous sur les performances. Et donc la réécriture en natif.
Vous irez plus vite pour la suite. Vous ne serez plus au pied du mur.
Pensez avant tout aux utilisateurs
Vous ne devez pas créer une app pour avoir une app.
Tout ceci doit avoir du sens. L’app fait partie de votre produit.
Apprenez à connaître vos utilisateurs. Leurs usages du mobile. Et focalisez-vous là-dessus.
Faites moins, faites mieux.
Une app ne doit pas être une copie mobile d’un site web.
Une app (mobile, tablette, assistant vocale, ou autre) est le plus court chemin entre votre utilisateur et vous.
Utilisez les outils offerts par les constructeurs
Arrêtez de réinventer la roue.
Si vous êtes les meilleurs dans votre métier, vous êtes bien loin de connaître les subtilités qui ont amenés Google et Apple au succès.
Écoutez. Observez. Apprenez.
Google et Apple vous propose des outils qui vous permettront d’offrir de meilleurs services à vos utilisateurs en vous rapprochant d’eux au maximum.
Et ils sont bien meilleurs que vous dans ce domaine.
Suivez-les plutôt que de vous obstiner.
Si aujourd’hui vous avez encore une chance de vous rattraper, n’oubliez pas que d’autres trains sont en marche : le vêtement connecté (écouteurs, montres), la maison connectée (Google Home, HomeKit), les assistants (Siri, Google Assistant, Alexa, Facebook Messenger), la voiture connectée (Carplay, Android Car), la TV connectée (Apple TV, Android TV), la réalité augmentée, la réalité virtuelle. Et bien d’autres.
Faites preuve de modestie et conformez-vous aux exigences des principaux acteurs du marché. Cela vous permettra de vous focaliser sur votre domaine de compétence premier : votre métier. Le reste, c’est pour Google et Apple.
