Flutter ou natif ? Comparer avant de lancer une application mobile
Flutter ou natif : c’est souvent la première décision technique d’un projet d’application mobile, et l’une des plus durables. Elle conditionne le profil des développeurs à recruter, le budget initial, la vitesse de sortie sur Android et iOS, mais aussi le coût de maintenance pendant des années. Entre le natif Android en Kotlin, Flutter, React Native et Kotlin Multiplatform, aucune option ne gagne sur tous les tableaux. Chacune répond mieux à un type de projet. Ce comparatif pose les critères qui comptent vraiment, sans parti pris pour une technologie.
Les quatre grandes options en présence
Avant de comparer, il faut savoir ce que recouvre chaque approche.
Le natif Android consiste à développer l’application avec les outils officiels de la plateforme : le langage Kotlin, l’environnement Android Studio, les bibliothèques Jetpack et Jetpack Compose pour l’interface. Une version iOS, si elle est nécessaire, se développe à part, avec les outils d’Apple. Deux bases de code, deux compétences, mais un accès complet et immédiat à tout ce que propose chaque système.
Flutter est un framework créé par Google, qui utilise le langage Dart. Il dessine lui-même l’interface au moyen de son propre moteur de rendu, au lieu de s’appuyer sur les composants graphiques du système. Une seule base de code produit une application Android et une application iOS, avec un rendu identique sur les deux.
React Native, porté par Meta, permet d’écrire l’application en JavaScript ou en TypeScript, avec une logique proche du développement web en React. L’interface s’appuie sur des composants natifs de chaque plateforme. Ce choix séduit les équipes qui maîtrisent déjà l’écosystème web.
Kotlin Multiplatform, développé par JetBrains, adopte une approche différente : partager la logique métier (accès aux données, règles de gestion, communication réseau) entre Android et iOS, tout en laissant la possibilité de garder une interface native sur chaque plateforme ou de la partager à son tour avec Compose Multiplatform. Pour une équipe Android, c’est une extension naturelle de Kotlin. Le comparatif Kotlin ou Java pour Android revient sur la place de ce langage dans l’écosystème.
Flutter ou natif : le tableau comparatif
Le tableau suivant résume les principaux critères. Les appréciations sont générales : la qualité d’une application dépend toujours davantage de l’équipe qui la réalise que de la technologie.
| Critère | Natif (Kotlin) | Flutter | React Native | Kotlin Multiplatform |
|---|---|---|---|---|
| Langage | Kotlin (Swift pour iOS) | Dart | JavaScript ou TypeScript | Kotlin, interface native ou partagée |
| Bases de code | Une par plateforme | Une seule | Une seule, avec du natif ponctuel | Logique partagée, interface au choix |
| Performances | Référence | Très bonnes dans la plupart des cas | Bonnes, à surveiller sur les cas exigeants | Proches du natif |
| Accès aux fonctions du téléphone | Complet et immédiat | Par extensions, parfois du code natif | Par modules, parfois du code natif | Complet côté natif |
| Rendu de l’interface | Composants du système | Moteur de rendu propre | Composants natifs | Natif ou partagé |
| Coût pour deux plateformes | Le plus élevé | Réduit | Réduit | Intermédiaire |
| Vivier de développeurs | Large sur Android | En croissance | Large, proche du web | Plus restreint, en croissance |
Performances et accès aux fonctions du téléphone
Sur les performances, l’écart entre les solutions s’est beaucoup réduit. Pour une application de gestion, de contenu ou de commerce, un utilisateur ne perçoit généralement pas de différence entre une application native et une application Flutter ou React Native bien réalisée. Les différences apparaissent sur des usages exigeants : animations très complexes, traitement d’image ou de vidéo en temps réel, jeux, réalité augmentée, applications qui sollicitent intensivement le processeur ou la batterie.
L’accès aux fonctions du téléphone est un critère plus décisif. Le natif offre un accès immédiat et complet à toutes les API d’Android dès leur sortie : nouvelles permissions, capteurs, Bluetooth, fonctions spécifiques à certains appareils, intégrations profondes avec le système. Les frameworks multiplateformes y accèdent via des extensions ou des modules, souvent maintenus par la communauté. Pour les fonctions courantes (caméra, géolocalisation, notifications, stockage), ces extensions existent et sont matures. Pour une fonction récente ou très spécifique, il faut parfois écrire soi-même du code natif, ce qui suppose d’avoir cette compétence dans l’équipe.
Un projet qui repose sur du matériel particulier, comme un objet connecté en Bluetooth, un terminal de paiement ou un scanner professionnel, a donc intérêt à vérifier très tôt la disponibilité et la qualité des extensions nécessaires, voire à privilégier le natif.
Le coût de développement, au départ et dans la durée
C’est souvent l’argument décisif pour une jeune entreprise : développer une seule base de code pour Android et iOS coûte moins cher que d’en développer deux. Avec Flutter ou React Native, une même équipe livre les deux applications, ce qui réduit à la fois le budget initial et le temps de mise sur le marché.
Il ne faut cependant pas en conclure que le multiplateforme divise le coût par deux. Une partie du travail reste spécifique à chaque système : adaptations d’interface aux conventions de chaque plateforme, gestion des permissions, publication sur deux stores aux règles différentes, tests sur les deux familles d’appareils. Le gain réel dépend du projet.
Pour un projet Android uniquement, la question se pose autrement : le multiplateforme n’apporte pas d’économie, et le natif reste en général le choix le plus simple. Les ordres de grandeur de taux et de prix d’une application sont détaillés dans l’article sur le TJM d’un développeur mobile.
| Situation | Option souvent pertinente | Pourquoi |
|---|---|---|
| Application Android seule | Natif Kotlin | Aucun gain à mutualiser, accès complet au système |
| Android et iOS, budget serré, interface classique | Flutter ou React Native | Une seule base de code, sortie rapide |
| Équipe venant du web | React Native | Réutilisation des compétences JavaScript |
| Application native existante à étendre vers iOS | Kotlin Multiplatform | Partage progressif de la logique, interface conservée |
| Usage intensif du matériel ou du graphisme | Natif | Performances et accès complet aux API |
Une autre stratégie consiste à commencer petit. Certains porteurs de projet lancent une première version en multiplateforme pour tester leur marché sur Android et iOS, puis réécrivent tout ou partie de l’application en natif lorsque l’usage se confirme et que les exigences augmentent. D’autres font l’inverse : une application native Android d’abord, puis une extension vers iOS en partageant progressivement la logique avec Kotlin Multiplatform. Aucune de ces trajectoires n’est meilleure dans l’absolu, mais chacune a un coût de transition qu’il vaut mieux anticiper dès le départ plutôt que de le découvrir au moment de franchir le pas.
Le poids de l’application et son temps de démarrage entrent aussi en ligne de compte pour certains publics, par exemple des utilisateurs équipés de téléphones d’entrée de gamme ou disposant d’une connexion limitée. Un framework qui embarque son propre moteur ajoute un surpoids, souvent modeste, qu’il est utile de mesurer sur un prototype.
La maintenance sur plusieurs années
Une application n’est pas un produit fini : elle vit au rythme des nouvelles versions d’Android et d’iOS, des règles des stores et de l’évolution de ses propres fonctionnalités. La technologie choisie pèse lourdement sur ce coût de maintenance à long terme.
Avec le natif, les mises à jour suivent directement les outils de la plateforme. Quand Google publie une nouvelle version d’Android ou impose un niveau d’API cible plus récent sur le Play Store, l’équipe native peut s’y adapter sans attendre un tiers.
Avec un framework multiplateforme, une couche s’intercale. Il faut suivre les versions du framework lui-même, et vérifier que les extensions utilisées sont compatibles avec les nouvelles versions des systèmes. Une extension abandonnée par son mainteneur peut bloquer une mise à jour et imposer un remplacement. Ce risque est maîtrisable, à condition de privilégier des extensions largement utilisées et maintenues activement.
La disponibilité des compétences joue aussi. Une application en natif Kotlin trouvera facilement un repreneur parmi les développeurs Android. Une application Flutter ou React Native demande un profil spécialisé dans ce framework. Le sujet est approfondi dans l’article consacré à la maintenance avec un développeur d’application mobile freelance.
Comment trancher entre Flutter ou natif
Plutôt qu’une réponse universelle, quelques questions permettent d’orienter le choix.
- Quelles plateformes, et dans quel ordre ? Android seul plaide pour le natif ; Android et iOS simultanément ouvrent la porte au multiplateforme.
- Quelles fonctions du téléphone sont indispensables ? Plus elles sont spécifiques, plus le natif devient pertinent.
- Quel niveau d’exigence sur l’interface et les performances ? Un rendu identique sur les deux systèmes favorise Flutter ; le respect strict des conventions de chaque plateforme favorise le natif.
- Quelle durée de vie et quel budget de maintenance ? Une application stratégique pour dix ans mérite une réflexion différente d’un prototype.
- Quelles compétences sont disponibles, en interne ou sur le marché, pour reprendre le projet un jour ?
Un développeur indépendant expérimenté doit pouvoir présenter ces arbitrages honnêtement, y compris lorsqu’ils l’éloignent de sa technologie favorite. C’est l’un des points à vérifier lors du recrutement, détaillé dans le guide pour recruter un freelance en application mobile.
Le débat Flutter ou natif n’a pas de vainqueur absolu. Le natif reste la référence pour les applications Android exigeantes ou centrées sur une seule plateforme ; Flutter et React Native permettent de sortir vite et à moindre coût sur deux systèmes ; Kotlin Multiplatform offre une voie médiane pour partager la logique sans renoncer au natif. Le bon choix est celui qui tient compte du produit, du budget et de la durée de vie visée, pas celui de la tendance du moment.