1 – Introduction
Vous est-il déjà arrivé de développer une application, en partant sur une technologie, et de vous rendre compte en cours de route que finalement, votre solution technique n’est plus adéquate car votre besoin a changé ? Vous êtes alors bloqués dans vos évolutions fonctionnelles ou vous passez trop de temps à faire des choses qui auraient été bien plus simple sur un autre socle technologique.
Chez Haute Couture, la maison de développement d’enioka, on audite souvent des applications pour répondre à ces problématiques. Il nous faut trouver, et développer, la bonne solution technologique pour satisfaire les besoins de nos clients.
Le cas classique c’est une société qui développe une application web et qui change soudainement de direction pour l’adapter ou la porter sur plateforme mobile, ce qui n’est pas sans conséquence en termes de coûts et d’expérience utilisateur.
Aujourd’hui il existe 5 grandes manières de développer, ou d’adapter des applications web existantes, en applications mobiles. Dans cet article nous allons les présenter rapidement, exposer leurs forces et leurs faiblesses, pour vous aider à trouver la solution adaptée à vos besoins au travers d’un cas client rencontré par nos équipes.
2 – Contexte client
Depuis 3 ans, notre client développe une application web, en ReactJS, pour ses collaborateurs. L’application est responsive et peut déjà être utilisée depuis des appareils mobiles.
L’évolution des besoins métiers, et notamment des usages liés à l’Internet des objets (IoT), les ont amenés à vouloir exploiter la technologie Near-field Communication (NFC) pour permettre aux agents d’interagir directement avec des objets physiques sur le terrain.
Chaque utilisateur dispose d’un téléphone Android et accède déjà à l’application depuis son navigateur mobile sur les lieux d’intervention où la connectivité n’est pas toujours fameuse, ce fut un critère important à considérer sur cette mission.
L’enjeu de cette mission, fut donc de faire évoluer une application existante, en utilisant le plein potentiel du hardware des téléphones Android pour capter des données à partir d’objets connectés, le tout dans un environnement à la connectivité capricieuse.
3 – Les scénarios envisagés
Dans ce chapitre nous allons aborder les solutions technologiques possibles pour développer une application mobile en 2023.
Je vous propose d’en faire une revue rapide car il existe bon nombre d’articles qui détaillent le fonctionnement de chacune de ces technologies, et nous vous proposons en annexe des liens pour approfondir vos connaissances sur chacune.
Chaque contexte étant spécifique nous allons définir rapidement les avantages et inconvénients de ces différentes options dans notre contexte client.
3. 1 – le Natif
Est considérée comme “native” une application développée spécifiquement pour une plateforme cible (iOS ou Android) en utilisant le langage officiel de son SDK (Swift pour iOS, Java ou Kotlin pour Android).
Le développement de ce type d’applications est simplifié par des IDE puissants (Android Studio & XCode) qui intègrent des émulateurs de smartphones, facilitent la création d’interfaces via des outils graphiques et d’autres outils qui facilitent grandement le travail du développeur. De plus, les bibliothèques évoluent en même temps que le système d’exploitation, alors créer une application native permet de s’assurer d’avoir accès aux dernières fonctionnalités de l’OS et de limiter le nombre de dépendances.
Développer deux applications, une pour iOS et une pour Android, rime avec plus de temps de développement, l’investissement pour l’entreprise est donc plus important et demande la maîtrise des deux langages de programmation (Java & Swift), ce qui n’est pas le cas pour notre client.
On peut partir sur une application native lorsque l’on a un fort besoin fonctionnel sur nos applications mobiles et que l’on veut s’assurer d’avoir toutes les cartes en main pour faire évoluer notre application dans de meilleures conditions. Bien évidemment, il faut aussi être en mesure de mettre en place l’investissement nécessaire.
Pour notre client cela reviendrait à re-développer entièrement l’application web existante et de renforcer les équipes techniques pour s’adapter à ces technologies.
3. 2 – Le cross plateforme
L’idée du cross plateforme est d’avoir une seule base de code interprétée et traduite pour les systèmes d’exploitation iOS et Android. Pour cela il existe deux principaux frameworks : React Native et Flutter.
A – React Native
React Native, créé en 2015 par Facebook en Open Source, est un framework qui permet de développer une application mobile une seule fois et de la déployer sur toutes les plateformes en utilisant la bibliothèque React JS.
Pour notre cas client on pourrait se dire, parfait, notre site web étant développé en React JS la bascule vers cette technologie sera simple.
Pas forcément, adapter un code web React JS en cross plateforme demandera de re-développer toute votre application. Même si le langage et l’architecture de base sont similaires (utilisation des states, props et JSX), vous allez devoir exploiter des composants mobiles spécifiques. Le routage ne pourra pas être géré de la même manière et les interactions utilisateurs seront différentes (maintenir appuyé, scroll view, swipe…).
Pour notre client, partir sur cette technologie demanderait de redévelopper l’application web existante mais permettrait de garder les mêmes équipes techniques et peut être, si l’architecture initiale est bonne, de récupérer des parties du code existant comme certains composants front.
La plupart des composants graphiques mobiles classiques sont déjà implémentés dans le core de React Native (menu de navigation, listes, boutons… *) et sont simples à intégrer à votre future application. Néanmoins, de nombreux composants sont eux développés par la communauté pour combler les manques, qui sont autant de dépendances supplémentaires à gérer en termes d’obsolescence, de licences et de sécurité.
*composants graphiques disponibles en React Native : https://reactnative.dev/docs/components-and-apis
B – Flutter
Développé en 2017 par Google, il permet de créer des applications cross plateforme en Dart, qui est un langage de programmation récent (2011) pensé pour développer rapidement des interfaces graphiques.
Flutter est rapidement devenu populaire dans le développement d’application cross plateforme.
Lors de sa sortie, ce framework dépassait de loin en termes de performance son concurrent grâce à son moteur majoritairement écrit en C++.
Flutter étant inspiré de React JS, il permet de décrire et gérer simplement les états des composants graphiques sans imposer l’utilisation du Javascript. Il implémente des codes connus des développeurs et est très facile à prendre en main.
C – Notre avis
Créer une seule application pour deux OS permet de gagner en temps de développement mais perd en finesse dans l’implémentation graphique des composants applicable à chacune des plateformes.
De plus pour cette solution et toutes celles qui vont suivre, si une nouvelle fonctionnalité est disponible côté hardware et système d’exploitation (le NFC par exemple), vous devrez attendre son implémentation en React Native et Flutter.
Pour mener cette étude nous avons choisi d’investiguer ces deux outils pour procéder à un choix éclairé et éviter de favoriser une piste plutôt qu’une autre.
A moins d’avoir une équipe de développeurs déjà habitués à React JS et ainsi limiter le temps de montée en compétence, Flutter est selon nous plus intéressant que son concurrent. Dart est un langage simple à prendre en main, typé, et Flutter propose de meilleurs outils de développement mais aussi de meilleures performances.
Flutter a la réputation de disposer de moins de bibliothèque tierces que React Native, ce qui peut lui être reproché, cependant, les bibliothèques existantes sont de qualité. On retrouve l’ensemble des composants nécessaires pour développer la plupart des applications, et on évite de dépendre de bibliothèques non maintenues et présentant des failles de sécurité.
3. 3 – L’hybride
Pour faire simple, une application hybride c’est un site web exécuté dans le navigateur du téléphone sans en informer l’utilisateur et qui simule le rendu d’une application mobile, via ce qu’on appelle une webview. Cela permet d’utiliser des technologies web (HTML, CSS, JS) ou des frameworks (React JS, Vue JS, Angular…) en ciblant des plateformes mobiles.
Cordova par exemple permet de créer une surcouche à votre application web existante pour en faire une application mobile disponible depuis le store. Cette surcouche permet d’exploiter certaines fonctionnalités hardware du téléphone (caméra, géolocalisation, NFC…) et même utiliser des systèmes de sauvegardes de données locales pour implémenter des fonctionnalités hors ligne.
Une application web responsive peut facilement être déployée en webview via Cordova ou un framework similaire.
Vous devrez néanmoins maintenir cette application en parallèle de votre site web pour adapter certains comportements, ce qui n’est pas “gratuit” en termes d’investissement, et les performances seront bien moindre qu’une application native ou cross plateforme. Certaines interactions propres à l’utilisation mobile ne pourront être implémentées. Par exemple, pour savoir si un utilisateur maintient un bouton enfoncé, en pur web JS, on devra implémenter un chronomètre, alors qu’avec Flutter on dispose d’une API onLongPress() ou OnLongClickListner() pour Android afin d’identifier cette interaction.
Cette solution est envisageable pour notre client, il pourrait réutiliser son application existante, en faire une version mobile pour ses utilisateurs et ainsi avoir accès à la fonctionnalité NFC dont il a besoin sans avoir à renouveler sa stack technique.
Gardons cette option en tête mais allons plus loin dans les options qui s’offrent à nous.
3. 4 – La PWA
PWA pour progressive web app est le niveau d’après du portage pur et simple d’un site web en application mobile. Depuis le site web, sur son navigateur mobile, l’utilisateur peut tout simplement ajouter le site parmi ses applications mobiles. Celle-ci fonctionnera comme une application hybride en encapsulant l’ensemble des pages web dans des webview.
Cela permet d’apporter une expérience mobile facilement à un site web existant.
Contrairement à une application hybride, celle-ci ne pourra pas disposer des API permettant d’accéder aux fonctionnalités hardware du téléphone, étant donné que l’application est exécutée via un navigateur. Néanmoins certains navigateurs ont développé des ponts pour permettre aux applications via des API du navigateur de communiquer avec certaines fonctionnalités hardware, si disponibles, dont nous parlerons plus tard dans cet article.
A noter également que l’application mobile EST le site web, ce qui peut être positif étant donné que vous n’aurez pas à maintenir différentes applications en parallèle mais peut avoir l’effet pervers de complexifier votre site. Par exemple si vous décidez d’implémenter de nombreuses fonctionnalités dépendantes de la plateforme sur laquelle il est exécuté, ce sont des comportements conditionnels supplémentaires qui peuvent rendre votre application plus complexe à tester.
Comment ça marche ? Le développeur ajoute un fichier au code source qui va contenir tous les éléments nécessaires à l’exécution en mode mobile (un logo, un nom, une couleur de fond attendu, le mode d’affichage, l’orientation…)
L’utilisation hors ligne est rendue possible via le service worker qui va se positionner comme un proxy** entre votre application, le réseau et le navigateur. Il va intercepter les requêtes et selon l’état du réseau agir en conséquence. S’exécutant sur un processus propre à l’application différent de celui utilisé pour rendre les vues, il peut télécharger et mettre à jour les données de l’application en parallèle de son exécution.
Les PWA peuvent utiliser certaines fonctionnalités du système de notification du téléphone de l’utilisateur.
Pour transformer son application web en PWA vous devez respecter un certain nombre de critères. L’outil Lighthouse permet d’évaluer facilement l’éligibilité de votre application et les améliorations possibles.
Exemple avec le site pinterest.fr :
Aucun déploiement sur les stores des plateformes ciblées n’est nécessaire avec une PWA. L’utilisateur télécharge l’application directement depuis le navigateur. L’application n’est donc pas disponible depuis le store.
La PWA est la solution peu coûteuse pour décliner un site web en application mobile. Cette économie n’est pas sans concession, il faut accepter des performances limitées, de ne peut-être pas avoir accès à des fonctionnalités hardware, et une expérience utilisateur qui ne pourra pas être adaptée à 100% à un usage mobile.
Cela dit, certaines fonctionnalités comme la caméra, la géolocalisation ou le NFC peuvent être accessibles via votre navigateur et donc via PWA. Cela dépend entièrement du navigateur choisi par l’utilisateur. Vous pouvez retrouver la liste de ce que votre navigateur est capable de faire ici : https://whatwebcando.today/
3. 5 – Évaluation des scénarios
Revenons-en à nos moutons. Notre client dispose d’une application web en React JS, il souhaite permettre à ses utilisateurs d’utiliser la technologie NFC sur leurs appareils Android ? Quelle serait selon vous la solution la plus adaptée en vue des éléments que nous avons parcourus ensemble ?
Déjà l’OS cible pourrait nous aiguiller vers un développement natif Android, ce qui permettrait de répondre largement au besoin et d’être au plus proche de l’OS et de ses évolutions mais demanderait d’écrire une nouvelle application et de renforcer l’équipe avec des compétences dans une technologie non maîtrisée.
Pour aller vers une technologie connue, le développement en React Native peut être une option envisageable mais demanderait tout de même de réécrire une grande partie de l’application.
La PWA semble être une option assez efficace pour les objectifs de notre client, néanmoins la lecture NFC via navigateur est aujourd’hui très limitée, disponible dans une version récente de chrome (ou Baidu) et sous Android uniquement.
Et si je vous disais qu’il existe une autre solution qui a permis à notre client de réutiliser entièrement son application existante, d’avoir une application mobile disponible depuis le Play Store, et d’utiliser la fonctionnalité NFC ?
C’est cette solution que nous avons implémentée pour notre client et que nous allons vous présenter : la TWA.
3. 6 – TWA
La TWA, pour Trusted Web Activity, c’est avant tout une PWA (avec tous ses avantages), avec quelques éléments en plus (et donc sans certains de ses inconvénients).
Disponible pour les utilisateurs Android uniquement, elle permet de vérifier une application via un digital assets link.
Au moment de construire notre application pour Android, on va générer via notre clé d’authentification Google Store une signature unique pour notre application. Cette clé sera définie dans ce digital asset links que l’on pourra publier sur notre serveur web pour assurer que cette application TWA est bien liée à notre site et éviter que n’importe qui publie une application sur le Google Store basée sur un site qui n’est pas le sien.
Ainsi votre APK (l’archive de votre application sous Android) pourra être déployée sur le store ou installée directement sur le smartphone de vos collaborateurs.
De plus la TWA s’assure que la WebView qui encapsule votre application web en mode mobile, s’exécute sur une version récente du navigateur Chrome. Contrairement à une PWA, elle va ignorer le choix de navigateur par défaut de l’utilisateur pour chercher la version installée compatible en TWA (Chrome) si installée.
Ces deux éléments limitent les erreurs de compatibilités. Vous savez quelle version de l’application est installée sur le smartphone de vos utilisateurs et vous passez outre les préférences en termes de navigateur pour encapsuler votre application dans un navigateur compatible (si disponible) avec les besoins de votre application.
Concrètement dans notre cas client, l’entreprise peut s’assurer de fournir un smartphone avec une version récente de Chrome. La TWA s’exécutera donc avec Chrome et permettra de profiter de fonctionnalités comme le WebNFC, qui permet la lecture de tags NFC à travers le navigateur.
Depuis ce site vous pouvez voir quelles fonctionnalités sont disponibles sur quels navigateurs par version : https://caniuse.com/webnfc
C’est grâce à cette solution que nous avons pu mettre en place pour notre client une solution qui répond à l’ensemble de ses besoins :
- Une application mobile
- Disponible sur Android
- Qui permet d’utiliser le NFC
- Avec un coût moindre en développement.
Nous les avons accompagnés pour répondre aux critères d’éligibilité d’une TWA, de performance et d’expérience utilisateur mobile de l’application existante. Nous avons aussi développé la fonctionnalité intégrant le scan NFC via WebNFC.
4 – Conclusion
Si toutes ces technologies existent pour développer vos applications mobiles ça n’est pas pour rien. Chacune vient avec des forces et des faiblesses qu’il vous faudra connaître pour faire le bon choix technologique en ayant une vision long terme du produit que vous souhaitez développer.
De la même manière que l’on développe une application web sans imaginer un usage mobile futur on peut développer une application cross plateforme simple avec Flutter et se retrouver à devoir implémenter des fonctionnalités de plus en plus complexes et rencontrer des difficultés.
Ou à l’inverse devoir entretenir une application Kotlin et une application Swift pour un besoin assez simple et multiplier les coûts et temps de développements.
Dans ce cas client, la TWA était l’option la plus adaptée en vue :
- Des utilisateurs de l’application
- Du parc matériel maîtrisé par notre client
- De l’application existante
- Des technologies maîtrisées par les développeurs chez notre client
- Du budget disponible
Chez enioka Haute Couture nous disposons de développeurs polyglottes qui n’ont pas de chapelle technologique à défendre. Nous nous adaptons aux besoins et au cadre des clients pour développer des applications non seulement adaptées mais aussi maintenables par les développeurs de nos clients.
Si vous avez besoin d’auditer une application existante, de faire évoluer ou de développer une nouvelle application, contactez-nous : contact-hc@enioka.com.
Des annexes pour aller plus loin :
PWA by Google https://web.dev/progressive-web-apps/
TWA by Google : https://developer.chrome.com/docs/android/trusted-web-activity/
Comparaison Flutter & React native : https://stackoverflow.blog/2022/10/31/comparing-frameworks-for-cross-platform-apps-flutter-vs-react-native/
https://www.browserstack.com/guide/flutter-vs-react-native
React Native vs Flutter – I built the same chat app with both
Qu’est-ce que Cordova, comment ça marche : https://cordova.apache.org/docs/en/latest/guide/overview/index.html