Application native ou hybride : comment choisir

Le choix entre une application native ou hybride se fait sur trois questions : de quoi votre application a besoin sur le téléphone, combien de versions vous êtes prêt à entretenir, et quelle fluidité vos utilisateurs attendent. Pour la plupart des projets d’entreprise, une application multiplateforme compilée (Flutter, par exemple) donne le rendu d’une application native avec un seul code. Le natif pur reste justifié dans quelques cas précis, que nous détaillons plus bas.

Native, hybride, multiplateforme : de quoi parle-t-on ?

Les mots sont souvent mélangés, et c’est la première source de confusion. Il existe en réalité trois grandes familles.

L’application native

Une application native est écrite dans le langage prévu par le fabricant du système : Swift pour l’iPhone, avec les outils d’Apple, et Kotlin pour Android, avec ceux de Google. Elle utilise directement les composants du système. Pour être présent sur les deux plateformes, il faut donc écrire deux applications distinctes, qui font la même chose avec deux codes différents.

L’application hybride au sens strict

L’application hybride « classique » est un site web emballé dans une application. Elle est écrite en HTML, CSS et JavaScript, puis affichée dans une vue web intégrée à l’application (une sorte de navigateur sans barre d’adresse). Des outils comme Capacitor ou Cordova fournissent des passerelles vers l’appareil photo, la géolocalisation ou les notifications.

L’application multiplateforme compilée

Entre les deux, une troisième famille s’est imposée : les frameworks multiplateformes qui produisent une vraie application pour chaque système à partir d’un seul code. Flutter (créé par Google) et React Native (créé par Meta) en sont les deux principaux. Dans le cas de Flutter, le code est compilé en code machine natif pour le processeur du téléphone, et le framework dessine lui-même l’interface, sans passer par une vue web. La documentation officielle de Flutter le décrit ainsi : le code Dart est compilé à l’avance en code machine natif.

Quand on vous propose une application « hybride », demandez toujours s’il s’agit d’un site dans une vue web ou d’une application compilée. Les deux n’ont pas grand-chose en commun à l’usage.

Quelles différences pour l’utilisateur ?

Celui qui télécharge votre application ne sait pas comment elle a été construite. Il voit seulement si elle démarre vite, si le défilement est fluide et si les gestes répondent comme dans les autres applications de son téléphone.

• Une application native offre la meilleure intégration possible : chaque nouveauté d’iOS ou d’Android est disponible dès sa sortie, et l’interface suit à la lettre les conventions du système.
• Une application multiplateforme compilée est, dans la grande majorité des usages, impossible à distinguer d’une application native : listes, formulaires, animations, cartes, paiements.
• Une application hybride web se trahit plus souvent : défilement un peu moins naturel, temps de chargement de certains écrans, comportements qui rappellent un site. Pour une application simple et peu utilisée, c’est acceptable. Pour une application qu’on ouvre tous les jours, la différence finit par se sentir.

Combien de codes faut-il écrire et entretenir ?

C’est la question qui pèse le plus sur la durée, et elle est souvent sous-estimée au moment de lancer le projet.

Une application native disponible sur iPhone et Android, c’est deux applications. Chaque nouvelle fonction est écrite deux fois, testée deux fois, et les deux versions finissent parfois par diverger : un bouton n’est pas au même endroit, un bug est corrigé d’un côté et pas de l’autre.

Avec une approche multiplateforme ou hybride, il n’y a qu’un seul code. Une correction ou une nouveauté part sur les deux stores en même temps. Pour une PME, c’est aussi un seul prestataire ou un seul développeur à mobiliser, et une seule base de code à faire reprendre si vous changez d’équipe un jour.

Il faut garder en tête qu’une application n’est jamais terminée. Apple et Google publient chaque année une nouvelle version de leur système, les stores font évoluer leurs règles, et vos utilisateurs demandent des améliorations. Le coût d’une application se joue donc autant sur ses années d’entretien que sur sa première version.

Tableau comparatif : native, hybride web ou multiplateforme compilée

Critère	Native (Swift et Kotlin)	Hybride web (vue web)	Multiplateforme compilée (Flutter)
Nombre de codes	Deux	Un	Un
Fluidité	Excellente	Variable selon les écrans	Très bonne
Accès au téléphone	Complet, immédiat	Par extensions	Très large, natif si besoin
Nouveautés d’iOS et d’Android	Dès leur sortie	Avec un délai	Avec un léger délai
Rendu identique sur les deux systèmes	Non, deux interfaces	Oui	Oui
Effort d’entretien	Le plus élevé	Faible	Faible

Ce tableau résume des tendances générales. Une application native mal conçue sera moins agréable qu’une bonne application multiplateforme, et inversement : la qualité du travail compte plus que la technologie.

Quand le natif reste le bon choix

Le natif pur garde sa place dans des situations précises. Mieux vaut les connaître avant de lancer un projet :

