Natif, hybride ou PWA : comment trancher en 2026
« Il nous faut une application. » La phrase arrive presque toujours avant la question qui la rend décidable : par quel chemin vos utilisateurs vont-ils l'ouvrir la première fois ? Trois formes se disputent la réponse : le natif, le cross-platform et la PWA. Le débat se tranche mal en comparant des technologies. Nous avons livré les trois : AquaPro est une PWA, Daiky une application Flutter publiée sur l'App Store, MamaSafe Food une application React Native publiée sur Google Play. Voici comment nous arbitrons, et ce que les règles d'Apple et de Google imposent avant même le premier écran.
Trois familles, une seule question de départ
Le natif désigne deux applications distinctes, écrites chacune dans le langage de sa plateforme, distribuées par les boutiques. Le cross-platform, ce qu'on appelle couramment « hybride », produit lui aussi des applications de boutique, mais depuis une base de code unique : c'est le terrain de Flutter et de React Native. La PWA est un site web que le navigateur sait installer sur l'écran d'accueil, servir hors connexion et faire ressembler à une application, sans passer par aucune boutique.
La différence décisive n'est pas la performance, ni le langage : c'est le canal de distribution. Les deux premières familles acceptent un intermédiaire qui examine le binaire, encaisse les paiements et impose son calendrier technique. La troisième s'en dispense, et perd du même coup ce que cet intermédiaire apporte : la vitrine, le bouton d'installation à un geste, la facturation intégrée et l'accès au matériel du téléphone.
Tout le reste en découle. Poser la question dans l'autre sens, « Flutter ou React Native ? », c'est avoir déjà tranché sans le dire.
Ce qu'AquaPro a prouvé : la PWA n'est pas un lot de consolation
AquaPro équipe des techniciens piscine en tournée. Le besoin : planning du jour, rapports photo, signature client sur l'écran, synchronisation avec le back-office, le tout hors connexion, parce qu'un local technique n'a pas de réseau. Nous avons livré une PWA en Vue.js / TypeScript, avec mode hors ligne et synchronisation automatique au retour du réseau, plus de 90 % de couverture de tests, un prototype fonctionnel en 24 heures et une mise en production anticipée par la chaîne d'intégration continue.
Rien dans ce cahier des charges n'appelait une boutique. Les utilisateurs sont connus : ce sont les salariés du client, à qui l'on transmet une adresse. Personne ne cherche « AquaPro » dans l'App Store. Aucun abonnement ne se souscrit dans l'outil. Dans cette configuration, la PWA supprime des postes entiers du projet : pas de compte développeur à ouvrir et à faire vérifier, pas de revue à subir avant chaque correctif, pas d'échéance de SDK à honorer pour rester publiable.
Ce dernier point n'est pas théorique. Google écrit que, « starting August 31, 2026 », les nouvelles applications et les mises à jour doivent cibler Android 16 (niveau d'API 36) ou supérieur pour être soumises au Play Store, avec une extension possible jusqu'au 1er novembre 2026 (niveau d'API cible requis, Android Developers). Une application de boutique porte donc une dette de maintenance annuelle, indépendante de ses fonctionnalités. Une PWA n'en porte aucune de ce type : sa cible, c'est le navigateur. Ces obligations pèsent aussi sur le planning initial, comme le détaille notre article sur les délais de développement d'une application mobile.
Où la PWA s'arrête, et pourquoi c'est plus net sur iOS
Le plafond n'est pas le même sur les deux systèmes, et l'ignorer est la faute la plus coûteuse de cet arbitrage.
Les notifications, d'abord. Sur iOS, elles existent, mais sous condition : la page doit avoir été ajoutée à l'écran d'accueil et déclarer le mode d'affichage standalone. Apple le formule sans détour dans sa session « What's new in web apps » : « If you want your site to be able to use Web Push and badging on iOS, then you should use the standalone display mode », et précise qu'un site ajouté à l'écran d'accueil sans ce mode « opens in the default browser » (What's new in web apps, WWDC23). Traduit en parcours réel : partager, faire défiler un menu, ajouter à l'écran d'accueil, puis seulement accepter les notifications. Face au bouton unique d'une boutique, le taux de perte est un sujet commercial, pas un détail technique.
Le moteur, ensuite. La règle 2.5.6 des App Store Review Guidelines pose que « apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript », un moteur alternatif n'étant possible que sur dérogation, et seulement pour l'Union européenne et le Japon (App Store Review Guidelines ; Alternative browser engines, Apple Developer). La conséquence est structurelle : sur un iPhone, ce que sait faire le web est ce que sait faire WebKit, quel que soit le navigateur installé. Une capacité absente de WebKit est absente de votre PWA pour tous vos utilisateurs iOS, et vous ne pouvez pas la contourner en recommandant un autre navigateur.
Android est plus accommodant, et va jusqu'à offrir une porte que iOS n'a pas : la Trusted Web Activity, « a new way to open your web-app content such as your Progressive Web App (PWA) from your Android app », la propriété du domaine étant vérifiée par Digital Asset Links (Trusted Web Activities, Android Developers). Une même base web peut donc vivre en site, en PWA installée et en application du Play Store. Le symétrique côté Apple n'existe pas : la règle 4.2 est explicite, « your app should include features, content, and UI that elevate it beyond a repackaged website ». Emballer un site pour le poser sur l'App Store n'est pas une stratégie de repli, c'est un motif de refus.
Daiky et MamaSafe Food : quand la boutique n'est pas négociable
Daiky analyse la composition d'un cosmétique : on scanne le code-barres du produit, ou on photographie l'étiquette quand il n'est pas référencé, et l'application rend un verdict lisible en une trentaine de secondes. MamaSafe Food fait le même geste sur une assiette, pour des femmes enceintes, avec un plan Premium à 4,99 € par mois. Deux produits grand public : leurs utilisateurs ne reçoivent pas une adresse par courriel, ils cherchent une application. La vitrine de la boutique est le canal d'acquisition, et l'abonnement se souscrit dans l'application.
Le débat PWA était clos avant de s'ouvrir, et la vraie question devenait celle du framework, celle que traite notre comparatif Flutter vs React Native. Daiky est en Flutter, avec Firebase pour l'authentification, la base de données, le stockage, les notifications et App Check, plus un module caméra et une bibliothèque de lecture de codes-barres. MamaSafe Food est en React Native avec Expo. Deux réponses différentes à deux contextes différents, prises une fois la forme arrêtée. Le détail de ce que Firebase couvre sur une application mobile et de ce qu'il faut lui ajouter est traité à part, parce que ce choix est indépendant de celui du framework.
AquaPro Manager montre le troisième cas de figure, le plus fréquent en B2B : une architecture double, application Flutter pour le terrain et web app Next.js pour le back-office, l'abonnement étant souscrit sur la plateforme. Là, ce n'est plus « l'un ou l'autre » mais « lequel pour quel usage », et le choix se fait poste de travail par poste de travail, pas en réunion de lancement.
Le natif pur : ce qui le justifie encore
Écrire deux applications séparées reste défendable dans trois situations, et il faut les nommer honnêtement plutôt que de vendre le cross-platform par défaut. La première : l'application vit sur une seule plateforme, et le second système n'est pas au programme, et payer une abstraction dont on n'utilisera jamais la moitié n'a pas de sens. La deuxième : le produit s'appuie sur des capacités système de pointe, disponibles le jour de leur annonce et pas six mois après, quand une couche intermédiaire les a rattrapées. La troisième : une équipe interne déjà constituée sur les deux plateformes, auquel cas le coût de reconversion dépasse le gain.
Hors de ces cas, le cross-platform gagne sur le poste qui pèse réellement dans un budget : le nombre de bases de code à maintenir. Notre article sur le coût d'une application mobile et le calculateur de budget détaillent ce raisonnement chiffré.
Cinq questions qui suffisent à trancher
Nous les posons dans cet ordre, en atelier de cadrage. La première réponse qui verrouille la décision arrête l'exercice.
| Question | Si oui | Si non |
|---|---|---|
| Vos utilisateurs doivent-ils vous trouver dans une boutique ? | Boutique obligatoire | Le web reste ouvert |
| Vendez-vous un abonnement ou du contenu dans l'application ? | Boutique, et règles de paiement à arbitrer tôt | Paiement web possible |
| Avez-vous besoin d'une fonction du téléphone que le navigateur n'expose pas ? | Cross-platform ou natif | PWA envisageable |
| Les notifications sont-elles au cœur de l'usage ? | Boutique, ou tunnel d'installation assumé sur iOS | PWA sans réserve |
| Une seule plateforme est-elle visée durablement ? | Natif défendable | Cross-platform |
Aucune de ces questions n'est technique. Elles portent sur le produit, son marché et son modèle économique, et c'est bien pour cela qu'elles se tranchent avec le dirigeant, avant la première maquette.
Changer d'avis coûte plus cher qu'on ne le croit
Le mouvement le plus tentant est aussi le plus mal évalué : partir en PWA « pour aller vite », puis l'emballer dans une application quand la boutique devient nécessaire. Sur Android, la Trusted Web Activity rend l'opération légitime, à condition que le contenu tienne les mêmes exigences qu'une installation depuis le navigateur. Sur iOS, la règle 4.2 attend au tournant, et un refus arrive au pire moment, après l'annonce du lancement.
Le chemin inverse est plus sûr. Une application de boutique s'accompagne presque toujours d'un web complémentaire (la vitrine, le back-office, le tunnel d'abonnement), et cette part-là se construit avec les mêmes exigences de performance que le reste du site : c'est le sujet de notre guide Core Web Vitals. À l'inverse, une PWA qui doit devenir une application de boutique redécouvre en fin de parcours tout ce que nous avons décrit dans l'article sur la publication sur l'App Store et Google Play : comptes développeur, déclarations de confidentialité, règles de paiement.
D'où notre règle : décider la forme au cadrage, l'écrire dans le devis, et ne la remettre en cause que sur un fait nouveau. C'est ce que couvrent notre service de développement d'application mobile et notre service d'application web, et ce que nous détaillons aux entreprises de la région sur la page agence application mobile à Antibes.
