Un développeur seul, un budget de 8 000 €, une idée d'app de réservation pour salles de sport. Le client veut iOS et Android pour la rentrée. Voilà le genre de brief qui arrive toutes les semaines quand on travaille dans le mobile — et c'est précisément le terrain où la question « cross-platform ou pas ? » cesse d'être théorique. Développer une application mobile cross-platform, c'est écrire une seule base de code et la faire tourner sur plusieurs systèmes. Sur le papier, tout le monde est d'accord. Dans les faits, je vois encore des équipes se tromper, et pas sur le choix du framework.
Points clés à retenir
- Le cross-platform fait économiser du temps au démarrage, pas forcément sur trois ans.
- Flutter brille sur les interfaces sur mesure, React Native sur les équipes déjà à l'aise en JavaScript.
- La part de code réellement partagée tourne souvent autour de 70 à 85 %, rarement plus.
- Les plugins natifs cassent plus de projets que les performances.
- Un MVP cross-platform se justifie presque toujours. Une app critique mêlant capteurs et arrière-plan, beaucoup moins.
Pourquoi développer une application mobile cross-platform reste un pari rentable (mais pas toujours)
J'ai longtemps cru que le natif était la seule voie sérieuse. Puis j'ai livré une app de suivi d'entraînement en Flutter pour un client qui n'avait pas les moyens de payer deux développeurs — un iOS, un Android — et le résultat m'a fait réviser ma position. On a sorti la première version en sept semaines. Deux bases natives auraient demandé le double, sans compter la synchronisation des deux équipes, qui est un enfer logistique.
Ce que vous gagnez vraiment
Le gain principal n'est pas tant le coût initial que la cohérence. Une seule logique métier, un seul système de validation, un seul endroit où corriger un bug. Quand un utilisateur signale que le bouton « valider » ne répond pas, vous regardez un fichier, pas deux.
- Mise sur le marché plus rapide — souvent deux à trois fois moins de temps au démarrage.
- Une seule équipe à recruter et à faire monter en compétence.
- Interface identique sur les deux plateformes, ce qui simplifie le support client.
- Mises à jour synchronisées, sans risque de décalage entre versions.
Ce que vous payez en échange
Et là, je vais être franc : le cross-platform ne fait pas de miracle sur les cas limites. Le jour où votre app doit lire un capteur de fréquence cardiaque en arrière-plan, dialoguer avec une montre connectée ou gérer des animations à 120 images par seconde, vous sentez le plafond. Ce n'est pas que ce soit impossible. C'est qu'il faut écrire du code natif par-dessus, et que ce code-là, il faut le maintenir deux fois.
Sur un projet que j'ai repris il y a deux ans, une app de paiement, l'équipe précédente avait empilé onze plugins pour couvrir des besoins natifs. Trois d'entre eux n'étaient plus maintenus. Résultat : une mise à jour iOS a tout fait tomber, et on a passé trois semaines à réécrire des ponts qu'on aurait pu éviter en partant sur du natif dès le départ.
Les frameworks et outils utilisés dans le développement d'applications mobiles : comment choisir sans se tromper
La vraie question n'est pas « quel est le meilleur framework ? ». Elle est « lequel correspond à votre équipe et à votre projet ? ». J'ai vu trop de choix guidés par un article de blog, jamais par le profil des gens qui allaient écrire le code.
Flutter, React Native, et le reste
Flutter, poussé par Google, compile vers du code machine et donne des interfaces très homogènes entre plateformes. Son langage, Dart, déroute au début, mais la prise en main est rapide. React Native, porté par Microsoft et Meta, s'appuie sur JavaScript et React — un avantage énorme si votre équipe web existe déjà, car elle peut basculer sans réapprendre un métier.
En dehors de ces deux-là, on trouve Ionic, qui enveloppe une application web dans une coque native. Pratique pour du contenu, risqué dès qu'on demande de la fluidité. Et .NET MAUI côté Microsoft, pertinent si vous vivez déjà dans l'écosystème Visual Studio et Azure.
| Outil | Langage | Idéal pour | Point faible |
|---|---|---|---|
| Flutter | Dart | Interfaces sur mesure, design exigeant | Dart rare sur le marché du travail |
| React Native | JavaScript / TypeScript | Équipes web déjà en place | Dépendance forte à l'écosystème de plugins |
| Ionic | Web (HTML/CSS/JS) | Apps simples, contenu, formulaires | Animations et gestes peu fluides |
| .NET MAUI | C# | Entreprises déjà sur Microsoft | Communauté plus réduite |
La grille que j'utilise maintenant
Avant de trancher, je pose trois questions au client. Est-ce que l'app dépend de fonctions natives pointues ? Quelle est la compétence réelle de l'équipe, aujourd'hui, pas dans six mois ? Et quel est l'horizon : un MVP à valider en trois mois, ou un produit qui doit tenir cinq ans ?
- MVP à tester vite → cross-platform, sans hésiter.
- App critique mêlant capteurs et arrière-plan → natif, ou cross-platform avec des briques natives assumées.
- Équipe déjà familière avec React → React Native réduit la friction à presque rien.
- Design très spécifique, animations au cordeau → Flutter tient mieux la route.
- App interne simple, peu d'utilisateurs → Ionic suffit largement.
Les compromis techniques qu'on ne vous dit pas
Le discours habituel parle de « quelques compromis ». Concrètement, voici ce qui se passe sur le terrain.
La part de code partagée n'est jamais de 100 %
On lit partout qu'une base unique couvre tout. En pratique, sur les projets que j'ai menés, on partageait entre 70 et 85 % du code. Le reste, ce sont les permissions, les notifications, les comportements de navigation propres à chaque système, et parfois l'accès aux fichiers. Ce n'est pas grave — il faut juste le budgéter dès le départ, sinon la surprise arrive en fin de projet.
La maintenance des plugins
C'est le point qui m'a le plus coûté. Un plugin non maintenu, c'est une bombe à retardement. Chaque mise à jour majeure d'iOS ou d'Android peut le casser. Ma règle aujourd'hui : avant d'adopter un plugin, je regarde la date du dernier commit et le nombre de contributeurs actifs. Un plugin sans mise à jour depuis plus d'un an, je cherche une alternative, même si elle demande plus de travail au début.
Spoiler : ce travail en amont vous fera gagner des semaines plus tard. Je l'ai appris à la dure, sur une release bloquée la veille d'un lancement.
Performances : où est le vrai plafond ?
Sur une app de formulaires ou de contenu, vous ne verrez aucune différence avec le natif. Sur du traitement d'image en temps réel ou de la 3D, la différence devient visible. Pas catastrophique, mais visible. Si votre produit repose sur ces usages, testez tôt, sur un appareil modeste, pas sur le dernier modèle du bureau.
Coût total de possession : le chiffre que personne ne calcule
Le coût de la première version, tout le monde le regarde. Le coût des trois années suivantes, presque personne. Et c'est là que le cross-platform peut se retourner contre vous — ou vous sauver.
Sur un projet natif double, chaque nouvelle fonctionnalité se développe deux fois, se teste deux fois, se corrige deux fois. Sur du cross-platform, une seule fois. Sur une année complète, avec une équipe réduite, ça représente facilement un tiers du temps de développement économisé. Ce n'est pas rien.
Mais il y a un revers. Une mise à jour majeure du système, un changement de politique de confidentialité, une nouvelle API obligatoire : sur du natif, vous suivez la documentation officielle. Sur du cross-platform, vous dépendez aussi du framework et de ses plugins. Quand Flutter ou React Native prennent du retard sur une nouveauté système, vous attendez. Parfois quelques jours. Parfois plusieurs mois.
Développer une application mobile cross-platform, ce n'est donc pas un choix technique isolé. C'est un choix de dépendance. Vous déléguez une partie de votre avenir à une communauté et à un éditeur. La plupart du temps, c'est un bon deal. Il faut juste le savoir avant de signer.
Questions qu'on me pose souvent
Est-ce que je peux passer du cross-platform au natif plus tard ?
Oui, mais rarement sans douleur. La logique métier se transpose bien, l'interface se réécrit. Le vrai coût, c'est la période de transition où vous maintenez les deux. Si vous prévoyez ce basculement dès le départ, gardez votre code métier isolé de l'interface. Ça change tout le jour où vous décidez de bouger.
Le cross-platform, c'est suffisant pour une app de e-commerce ?
Pour la grande majorité des boutiques, oui. Les parcours d'achat, les paiements, les catalogues se gèrent très bien. Le point d'attention, ce n'est pas le framework, c'est le tunnel de paiement : il faut qu'il soit irréprochable sur les deux plateformes, car chaque friction se paie en chiffre d'affaires.
Combien de temps pour une première version ?
Sur les projets que j'ai suivis, une app avec authentification, liste de contenus et notifications partait sur six à dix semaines en cross-platform, contre douze à seize en natif double. Le périmètre compte plus que la techno : ajoutez un paiement ou un chat temps réel, et tout double.
Ce que je recommande, et que j'assume
Si vous démarrez aujourd'hui, en 2026, avec une équipe réduite et une idée à valider : partez sur du cross-platform. Le temps gagné au démarrage vaut plus que la perfection technique que vous n'atteindrez de toute façon pas sur une première version.
Si vous construisez un produit où la performance native est le cœur de l'expérience, ou si vous dépendez de matériel spécifique, réfléchissez à deux fois. Le natif coûte cher, mais il vous évite des plafonds que vous ne verrez qu'au pire moment.
Le reste, c'est du détail. Le vrai piège n'est jamais le framework. C'est de choisir sur un coup de tête, sans regarder l'équipe, le périmètre et l'horizon. Faites cet exercice honnêtement, et la décision se prend presque toute seule. La question à vous poser n'est pas « quelle techno est la meilleure ? » mais « de quoi mon équipe est-elle réellement capable, seule, dans six mois, quand personne ne regardera plus ? ».
