Application hybride : comment éviter l’échec du projet à cause de mauvaise performance ?

Posted on by Olivier PHILIPPOT
Reading Time: 4 minutes

À l’heure de la digitalisation et de la forte croissance de la mobilité, le développement des applications mobiles est devenu stratégique pour toutes les entreprises.

Le challenge des applications mobiles actuelles

Les multiples écrans mobiles sont en effet devenus les interfaces privilégiées de tous les services (numériques ou non) : guichet pour les banques, formulaire pour les opérateurs, vitrine pour le commerce… Ce positionnement stratégique dans la chaîne de valeur de l’entreprise implique une pression forte sur les équipes de développement : plannings serrés, besoin de couvrir différentes plateformes (iOS, Android…), nécessité de repartir du système d’information existant… Cette pression implique des choix techniques sur les technologies et les architectures qui répondent au mieux à ces besoins.

Si les choix d’architecture permettent dans un premier temps de répondre aux contraintes du marché, ils posent de nombreux problèmes lorsque l’application arrive en production. En effet, ces choix ne prennent pas forcément en compte tous les critères (performance, consommation d’énergie, dette…). GREENSPECTOR intervient malheureusement fréquemment suite à des mises en production avec des problématiques critiques : performances non satisfaisantes, impact sur la batterie trop élevé… Et les applications hybrides sont souvent la cause de ces problèmes.

En effet, l’efficience est un des critères les plus importants pour le succès d’une application. Les utilisateurs sont en attente de rapidité mais veulent aussi des smartphones qui durent. Il est important de bien choisir la technologie en prenant en compte bien sûr les contraintes projet et marché mais aussi ce besoin utilisateur. Sans cela, on risque un écueil du projet. Dans le projet d’un choix de technologie déjà acté et d’une application en production, l’amélioration est cependant possible.

État de l’art des architectures mobiles

Il est nécessaire de bien distinguer les différentes technologies pour développer une application mobile :

  • Les applications natives sont développées dans le langage supporté par la plateforme. Pour Android : Java ou Kotlin. Pour iOS : Objective-C. L’avantage est que l’application sera optimisée pour la plateforme. Le problème est qu’il est nécessaire de développer autant d’applications que de plateformes couvertes.

  • Les applications hybrides vont permettre d’utiliser des technologies non-natives aux plateformes mobiles et principalement des technologies web. L’avantage est de pouvoir utiliser du code qui aura potentiellement été déjà développé pour du web ou tout simplement de développer une application mobile avec des équipes web. La technologie la plus répandue est Cordova mais React Native devient de plus en plus présente.

  • Les Progressive Web App (PWA) sont la suite logique des applications hybrides. Les navigateurs mobiles et la norme HTML ayant intégrés des capacités de communication avec la plateforme (Bluetooth Low Energy par exemple), il est maintenant possible de développer une application en full web.

Critères de choix pour une architecture et écueils

Les critères de choix lors du lancement du projet reposent principalement sur trois points :

  • Les développeurs sont principalement Web
  • Il existe déjà beaucoup de solutions (legacy, CMS…) pour le web qui vont me permettre d’aller plus vite
  • On va aller plus vite car il n’y a pas deux applications (iOS et Android) à développer.

Le calcul économique semble en effet simple. Cependant il est important de faire un calcul sur la totalité du cycle de vie de l’application.

Il est donc nécessaire de bien identifier en amont les potentiels problèmes que l’on va rencontrer :

  • L’encapsulation des technologies web amène des problèmes d’outillage. Par exemple, une fois encapsulée dans une application Cordova, une application web sera difficilement analysable. Il est sera difficile de suivre la consommation de ressources, le comportement interne… dans les outils natifs. Rien d’impossible (par exemple via les outils de remote debugging de Chrome) mais une barrière que certaines équipes ne voudront pas passer. Au final, on arrivera à un développement maîtrisé sur la partie web mais avec un comportement boîte noire sur la plateforme finale.
  • Les librairies, code legacy ou CMS initialement conçus pour le web ne prennent pas en compte les contraintes des plateformes mobiles (Connexion radio avec un comportement différents du wifi, non optimisation…). Et même si une adaptation aux plateformes mobiles a été faite, la conception et l’architecture initiales ne pourront pas être changées. Au final, on risque d’intégrer des mécanismes non optimaux pour les plateformes mobiles.
  • Dans le cas de technologies comme Cordova, le framework initial est lourd en termes de ressources. Il faut compter plus de 100 Mo de consommation mémoire pour faire tourner Cordova (contre quelques dizaines pour une application native). On ne pourra pas optimiser ce talon de consommation.

Le risque sur l’application finale est d’avoir des impacts sur la fluidité et la performance de l’application. Nous avons observé des temps de chargement de plus de 10 secondes sur des vues d’application alors que 2 secondes auraient pu être réalisées en natif, des crashs mémoires d’applications réparties sur plusieurs APK, des consommations d’énergie amenant à des autonomies non acceptables… Au final, ces écueils nécessitent l’analyse des équipes, l’intervention d’experts externes, des projets de refactoring, des nouvelles campagnes de validation… Sans compter l’impact économique d’une application non performante pour l’utilisateur.

L’analyse économique simplifiée en début de projet ne tient alors plus la route.

Mon architecture a été mal choisie, que faire ?

Si vous êtes dans le cas d’une application hybride, il est possible que tout aille bien (Affichage à moins de 3s en 2G, pas d’impact sur la batterie, consommation faible sur des devices Low End…). Si cela n’est pas le cas, il est toujours possible d’améliorer la performance en s’outillant et en appliquant des bonnes pratiques d’écoconception ou de performance. Cependant, il est probable que vous n’arriverez pas à l’efficience équivalente d’une application native, tout dépend du niveau d’efficience que vous voulez pour l’utilisateur.

Si les technologies web sont un axe que vous souhaitez quand même utiliser, il sera préférable d’étudier les technologies comme React ou les applications PWA. Les promesses de performance sont plus importantes pour ces technologies. Cependant, comme toute nouvelle technologie, ces promesses peuvent ne pas être au rendez-vous. Il est alors important d’une part de benchmarker les solutions avant de les choisir (Etude de l’impact sur les ressources, performance du « Hello World »…) et d’autre part de mesurer en continu l’impact de votre application. En effet, quelle que soit la technologie, l’intégration de librairies tierces ou de mauvaises pratiques annulera les efforts initiaux d’optimisation.

Dans une optique d’efficience maximale, les technologies natives seront à privilégier. Le point d’attention des technologies web (contrôle d’une dérive potentielle de la consommation) est cependant toujours vrai.

Pas de solution miracle donc, il faut contrôler en continu (Lors du choix des technologies, du développement et de la maintenance) la consommation de ressource et la performance des applications. En effet les promesses de performance et de développement rapide des frameworks et de librairies est peut-être véridique, l’entropie des logiciels est systématiquement vérifiée. Il existe une seule façon de le contrôler : la mesure en continu.