Développer une application disponible sur iPhone et Android pose rapidement une question technique : faut-il créer deux applications natives ou utiliser une technologie multiplateforme comme Flutter ?
Les deux approches permettent de construire des applications performantes et publiables sur l'App Store et Google Play.
La différence se situe principalement dans **la manière dont elles sont développées et maintenues**.
Le choix dépend donc du projet, des fonctionnalités nécessaires et de la durée de vie prévue de l'application.
## Qu'est-ce qu'une application mobile native ?
Une application native est développée spécifiquement pour un système d'exploitation.
Pour iOS, le développement repose principalement sur **Swift** et les outils proposés par Apple.
Pour Android, **Kotlin** est aujourd'hui l'un des principaux langages utilisés.
Si une entreprise souhaite proposer son application sur les deux plateformes, elle dispose donc généralement de deux projets :
* une application iOS ;* une application Android.
Les deux applications proposent les mêmes fonctionnalités, mais leur code est en grande partie distinct.
## Qu'est-ce que Flutter ?
Flutter est un framework développé autour du langage Dart.
Il permet de créer des applications pour plusieurs plateformes à partir d'un même projet.
Une équipe peut donc développer une grande partie de l'application une seule fois puis générer les versions destinées à iOS et Android.
Cela ne signifie pas que tout est automatiquement identique entre les deux plateformes.
Certaines fonctionnalités nécessitent toujours des adaptations spécifiques.
Mais une grande partie de la logique métier et des interfaces peut être partagée.
## Un seul code pour iOS et Android
C'est le principal intérêt de Flutter.
Prenons une application permettant à des techniciens de consulter leurs interventions.
Elle comporte :
* une authentification ;* un planning ;* une fiche client ;* une carte ;* un formulaire ;* des photos ;* une signature ;* une synchronisation avec un serveur.
Avec deux développements natifs, ces fonctionnalités doivent être développées et maintenues pour iOS et Android.
Avec Flutter, une grande partie de cette logique est commune aux deux applications.
Cela peut réduire considérablement le travail nécessaire au développement et surtout aux évolutions futures.
## Flutter permet-il de créer de vraies applications mobiles ?
Oui.
Une application Flutter peut être distribuée sur **l'App Store d'Apple et Google Play** comme une application native classique.
Pour l'utilisateur, il n'est pas nécessaire de savoir avec quelle technologie l'application a été développée.
Elle possède une icône, peut utiliser les notifications et peut accéder aux fonctionnalités du téléphone selon les permissions accordées.
## Peut-on utiliser la caméra, le GPS ou le Bluetooth avec Flutter ?
Oui.
Flutter permet d'accéder à de nombreuses fonctionnalités du téléphone :
* caméra ;* GPS ;* notifications ;* stockage local ;* fichiers ;* microphone ;* biométrie ;* Bluetooth ;* NFC.
L'accès à ces fonctions repose généralement sur des bibliothèques ou sur du code spécifique à iOS et Android lorsque cela est nécessaire.
Pour la majorité des applications métier ou e-commerce, les fonctionnalités courantes des smartphones peuvent donc être exploitées avec Flutter.
## Les performances de Flutter sont-elles suffisantes ?
Pour la plupart des applications professionnelles, oui.
CRM mobile, e-commerce, outil terrain, réservation, suivi de commandes ou application de gestion peuvent fonctionner avec d'excellentes performances.
Les différences avec le natif deviennent surtout importantes lorsque l'application possède des besoins très spécifiques liés au matériel ou réalise des traitements particulièrement exigeants.
Dans ce type de projet, un développement natif peut rester préférable.
La technologie doit donc être choisie en fonction du besoin réel et non uniquement de la popularité d'un framework.
## Flutter permet-il de réduire le coût de développement ?
Souvent, mais pas automatiquement.
Partager une grande partie du code évite de développer deux fois certaines fonctionnalités.
Cela peut réduire le temps nécessaire pour créer puis maintenir l'application.
Mais une application Flutter destinée à deux plateformes doit toujours être :
* testée sur iOS ;* testée sur Android ;* adaptée aux différentes tailles d'écran ;* publiée sur les deux stores ;* maintenue lors des évolutions des systèmes.
Flutter ne divise donc pas simplement le coût par deux.
Son principal avantage économique apparaît surtout **sur la durée de vie du projet**.
## La maintenance est un point essentiel
Une application mobile n'est jamais réellement terminée.
Apple et Google font évoluer régulièrement leurs systèmes.
Les bibliothèques utilisées par l'application évoluent également.
Il faut donc publier périodiquement de nouvelles versions.
Avec deux applications natives, une nouvelle fonctionnalité doit généralement être intégrée dans les deux projets.
Avec Flutter, une modification de la logique commune peut être réalisée une seule fois avant d'être testée sur les deux plateformes.
Pour une application destinée à évoluer pendant plusieurs années, cet avantage peut devenir important.
## Flutter et les applications e-commerce
Flutter peut parfaitement être utilisé pour créer une application e-commerce.
L'application peut communiquer avec une boutique existante grâce à une API.
Le site web et l'application mobile utilisent alors le même catalogue.
L'application peut notamment récupérer :
* les produits ;* les catégories ;* les prix ;* les promotions ;* les stocks ;* le compte client ;* les commandes.
Une commande passée depuis l'application peut ensuite être transmise au système e-commerce ou à l'ERP.
Il n'est donc pas nécessaire de maintenir deux catalogues séparés.
## Flutter et les applications métier
C'est un autre domaine dans lequel Flutter est particulièrement intéressant.
Une entreprise peut disposer d'un logiciel métier accessible depuis un navigateur au bureau et d'une application mobile utilisée sur le terrain.
Par exemple :
**Au bureau :**
planning → clients → facturation → supervision.
**Sur mobile :**
interventions → GPS → photos → formulaires → signature.
Les deux applications communiquent avec la même base de données via une API.
Cette architecture permet de proposer une interface adaptée à chaque contexte sans dupliquer les informations.
## Une application Flutter peut-elle fonctionner hors connexion ?
Oui.
C'est particulièrement important pour les applications terrain.
Une connexion mobile n'est jamais garantie.
Un technicien peut intervenir dans un sous-sol, un bâtiment industriel ou une zone rurale sans couverture réseau suffisante.
L'application peut donc stocker certaines informations directement sur le téléphone.
Lorsque le réseau revient, les modifications sont synchronisées avec le serveur.
Par exemple :
1. le technicien ouvre une intervention ;2. il prend trois photos ;3. il complète le formulaire ;4. le client signe ;5. l'application enregistre les informations localement ;6. la connexion revient ;7. les données sont automatiquement envoyées au serveur.
Le développement doit cependant prévoir la gestion des conflits et des erreurs de synchronisation.
Le mode hors ligne doit donc être pensé dès la conception de l'application.
## Flutter peut-il communiquer avec Laravel ?
Oui.
C'est une architecture que nous utilisons notamment pour certaines applications métier.
Laravel peut gérer la partie serveur :
* utilisateurs ;* droits ;* données ;* règles métier ;* automatisations ;* connexion aux autres logiciels.
Flutter gère l'application installée sur le smartphone.
Les deux communiquent via une **API**.
Cette séparation permet également de connecter d'autres interfaces au même système.
Une application web, une application mobile et un site e-commerce peuvent ainsi utiliser les mêmes services.
## Quand préférer le développement natif ?
Flutter n'est pas systématiquement le meilleur choix.
Le natif peut être préférable lorsque l'application dépend fortement de fonctionnalités très spécifiques au système ou au matériel.
Cela peut concerner certains projets nécessitant :
* des traitements graphiques très avancés ;* une intégration particulièrement profonde avec iOS ou Android ;* des fonctions matérielles spécifiques ;* des contraintes de performances inhabituelles.
Il peut également être pertinent lorsqu'une entreprise possède déjà deux équipes spécialisées, l'une sur iOS et l'autre sur Android.
## Quand choisir Flutter ?
Flutter devient particulièrement intéressant lorsqu'une entreprise souhaite proposer la même application sur iOS et Android.
C'est notamment le cas pour :
* une application e-commerce ;* une application de fidélité ;* un CRM mobile ;* une application de réservation ;* un outil pour commerciaux ;* une application pour techniciens ;* une application de suivi des interventions.
Le partage du code permet alors de maintenir plus facilement les fonctionnalités communes.
## Flutter ou natif : il n'existe pas de réponse universelle
La question ne devrait pas être : « Quelle est la meilleure technologie ? »
Il faut plutôt se demander :
**Quelle technologie est la plus adaptée à cette application ?**
Une application utilisée par des techniciens pour prendre des photos et remplir des rapports n'a pas les mêmes contraintes qu'un jeu vidéo ou qu'une application utilisant intensivement les capteurs du téléphone.
Le choix technique doit donc être réalisé après avoir défini les usages.
## Commencer par les utilisateurs, pas par Flutter
Avant de décider d'utiliser Flutter, Swift ou Kotlin, il faut comprendre qui utilisera l'application.
Dans quelles conditions ?
Avec quelle connexion ?
Sur quels appareils ?
Quelles informations doivent être accessibles immédiatement ?
L'application doit-elle fonctionner hors ligne ?
Doit-elle communiquer avec un ERP ou un site e-commerce ?
Ces questions ont souvent beaucoup plus d'impact sur le projet que le choix initial du framework.
Chez Prestacode, nous utilisons notamment Flutter pour développer des applications mobiles connectées à des sites e-commerce et à des logiciels métier.
L'objectif reste le même : **choisir la technologie qui permet de construire une application fiable et maintenable, plutôt que d'imposer une technologie au projet**.