Ce que le natif apporte encore
Développer deux applications séparées, une en Swift pour iOS et une en Kotlin pour Android, reste le choix le plus sûr quand l'application repose sur le matériel : traitement vidéo, réalité augmentée, capteurs à haute fréquence, ou intégration profonde avec le système comme les widgets avancés et les extensions.
Le natif garde aussi l'avance sur le jour zéro : quand Apple ou Google publie une nouveauté système, elle est disponible immédiatement, alors qu'un framework multiplateforme doit d'abord la porter.
Le prix de cette sûreté est mécanique : deux bases de code, deux compétences à trouver, et chaque fonctionnalité écrite puis testée deux fois. En pratique, comptez presque le double.
Ce que Flutter change
Flutter compile une seule base de code vers iOS et Android, et dessine lui-même son interface plutôt que de piloter les composants du système. C'est ce qui explique à la fois sa force et sa limite : le rendu est identique partout et fluide, mais l'application ressemble moins spontanément à une application native.
Pour la très grande majorité des applications métier, c'est un bon compromis. Un catalogue, un espace client, une prise de commande, un suivi de livraison, un outil interne : tout cela se construit une fois et sort sur les deux magasins.
Le vrai gain n'est pas seulement le coût initial, c'est la maintenance. Une correction s'écrit une fois. Sur deux applications natives, elle s'écrit deux fois, se teste deux fois, et se désynchronise tôt ou tard.
L'option qu'on oublie : l'application web installable
Avant de partir sur une application, il faut se demander si vous en avez besoin. Une application web moderne s'installe sur l'écran d'accueil, fonctionne hors ligne, envoie des notifications sur Android, et se met à jour sans passer par une revue de magasin.
Elle évite deux frictions majeures : le téléchargement, qui fait perdre une bonne part des utilisateurs, et la revue des magasins, qui ajoute des jours à chaque correction. Elle coûte aussi nettement moins cher, parce que c'est le même travail qu'un site.
Ses limites sont réelles : les notifications restent bridées sur iOS, l'accès au matériel est plus restreint, et vous n'apparaissez pas dans les magasins, ce qui compte si la découverte passe par eux. Mais pour un outil utilisé par des clients qui viennent déjà de votre site, c'est souvent la réponse la plus rationnelle.
Le critère qui tranche
Posez la question dans cet ordre. Est-ce que l'application a besoin du matériel du téléphone au-delà de la caméra et de la position ? Si oui, natif. Sinon, est-ce que la présence dans les magasins est un canal d'acquisition réel pour vous ? Si non, une application web installable suffit probablement.
Si vous avez besoin des magasins mais pas du matériel avancé, Flutter est le point d'équilibre : une base de code, deux magasins, un coût proche de celui d'une seule application native.
Ne choisissez pas sur la réputation d'un framework. Choisissez sur ces trois questions, dans cet ordre, et la réponse est presque toujours la même que celle qu'un développeur honnête vous donnera.
Le comparatif
| Critère | Flutter | Natif (iOS + Android) |
|---|---|---|
| Bases de code à maintenir | Une | Deux |
| Coût relatif | Référence | Environ le double |
| Accès au matériel avancé | Bon, via des passerelles | Complet et immédiat |
| Nouveautés système | Disponibles après portage | Disponibles le jour même |
| Cohérence entre les deux OS | Identique par construction | À maintenir manuellement |
| Présence dans les magasins | Oui | Oui |
| Correction d'un bug | Écrite une fois | Écrite et testée deux fois |
En résumé
Choisissez le natif si l'application vit du matériel ou doit adopter les nouveautés système immédiatement. Acceptez alors le double coût, il est structurel.
Choisissez Flutter pour la quasi-totalité des applications métier qui doivent exister sur les deux magasins. C'est le meilleur rapport entre le coût, le délai et la qualité perçue.
Et posez-vous sérieusement la question de l'application web installable avant les deux autres. Sur un outil destiné à des utilisateurs qui vous connaissent déjà, elle sort plus vite, coûte moins cher, et se corrige sans attendre une revue.