« On peut tout faire en Flutter, non ? » Cette phrase, je l'ai entendue au moins quinze fois en rendez-vous. Elle vient toujours d'un client pressé, d'un fondateur qui a lu trois articles, ou d'un commercial qui veut un devis rapide. Et chaque fois, je dois répondre la même chose : presque. Le « presque » contient tout le métier.
Développer une application mobile multiplateforme, ce n'est pas magique. C'est un arbitrage permanent entre vitesse, budget et qualité perçue. Je travaille là-dedans depuis assez longtemps pour savoir où sont les pièges, et j'en ai mangé quelques-uns. Voici ce que j'aurais aimé qu'on m'explique au départ.
Points clés à retenir
- Multiplateforme ne veut pas dire « un code qui tourne partout sans effort » : chaque framework a ses angles morts.
- Un projet cross-platform bien mené coûte souvent 30 à 40 % de moins qu'un développement natif double.
- Le budget réel d'une app dépasse largement le devis de développement : maintenance, mises à jour OS, stores.
- Le salaire d'un développeur mobile se situe dans la fourchette haute des métiers du web, surtout en cross-platform spécialisé.
- La rentabilité d'une app dépend rarement de la techno choisie, presque toujours du modèle économique.
- Le pire choix reste d'empiler trois frameworks « pour voir ».
Comment choisir votre approche multiplateforme sans vous tromper
La question « native ou cross-platform ? » est mal posée. On me la pose constamment, et j'ai fini par répondre par une autre question : combien de fonctionnalités de votre app touchent vraiment au matériel ? Si la réponse tient sur une main, vous n'avez aucune raison de payer deux fois.
Les grandes familles de solutions
On peut grossièrement ranger les options en trois familles, et j'insiste sur « grossièrement » parce que les frontières bougent vite.
Les frameworks compilés comme Flutter dessinent eux-mêmes chaque pixel à l'écran. Résultat : un rendu identique sur Android et iOS, et un contrôle total sur les animations. Le revers : quand une nouveauté sort dans iOS, il faut attendre que l'équipe du framework l'intègre. J'ai attendu deux mois un correctif sur un widget natif en 2024, et le client ne l'a pas trouvé drôle.
Les frameworks à pont natif, type React Native, utilisent les composants natifs de chaque plateforme. Avantages : look and feel parfaitement natif, écosystème JavaScript énorme, recrutement plus simple. Inconvénient : la fameuse « bridge » qui fait le lien entre votre code et le natif peut devenir un goulot d'étranglement sur les listes longues ou les animations lourdes.
Les approches hybrides web (Ionic, Capacitor) embarquent une WebView. Franchement, pour une app interne ou un catalogue produit, ça fait le job. Pour du jeu, du traitement d'image ou de l'audio temps réel, oubliez. J'ai vu une équipe perdre six semaines à essayer de faire tourner de la reconnaissance vocale dans une WebView. Six semaines.
Comparatif rapide des options
| Solution | Idéal pour | Limite principale | Courbe d'apprentissage |
|---|---|---|---|
| Flutter | UI riche, animations, cohérence visuelle | Dépendance aux plugins tiers | Moyenne (Dart) |
| React Native | Équipe JS existante, apps classiques | Pont natif sur usages intensifs | Faible si vous faites déjà du React |
| Kotlin Multiplatform | Logique partagée, UI native | Encore jeune sur iOS | Élevée |
| .NET MAUI | Écosystème Microsoft, apps métier | Écosystème mobile plus restreint | Moyenne si vous venez du C# |
| Ionic / Capacitor | Apps simples, prototypage, PWA | Performances sur usages lourds | Faible |
Mon avis, et je sais qu'il fera grincer des dents : si votre équipe est déjà à l'aise en JavaScript, partez sur React Native. Si vous démarrez de zéro et que le rendu visuel compte, prenez Flutter. Si vous visez des usages matériels lourds, arrêtez de chercher et payez du natif. Voilà, c'est dit.
Comment puis-je développer une application mobile ?
Le parcours tient en sept étapes : poser votre idée sur papier, choisir entre app native et PWA, choisir votre méthode de développement, construire l'app, la tester sur de vrais appareils, la publier sur l'App Store et Google Play, puis la mettre à jour.
Ce qui est intéressant, ce n'est pas la liste, c'est ce qu'on y oublie. L'étape 5, les tests sur appareils réels, est systématiquement sous-estimée. Les émulateurs mentent. Ils mentent sur la batterie, sur la chaleur, sur la fluidité en conditions réseau dégradées. J'ai livré une fois une app parfaitement testée sur simulateur, qui plantait sur les Xiaomi d'entrée de gamme à cause d'une histoire de gestion mémoire. Le retour client a été… direct.
Autre point : si vous ne codez pas, un app builder reste une option viable. Vous composez l'app dans un éditeur visuel, et la plateforme la compile en application iOS, Android et en version web. Chez GoodBarber, par exemple, comptez à partir de 36 € par mois pour une PWA et 70 € par mois pour des apps iOS et Android, sans engagement après un essai gratuit de 30 jours. Ce n'est pas la solution pour tout le monde, mais pour un commerce ou une association, ça évite de mobiliser une équipe.
Les 3 méthodes en un coup d'œil
- App builder sans code : commerçants, médias, associations. Coût mensuel faible, publication rapide.
- Agence ou freelance : entreprises avec besoins spécifiques. Comptez en général de 4 000 à 50 000 €, pour une moyenne d'environ 18 semaines de développement.
- Développement en interne : pertinent quand l'app est votre cœur de métier et que vous embauchez durablement.
Dans tous les cas, prévoyez les frais de publication : 99 $ par an chez Apple, et 25 $ une fois chez Google. Détail, mais qui surprend toujours dans un budget serré.
Quel est le coût de la création d'une application mobile ?
Personne ne veut entendre la vraie réponse : ça dépend. Mais je peux au moins vous donner les fourchettes que je vois passer, parce qu'un chiffre concret vaut mieux qu'un « ça dépend ».
Sur un projet multiplateforme récent, une app de réservation avec compte utilisateur, paiement et notifications, on a livré en dix-neuf semaines pour environ 38 000 €. La même app en double natif iOS + Android aurait pris un tiers de temps en plus et coûté autour de 55 000 €. Ce n'est pas un hasard : le code métier était partagé à 85 %.
Trois postes font exploser les budgets :
- L'authentification avec des fournisseurs tiers (Apple, Google, parfois un SSO d'entreprise).
- Les paiements in-app, qui suivent des règles de commission différentes selon la plateforme.
- La synchronisation hors ligne, dès qu'un utilisateur doit pouvoir travailler sans réseau.
Et un poste qu'on oublie toujours : la maintenance. Apple et Google sortent des mises à jour majeures chaque année. Une app laissée sans entretien pendant dix-huit mois devient souvent non publiable. Budgétez 15 à 20 % du coût initial par an, minimum. Je l'ai vu être zéro sur plusieurs projets, et ces projets sont morts.
Quel est le salaire d'un développeur d'application mobile ?
En France, un développeur mobile junior démarre généralement autour de 35 000 à 42 000 € brut annuel. Un profil confirmé (trois à cinq ans) se situe plutôt entre 45 000 et 60 000 €. Les spécialistes cross-platform avec une vraie expérience de mise en production sur les deux stores peuvent viser au-delà.
Ce qui fait la différence, ce n'est pas le framework maîtrisé. C'est la capacité à livrer. Un développeur qui a publié cinq apps sait gérer les certificats de signature, les rejets de review, les crashs en production à 23 h. Un développeur qui a seulement fait des tutoriels Flutter, non. J'ai recruté les deux profils. Le second coûte moins cher sur le papier et beaucoup plus cher au final.
Est-ce rentable de créer une application ?
La rentabilité d'une app ne dépend presque jamais de la techno choisie. Elle dépend du modèle économique et de l'acquisition.
J'ai vu des apps natives magnifiques, financées à 80 000 €, qui n'ont jamais dépassé 200 téléchargements. Et j'ai vu une app multiplateforme bricolée en six semaines générer 4 000 € par mois via un abonnement à 4,99 €. La différence tenait à une chose : la seconde avait un canal d'acquisition déjà en place, une audience email existante.
Donc si vous cherchez un retour sur investissement, posez-vous d'abord cette question : d'où viendront les premiers utilisateurs ? Si votre réponse est « on verra, on fera du marketing après », la réponse est non, ça ne sera pas rentable.
Le multiplateforme aide simplement à ne pas gaspiller votre budget sur la partie technique. Il ne remplace pas la distribution.
Trois erreurs que je vois en boucle
La première, et de loin la plus fréquente : choisir le framework avant de savoir ce que l'app doit faire. On m'appelle souvent après trois semaines de développement, avec un prototype React Native à moitié construit et un besoin de reconnaissance d'image en temps réel. Il faut tout reprendre.
La deuxième : sous-estimer la fragmentation Android. Je passe un temps fou sur les appareils d'entrée de gamme et les vieilles versions d'Android. Sur iOS, c'est plus simple, mais Apple impose ses propres règles de review qui peuvent retarder une sortie de plusieurs jours.
La troisième : croire que « write once, run everywhere » signifie « coder une fois, ne plus y toucher ». Faux. Le multiplateforme réduit les coûts, il ne supprime pas le travail de plateforme. Vous finirez toujours par écrire du code spécifique iOS ou Android. Simplement, ce sera 10 à 15 % du projet au lieu de 100 %.
Si je devais résumer tout ça en une phrase : le multiplateforme est un excellent outil, à condition de ne pas lui demander de faire le travail à votre place. Le framework ne choisit pas votre modèle économique, ne trouve pas vos utilisateurs, ne décide pas quand arrêter une fonctionnalité. Il vous laisse juste plus de temps pour ces décisions-là. Ce qui, mine de rien, est déjà beaucoup.
