Flutter promet une base de code partagée. Le natif rassure par sa proximité avec iOS et Android. La PWA paraît plus simple à diffuser. Sur le papier, les trois options se défendent. Le problème, c’est qu’elles ne répondent pas aux mêmes contraintes.
Le choix se joue donc ailleurs : dans ce que l’application doit réellement faire sur le téléphone, la façon dont elle sera distribuée et les compétences disponibles pour la maintenir. Une bonne V1 ne cherche pas à tout prévoir. Elle doit tester le produit sans préparer une impasse dès la version suivante.
En bref
- Choisissez à partir des usages, pas de la popularité d’un framework.
- Le natif est à étudier lorsque l’application dépend fortement du système, du matériel ou des traitements en arrière-plan.
- Une PWA convient bien à un service diffusé d’abord par le web, à condition de tester ses fonctions sur les appareils visés.
- Flutter partage une large partie du code entre iOS et Android, mais ne supprime ni les tests ni les adaptations propres à chaque plateforme.
- Comparez le coût initial avec la maintenance, la reprise du code et le rythme des futures versions.
- Pour une application liée à un objet connecté, le Bluetooth, le hors-ligne et la synchronisation peuvent faire basculer la décision.
Commencer par le produit, pas par le framework
Faire cadrer le projet par une agence de développement d’application mobile permet de confronter l’idée aux contraintes réelles d’iOS, d’Android et du web. Mirai Tech présente une approche qui ne pousse pas une technologie unique : l’agence travaille en natif, Flutter ou React Native selon le projet.
Elle indique aussi prendre en charge le cadrage, le design, les tests sur de vrais appareils, la publication, puis la maintenance de l’application et le suivi de sa compatibilité avec les stores.
Le choix de la stack reste lié au budget, aux performances et à la feuille de route. Mirai Tech précise que le client garde son code source et ses comptes App Store et Google Play. Ce détail devient décisif lorsqu’il faut changer de prestataire ou reprendre le développement.
Six contraintes à écrire avant le premier écran
Avant de parler framework, six questions suffisent déjà à faire le tri :
- l’application doit-elle exploiter le Bluetooth, le GPS, la caméra, le NFC ou la biométrie ?
- que doit-elle encore faire sans connexion ? Que se passe-t-il si la connexion coupe pendant la synchronisation ?
- doit-elle synchroniser des données ou déclencher des tâches en arrière-plan ?
- sera-t-elle ouverte depuis une URL, installée sur un parc interne ou téléchargée depuis les stores ?
- quelles compétences seront disponibles pour la maintenir dans deux ou trois ans ?
- quelle hypothèse la première version doit-elle valider ?
Ces réponses écartent souvent une option sans débat interminable. Un portail consulté quelques fois par mois n’a rien à voir avec une application qui doit configurer un capteur par Bluetooth, dans un sous-sol et sans réseau.
Une V1 doit apprendre quelque chose
Le périmètre technique vient après le périmètre produit. Une V1 chargée de vingt fonctions peut produire beaucoup de code et très peu de réponses. Le premier livrable doit mesurer une hypothèse : adoption, fréquence d’usage, réalisation d’une tâche ou capacité à vendre le service.
Le prototype doit cibler le risque principal, par exemple une synchronisation hors ligne, plutôt que l’écran le plus visible.
Le Mirai Talk avec Tristan Gabriel illustre ce point. Il explique avoir attendu environ deux ans avant de confronter le produit au marché. L’application avait été pensée trop largement, et les conséquences du choix de Flutter n’avaient pas été pleinement mesurées au départ. La vidéo montre surtout pourquoi le cadrage et la réduction du MVP précèdent le choix définitif des outils.
Application native : quand le téléphone impose ses règles
Une application native utilise les outils propres à chaque plateforme, généralement Swift ou Objective-C côté iOS, Kotlin ou Java côté Android. Elle donne l’accès le plus direct aux API du système et aux nouveautés publiées par Apple ou Google.
Les cas où le natif se justifie
Le natif mérite d’être étudié lorsque les API web ou les plugins multiplateformes couvrent mal une capacité requise, par exemple une intégration Bluetooth particulière ou un traitement d’image spécifique.
Il convient aussi aux applications qui exigent une interface très particulière, un contrôle fin des mécanismes d’arrière-plan, ou dont la performance graphique et la réactivité font partie du service rendu. iOS et Android continuent toutefois de limiter l’exécution en arrière-plan pour préserver la batterie, les données et la confidentialité.
Pour un usage critique, ce contrôle peut valoir plus que la mutualisation du code.
Le prix de ce contrôle
Deux plateformes signifient souvent deux implémentations, deux jeux de tests et des publications à coordonner. Pour une petite équipe, maintenir la parité entre iOS et Android peut vite devenir un travail à part entière.
Le natif est donc surdimensionné pour un service simple dont l’activité principale se déroule déjà sur le web. Son intérêt apparaît lorsque les fonctions essentielles dépendent étroitement d’iOS, d’Android ou du matériel. Le choisir par simple souci d’image n’apporte rien au produit.
PWA : diffuser vite sans emballer trop tôt le produit
Une Progressive Web App utilise les technologies du web. Elle s’ouvre depuis une URL et peut, selon le navigateur et le système, être installée avec une icône, fonctionner hors ligne ou accéder à certaines fonctions de l’appareil.
Les situations où une PWA peut suffire
La PWA convient à un portail métier, un service consulté ponctuellement ou un outil destiné à un parc connu. Elle évite de soumettre chaque correction aux stores. Cette souplesse ne rend pas les mises à jour magiques pour autant : le service worker et le cache doivent gérer correctement le passage vers la nouvelle version.
La PWA convient lorsque le web reste le canal principal et que les fonctions matérielles avancées ne sont pas indispensables.
Les limites se vérifient appareil par appareil
Les capacités du web progressent, mais elles ne sont pas identiques partout. Une API peut être disponible dans un navigateur et absente dans un autre. L’installation varie également : sur iOS et iPadOS, l’ajout à l’écran d’accueil passe par le menu de partage plutôt que par une invite automatique du navigateur.
Le hors-ligne demande une vraie stratégie de cache et de synchronisation. Les permissions, les notifications ou l’accès au matériel doivent être testés sur la flotte cible. Une PWA n’est pas une application native moins chère : c’est un produit web avec ses propres règles.
Flutter : partager le code sans effacer les plateformes
Flutter est un toolkit multiplateforme basé sur Dart. Il permet de partager une large partie du code et de l’interface entre iOS et Android. Pour les versions mobiles de production, le code est compilé vers du code machine.
Le compromis adapté à de nombreuses premières applications
Flutter devient intéressant lorsqu’un même produit doit rejoindre rapidement les deux stores avec une équipe resserrée. Une base commune limite la duplication et aide à faire évoluer les fonctions au même rythme.
Le code partagé ne règle pas tout
Les permissions, les règles des stores et certains comportements restent propres à iOS ou Android. Une intégration avancée peut dépendre d’un plugin, d’un platform channel ou de code natif. Il faut alors évaluer la qualité de la dépendance, sa maintenance et la possibilité de la remplacer.
Les tests sur de vrais appareils restent indispensables avant la mise en production. Flutter réduit la duplication, mais il ne transforme pas deux systèmes mobiles en une plateforme unique. Le gain tient tant que le projet reste bien couvert. Une fonction atypique peut vite consommer le temps économisé.
Tableau comparatif : quelle option selon vos contraintes ?
| Critère | Natif | PWA | Flutter |
|---|---|---|---|
| Distribution principale | App Store et Google Play | URL, installation selon navigateur et système | App Store et Google Play |
| Accès aux fonctions du téléphone | Le plus direct | Variable selon les API et les plateformes | Large, avec plugins ou code plateforme si nécessaire |
| Partage du code iOS/Android | Limité | Fort côté web | Élevé |
| Hors-ligne | Maîtrisable finement | Possible avec cache et synchronisation à concevoir | Maîtrisable selon l’architecture |
| Équipe réduite | Deux compétences à couvrir | Pertinent si l’équipe maîtrise le web | Bon compromis si l’équipe maîtrise Dart et le mobile |
| Risque principal | Coût et double maintenance | Support inégal des capacités | Dépendances et faux sentiment d’unification |
| Bon premier usage | Produit très intégré au téléphone | Portail, outil interne ou service web-first | Application mobile destinée aux deux stores |
Lire le budget sur tout le cycle de vie
Le devis le moins élevé n’est pas toujours le moins coûteux. Une PWA réduit souvent le développement initial, mais demande des tests entre navigateurs, un cache et une synchronisation. Flutter mutualise le code, pas les plugins, les adaptations natives et les publications. En natif, il faut financer deux chaînes de développement et de test, mais ce choix peut éviter des adaptations fragiles lorsque le produit dépend fortement des fonctions natives du mobile.
Comparez aussi les appareils de test, les comptes développeur, les dépendances et les compétences de reprise. Regardez ce que le produit coûtera à corriger et à faire évoluer, pas seulement ce qu’il coûte à mettre en ligne.
Le cas d’une application compagnon IoT
Dans un projet IoT, l’application n’est que la partie visible du système. Elle dialogue avec un équipement, une API, un système d’identité et parfois une chaîne de mise à jour du firmware. Le guide pour concevoir un objet connecté aide à replacer l’interface mobile dans cet ensemble.
Pour un outil d’installation sur un parc contrôlé, une PWA peut suffire si toutes les API requises sont prises en charge. Web Bluetooth n’est notamment pas pris en charge par Safari sur iOS à la date de rédaction : un projet qui en dépend doit tester cette incompatibilité avant de retenir le web.
Pour une application grand public avec Bluetooth, notifications et publication sur les deux stores, Flutter peut offrir un bon équilibre après validation des plugins. Si la communication avec l’appareil ou l’exécution en arrière-plan devient critique, le natif peut reprendre l’avantage.
Dans tous les cas, cartographier l’architecture IoT du capteur au cloud évite de choisir le front mobile sans regarder la synchronisation, la sécurité et l’exploitation du reste du système.
La checklist avant de signer le développement
- Où les utilisateurs trouveront-ils l’application ? Une URL, un catalogue interne ou les stores n’imposent pas le même parcours.
- Quelles fonctions du téléphone sont indispensables ? Distinguez le cœur du produit des options confortables.
- Que se passe-t-il sans réseau ? Précisez les données accessibles, les actions possibles et les règles de resynchronisation.
- Qui maintiendra le code dans trois ans ? Vérifiez les compétences, la documentation et la disponibilité des dépendances.
- Quelle preuve attendez-vous de la V1 ? Une métrique claire aide à couper les fonctions qui ne servent pas encore la décision.
Si deux options restent crédibles, testez la fonction la plus risquée sur les appareils cibles. Le résultat tranchera mieux qu’un comparatif théorique.
Vérifiez aussi la propriété du code et des comptes stores, les tests, le diagnostic des incidents et les dépendances qui pourraient bloquer une reprise. Un devis attractif coûte vite cher si personne ne sait relancer le produit.
PWA si le web et la diffusion directe dominent. Flutter pour viser les deux stores avec un socle commun. Natif si les contraintes du téléphone commandent l’architecture. Le bon choix n’est pas le plus récent, mais celui qui teste la V1 sans compliquer la suivante.
FAQ : choisir entre natif, PWA et Flutter
Quelle solution coûte le moins cher pour une première application ?
Il n’existe pas de réponse valable pour tous les projets. Une PWA revient souvent moins cher si le service reste centré sur le web. Flutter limite la duplication entre iOS et Android. Le natif demande généralement plus de travail sur deux plateformes, mais peut éviter des adaptations coûteuses lorsque le produit dépend fortement des fonctions du mobile.
Une PWA fonctionne-t-elle vraiment hors ligne ?
Oui, à condition d’avoir prévu ce fonctionnement dès la conception. Il faut choisir les données conservées sur l’appareil, les actions autorisées sans réseau et la manière de resynchroniser les changements. Une PWA ne devient pas automatiquement utilisable hors ligne parce qu’elle possède un service worker.
Flutter est-il équivalent à du développement natif ?
Non. Flutter est un framework multiplateforme qui compile ses applications mobiles vers du code machine. Il partage une grande partie du code entre iOS et Android, mais certaines permissions, intégrations ou règles de publication restent propres à chaque système. Des plugins ou du code spécifique peuvent alors être nécessaires.
Faut-il choisir le natif pour utiliser le Bluetooth ?
Pas systématiquement. Flutter peut s’appuyer sur des plugins, tandis que certaines API web couvrent une partie des usages Bluetooth. La décision dépend du protocole, des échanges attendus et des appareils visés. Une PWA fondée sur Web Bluetooth reste notamment incompatible avec Safari sur iOS à la date de rédaction.
Peut-on changer de technologie après le lancement ?
Oui, mais le changement implique souvent de réécrire une partie de l’application. Une API bien séparée, des données documentées, des tests et la propriété du code facilitent la transition. Mieux vaut donc préserver ces éléments dès la V1, même lorsque la technologie retenue n’est que provisoire.