Le choix entre développement natif et cross-platform est l’une des premières décisions de tout projet mobile. Il conditionne le budget, les recrutements, le rythme des mises à jour et ce que l’application pourra faire pendant des années. Il n’existe pas de réponse valable pour tous. La bonne approche dépend de ce que votre application doit faire sur l’appareil, de l’équipe qui la maintiendra et du délai dans lequel vous devez être présent à la fois sur iOS et sur Android. Ce guide explique comment décider sur des faits plutôt que par préférence.
Que signifient vraiment « natif » et « cross-platform » ?
Une application native est développée séparément pour chaque plateforme, avec les outils fournis par son éditeur : Swift et SwiftUI pour iOS, Kotlin et Jetpack Compose pour Android. Vous obtenez deux bases de code, chacune disposant d’un accès complet et immédiat à tout ce qu’offre le système d’exploitation.
Une application cross-platform, ou multiplateforme, est écrite une seule fois dans un framework comme Flutter ou React Native, puis compilée en véritables applications pour les deux stores. L’essentiel du code est partagé, avec de petites parties propres à chaque plateforme là où c’est nécessaire. Kotlin Multiplatform se situe entre les deux : il partage la logique métier tout en gardant une interface native de chaque côté.
Ni l’une ni l’autre n’est un site web glissé dans une coque. Les deux donnent des applications installables, qui passent la validation des stores, envoient des notifications push et fonctionnent hors ligne si elles ont été conçues pour cela.
Natif ou cross-platform : comment choisir pour votre application
Partez du produit, pas de la technologie. Répondez franchement à ces questions avant que quiconque ne propose un framework :
- Que fait l’application sur l’appareil ? Formulaires, listes, contenus, réservations et paiements : les deux approches conviennent. Un usage intensif de l’appareil photo, la réalité augmentée, des périphériques Bluetooth complexes ou des traitements en arrière-plan font pencher vers le natif.
- Vous faut-il les deux plateformes dès le premier jour ? Si votre public se partage entre iOS et Android, une base de code commune vous permet d’être présent sur les deux avec une seule équipe.
- Qui la maintiendra ? L’équipe qui s’occupe de l’application pendant des années compte davantage que celle qui la lance.
- À quelle fréquence évoluera-t-elle ? Les produits mis à jour souvent gagnent à ne développer chaque fonctionnalité qu’une fois.
- Qu’est-ce qui existe déjà ? Une application native existante, une équipe web à l’aise avec React ou un back-end à l’architecture particulière : chacun de ces éléments oriente la décision.
Quand le natif est-il le meilleur choix ?
Le natif justifie son surcoût lorsque l’application dépend de l’appareil lui-même : graphismes et animations exigeants, traitement audio ou vidéo en temps réel, intégration poussée avec les montres et objets connectés, les widgets, les interfaces embarquées en voiture ou les données de santé, et tout ce qui doit adopter les nouveautés du système d’exploitation dès leur sortie.
C’est aussi la voie raisonnable lorsqu’une seule plateforme suffit, par exemple pour un outil interne destiné à des équipes qui utilisent toutes le même appareil. Elle convient également aux organisations qui emploient déjà des développeurs iOS et Android : un nouveau framework y ajouterait une troisième compétence au lieu d’en supprimer une.
La contrepartie est simple : avec deux bases de code, chaque fonctionnalité est conçue, développée, testée et publiée deux fois, et il faut de la discipline pour que les deux applications avancent du même pas.
Quand le cross-platform est-il plus pertinent ?
Dans la plupart des applications d’entreprise, les écrans combinent contenus, formulaires, comptes, recherche, cartes, paiements et notifications. Les frameworks cross-platform gèrent bien tout cela, et les utilisateurs ne sauront pas dire comment l’application a été développée si elle l’a été avec soin.
Les principaux avantages sont pratiques :
- Une seule équipe et une seule base de code : les fonctionnalités arrivent sur les deux plateformes en même temps.
- Un comportement et un design cohérents sur iOS et Android.
- Moins de tests en double, et moins d’endroits où un même bug peut se cacher.
- Une maintenance plus simple après le lancement.
Les limites sont réelles, elles aussi. Vous dépendez du framework et de bibliothèques tierces, qui doivent suivre le rythme des évolutions des systèmes d’exploitation. Des fonctions matérielles inhabituelles peuvent exiger des modules natifs écrits pour chaque plateforme, ce qui ramène une partie du travail en double. Une équipe qui voit dans le cross-platform un raccourci et néglige les conventions de chaque plateforme livrera une application qui sonne faux sur les deux.
Qu’est-ce qui détermine le coût et le calendrier de chaque approche ?
Le framework est rarement le premier facteur. Ce qui fait bouger le budget et le calendrier :
- Le périmètre : le nombre d’écrans, de rôles utilisateur et de cas particuliers.
- Le back-end : comptes, données, intégrations avec des systèmes de paiement, de réservation ou internes. Ce travail est le même, quelle que soit l’approche retenue.
- L’ambition du design : des animations et des composants sur mesure demandent plus de temps que des modèles standards.
- Les fonctions de l’appareil : chacune de celles qui exigent du code propre à une plateforme réduit l’économie tirée du code partagé.
- Le fonctionnement hors ligne : synchroniser les données de façon fiable est exigeant, quelle que soit la technologie.
- Les tests et la conformité : l’éventail d’appareils pris en charge, l’accessibilité et les éventuelles exigences réglementaires.
Le cross-platform réduit en général l’effort de développement et de maintenance, puisque les fonctionnalités ne sont écrites qu’une fois, mais il ne le divise pas par deux. Le design, le back-end, les tests sur de vrais appareils et la publication sur les stores restent à faire pour les deux plateformes. Demandez des estimations qui distinguent ces postes : vous verrez où se trouve réellement l’économie.
Quelles erreurs éviter avant de vous engager ?
L’erreur la plus fréquente consiste à choisir selon la mode, ou selon la préférence de l’équipe disponible. Juste derrière : décider avant que la liste des fonctionnalités soit claire, puis découvrir qu’une fonctionnalité essentielle se heurte au framework retenu.
Avant de vous engager, dressez la liste des fonctions de l’appareil dont l’application aura besoin pendant ses deux premières années, et pas seulement au lancement. Demandez à l’équipe de développement de prototyper d’abord la plus risquée. Vérifiez que le code, les comptes des stores et les clés de signature seront au nom de votre organisation. Et prévoyez la maintenance dès le départ : les deux systèmes d’exploitation publient une version majeure chaque année, et une application qui n’est pas mise à jour cesse peu à peu de fonctionner correctement.
Questions fréquentes
Les utilisateurs voient-ils la différence entre une application native et une application cross-platform ?
Pas si elle est bien faite. Ce que les utilisateurs remarquent, ce sont des écrans lents, une navigation malcommode et un comportement qui ignore les conventions de leur téléphone. Ces problèmes tiennent à la qualité du travail, et on les rencontre aussi dans des applications natives.
Peut-on commencer en cross-platform et passer au natif plus tard ?
Oui, et c’est une trajectoire raisonnable pour un nouveau produit. Le back-end, le design et tout ce que vous aurez appris des utilisateurs réels sont conservés. Le code de l’application, lui, serait réécrit : ne l’envisagez que si l’orientation du produit l’exige vraiment.
Une application web progressive (PWA) est-elle une alternative moins coûteuse ?
Parfois. Une application web progressive fonctionne dans le navigateur et peut être installée sur l’écran d’accueil, ce qui convient aux contenus et aux outils simples. Son accès aux fonctions de l’appareil est plus limité et elle n’est pas présente par défaut dans les stores : ce n’est donc pas un véritable équivalent.
Le cross-platform dispense-t-il de tout travail propre à chaque plateforme ?
Non. Les fiches des stores, les autorisations, la configuration des notifications push, les achats intégrés et certains détails d’interface diffèrent entre iOS et Android. Une bonne équipe prévoit ce travail au lieu de le découvrir tardivement.
Si vous souhaitez une recommandation fondée sur votre liste de fonctionnalités plutôt que sur un framework favori, notre équipe de développement d’applications peut évaluer votre produit et vous expliquer les compromis avant qu’une seule ligne de code ne soit écrite.
