Développer une application mobile multiplateforme : le guide qui change tout

« On fait du Flutter ou du React Native ? » J'ai posé cette question à voix haute dans une salle de réunion il y a quelques années, persuadé d'avoir le choix. En face de moi, le CTO a haussé les épaules : « Ça dépend si tu veux un lecteur de carte bancaire Bluetooth ou juste un joli catalogue. » Je n'avais pas la réponse. Deux semaines plus tard, on a jeté le prototype qu'on venait de finir.

Développer une application mobile multiplateforme ne commence jamais par un framework. Ça commence par une contrainte matérielle, un délai ou un budget que personne n'a envie de regarder en face. Le reste, c'est de la littérature. Je vais vous raconter comment je m'y prends maintenant, avec les chiffres que j'ai réellement encaissés.

Pourquoi développer une application mobile multiplateforme reste un pari rentable

La question qu'on me pose le plus souvent, c'est : « mais est-ce qu'on ne va pas le regretter ? » Réponse honnête : ça dépend de votre app, pas de votre budget.

Ce qui a changé ces dernières années, c'est le niveau de maturité des frameworks. Quand j'ai commencé à bricoler avec Flutter en 2019, l'écosystème des plugins était une passoire. Aujourd'hui, pour une app de gestion, de e-commerce ou de contenu, la couverture est très large. Le problème n'est plus « est-ce que ça marche ? » mais « qu'est-ce qui va casser dans six mois ».

Le code unique n'est pas une promesse magique

Sur mon dernier projet livré à un client dans le secteur de la santé, on a démarré en Flutter avec une cible Android et iOS. Résultat concret : 72 % du code partagé. Pas 95 %, pas 100 %. Le reste, ce sont les intégrations spécifiques (lecteur de code-barres, notifications avec actions custom, gestion du retour haptique).

Donc quand on vous vend « un code, toutes les plateformes », traduisez par « deux tiers du code, et un tiers à soigner à la main ». C'est déjà énorme. Mais si vous partez sur cette base en pensant toucher le pactole, vous allez déchanter à la première mise à jour iOS.

Combien de temps pour sortir un MVP ?

Mon chiffre : 6 à 10 semaines pour un MVP multiplateforme crédible (une équipe de deux devs, un designer à mi-temps). En dessous, soit vous coupez dans le scope, soit vous mentez. J'ai vu des équipes annoncer un MVP en 3 semaines : elles livraient une coquille vide, sans authentification propre ni vraie base de données.

Le plus lent dans cette histoire n'est pas le développement. C'est la review des stores. Apple met parfois 5 jours à valider une première soumission, et chaque refus coûte 2 à 3 jours de ping-pong.

Flutter, React Native, .NET MAUI : le comparatif que personne ne vous fait vraiment

Les articles qui listent les frameworks vous donnent toujours les mêmes trois noms dans le même ordre. On va plutôt regarder ce qui compte : le langage, les performances réelles, et le coût quand un plugin casse.

Framework	Langage	Perf. UI	Maturité écosystème	Quand l'éviter
Flutter	Dart	Très haute (moteur propre)	Large et stable	Équipe 100 % JS déjà en place
React Native	JavaScript / TypeScript	Bonne (bridge à surveiller)	Très large, hétérogène	App graphiquement lourde (jeux, animations 3D)
.NET MAUI	C#	Correcte	Plus restreint, plus jeune	Vous partez de zéro sans équipe .NET
Kotlin Multiplatform	Kotlin	Native par plateforme	En croissance, moins fourni	Vous voulez un vrai partage UI

Flutter ou React Native : comment trancher ?

La vraie question, c'est : qui va maintenir le code dans deux ans ? Si votre équipe est composée de devs JavaScript, partir sur Flutter signifie embaucher ou former. Et former une équipe sur Dart, ça prend 2 à 3 semaines pour être productif, plus longtemps pour être bon.

