Les trois grandes approches
L'application native est écrite dans le langage de chaque plateforme : Swift pour iPhone, Kotlin pour Android. Deux applications, deux bases de code.
L'application multiplateforme est écrite une fois et produit les applications iPhone et Android. Flutter, le framework open source de Google, est aujourd'hui l'une des solutions les plus utilisées pour cela. L'application s'installe depuis les stores comme une application native.
L'application web s'ouvre dans le navigateur, sur ordinateur comme sur téléphone. Elle peut s'ajouter à l'écran d'accueil, mais ne passe pas par les stores.
Flutter en deux phrases
On écrit l'application en Dart, et Flutter la compile en code natif pour iOS et Android ; il sait aussi produire des versions web et bureau.
Sa particularité : il ne s'appuie pas sur les composants graphiques du système, il dessine lui-même chaque pixel de l'interface avec son propre moteur de rendu. C'est ce qui garantit un affichage identique d'une plateforme à l'autre.
Quand choisir le natif
Le natif reste le meilleur choix quand l'application exploite intensément le téléphone : Bluetooth et objets connectés, traitement d'image ou de son en temps réel, réalité augmentée, widgets et intégrations profondes au système. Il donne aussi accès aux nouveautés d'Apple et de Google dès leur sortie.
Contrepartie : deux bases de code à développer et à maintenir. Le coût est plus élevé, et chaque évolution doit être faite deux fois.
Quand choisir Flutter
Pour la grande majorité des applications de gestion, de réseau, de réservation, de contenu ou de service client, le multiplateforme est le choix rationnel :
- une seule base de code : une fonctionnalité est développée, testée et corrigée une fois ;
- le rechargement à chaud (hot reload) : une modification de l'interface apparaît en une seconde sur le téléphone de test, sans relancer l'application — les allers-retours de mise au point deviennent rapides ;
- des performances suffisantes pour ces usages : le code est compilé, pas interprété ;
- un écosystème riche de paquets sur pub.dev pour les besoins courants : notifications, appareil photo, géolocalisation, stockage local, authentification.
Les limites de Flutter
L'accès aux fonctions récentes ou pointues du système passe par des paquets tiers, ou par du code natif en Swift et Kotlin relié à Flutter par des platform channels. C'est faisable, mais le bénéfice de la base de code unique diminue à chaque module natif ajouté.
La taille de l'application est un peu plus importante qu'une application native équivalente, puisque le moteur de rendu est embarqué.
L'apparence « native » n'est pas automatique : Flutter reproduit les styles Material (Android) et Cupertino (iOS), mais une interface qui doit épouser parfaitement les conventions de chaque système demande un travail spécifique.
Quand une application web suffit
Si l'outil sert surtout au bureau, s'il est utilisé occasionnellement, ou s'il s'adresse à un public qui n'installera pas une application de plus, une application web est souvent la meilleure réponse. Pas de publication sur les stores, pas de validation à attendre, une mise à jour visible immédiatement par tous.
Ses limites : des notifications moins fiables selon les téléphones, un accès plus restreint au matériel, et une présence absente des stores, où certains utilisateurs cherchent d'abord.
Les pièges qu'on découvre en production
Les dépendances qui vieillissent. Une application qui s'appuie sur une dizaine de paquets tiers dépend de leur maintenance. À chaque nouvelle version de Flutter, d'iOS ou d'Android, il faut vérifier qu'ils suivent. Choisir des paquets activement maintenus, et en limiter le nombre, est une décision d'architecture.
Les exigences des stores évoluent chaque année : version minimale du SDK Android ciblé, déclarations de confidentialité, suppression du compte depuis l'application. Natif ou Flutter, prévoir une mise à jour annuelle au minimum.
Les anciennes versions installées. Vos utilisateurs ne mettent pas tous à jour. Si l'API évolue, une version ancienne peut cesser de fonctionner. Nous prévoyons systématiquement un mécanisme de mise à jour forcée : au démarrage, l'application interroge le serveur, qui lui indique la version minimale acceptée.
// Au démarrage : la version minimale vient du serveur
final reponse = await api.get('/maj');
if (versionInstallee < reponse.versionMinimale) {
afficherEcranMiseAJourObligatoire();
}Ce point d'entrée doit rester accessible sans authentification : c'est justement lui qui permet de débloquer une version trop ancienne pour savoir se connecter.
Les questions à se poser
Qui va utiliser l'outil, où, et à quelle fréquence ? A-t-il besoin de fonctionner sans réseau ? Doit-il envoyer des notifications ? Utilise-t-il le matériel du téléphone au-delà de l'ordinaire ? Quel budget de maintenance est envisageable sur plusieurs années ?
Notre règle : Flutter quand l'application est avant tout une interface de consultation et de saisie reliée à un serveur — la grande majorité des projets professionnels ; le natif quand elle exploite intensément le matériel ou les intégrations du système ; le web quand l'installation est un frein. Dans tous les cas, l'essentiel du travail se trouve souvent ailleurs : dans l'API, le back-office et la sécurité du serveur qui alimentent l'application.
Publié le 20/11/2025.