1. Une application très liée au système : un clavier personnalisé, une application de montre connectée au cœur du produit, une intégration poussée avec des fonctions qu’Apple ou Google viennent de sortir.
2. Des besoins de calcul extrêmes : jeux 3D exigeants, traitement vidéo en temps réel, réalité augmentée avancée.
3. Une seule plateforme visée : si votre clientèle est entièrement sur iPhone (ou sur Android) et le restera, l’argument du code unique perd de sa force.
4. Une équipe interne déjà native : si vos développeurs maîtrisent Swift et Kotlin et entretiennent déjà des applications natives, rester sur leurs outils est souvent raisonnable.

Même dans le premier cas, une application Flutter peut intégrer quelques morceaux de code natif, écrits en Swift ou en Kotlin, là où c’est nécessaire. Un widget sur l’écran d’accueil de l’iPhone se fait ainsi, sans réécrire toute l’application.

Quand l’hybride web suffit

À l’inverse, une application hybride au sens strict peut convenir quand :

• vous avez déjà un site web bien fait et vous voulez surtout une présence sur les stores ;
• l’application affiche essentiellement du contenu (actualités, catalogue, informations pratiques) ;
• le budget et le délai sont très serrés, et l’usage restera occasionnel.

Une autre piste mérite d’être citée : la progressive web app, un site qui s’installe sur l’écran d’accueil sans passer par les stores. Elle évite la validation d’Apple et de Google, mais elle reste plus limitée sur iPhone, et elle n’apparaît pas quand on cherche une application dans l’App Store.

Comment choisir entre application native ou hybride pour votre projet ?

Plutôt que de partir de la technologie, partez de votre projet. Voici les questions que nous posons au premier échange :

• Qui sont vos utilisateurs, et sur quels téléphones ? En France, iPhone et Android sont tous deux largement répandus : viser un seul système, c’est généralement laisser une partie de votre public de côté.
• Quelles fonctions du téléphone sont indispensables ? Appareil photo, géolocalisation, notifications, paiement, Bluetooth : la plupart sont très bien prises en charge par Flutter. Une liste précise permet de lever les doutes dès le départ.
• À quelle fréquence l’application sera-t-elle ouverte ? Plus l’usage est quotidien, plus la fluidité compte.
• Qui l’entretiendra dans trois ans ? Un code unique, écrit avec une technologie répandue et documentée, est plus facile à confier à une autre équipe.

Prenons deux exemples. Un cabinet de kinésithérapie veut une application de prise de rendez-vous et de rappels d’exercices pour ses patients. Les patients ont des iPhone et des Android, l’application doit être fluide et envoyer des notifications : une application multiplateforme compilée répond à tout, avec un seul code à faire évoluer. Une start-up qui développe un accessoire connecté avec un fonctionnement en tâche de fond très particulier sur iPhone, en revanche, aura intérêt à écrire au moins cette partie en natif.

Pourquoi nous avons choisi Flutter

Chez Devolim, nous développons nos applications avec Flutter. Nos dix applications publiées sur l’App Store et Google Play sont construites ainsi, et elles servent aujourd’hui plus de 10 000 utilisateurs. Ce choix vient de l’expérience : une seule base de code, un rendu identique sur les deux systèmes, une fluidité qui ne se distingue pas du natif, et la possibilité d’ajouter du code natif pour les rares fonctions qui l’exigent.

Nous détaillons les avantages et les limites de cette technologie dans Pourquoi nous développons nos applications avec Flutter. Et si votre projet demande vraiment du natif, nous vous le disons dès le départ.

Questions fréquentes

Une application hybride est-elle moins bien référencée sur les stores ?

Non. L’App Store et Google Play ne tiennent pas compte de la technologie utilisée pour classer une application. Ce qui compte, ce sont la fiche (titre, description, captures), les notes, les avis et l’usage. Une application lente ou instable aura en revanche de moins bonnes notes, ce qui finit par peser.

Peut-on passer d’une application hybride à une application native plus tard ?

Oui, mais il s’agit en pratique d’une réécriture. Le code d’une application hybride web ne se transforme pas en code natif. C’est pourquoi le choix de départ mérite réflexion, surtout si l’application doit durer plusieurs années.

Flutter est-il considéré comme natif ou hybride ?

Flutter est classé parmi les frameworks multiplateformes. Son code est compilé en code machine natif et il n’utilise pas de vue web, ce qui le distingue des applications hybrides au sens strict. À l’usage, une application Flutter se comporte comme une application native.

Une application multiplateforme peut-elle utiliser l’appareil photo, le GPS et les notifications ?

Oui. Ces fonctions sont couvertes par des extensions maintenues, et pour un besoin très particulier, il reste possible d’écrire un morceau de code natif appelé depuis l’application.

Si vous hésitez encore entre une application native ou hybride, le plus simple est de partir de ce que votre application doit faire. Notre page applications mobiles présente notre façon de travailler, et vous pouvez nous décrire votre idée sur la page Parler de votre projet.