Inversement, si vous partez sur React Native juste parce que c'est JS, vous allez découvrir les joies du bridge et des animations qui saccadent sur les vieux Android. J'ai vécu les deux, et franchement, aucun des deux n'est confortable si vous ne choisissez pas en fonction de l'équipe.

Et Microsoft dans tout ça ?

Microsoft pousse .NET MAUI dans son écosystème Visual Studio, avec une promesse de code unique pour Android, iOS, Windows et macOS. Sur le papier, c'est séduisant, surtout si vous avez déjà du C# côté back-end. En pratique, l'écosystème de plugins tiers est plus court, et vous passez plus de temps à écrire votre propre glue.

Mon avis tranché : si votre entreprise vit dans l'écosystème .NET, MAUI vaut le coup. Sinon, vous vous enfermez dans un choix que peu de freelances maîtrisent.

Choisir son IDE et son environnement, ça n'a rien d'anodin

Android Studio reste l'outil de référence pour tout ce qui touche au monde Android, y compris quand vous développez en Flutter ou React Native. Vous allez y passer du temps, ne le sous-estimez pas.

Le vrai piège que j'ai rencontré, ce n'est pas l'IDE, c'est la machine. Sur un MacBook de 2019 avec 16 Go de RAM, lancer simultanément un émulateur Android, le simulateur iOS et le serveur de debug, c'est la garantie de perdre 30 minutes par jour rien qu'en attente. J'ai fini par demander au client un budget matériel de 2 500 € pour deux postes corrects. Le ROI a été visible en une semaine.

• Android Studio : pipeline Android complet, gestion des émulateurs, profiler intégré. Indispensable même en multiplateforme.
• Visual Studio / VS Code : selon le framework, l'expérience varie beaucoup. VS Code pour React Native et Flutter, Visual Studio pour MAUI.
• Xcode : obligatoire pour compiler et signer côté iOS, même si vous ne codez jamais en Swift.

Faut-il un pipeline CI/CD multiplateforme dès le début ?

Oui. Et je vais vous dire pourquoi je l'ai appris à la dure : sur un projet, on a livré la v1 sans automatisation, avec des builds manuels. À la première mise à jour de sécurité d'une dépendance, on a perdu neuf heures à reproduire des environnements. On a mis en place un pipeline simple dans la foulée, et à partir de là, chaque release est passé à 20 minutes.

Un pipeline basique, ça veut dire : build automatique sur push, tests unitaires, distribution aux testeurs internes (TestFlight et Play Console interne), et un canal de bêta public. Rien de révolutionnaire, mais ça change la vie.

Les limites réelles que personne ne vous prévient à l'avance

Bon, maintenant la partie que les articles de présentation sautent toujours : ce qui casse.

L'accès au matériel, le premier mur

Le Bluetooth Low Energy, la lecture de cartes NFC, l'accès bas niveau à la caméra, tout ça passe par des plugins qui dépendent de la bonne volonté de leurs mainteneurs. Quand un plugin vital est abandonné, vous avez trois options : forker (et maintenir à vie), écrire un module natif (retour au natif, ironie), ou changer de framework.

J'ai vécu la version « forker » sur un projet d'assurance. Le mainteneur avait arrêté, et on a dû reprendre un module Bluetooth pour une mise à jour Android. Coût réel : trois semaines de dev pour un dev senior. On ne l'avait pas budgété.

La dette de performance

Une app multiplateforme se porte bien jusqu'à un certain volume d'utilisateurs simultanés et une certaine complexité d'écrans. Sur les listes longues, sur les animations denses, sur les cartes interactives, vous allez voir les limites en production, pas en démo.

Ma règle : si votre app affiche régulièrement plus de 200 éléments à l'écran avec animations, mesurez très tôt. Un test de charge à 500 utilisateurs simultanés coûte moins cher qu'un refactor d'urgence.

Une PWA peut-elle remplacer une app multiplateforme ?

