Natif ou multiplateforme : comment nous choisissons
Les deux approches permettent de sortir de bonnes applications. Le bon choix dépend du produit, de l'équipe et de ce qui se passe après le lancement.
L’une des premières questions techniques pour une nouvelle application est de savoir s’il faut la développer deux fois, une pour chaque plateforme, ou une seule fois avec un framework multiplateforme. Les avis sont tranchés des deux côtés. Nous n’avons pas d’a priori. Nous commençons par quelques questions sur le produit et sur l’équipe qui s’en occupera.
Les options
Le natif consiste à développer l’application iOS en Swift et l’application Android en Kotlin, chacune avec les outils et les frameworks d’interface propres à sa plateforme. Les frameworks multiplateformes comme React Native et Flutter permettent d’utiliser une seule base de code pour les deux. Kotlin Multiplatform se situe entre les deux : une logique métier partagée, avec des interfaces qui peuvent être partagées ou écrites nativement de chaque côté.
Quand le natif justifie son coût
Le natif s’impose quand l’application repose fortement sur la plateforme : traitement audio ou vidéo avancé, widgets et applications pour montres connectées, liens profonds vers les fonctions du système ou graphismes exigeants. Il est aussi précieux quand l’application doit offrir une expérience parfaitement naturelle sur chaque plateforme et intégrer les nouvelles fonctionnalités système dès leur sortie. Le coût : deux bases de code, ce qui implique généralement plus de monde, plus de temps, ou les deux.
Quand le multiplateforme a toute sa place
Le multiplateforme est logique lorsque l’application se compose principalement d’écrans, de formulaires, de listes et d’appels réseau, ce qui correspond à beaucoup d’applications professionnelles. Une seule base de code signifie un seul ensemble de fonctionnalités à concevoir et à tester, et les deux plateformes sortent en même temps. Si l’équipe écrit déjà du TypeScript pour le web, React Native lui permet de réutiliser ces compétences et une partie de ce code.
Regardez l’équipe, pas seulement l’application
La meilleure technologie est celle que votre équipe peut maintenir après le lancement. Si l’application doit être confiée à une équipe interne, construisez-la avec les outils qu’elle maîtrise ou pour lesquels elle peut recruter. Un framework que personne dans l’équipe ne comprend devient un risque dès que quelque chose casse d’une manière non documentée.
Prévoyez tout de même du travail natif
Le multiplateforme signifie rarement l’absence totale de code propre à la plateforme. Les notifications push, les achats intégrés, les tâches en arrière-plan et certaines fonctionnalités de l’appareil nécessitent toujours une configuration native, et chaque store a son propre processus de publication. Prévoyez du travail natif dans chaque projet multiplateforme, et assurez-vous qu’un membre de l’équipe sait s’en charger.
Gardez la logique métier portable
Quelle que soit l’option choisie, séparez les règles du produit (comme la tarification, les permissions et les calculs) des écrans, et placez-les sur le serveur lorsque c’est pertinent. Cela facilite les tests de l’application, assure la cohérence entre les plateformes et rend un éventuel changement d’approche bien moins difficile.
En résumé
Choisissez le natif quand l’application dépend fortement de la plateforme, et le multiplateforme quand elle repose surtout sur des écrans et des données. Dans tous les cas, choisissez une solution que l’équipe pourra maintenir pendant des années. Le choix compte moins que la qualité de la réalisation.