Flutter vs React Native vs Kotlin Multiplatform : le verdict 2026

Tous les comparatifs Flutter vs React Native vs Kotlin Multiplatform que vous avez lus commencent par affirmer qu'il n'y a pas de mauvaise réponse. À mon avis, c'est esquiver la question. Certains choix sont mauvais pour une app donnée ; tout dépend de ce que vous construisez et de qui le construit.

Voici donc la version avec des opinions dedans.

Flutter vs React Native vs Kotlin Multiplatform : la réponse courte

En bref : sans équipe mobile et avec un lancement ce trimestre, prenez Flutter. Si vous employez déjà des développeurs React, React Native. Avec des développeurs iOS et Android en interne, Kotlin Multiplatform : un cœur commun, deux interfaces natives. Et s'il ne vous faut qu'une plateforme, construisez en natif et laissez les trois de côté.

Les trois ne résolvent pas le même problème

C'est la partie que la plupart des comparatifs sautent, et elle explique presque tous les désaccords à leur sujet.

Flutter rend sa propre interface. Il embarque un moteur de rendu, dessine chaque pixel lui-même et n'utilise pas du tout les composants natifs de la plateforme. Un bouton Flutter est un bouton Flutter sur les deux plateformes. C'est pourquoi une app Flutter est identique partout, et pourquoi elle peut sembler un peu étrangère sur les deux.

React Native fait l'inverse. Il pilote de vrais composants natifs (un vrai UIButton sur iOS, un vrai bouton Android) depuis JavaScript. Vous obtenez gratuitement l'apparence et le comportement natifs, et vous héritez de la complexité de deux environnements d'exécution qui doivent se parler.

Kotlin Multiplatform, par défaut, ne partage que votre logique métier (réseau, modèles de données, validation, stockage) et laisse toute l'interface native sur chaque plateforme. Vous écrivez SwiftUI sur iOS et Jetpack Compose sur Android, et les deux appellent un cœur Kotlin commun.

Fig. — Trois réponses différentes à la question de ce que « partagé » devrait vouloir dire.

Derrière chaque framework, il y a un langage : Dart pour Flutter, JavaScript ou TypeScript pour React Native, Kotlin pour KMP. Si vous en êtes encore à ce choix, notre guide des langages de développement d'applications (en anglais) les passe en revue un par un.

Flutter : celui qui livre le plus vite

Si votre priorité est de mettre rapidement une app soignée et cohérente sur les deux stores, Flutter reste la réponse la plus forte, et de loin.

La raison : quand on possède la couche de rendu, toute une catégorie de problèmes disparaît. Votre mise en page se comporte de la même façon sur les deux plateformes, parce que c'est le même code qui dessine les mêmes pixels. Vous ne poursuivez pas un bug qui n'apparaît qu'avec la taille de police d'un seul constructeur Android. Le hot reload fonctionne. La bibliothèque de composants est assez complète pour que la plupart des écrans n'exigent aucun code spécifique à la plateforme.