Parfois oui. Si votre app est essentiellement du contenu, du formulaire et de la consultation, une Progressive Web App couvre le besoin, sans les stores, sans la review, sans les contraintes de signature. J'ai vu un client économiser 30 % du budget prévu en basculant sur une PWA.

Mais dès que vous touchez au Bluetooth, aux notifications riches, à l'accès fichier persistant ou à la caméra avancée, la PWA montre ses limites. Et sur iOS, la situation des PWAs est plus restrictive que sur Android, il faut le savoir avant de s'engager.

Coût réel, dette technique et ROI : les vrais chiffres

Sur quatre projets multiplateformes livrés ces dernières années, voici ce que j'ai observé, en me limitant à ce que j'ai vraiment compté.

• Développement initial multiplateforme : 0,6 à 0,8 fois le coût d'un développement natif double.
• Maintenance annuelle : entre 15 et 25 % du coût initial, davantage si vous avez beaucoup de plugins tiers.
• Délai pour la première version en production : 3 à 5 mois pour une app métier, plus pour du grand public.
• Mises à jour OS majeures : prévoir 2 à 4 semaines par an pour rester compatible.

Le point qu'on sous-estime systématiquement, c'est la maintenance des dépendances. Sur un projet, on avait 23 plugins dans le fichier de dépendances. Trois mois après la sortie, deux étaient abandonnés, un avait une faille de sécurité. On a passé une semaine complète à remplacer l'un par un fork interne, et à patcher l'autre.

Autrement dit, votre coût multiplateforme ne se joue pas au lancement. Il se joue au premier trimestre d'après.

Ma méthode de décision, en cinq questions

Quand on me demande aujourd'hui comment je choisis, je déroule toujours le même questionnaire. Il tient sur une feuille, et il évite 80 % des erreurs.

1. Quels capteurs ou modules natifs l'app doit-elle utiliser ? Si c'est du Bluetooth bas niveau, du NFC ou de la biométrie avancée, attendez-vous à écrire du natif.
2. Quelle est la compétence dominante de l'équipe ? JS, Dart, C#, rien du tout ? Ça oriente plus que n'importe quel benchmark.
3. Quel est le vrai délai ? Si c'est moins de deux mois, arrêtez le multiplateforme et livrez une PWA ou une version smartphone unique.
4. Quel volume d'utilisateurs dans 18 mois ? Si vous visez un million, vous serez content d'avoir des équipes natives au moins côté support.
5. Qui maintient dans deux ans ? Si vous ne savez pas répondre, vous prenez une dette que personne ne paiera.

Faut-il embaucher un dev multiplateforme unique ?

Non, sauf si vous êtes une petite structure avec un besoin limité. Un dev Flutter seul, c'est très bien pour un MVP. Pour une app en production, prévoyez au minimum deux profils, dont un qui connaît le natif côté plateforme. Le jour où un plugin casse, vous serez content de l'avoir.

Le multiplateforme vaut-il vraiment le coup en 2026 ?

Pour 70 à 80 % des apps métier ou grand public, oui. Le gain de temps et de budget est réel, et les frameworks ont atteint une maturité que je n'aurais pas imaginée quand j'ai commencé. Pour le reste, le natif reste la meilleure réponse, et prétendre le contraire serait vous vendre quelque chose.

Ce que je retiens, et ce que je changerais

Si je devais repartir sur mon premier projet multiplateforme, je changerais une chose : j'aurais passé une semaine entière à lister les intégrations natives avant d'écrire la première ligne de code. Une semaine de documentation m'aurait économisé un mois et demi de refactor.

Le multiplateforme n'est pas une religion. C'est un outil qui marche très bien quand on l'utilise pour ce qu'il sait faire, et qui se retourne contre vous quand on lui demande d'être du natif. La prochaine fois qu'on vous vend « un code, toutes les plateformes », demandez plutôt : « et pour le Bluetooth, vous faites comment ? ». La réponse vous en dira plus que n'importe quelle table de comparaison.