On me pose la question à l'envers presque à chaque fois. « Tu ferais ça en React Native ou en PWA ? », comme s'il fallait choisir un camp une bonne fois, défendre une techno contre l'autre. Je fais les deux, et justement parce que je fais les deux, je n'ai aucune fidélité. La vraie question n'est jamais « laquelle est la meilleure ». C'est « qu'est-ce que ton app doit faire, pour qui, et combien tu peux y mettre ». À partir de là, le choix se fait presque tout seul. Il y a trois ou quatre critères qui tranchent, et ils tranchent vite.
Le matériel, c'est le critère qui décide en premier
Si ton app doit parler à du matériel, la discussion est souvent close avant d'avoir commencé. Lecteur de badge NFC, capteur Bluetooth, balance connectée, terminal de paiement, caméra que tu pilotes finement (mise au point, exposition, flux brut), capteurs de mouvement précis. Dès qu'on descend à ce niveau, le web montre ses limites, et sur iPhone, c'est un mur.
Concrètement : Web Bluetooth, Web NFC, WebUSB, Web Serial ne sont pas supportés sur iOS. Comme tous les navigateurs de l'iPhone tournent sur le moteur de Safari, ce n'est pas « Chrome iOS le fera » : aucun navigateur iOS n'y a accès, et Apple ne montre aucun signe de vouloir changer ça. Le code parle plus clair qu'un long paragraphe :
// Sur Android, dans Chrome : navigator.bluetooth existe, tu scannes ton capteur.
// Sur iPhone, dans n'importe quel navigateur : undefined. Porte fermée.
if ('bluetooth' in navigator) {
const device = await navigator.bluetooth.requestDevice({ /* filtres */ })
} else {
// pas de plan B en pur web sur iOS
}Sur Android, une PWA peut tout à fait dialoguer en BLE avec un appareil, et ça marche bien. Mais si ton app doit aussi tourner sur iPhone (et pour la plupart des clients, c'est non négociable), tu ne peux pas t'appuyer sur une API que la moitié de ton parc n'aura jamais. React Native, lui, passe par les briques natives via des modules éprouvés (BLE, NFC, caméra avancée), des deux côtés. Quand le matériel est au cœur du besoin, React Native ou le natif gagnent, et il n'y a même pas vraiment de débat.
Une nuance honnête : la caméra « simple » (prendre une photo, scanner un QR code) marche très bien en web, sur iOS comme ailleurs. C'est le matériel branché, les protocoles bas niveau et le contrôle fin des capteurs qui font basculer vers le natif.
L'offline sérieux, l'autre point qui ne pardonne pas
Il y a offline et offline. Une PWA gère parfaitement le « je consulte mes données dans le métro sans réseau » : un service worker, un cache, un peu d'IndexedDB, et l'app répond hors-ligne. Pour beaucoup d'apps métier, c'est suffisant.
Puis il y a l'autre offline. Celui où il n'y a jamais de réseau, où l'app est le seul logiciel qui tourne, où elle doit encaisser des heures d'usage sans jamais recontacter un serveur. J'ai construit Prolog là-dessus : une app React Native qui dialogue en WiFi direct avec une sonde de forage et fait tourner un modèle de machine learning embarqué, sur une tablette Android durcie, à côté d'une foreuse, sans la moindre connexion internet. Le modèle est dans l'app, l'inférence se fait sur l'appareil, les mesures sont écrites en local. Une PWA n'aurait pas tenu ce cahier des charges, ne serait-ce que parce que sur iOS, des mécanismes comme le background sync ne sont pas là, et que faire tourner un modèle ML embarqué qui cause à un capteur en liaison directe, ce n'est pas un terrain pour le navigateur.
Donc si ton app vit sur le terrain, sur un appareil dédié, qu'elle doit être fiable sans réseau et garder la main sur le système, penche React Native sans hésiter. Si ton « offline » se résume à du cache de confort pour un utilisateur de bureau ou un commercial en déplacement, la PWA fait le travail.
La distribution et le coût, là où la PWA reprend la main
On a parlé des cas où le web cale. Le reste du temps, c'est lui qui mène, et largement.
Une PWA, c'est une URL. Tu déploies, c'est en ligne, tout le monde y accède depuis son navigateur, et ta mise à jour est instantanée pour tous au rechargement suivant. Pas de soumission à l'App Store, pas de revue qui te bloque trois jours pour une virgule dans la description, pas de build à signer par plateforme, pas de compte développeur payant à renouveler chaque année, pas de version 1.2.4 que la moitié de tes utilisateurs n'installera jamais. Une seule base de code web qui touche le mobile, la tablette et le poste fixe. Pour démarrer, et surtout pour maintenir dans la durée, c'est nettement moins cher et moins lourd.
React Native demande plus d'investissement, et il faut le dire franchement. Tu as deux stores à gérer, des builds à produire et à signer, parfois du code natif à écrire quand un module ne couvre pas ton besoin, et le cycle de validation des stores entre toi et tes utilisateurs. Ça se gère très bien (l'outillage autour d'Expo a beaucoup adouci tout ça), mais ça reste un coût réel, en temps et en argent, qu'une PWA n'a pas. Si la portée, le budget de départ et la simplicité de mise à jour sont tes priorités, et que rien dans la liste plus haut ne t'oblige à passer natif, commence par une PWA. Tu pourras toujours faire une app native plus tard, quand un vrai besoin la justifiera.
L'expérience perçue, plus souvent un faux argument qu'un vrai
C'est l'argument qu'on me sort pour justifier le natif « par défaut » : ce sera plus fluide, plus beau, plus « vrai ». Parfois c'est juste. Sur des gestes complexes, des animations qui collent au système, une intégration profonde (partage natif, widgets, interactions fines), React Native est devant, et ça se sent.
Mais regarde honnêtement ce que fait ton app métier. Des formulaires, des listes, des tableaux de bord, de la consultation, de la saisie, des filtres. Pour 80 % de ces écrans, une PWA soignée est indiscernable d'une app native pour l'utilisateur. Personne, dans la vraie vie, ne sort son téléphone pour deviner si l'app de saisie de son chantier est « native ou pas ». Il veut qu'elle s'ouvre vite, qu'elle ne plante pas, qu'elle réponde. Le réflexe « natif parce que c'est plus pro » coûte cher pour un gain que l'utilisateur final ne perçoit pas. Je le déconseille tant qu'aucun critère technique réel ne le commande.
iOS, le caillou dans la chaussure des PWA
Soyons précis, parce que c'est là que se nichent les déceptions. Le point faible des PWA, ce n'est pas « le web », c'est iOS. Sur Android, l'expérience PWA est solide : installation proposée au bon moment, accès à pas mal de matériel, notifications. Sur iPhone, c'est plus rugueux.
Les notifications push existent enfin sur iOS depuis Safari 16.4, mais à une condition : l'utilisateur doit avoir ajouté la PWA à son écran d'accueil. Tant que ton site vit dans un onglet Safari, pas de push, point. Et cet ajout à l'écran d'accueil, justement, reste un geste manuel : pas de bannière d'installation automatique comme sur Android, c'est à l'utilisateur d'aller le chercher dans le menu de partage. Autant dire qu'il faut le lui expliquer, et qu'une bonne partie ne le fera jamais. Ajoute à ça l'absence des API matérielles déjà citées et de certains mécanismes d'arrière-plan, et tu obtiens le vrai visage de la décision : une PWA, c'est excellent partout, et un peu bridé sur iPhone. Si ton public est massivement sur iOS et que tu as besoin de notifications fiables ou d'une présence forte sur l'écran d'accueil, ce frein doit peser dans ta balance.
Comment je tranche, en pratique
Mon réflexe, concrètement : je pars sur une PWA quand la portée, le coût et la simplicité commandent, et que rien n'exige du matériel ni de l'offline dur. Je bascule sur React Native dès qu'il faut parler à un capteur, tenir sans réseau sur un appareil dédié, ou offrir une expérience vraiment native que l'usage justifie. Et il m'arrive de faire les deux sur le même projet : une PWA pour le grand public, qui touche tout le monde sans friction, et une app native pour les opérateurs terrain, qui ont besoin du matériel et du hors-ligne. Ce n'est pas un compromis bancal, c'est souvent la bonne réponse, chaque outil sur le terrain où il est imbattable.
Le piège, c'est de choisir la techno avant d'avoir regardé le besoin. Commence par lister ce que ton app doit faire, vraiment, et la réponse sera déjà à moitié écrite.
Tu hésites sur ton propre projet ? Parlons-en, je te dirai honnêtement vers quoi je partirais.