Tous les comparatifs cross-platform que vous avez lus commencent par affirmer qu'il n'y a pas de mauvaise réponse. C'est une façon polie d'esquiver la question. Il y a de mauvaises réponses — elles dépendent juste de ce que vous construisez et de qui le construit.
Voici donc la version avec des opinions dedans.
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 subtilement é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é d'un pont entre deux environnements d'exécution.
Kotlin Multiplatform ne partage ni l'un ni l'autre. Il partage 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.
L'un des trois n'est pas comme les autres. Flutter et React Native essaient d'écrire l'app une seule fois. KMP, explicitement, n'essaie pas.
Fig. — Trois réponses différentes à la question de ce que « partagé » devrait vouloir dire.
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 : posséder la couche de rendu élimine une catégorie entière de problèmes. Votre mise en page se comporte identiquement 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 que sur la mise à l'échelle des polices d'un seul constructeur Android. Le hot reload fonctionne vraiment. 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 pipeline 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 l'OS livre un nouveau contrôle natif, Flutter le réimplémente selon son propre calendrier au lieu d'en hériter.
L'accessibilité mérite aussi une mention. Parce que Flutter dessine au lieu de composer 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 qui a été peint. 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 ce où un look de marque distinctif compte plus que la convention de plateforme.
React Native : celui qui va avec l'équipe que vous avez déjà
L'argument le plus fort pour React Native n'a jamais été technique. C'est que vous employez probablement déjà des développeurs React, et qu'ils y sont productifs en une semaine.
Ne sous-estimez pas cela. Quatre ingénieurs web qui livrent une app mobile compétente sans embauche, c'est une proposition matériellement différente de recruter des spécialistes Swift et Kotlin sur un marché où les deux coûtent cher.
Le tableau technique s'est aussi amélioré plus que sa réputation ne le suggère. La nouvelle architecture a supprimé le pont asynchrone qui causait la plupart des plaintes historiques de performance, et 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. Cette taxe d'entretien est l'inconvénient honnête — et elle est permanente, pas ponctuelle.
Choisissez React Native quand votre équipe est déjà JavaScript, quand vous voulez une vraie sensation native sans écrire deux interfaces, 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 refuse la prémisse. Il n'essaie pas d'écrire votre interface une fois. Il suppose que vous construirez les deux interfaces en natif — et ne partage que la couche du dessous.
Ça sonne comme plus de travail, et au début ça l'est. Ce que vous obtenez en échange : les 40 % les plus durs de votre app — le réseau, la synchronisation hors ligne, les modèles de données, les règles métier, la validation — existent une fois, dans un langage, testés une fois. Pendant ce temps, chaque interface est entièrement native, utilise les contrôles de l'OS 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 résultat de la plus haute qualité accessible. Personne n'apprend un nouveau framework d'interface. Les apps sonnent juste. La logique dupliquée qui dérivait entre les plateformes cesse de dériver.
Les réserves sont honnêtes. 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.
Choisissez KMP quand vous avez déjà des développeurs natifs, quand la justesse de la logique partagée compte plus que la vitesse de livraison, ou quand l'app vivra des années et que vous optimisez l'entretien plutôt que le lancement.
Et la performance, vraiment
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.
Pour l'écrasante majorité des apps — formulaires, listes, contenu, paiement, chat — les trois sont assez rapides pour que les utilisateurs ne voient pas la différence. Le goulot d'étranglement d'une app typique est le réseau, pas la couche de rendu. 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 vrai handicap sur les appareils bon marché, dans les marchés où le stockage est compté.
Le test utile n'est pas un benchmark. 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 deux jours et ça tranche mieux que n'importe quel tableau comparatif.
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 nombreux et moins chers 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 profiler un problème de fluidité dans le moteur. React Native hérite de l'énorme vivier React, son plus grand avantage pratique — même si « connaît React » et « a livré et maintenu une app React Native à travers trois versions d'OS » sont deux choses différentes, au prix différent.
KMP est le plus difficile à staffer, 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.
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 la taxe d'entretien, 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 — 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 une taxe pour rien — une couche d'abstraction en plus, un tapis roulant de mises à jour en plus, et un chemin plus lent vers chaque nouvelle fonctionnalité de l'OS. Bien des équipes choisissent Flutter pour une app qui ne sortira jamais que sur Android.
Et si votre app est vraiment simple, une web app mobile bien construite comble peut-être tout l'écart. Ce n'est pas la réponse à la mode — mais 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, et les équipes la traitent comme si elle était définitive. Réécrire une app de deux ans dans un autre framework coûte cher mais se survit — et c'est 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. Se tromper est rattrapable. Passer quatre mois à choisir ne l'est pas.
Le choix du framework compte moins que les équipes ne l'attendent — et l'équipe que vous avez compte bien plus qu'elles ne veulent l'admettre. 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 bon marché.
Choisir la bonne stack pour une équipe et un produit précis, c'est le genre de travail que nous faisons chez CODT.