Les coûts sont réels malgré tout. La taille de l'app démarre plus haut, puisque vous embarquez un moteur. L'intégration profonde à la plateforme (une chaîne de traitement caméra complexe, un périphérique Bluetooth, tout ce qui sort de l'ordinaire) signifie écrire des platform channels : du code natif avec des étapes en plus et une frontière à déboguer. Et quand le système livre un nouveau contrôle natif, Flutter doit le refaire, selon son propre calendrier.

L'accessibilité mérite aussi une mention. Parce que Flutter dessine au lieu d'assembler des vues natives, la prise en charge des lecteurs d'écran dépend de la capacité de sa couche sémantique à décrire correctement ce qu'il a dessiné. C'est correct aujourd'hui. Ça reste une traduction, et les traductions perdent des choses.

Choisissez Flutter pour les apps grand public avec un design system propre, les produits riches en contenu, et tout projet où une identité visuelle forte compte plus que les conventions de la plateforme.

React Native : celui qui va avec l'équipe que vous avez déjà

L'argument le plus fort pour React Native, c'est l'équipe : vous employez probablement déjà des développeurs React, et ils y sont productifs en une semaine.

Ne sous-estimez pas cela. Quatre ingénieurs web qui livrent une app mobile solide sans embauche, c'est tout autre chose que recruter des spécialistes Swift et Kotlin sur un marché où les deux coûtent cher.

Sur le plan technique aussi, les choses ont progressé plus que sa réputation ne le laisse croire. La nouvelle architecture a supprimé le pont asynchrone qui causait la plupart des anciennes plaintes de performance, et depuis React Native 0.82 (octobre 2025), c'est la seule architecture sur laquelle une app peut tourner. L'écart entre une app React Native bien construite et une app native est devenu invisible pour les utilisateurs de la grande majorité des apps.

Là où ça fait encore mal : la gestion des dépendances. Un projet React Native d'un certain âge accumule des modules natifs de mainteneurs différents sur des calendriers de mise à jour différents, et un saut de version majeure peut tourner à la semaine de démêlage. Ce coût de maintenance est le vrai inconvénient, et il ne s'arrête jamais.

Choisissez React Native quand votre équipe fait déjà du JavaScript, ou quand vous devez partager de la logique avec une web app existante.

Kotlin Multiplatform : celui qui admet que l'interface est la partie difficile

KMP est le plus intéressant des trois parce qu'il rejette le postulat de départ. Il suppose que vous construirez les deux interfaces en natif, et ne partage que la couche du dessous.

Sur le papier, c'est plus de travail, et au début ça l'est. Ce que vous obtenez en échange : la partie difficile sous les écrans (le réseau, la synchronisation hors ligne, les modèles de données, les règles métier, la validation) existe une fois, dans un langage, testée une fois. Pendant ce temps, chaque interface est entièrement native, utilise les contrôles du système le jour de leur sortie, et se comporte exactement comme les utilisateurs de cette plateforme l'attendent.

Pour une équipe qui a déjà des développeurs iOS et Android, c'est souvent le meilleur résultat possible en qualité. Personne n'apprend un nouveau framework d'interface. Les apps se comportent comme il faut. La logique dupliquée qui dérivait entre les plateformes cesse de dériver.

Il y a des contreparties. Il vous faut toujours les deux compétences, donc l'économie d'effectifs est moindre. L'outillage côté iOS s'est beaucoup amélioré mais reste plus rugueux que côté Android. Et l'écosystème est plus petit : vous écrivez davantage vous-même.

Une chose a changé depuis les débuts de KMP. JetBrains a déclaré Compose Multiplatform pour iOS stable en mai 2025 (version 1.8.0). Vous pouvez donc désormais partager aussi l'interface, écrite une fois en Compose. C'est une vraie option. Mais si vous partagez tout, vous revenez sur le terrain de Flutter, et je comparerais les deux sur votre écran le plus difficile avant de trancher. Si la sensation native est la raison de votre choix de KMP, gardez SwiftUI sur iOS.

KMP convient à une app appelée à vivre des années, où l'entretien compte plus que le jour du lancement.

Et les performances, concrètement ?

La performance est l'argument qu'on brandit quand on cherche une raison technique à une préférence déjà acquise. Soyons donc précis sur où elle compte et où elle ne compte pas.

Prenez les formulaires, les listes, le contenu, le paiement et le chat : pour l'écrasante majorité des apps, les trois sont assez rapides pour que les utilisateurs ne voient pas la différence. Dans une app typique, c'est le réseau qui freine. Débattre des temps de frame pendant que votre API met 900 millisecondes à renvoyer une liste de produits, c'est optimiser la mauvaise chose.

Là où les différences deviennent visibles : les longues listes défilantes aux cellules complexes, les interfaces très animées à 120 Hz, le traitement d'image ou de vidéo en temps réel, et les apps qui doivent se lancer instantanément sur du matériel Android bas de gamme. Flutter et KMP ont l'avantage sur les trois premiers. Sur le démarrage à froid et la taille de l'app, le natif et KMP gagnent, et le moteur de Flutter est un handicap sur les appareils bon marché, dans les marchés où le stockage est compté.

Le test auquel je me fie, côté QA, est simple. Construisez votre écran le plus complexe dans le framework envisagé, faites-le tourner sur le pire téléphone que vos utilisateurs possèdent réellement, et jugez au ressenti. Ça prend quelques jours et ça tranche mieux que n'importe quel tableau comparatif, y compris celui en haut de cette page.

Le coût qui ne figure dans aucun devis

C'est au recrutement que l'économie du cross-platform fonctionne ou échoue en silence.

Les développeurs Flutter sont plus faciles à trouver que les spécialistes natifs, mais le vivier est moins profond en expertise pointue : beaucoup savent construire des écrans, peu savent déboguer un platform channel ou traquer un problème de fluidité dans le moteur. React Native hérite de l'énorme vivier React, son plus grand avantage pratique. Mais « connaît React » et « a livré et maintenu une app React Native à travers trois versions du système » sont deux choses différentes, qui ne coûtent pas le même prix.

Pour KMP, les postes sont les plus difficiles à pourvoir, parce que vous ne recrutez pas des développeurs KMP. Vous recrutez des développeurs iOS et Android prêts à travailler dans du Kotlin partagé, et la seconde moitié de cette phrase élimine plus de candidats que vous ne l'imaginez.

Comptez aussi le coût de remplacement. Si une personne part, combien de temps avant que quelqu'un d'autre puisse modifier le code sans danger ? Cette question favorise le choix ennuyeux plus souvent que les équipes ne l'admettent au moment de choisir. (Si vous hésitez entre un freelance seul et une agence pour le développement, ce guide traite ce côté de la question.)

Ce que nous avons choisi sur nos propres projets

Deux apps de notre portfolio, deux réponses différentes. Les apps du FeelEat Happy Fridge, qui ouvrent le frigo et affichent le menu, ont démarré comme coques WebView natives et ont été refaites en Flutter à partir de 2023. Pour l'app des employés de FeelEat, nous avons pris l'autre chemin : une app native pour iOS et une autre pour Android, pour que chaque système ait toute sa performance et la connexion par visage ou empreinte digitale. La construction a coûté plus cher, en échange d'un risque plus faible au quotidien.

Aucun de nos projets publiés n'utilise encore Kotlin Multiplatform. La partie sur KMP s'appuie donc sur la documentation publique et l'écosystème ; nous n'avons pas encore de mise en production KMP à montrer.

La décision, sans se défiler

Vous n'avez pas d'équipe mobile et devez livrer ce trimestre : prenez Flutter. La vitesse et la cohérence dominent tout le reste à ce stade, et vous pourrez réécrire plus tard si le produit survit.

Vous avez une équipe React et aucune embauche mobile prévue : prenez React Native. L'adéquation avec l'équipe l'emporte sur le coût de maintenance, et l'objection de performance ne tient plus pour la plupart des produits.

Vous avez déjà des ingénieurs iOS et Android : prenez Kotlin Multiplatform. Vous n'économisez de toute façon pas d'effectifs, alors placez le code partagé là où il paie vraiment : la logique, pas les boutons.

Il y a une quatrième option qui mérite d'être dite tout haut : si vous construisez une app pour une seule plateforme parce que c'est là que sont réellement vos utilisateurs, construisez en natif et arrêtez de lire des comparatifs. Le cross-platform est une solution au problème de servir deux plateformes. Si vous n'avez pas ce problème, vous payez pour rien : une couche d'abstraction en plus, des mises à jour en plus à suivre sans fin, et un chemin plus lent vers chaque nouvelle fonctionnalité du système. Choisir Flutter pour une app qui ne sortira jamais que sur Android, c'est exactement payer pour rien.

Et si votre app est vraiment simple, une web app mobile bien construite comble peut-être tout l'écart. C'est une réponse peu à la mode. Pourtant, bien des apps des stores auraient été meilleures en site web avec une bonne invite d'installation.

Une réserve sur tout ce qui précède : cette décision se révise, même s'il est tentant de la traiter comme définitive. Réécrire une app de deux ans dans un autre framework coûte cher, mais on s'en remet. C'est aussi un projet plus petit qu'on ne le croit, parce que le plus durement acquis (les contrats d'API, les règles métier, la compréhension de ce que font vraiment les utilisateurs) se transfère inchangé. Ce qui ne se transfère pas, c'est la couche d'interface, qui était généralement la partie à réécrire de toute façon. Accordez donc quelques semaines au plus à cette décision.

Une équipe capable livre une bonne app dans le mauvais framework. Une équipe en difficulté livre une mauvaise app dans le bon framework, dans les délais, et personne ne comprend pourquoi elle fait bas de gamme.

Si vous voulez un deuxième avis sur le stack de votre app, notre équipe de développement d'applications le passe en revue avec vous. Envoyez-nous les grandes lignes. Pour une première idée du coût du développement lui-même, essayez le calculateur de coût d'application.

Questions fréquentes

Quel framework cross-platform a le meilleur avenir ?

Les trois ont de gros acteurs derrière eux et des versions régulières : Google pour Flutter, Meta pour React Native, JetBrains pour Kotlin Multiplatform. Aucun ne semble près de disparaître. Le pari le plus sûr à long terme est celui que votre équipe pourra maintenir dans trois ans.

Flutter ou Kotlin Multiplatform pour une nouvelle app mobile ?

Flutter, si vous n'avez pas de développeurs mobiles et voulez une seule base de code, interface comprise, rapidement sur les deux stores. Kotlin Multiplatform, si vous employez déjà des développeurs iOS et Android et voulez des écrans natifs sur un cœur commun. Avec Compose Multiplatform, KMP partage aussi l'interface ; dans ce cas, comparez les deux sur votre écran le plus difficile.

KMP ou React Native : lequel choisir ?

Ils répondent à des questions différentes. React Native permet à une équipe JavaScript d'écrire une app qui affiche de vrais composants natifs. Kotlin Multiplatform permet à des développeurs natifs de partager la logique en gardant l'interface propre à chaque plateforme. Choisissez donc selon votre équipe : avec des développeurs React, prenez React Native ; avec des développeurs Swift et Kotlin, prenez KMP.

Avec lequel l'app est-elle la plus légère ?

En général avec Kotlin Multiplatform et des interfaces natives, parce que chaque app n'ajoute que le cœur Kotlin commun à ce qu'une app native contient de toute façon. Flutter et React Native embarquent chacun leur propre environnement d'exécution, donc leurs apps partent plus lourdes. Sur des téléphones Android bon marché avec peu de stockage libre, les utilisateurs peuvent remarquer la différence.