Application mobile : native, Flutter, PWA ou Tauri 2, comment choisir ?

Choisir la technologie d'une application mobile engage l'équipe pour plusieurs années. Un mauvais choix se paie en coûts de maintenance, en fonctionnalités impossibles à livrer ou en refus de publication sur les stores. Nous accompagnons régulièrement des organisations sur cette question, et la réponse dépend moins des modes que de quelques critères très concrets : ce que l'application doit faire avec le matériel, si elle doit fonctionner sans réseau, et qui la maintiendra demain. Voici notre grille de lecture, avec les quatre grandes familles d'approches.

Les quatre familles d'approches

Le natif : Swift et Kotlin

Le développement natif consiste à écrire deux applications distinctes : Swift (ou SwiftUI) pour iOS, Kotlin (et Jetpack Compose) pour Android. C'est la voie qui offre le meilleur accès aux API de la plateforme dès leur sortie, les meilleures performances graphiques et l'intégration la plus fidèle aux conventions de chaque système.

Le prix à payer est double : deux bases de code, donc deux équipes ou des profils rares, et un coût de maintenance qui se multiplie à chaque évolution fonctionnelle. Le natif se justifie pour les applications très gourmandes en calcul graphique, en réalité augmentée ou fortement liées à des API récentes du système.

Le cross-platform : Flutter et React Native

Flutter (Dart) dessine sa propre interface avec son moteur de rendu. React Native (TypeScript) pilote des composants natifs depuis du JavaScript. Dans les deux cas, une seule base de code vise iOS et Android, avec un accès au matériel via des plugins maintenus par l'écosystème.

C'est un excellent compromis pour une application mobile « pure ». Les limites apparaissent quand il faut aussi un site web ou une application de bureau : l'interface mobile ne se réutilise pas directement, et il faut souvent maintenir une seconde application web à côté.

La PWA : le web installable

Une Progressive Web App est un site web enrichi d'un manifeste, d'un service worker et d'une mise en cache. Elle s'installe sur l'écran d'accueil, fonctionne hors-ligne dans une certaine mesure et se déploie comme n'importe quel site : pas de validation par un store, mise à jour instantanée.

Ses limites sont connues. L'accès au matériel dépend du navigateur : la caméra et la géolocalisation fonctionnent bien, le Bluetooth ou le NFC restent inégaux, notamment sur iOS. La présence sur les stores n'est pas native, et le comportement du stockage hors-ligne varie selon les navigateurs. Pour un outil interne ou un service de consultation, c'est souvent largement suffisant.

Tauri 2 : une base web, un cœur en Rust

Tauri 2 permet de réutiliser une application web (Vue, Nuxt, React ou autre) et de l'empaqueter dans une application native, avec un cœur en Rust. Une même base de code cible le web, le bureau (Windows, macOS, Linux), Android et iOS. L'interface est rendue par la WebView du système, ce qui donne des binaires légers, et les fonctions natives sont exposées par des plugins officiels (scanner de codes-barres, NFC, notifications, système de fichiers, etc.).

Pour une équipe qui maîtrise déjà Vue et Nuxt, c'est un levier considérable : les composants, les stores et les routes sont partagés entre le site, l'application mobile et la version bureau. Le code Rust n'intervient que lorsqu'un besoin spécifique l'exige.

Les critères qui comptent vraiment

Accès matériel

Pour un scanner de codes-barres, de la NFC ou une caméra pilotée finement, le natif et les solutions cross-platform sont à l'aise. Tauri 2 couvre ces besoins via ses plugins officiels, et permet d'écrire ses propres commandes en Rust quand un plugin n'existe pas. La PWA reste la plus limitée, surtout sur iOS.

Hors-ligne

Un usage en magasin, en entrepôt ou en zone mal couverte impose de penser la synchronisation dès le départ. Une base locale (SQLite, IndexedDB), une file d'opérations en attente et une stratégie de résolution de conflits comptent plus que le choix du framework. Une application empaquetée avec Tauri garde ses ressources sur l'appareil, ce qui simplifie le démarrage sans réseau par rapport à une PWA dépendante de son cache.

