« On fait du React Native ou du natif ? » Cette question, je l'entends à chaque début de projet. Et à chaque fois, la même scène : trois personnes autour d'une table, deux camps qui se dessinent, et un devis qui varie du simple au triple selon la réponse.
La vérité que personne ne dit dans les réunions de cadrage, c'est que la comparaison entre applications natives et hybrides a changé de nature. La ligne de démarcation de 2018 n'existe plus. Aujourd'hui, un projet Flutter bien mené surpasse un natif mal optimisé, et un hybride WebView bâclé coule une startup en trois mois.
J'ai livré les deux. J'ai aussi vu les deux échouer. Voici ce que j'en ai tiré.
Points clés à retenir
- « Natif » et « hybride » ne suffisent plus à décrire la réalité : il faut distinguer les frameworks WebView (Ionic, Capacitor) des frameworks compilés (React Native, Flutter, .NET MAUI).
- Sur un projet type e-commerce, l'écart de coût initial entre natif double plateforme et Flutter se situe souvent autour de 40 à 60 %.
- La performance brute ne décide presque jamais du succès d'une app : l'ergonomie et la fiabilité pèsent bien plus lourd dans les avis stores.
- L'accès matériel (Bluetooth basse consommation, AR, caméra temps réel) reste le point où le natif garde un avantage difficile à contourner.
- La maintenance à long terme est le poste de coût que tout le monde sous-estime au démarrage.
Pourquoi la frontière entre natif et hybride s'est brouillée
Pendant longtemps, le débat était binaire. D'un côté l'app native, écrite en Swift ou Kotlin, qui parle directement au système. De l'autre l'hybride, une page web enfermée dans une coquille, avec un pont JavaScript pour accéder à la caméra et au GPS quand ça veut bien fonctionner.
Ce monde-là est mort. Ce qui l'a tué, c'est l'arrivée de frameworks qui compilent du code vers du natif réel, sans passer par une WebView.
Trois familles, pas deux
Le premier tri à faire dans votre tête, c'est celui-ci :
- Natif pur — Swift/SwiftUI sur iOS, Kotlin/Jetpack Compose sur Android. Deux bases de code, deux équipes, deux calendriers.
- Hybride WebView — Ionic, Capacitor, Cordova. Votre app est une page web embarquée. Pratique pour du contenu, douloureux dès qu'on demande de la fluidité.
- Compilé cross-platform — React Native, Flutter, .NET MAUI. Un seul code, mais rendu natif. C'est la catégorie qui a redessiné la carte.
J'ai longtemps classé Flutter dans « hybride » par réflexe. Erreur. Un widget Flutter ne s'affiche pas dans une WebView : il est peint par le moteur graphique de l'app, exactement comme une vue native. La différence est invisible pour l'utilisateur dans 90 % des cas.
Ce que la WebView change vraiment
Sur un projet de réservation pour un réseau de salles de sport, j'ai récupéré une base Ionic existante. Le listing des cours mettait 1,4 seconde à s'afficher sur un Android d'entrée de gamme. Après réécriture de la liste en virtualisation correcte et suppression de deux bibliothèques inutiles, on est descendu à 380 ms. Le problème n'était pas l'hybride en soi, c'était le code.
Voilà le piège : on accuse la technologie d'un problème d'ingénierie. Inversement, j'ai vu un natif iOS ramer au scroll parce que les images n'étaient pas redimensionnées. La plateforme n'excuse rien.
Comparer applications natives et hybrides : les critères qui comptent
Oubliez les grilles à dix lignes qu'on trouve partout. En pratique, quatre critères décident à eux seuls de 80 % des arbitrages.
La performance, mesurée et pas fantasmée
Sur les animations complexes, les transitions 60 fps et le rendu de listes longues, le natif pur reste devant. Mais l'écart avec Flutter ou React Native bien écrit se compte souvent en millisecondes, pas en secondes. Sur les jeux 3D, la réalité augmentée ou le traitement vidéo en temps réel, en revanche, la marche est haute et le natif s'impose presque toujours.
L'accès au matériel
C'est ici que le débat se joue vraiment. Un module Bluetooth basse consommation, un scanner de codes-barres industriel, un accès au capteur de profondeur Face ID : en natif, c'est une API documentée. En cross-platform, c'est soit un plugin maintenu par la communauté (parfois abandonné), soit du code natif à écrire vous-même — et vous retombez alors sur deux bases à maintenir.
Sur une app de contrôle d'accès par badge NFC, j'ai perdu deux semaines à contourner un plugin React Native qui ne gérait pas un cas particulier de carte. En natif, la même fonctionnalité aurait pris trois jours. Ce genre d'écart ne se voit pas dans un tableau comparatif.
Le coût et le délai
Un chiffre vaut mieux qu'un discours. Sur une app de e-commerce avec catalogue, panier, paiement et notifications :
| Approche | Jours-homme estimés | Coût indicatif | Mise en production |
|---|---|---|---|
| Natif iOS + Android | 180 à 220 | Élevé | 5 à 7 mois |
| Flutter ou React Native | 110 à 140 | Moyen | 3 à 4 mois |
| Ionic / Capacitor | 70 à 100 | Faible | 2 à 3 mois |
Les fourchettes sont larges parce que la qualité du code varie énormément d'une équipe à l'autre. Mais l'ordre de grandeur tient : vous divisez grosso modo par deux le coût initial en passant du natif pur au cross-platform compilé.
La maintenance, le vrai poste caché
Chaque année, Apple et Google sortent une nouvelle version majeure de leur OS. En natif, il faut adapter deux bases. En Flutter ou React Native, une seule — le framework absorbe une partie des ruptures. En WebView, une seule aussi, mais vous dépendez du moteur de rendu du système, qui évolue sans vous.
J'ai chiffré, sur trois ans, la maintenance d'une app native double plateforme face à son équivalent Flutter : environ 1,8 fois plus cher côté natif, à périmètre fonctionnel identique. C'est ce chiffre, pas le devis initial, qui devrait guider la décision.
Vers quelle approche vous orienter, concrètement
Voici comment je tranche, projet après projet :
- Besoin d'AR, de 3D temps réel, de Bluetooth bas niveau ou de capteurs exotiques ? Natif. Sans hésiter.
- MVP à valider en trois mois avec un budget serré, contenu majoritairement textuel et formulaire ? Flutter ou React Native.
- Vous avez déjà une app web solide et voulez juste la mettre dans un store ? Capacitor, à condition d'accepter une expérience perfectible.
- App bancaire, santé ou tout ce qui touche à des données sensibles avec des contraintes de conformité lourdes ? Le natif rassure les équipes sécurité, mais le cross-platform n'est pas disqualifié — il faut juste le documenter proprement.
Un dernier point qu'on oublie souvent : la publication sur les stores. Apple refuse régulièrement les apps hybrides qui ressemblent trop à un site web déguisé, critère 4.2 de ses guidelines. J'ai vu une app Capacitor se faire recaler deux fois pour cette raison avant d'ajouter de vraies fonctionnalités natives. Ajoutez toujours une couche qui justifie l'installation.
Ce que je recommande vraiment
Si vous me demandez mon avis tranché : par défaut, partez sur Flutter ou React Native. Le gain de coût et de vitesse est réel, la performance est largement suffisante pour 90 % des apps du marché, et la maintenance à long terme est plus simple.
Gardez le natif pur pour ce qu'il fait mieux que tout le monde : le matériel pointu, la 3D, et les cas où l'expérience utilisateur doit être irréprochable au pixel près. Ce n'est pas un dogme, c'est une question de contraintes.
Et méfiez-vous de la fausse bonne idée inverse : choisir l'hybride parce que « c'est moins cher », puis découvrir six mois plus tard qu'il faut réécrire en natif. J'ai vu cette erreur coûter près de 80 000 € à une équipe qui aurait dû prendre la bonne décision dès le départ.
La technologie ne fait pas l'application. L'équipe, le cadrage et la rigueur, oui. Le reste, c'est de la littérature de salon.
