Quelle technologie pour développer son app mobile ?

Le 6 mars dernier j'animais un meetup ByTech à l'EPITA. C'était l'occasion pour TF1, Colas, Bouygues Telecom et Bouygues Construction de partager avec les étudiants leurs enjeux et leurs choix technologiques pour le développement d'applications mobiles.
Les échanges étaient très riches et ont couverts de nombreux sujets mais j'ai retenu particulièrement celui autour du choix d'une technologie pour développer son application mobile.

Voici donc quelques questions que les intervenants se sont posées et que je vous propose de partager.

C'était le leitmotiv de tous les intervenants, le choix d'une technologie ne se fait pas sur des critères purement techniques mais par rapport à un besoin métier. Nul besoin donc de construire une grille d'analyse multicritère pour valider les qualités intrinsèques de telle ou telle technologie. C'est parce qu'elle s'adapte à un besoin particulier qu'on va décider de choisir une technologie et, pour un autre besoin, le choix pourrait être très différent. On a d'ailleurs constaté combien, entre les différents intervenants du meetup, les choix technologiques (par exemple hybride vs natif) peuvent être éloignés.

C'est évidemment une question cruciale pour choisir une technologie. Les technologies natives ne sont pas multiplateformes ce qui impose de développer la même application sur différentes plateformes ce qui peut coûter très cher. Les technologies hybrides type ReactNative ou Flutter sont multiplateformes mais elles ne sont pas aujourd'hui adaptées au web ce qui impose de toute manière de développer aussi une version web, si vous en avez besoin en plus de la version mobile.
Il existe des technologies hybrides permettant de développer en web (Ionic, Cordova) mais elles sont vieillissantes et les webview sur lesquelles elles s'appuient pour fonctionner sont beaucoup moins performantes que du code natif.
Evidemment, cette question est aussi dépendante de la maîtrise que vous avez du parc de terminaux des utilisateurs de l'application: téléchargeable par tous sur un store grand public ou téléchargeable uniquement sur des terminaux d'entreprise via un outil de MDM.

Clairement les technologies natives et plus généralement le fait d'avoir une application installée favorisent l'engagement de l'utilisateur. Quand on veut simplement donner une information à un utilisateur, un site web responsive ou une Progressive Web App peuvent suffire mais si on souhaite établir une relation privilégiée avec l'utilisateur: l'inciter à consulter régulièrement l'application, mettre en place des notifications, s'intégrer avec d'autres applications, … une application native est indispensable.
Plus encore, une application native permettra d'exploiter des fonctionnalités systèmes avancées  ou des fonctionnalités des dernières versions de iOS/Android qui pourront permettre une mise avant sur les stores par Google et Apple, ce qui favorisera encore plus le téléchargement de l'application.

Ce serait tellement formidable de pouvoir disposer d'un expert sur une technologie dès qu'elle est disponible. Mais hélas, il faut souvent composer avec des compétences existantes dans ses équipes.
Difficile de transformer un développeur iOS ou Android en un développeur ReactNative: il aura a tendance à dénigrer la technologie en disant que "c'est du web" parce que c'est dérivé de JavaScript…
Inversement, comment attirer des jeunes développeurs si vous leur proposez de faire du Java et de l'ObjectiveC alors qu'ils ne rêvent que de Kotlin, Swift ou ReactNative ? Mais comment maintiendrez-vous le code existant si vous n'avez plus de développeurs disposant des compétences sur Java et ObjectiveC ?
N'est-il pas tentant également de "recycler" ses développeurs .NET en misant sur Xamarin, une technologie dans lequel ils retrouveront leurs marques ?

On part rarement de zéro lorsqu'on développe ou lorsqu'on fait évoluer une application mobile. Il est assez facile d'intégrer du Kotlin dans du code Java, c'est un peu plus difficile d'intégrer du Swift avec de l'ObjectiveC, c'est franchement compliqué d'intégrer du code natif existant avec des technologies hybrides de type Flutter ou ReactNative.
Il peut être intéressant également d'intégrer des pages web dans son application mobile, soit pour être plus agile sur les mises à jour, soit pour fonctionner en mode dégradé. Dans ce cas, on devra prévoir l'intégration de webviews dans l'application, ce qui milite pour l'utilisation de l'hybride.

Faire du code natif est forcément plus performant et plus optimisé. L'hybride peut pénaliser les performances et/ou la taille des applications. Que ce soit ReactNative, Flutter ou encore pire Xamarin, il faut s'attendre à ce que l'application finale nécessite plus de ressources. Ce n'est pas forcément gênant si on maîtrise son parc de machines cibles mais quand on veut pouvoir fonctionner sur une machine d'entrée de gamme, on risque d'être confronté à des utilisateurs qui pourraient être tenté de supprimer l'application parce qu'elle monopolise la mémoire ou la batterie.

Les systèmes et les technologies mobiles évoluent très vites, on ne peut pas considérer comme sur un PC qu'on va utiliser une application pendant 5 ans ou plus. Du coup, on peut très bien imaginer que l'application mobile sera "jetable".
Il faut donc plutôt capitaliser dans le "backend" de l'application, c'est à dire déplacer des fonctionnalités sur le serveur pour faire en sorte que même si l'application doit être réécrite, le cœur des fonctionnalités soit conservé. L'application mobile n'est alors qu'une fenêtre intelligente sur des fonctionnalités du backend.
D'ailleurs il est intéressant d'implémenter le maximum de fonctionnalités du côté du serveur pour éviter d'être tributaire de mises à jour qui dépendent souvent du bon vouloir de l'utilisateur. Que se passera t-il si vous changez votre système de facturation et qu'il ne peut être mis à jour tant que certaines versions mobiles de l'application utilisent encore l'ancien système ?

Voilà quelques unes des questions (et pas toujours de réponse…) à laquelle vous pourriez être confronté dans le choix de votre technologie mobile. Mais encore une fois: la solution ne dépend pas de la qualité de la technologie mais du besoin à laquelle l'application doit répondre !

Et vous, quels ont été vos choix ? Quelles autres questions vous êtes vous posé pour prendre votre décision ?