Choisir entre une application native ou multiplateforme, c’est choisir entre écrire une application distincte pour iPhone et pour Android, chacune dans le langage de sa plateforme, ou écrire l’essentiel de l’application une seule fois et la faire tourner sur les deux grâce à un framework comme Flutter ou React Native. Le natif offre l’adaptation la plus fine à chaque appareil et l’accès le plus rapide aux nouvelles fonctionnalités ; le multiplateforme offre une base de code partagée, un chemin plus rapide vers les deux stores et, en général, des évolutions moins coûteuses. Ce guide définit chaque option, compare cinq approches côte à côte, montre quand chacune s’impose et se termine par une méthode de décision et l’effet sur le coût et la maintenance.
Dernière mise à jour : 26 octobre 2026.
Que signifient vraiment « natif » et « multiplateforme » ?
Ces mots sont employés de manière approximative : mieux vaut les préciser avant de comparer quoi que ce soit. La question de fond est toujours la même : quelle part de l’application est écrite une fois, et quelle part l’est pour chaque plateforme.
Applications natives
Une application native est construite avec les outils que fournit chaque éditeur de plateforme : Swift et SwiftUI dans Xcode pour l’iPhone et l’iPad, documentés sur le site développeurs d’Apple, et Kotlin avec Jetpack Compose dans Android Studio pour Android. Deux bases de code, deux ensembles de compétences, et chacune parle directement à son système d’exploitation, sans couche intermédiaire.
Applications multiplateformes
Une application multiplateforme partage l’essentiel de son code entre iOS et Android. Les deux frameworks dont les clients entendent le plus parler suivent des voies différentes. Flutter, de Google, dessine lui-même chaque pixel de l’interface avec son propre moteur de rendu et s’écrit en Dart. React Native, de Meta, s’écrit en JavaScript ou TypeScript et affiche de vrais composants de la plateforme : un bouton est le bouton du système. Tous deux permettent de descendre au code natif quand une fonctionnalité l’exige.
Les deux options intermédiaires
Kotlin Multiplatform partage la logique (données, appels au serveur, règles métier) en Kotlin et garde une interface native de chaque côté, ou la partage aussi avec Compose Multiplatform. Une progressive web app (PWA) est un site web qui s’installe sur l’écran d’accueil, fonctionne hors ligne et peut envoyer des notifications, sans passer par un store. Les deux ont leur place dans la comparaison, car pour beaucoup de projets ce sont les meilleures réponses.
En bref : natif signifie deux applications écrites pour deux plateformes. Multiplateforme signifie une application, un langage principal et un framework qui fait la traduction. Kotlin Multiplatform partage le moteur et garde des écrans natifs. Une PWA se passe complètement des stores. Aucune option ne convient à tous les projets.
Pourquoi ce choix compte-t-il plus que la guerre des frameworks ?
La plupart des articles sur Flutter contre React Native se lisent comme un match. Pour une entreprise, la question utile est ailleurs : ce que l’application doit faire pendant ses deux premières années, qui la maintiendra et à quelle fréquence elle doit évoluer. Le framework découle de ces réponses.
Chez Odduel, agence créative et technologique à Barcelone et São Paulo, chaque projet de développement d’applications part de cette question, et non d’une stack préférée. Si vous êtes encore en train de dessiner la première version, notre guide du développement MVP explique comment réduire le périmètre avant de choisir la technologie, ce qui règle souvent la question à lui seul.
Natif ou multiplateforme : le comparatif
Le tableau compare les cinq approches sur les points qu’un client ressent une fois l’application en ligne. Il décrit un comportement typique : une application bien construite dans n’importe quelle colonne peut battre une application mal construite dans une autre.
| Natif (Swift / Kotlin) | Flutter | React Native | Kotlin Multiplatform | PWA | |
|---|---|---|---|---|---|
| Performance | La meilleure ; accès direct au système | Très proche du natif ; moteur de rendu propre | Proche du natif pour la plupart des applications ; animations lourdes à soigner | Interface native, logique partagée à vitesse native | Bonne pour contenus et formulaires ; limitée pour les graphismes lourds |
| Fidélité de l’interface | Apparence et comportement exacts de la plateforme | Identique au pixel près sur les deux plateformes ; le ressenti de chaque plateforme est à construire | Utilise de vrais composants de la plateforme | Écrans entièrement natifs (ou partagés avec Compose) | Apparence web ; ressemble à un site sans un design soigné |
| Fonctionnalités de l’appareil | Toutes, dès le premier jour d’une nouvelle version du système | La plupart via des plugins ; les nouveautés après mise à jour des plugins | La plupart via des modules ; les nouveautés après mise à jour des modules | Toutes, côté natif | Restreintes ; variables selon le navigateur et la plateforme |
| Partage du code | Aucun entre plateformes | L’essentiel de l’application, interface comprise | L’essentiel de l’application ; une partie de la logique partageable avec une application web | Logique partagée, interface au choix | Une seule base de code pour tous les appareils et l’ordinateur |
| Compétences de l’équipe | Deux spécialités : iOS et Android | Dart et Flutter | JavaScript ou TypeScript, proche des équipes web | Kotlin, plus des connaissances iOS pour l’interface | Développement web |
| Maintenance | Deux bases de code à mettre à jour à chaque modification | Une base de code ; des mises à niveau du framework à suivre | Une base de code ; des mises à jour de dépendances qui demandent de la rigueur | Un cœur partagé, deux interfaces légères | Une base de code, aucune validation des stores |
| Stores d’applications | Oui | Oui | Oui | Oui | Non (référencement possible sur certains stores) |
Le tableau cache un point qu’il vaut la peine de dire : l’écart entre le natif et un bon multiplateforme s’est beaucoup réduit. Pour la plupart des applications d’entreprise, les utilisateurs ne peuvent pas dire quelle approche a été utilisée. La différence se voit aux marges : nouveau matériel, graphismes lourds, intégration profonde au système, et la longue durée de la maintenance.
Quand choisir le natif ?
Le natif est le bon choix quand la valeur de l’application dépend de l’appareil lui-même. Choisissez-le quand :
- l’application repose sur du matériel nouveau ou particulier : appareils photo avec traitement sur mesure, capteurs, données de santé, réalité augmentée, objets connectés à porter ou accessoires Bluetooth ;
- l’application doit adopter chaque nouvelle fonctionnalité du système d’exploitation le jour de sa sortie, comme les widgets, les activités en direct ou de nouveaux formats d’écran ;
- la performance est le produit : audio ou vidéo en temps réel, jeux, cartes au rendu intensif ;
- l’application vit surtout sur une plateforme, si bien que la seconde base de code est petite ou pas encore nécessaire.
Les nouveaux formats d’appareils sont un bon test. Quand Apple introduit une nouvelle forme d’écran, les applications natives peuvent s’y adapter dès que les outils sont disponibles, tandis que les frameworks suivent une fois leur propre prise en charge arrivée. Nous avons étudié ce cas en détail dans applications iPhone Duo : ce que change l’iPhone pliable.
Quand choisir Flutter ?
Flutter convient aux applications où l’apparence de la marque compte plus que les conventions de la plateforme, et où la même interface doit s’afficher à l’identique sur les deux téléphones. Comme il dessine sa propre interface, un design system sur mesure, des animations spécifiques et une identité visuelle forte se retrouvent sur chaque écran sans adaptation. Il atteint aussi le web et l’ordinateur à partir du même code, ce qui sert les outils internes et les tableaux de bord. La contrepartie : le ressenti de chaque plateforme (physique du défilement, menus système, détails d’accessibilité) doit être vérifié délibérément de chaque côté. Sa documentation officielle se trouve sur flutter.dev.
Quand choisir React Native ?
React Native convient aux entreprises qui ont déjà des développeurs web travaillant en JavaScript ou TypeScript, ou un site React dont la logique et les équipes peuvent être partagées avec l’application. Comme il utilise les composants propres à la plateforme, il paraît naturel sur chaque téléphone sans travail supplémentaire. Les mises à jour à distance de la couche JavaScript peuvent raccourcir le chemin des petites corrections, dans le respect des règles des stores. La contrepartie : un plus grand nombre de dépendances tierces à tenir à jour. La documentation du projet se trouve sur reactnative.dev.
Quand choisir Kotlin Multiplatform ?
Kotlin Multiplatform convient aux équipes qui veulent des écrans natifs mais refusent d’écrire deux fois les mêmes règles métier. Il convient aux applications à logique complexe (tarification, synchronisation hors ligne, réservations, calculs financiers), où un bug corrigé une fois doit l’être partout, ainsi qu’à une application Android existante qui s’ouvre à iOS. L’interface reste entièrement native : pour les écrans, il coûte plus que Flutter ou React Native, et au total moins que deux applications natives distinctes.
Quand une application web progressive suffit-elle ?
Une PWA suffit quand l’application consiste surtout en contenus, formulaires, commandes ou gestion de compte, et quand le vrai obstacle est de convaincre les gens d’installer quoi que ce soit. Elle partage une base de code avec le site web, se met à jour dès que vous publiez et ne passe par aucune validation de store. Ses limites tiennent à l’accès aux fonctionnalités de l’appareil, aux tâches en arrière-plan et au comportement des notifications, qui varient selon le navigateur et la plateforme. Beaucoup de produits démarrent comme un site mobile bien construit, prouvent leur utilité, et ne justifient qu’ensuite une application sur les stores.
Comment choisir entre natif et cross-platform ?
Voici les étapes que nous suivons avec nos clients. Elles demandent un court atelier, pas un projet de recherche.
- Listez ce que l’application doit faire dans sa première version et l’année suivante. Repérez chaque fonctionnalité qui touche l’appareil : appareil photo, localisation, notifications, paiement, capteurs, usage hors ligne.
- Repérez les fonctionnalités nouvelles ou propres à une plateforme. Si plusieurs d’entre elles sont au cœur du produit, le natif ou Kotlin Multiplatform remontent dans la liste.
- Décidez à quel point le design doit suivre chaque plateforme. Une identité forte et sur mesure oriente vers Flutter ; un ressenti familier de la plateforme oriente vers React Native ou le natif.
- Regardez qui la maintiendra. Une équipe web interne oriente vers React Native ou une PWA ; une équipe Android vers Kotlin Multiplatform ; un partenaire externe doit nommer les personnes et le plan.
- Vérifiez si vous avez vraiment besoin des stores. Si la réponse est « pas encore », une PWA peut être la première étape.
- Construisez un écran risqué en guise de test. Un court prototype technique sur la fonctionnalité la plus difficile vous en apprend plus que n’importe quel tableau.
- Consignez la décision et ses raisons. La prochaine personne qui modifiera l’application doit savoir pourquoi elle a été construite ainsi.
La manière de mener le développement compte autant que la stack. Notre comparatif méthode agile ou en cascade explique pourquoi les applications se prêtent en général à une phase de cadrage fixe suivie de cycles de développement courts.
Qu’est-ce qui change pour le coût et la maintenance ?
Le coût suit la quantité de travail, et les approches déplacent ce travail plutôt qu’elles ne le suppriment. Nous ne publions pas de fourchettes de prix, car elles dépendent du brief ; un devis ferme suit un court brief. Ce que nous pouvons dire, c’est où va l’argent.
La réalisation
Deux applications natives, ce sont deux interfaces à développer, deux séries de tests et en général deux spécialistes. Le multiplateforme mutualise l’essentiel : le développement est en général le poste le plus léger, même si la finition propre à chaque plateforme et les modules natifs demandent encore du temps. Kotlin Multiplatform se situe entre les deux. Une PWA est en général le plus petit développement, car elle prolonge le site web.
Les années après le lancement
C’est dans la maintenance que le choix se révèle vraiment. Chaque nouvelle version du système d’exploitation, chaque changement de règles des stores et chaque mise à jour de sécurité doivent être absorbés. Le natif oblige à le faire deux fois ; le multiplateforme une fois, plus le suivi des mises à niveau du framework ; une PWA oblige à suivre les navigateurs. Sur la durée de vie d’une application, la maintenance pèse souvent plus que le premier développement : demandez à chaque devis comment sont gérées les mises à jour, les mises à niveau et les soumissions aux stores.
Lire un devis
Un bon devis nomme l’approche et la raison de ce choix, distingue design, développement, tests et publication sur les stores, et précise ce que couvre le support après le lancement. Si deux devis diffèrent fortement, vérifiez si l’un inclut les deux plateformes, les tests d’accessibilité et un plan de maintenance, et l’autre non.
Questions fréquentes
Le natif est-il toujours plus rapide que le multiplateforme ?
Le natif a l’accès le plus direct à l’appareil : il fixe donc le plafond de performance. En pratique, les applications Flutter et React Native tournent de façon fluide pour la plupart des usages professionnels, comme les listes, les formulaires, les commandes et les comptes. L’écart apparaît avec les graphismes lourds, les médias en temps réel et les animations complexes, où le natif ou une optimisation soignée valent le travail supplémentaire.
Flutter ou React Native : lequel choisir ?
Choisissez Flutter quand un design sur mesure et affirmé doit être identique sur les deux plateformes et que travailler en Dart ne vous gêne pas. Choisissez React Native quand vous avez des développeurs JavaScript ou TypeScript, un site React avec lequel partager la logique, ou que vous voulez les composants propres à chaque plateforme. Les deux sont matures, très utilisés et capables d’appeler du code natif.
Peut-on passer du multiplateforme au natif plus tard ?
Oui, mais il s’agit en général d’une réécriture de l’interface plutôt que d’une migration. La logique métier, les designs, les contenus et les services back-end sont conservés ; les écrans, non. Un parcours fréquent consiste à lancer en multiplateforme, à apprendre ce dont les utilisateurs ont vraiment besoin, puis à ne reconstruire que les parties qui exigent la performance native ou l’accès à l’appareil.
Apple et Google acceptent-ils les applications multiplateformes ?
Oui. Les deux stores acceptent les applications construites avec Flutter, React Native et Kotlin Multiplatform, et les jugent selon les mêmes règles de validation que les applications natives. Ce qui compte, c’est que l’application se comporte bien, respecte les règles de confidentialité et apporte une vraie valeur. Une simple coquille autour d’un site web, sans fonctionnalités propres à une application, a plus de chances d’être refusée.
Une PWA est-elle une vraie alternative à une application ?
Pour les contenus, les commandes, les réservations et les outils de gestion de compte, souvent oui : elle s’installe sur l’écran d’accueil, fonctionne hors ligne et ne coûte qu’une base de code. Elle est plus faible pour l’accès profond à l’appareil, les tâches en arrière-plan et certains comportements de notification, qui varient selon le navigateur et la plateforme. C’est une première étape solide quand vous n’êtes pas sûr d’avoir besoin d’une présence sur les stores.
Si vous hésitez entre natif et multiplateforme pour un nouveau produit ou une refonte, le plus rapide est un court brief : ce que l’application doit faire, qui la maintiendra et quand elle doit être entre les mains des utilisateurs. Nous vous dirons quelle approche convient, et pourquoi, dans le cadre de notre offre de développement d’applications. Parlez-nous de votre application.