Performance

Le natif et Flutter gagnent sur les animations complexes et les interfaces très riches. Une application de gestion, composée de listes, de formulaires et de scans, tourne parfaitement dans une WebView moderne. La performance perçue dépend davantage de la qualité de l'interface et des appels réseau que du moteur de rendu.

Maintenance et mises à jour

Moins il y a de bases de code, moins il y a de dette. Sur ce point, Tauri et la PWA partent avec un avantage quand une équipe web existe déjà. Côté mises à jour, la PWA est imbattable (un déploiement suffit). Pour les applications publiées sur les stores, chaque version repasse par une validation, ce qui impose de prévoir des délais et de découpler le plus possible la logique métier côté serveur.

Publication sur les stores

Publier sur l'App Store et Google Play suppose des comptes développeur, des certificats, des captures d'écran, une politique de confidentialité et le respect des règles de chaque store. C'est vrai quelle que soit la technologie. Le natif, Flutter, React Native et Tauri produisent tous des binaires acceptés. La PWA, elle, ne passe pas par ce circuit sans enveloppe supplémentaire.

Tableau comparatif

Un exemple avec Tauri 2 et Vue

Côté Vue, l'appel d'un plugin natif se fait avec quelques lignes de TypeScript. Voici un composant qui lance un scan de code-barres après avoir demandé l'autorisation d'utiliser la caméra :

<script setup lang="ts">
import { ref } from 'vue'
import {
  Format,
  checkPermissions,
  requestPermissions,
  scan,
} from '@tauri-apps/plugin-barcode-scanner'

const code = ref<string | null>(null)

async function scanProduct() {
  let state = await checkPermissions()
  if (state !== 'granted') {
    state = await requestPermissions()
  }
  if (state !== 'granted') return

  const result = await scan({ formats: [Format.EAN13], windowed: false })
  code.value = result.content
}
</script>

<template>
  <button type="button" @click="scanProduct">Scanner un produit</button>
  <p v-if="code">Code lu : {{ code }}</p>
</template>

Et pour une logique spécifique, une commande Rust s'expose en quelques lignes, puis s'appelle depuis le front :

#[tauri::command]
fn normalize_ean(code: String) -> String {
    code.trim().chars().filter(|c| c.is_ascii_digit()).collect()
}

import { invoke } from '@tauri-apps/api/core'

const ean = await invoke<string>('normalize_ean', { code: ' 3017 6200 00000 ' })

Le cycle de développement mobile reste dans la ligne de commande :

pnpm tauri android init
pnpm tauri ios init
pnpm tauri ios dev
pnpm tauri ios build

Notre retour d'expérience

Nous avons livré en production une application de gestion des dates de péremption destinée à la grande distribution, construite avec Nuxt, Tauri et Supabase, et disponible sur l'App Store. Ce projet nous a confirmé plusieurs points : une base Vue/Nuxt partagée accélère nettement les livraisons, le scan de codes-barres via plugin est fiable dès lors qu'on soigne les permissions et l'ergonomie, et le hors-ligne se conçoit en amont, pas en rattrapage. Il nous a aussi rappelé que la publication sur le store est un chantier à part entière, à anticiper dans le calendrier.

Comment trancher

Quelques repères simples résument notre approche :

• Un outil de consultation ou un service sans besoin matériel avancé : une PWA suffit souvent.
• Une application métier avec scan, hors-ligne et présence sur les stores, portée par une équipe web : Tauri 2 est un très bon candidat.
• Une application grand public, très visuelle, sans site web associé : Flutter ou React Native.
• Des exigences de performance graphique ou d'intégration profonde au système : le natif.

Dans tous les cas, mieux vaut valider le risque principal par un prototype court (le scan, la synchronisation, le passage en production sur le store) avant d'engager le projet complet.

Besoin d'un coup de main ?

Vous hésitez entre plusieurs approches ou vous souhaitez valider la faisabilité d'une application mobile ? Nous pouvons réaliser avec vous un cadrage technique et un prototype ciblé. N'hésitez pas à nous contacter.