L'argument commercial est connu : un seul développement pour iOS et Android, donc deux fois moins cher. C'est vrai dans les grandes lignes, mais imprécis — et l'économie réelle ne se situe pas tout à fait là où on la présente.
L'économie n'est pas sur le développement initial
Sur une première version, l'écart est réel mais moins spectaculaire qu'annoncé. Le travail de conception, de définition des parcours, d'intégration avec votre système de gestion et de préparation des fiches sur les magasins ne se divise pas par deux : il est fait une fois de toute façon.
Ce qui se mutualise, c'est l'écriture du code de l'interface et de la logique applicative. Comptez plutôt une économie de 30 à 40 % sur le budget total, pas de 50 %.
L'économie est sur les cinq années suivantes
C'est là que la différence devient franche. Avec deux bases natives, chaque correction se fait deux fois, se teste deux fois, se soumet deux fois aux magasins. Chaque évolution fonctionnelle est spécifiée une fois mais développée deux fois. Et les deux versions divergent, lentement mais sûrement.
Avec une base unique, une correction est écrite une fois. Sur une application maintenue cinq ans, l'écart cumulé dépasse largement l'économie initiale.
Le coût d'une application ne se juge pas à sa sortie, mais à la somme de ses mises à jour.
Ce que Flutter fait aussi bien que le natif
- Accès à l'appareil photo, au GPS, aux notifications, au stockage local, à la biométrie
- Mode hors ligne avec file d'attente et synchronisation au retour du réseau
- Fluidité d'affichage sur les appareils de milieu de gamme
- Publication sur l'App Store et Google Play, sans traitement particulier
Ce pour quoi le natif garde l'avantage
Il faut être honnête, il reste des cas :
- Réalité augmentée et traitement vidéo lourd en temps réel
- Intégration système poussée : widgets d'écran d'accueil complexes, extensions, montres connectées
- Accès immédiat aux nouveautés d'iOS ou d'Android le jour de leur sortie — les passerelles ont quelques semaines de retard
- Applications à très forte contrainte de taille, Flutter ajoutant quelques mégaoctets au binaire
Pour une application de gestion, une application e-commerce ou un outil pour équipes terrain, aucun de ces points ne s'applique.
Le point que personne ne vérifie avant de signer
Plus important que le choix technique : à qui appartiennent les comptes.
Nous reprenons régulièrement des applications dont les comptes développeur Apple et Google sont au nom du prestataire précédent, avec des clés de signature perdues. Conséquence : impossible de publier une mise à jour. Il faut republier sous une nouvelle fiche, et repartir de zéro sur les avis et le classement.
Trois choses à exiger contractuellement, quel que soit le choix technique :
- Comptes développeur Apple et Google ouverts à votre nom
- Clés de signature et certificats remis, avec leur procédure de renouvellement
- Dépôt Git complet et documentation de déploiement
En résumé
| Situation | Recommandation |
|---|---|
| Application métier ou e-commerce | Flutter |
| Outil pour équipes terrain, mode hors ligne | Flutter |
| Réalité augmentée, traitement vidéo | Natif |
| Budget serré, besoin des deux plateformes | Flutter |
| Une seule plateforme, intégration système poussée | Natif |
Dans le doute, posez la question autrement : combien d'évolutions prévoyez-vous dans les trois ans ? Plus la réponse est élevée, plus la base unique se justifie.