TL;DR — choix par scénario
- Créez une web app si votre produit est un SaaS B2B, un outil interne ou un service à fort contenu où les utilisateurs arrivent via la recherche ou des liens partagés. Aucune barrière à l’installation, tous les appareils, itération la plus facile.
- Créez une PWA si vous avez besoin d’une web app plus une présence sur l’écran d’accueil, des notifications push et un accès hors ligne — sans maintenir deux bases de code natives. La meilleure option pour l’e-commerce, les médias, les tableaux de bord B2C et les places de marché.
- Créez une app native (iOS + Android) si votre app dépend d’ARKit/ARCore, de paiements NFC, HealthKit, de la localisation en arrière-plan, du machine learning embarqué ou d’intégrations OS étroites comme CarPlay et Android Auto. Également le choix par défaut pour les produits grand public où l’usage quotidien actif est le KPI central dès le premier jour.
- Pour la plupart des produits B2C dans la tranche budgétaire de 50 000–200 000 €, une PWA bien exécutée vous donne 80 % de l’expérience native à 40–60 % du coût. Ne sur-construisez pas sans raison concrète.
Web app, native, PWA : ce que chacune signifie vraiment en 2026
Ces termes sont souvent utilisés à mauvais escient. Voici une définition précise de chacun, car le choix entre eux dépend de la compréhension de ce qu’ils sont réellement.
Web app
Une application web s’exécute dans un onglet de navigateur. Il peut s’agir d’un simple site multi-pages, d’une SPA React ou d’une app Next.js rendue côté serveur — la caractéristique définissante est que l’utilisateur navigue vers une URL et que le navigateur héberge l’expérience. Pas d’installation. Pas d’App Store. Tout système d’exploitation et tout appareil disposant d’un navigateur moderne peut l’utiliser. C’est le choix par défaut pour les SaaS B2B, les outils internes et tout produit où l’acquisition provient de la recherche organique ou de liens directs.
Application native
Une application native est compilée pour une plateforme spécifique — Swift/SwiftUI pour iOS, Kotlin/Jetpack Compose pour Android — ou développée avec un framework multiplateforme comme React Native ou Flutter ciblant les deux. Elle est distribuée via l’App Store ou Google Play, installée sur l’appareil et dispose d’un accès complet aux API matérielles, aux services OS et à l’exécution en arrière-plan. Le prix de cette puissance est double : deux bases de code (ou une base multiplateforme avec des modules spécifiques à la plateforme), la latence de validation App Store et une étape d’installation obligatoire qui exclut 20–50 % des utilisateurs occasionnels avant qu’ils voient votre produit. Consultez notre comparaison de React Native vs Flutter en 2026 pour en savoir plus sur le choix du framework multiplateforme.
Progressive Web App (PWA)
Une PWA est une web app qui ajoute trois éléments : un service worker (active la mise en cache et le mode hors ligne), un Web App Manifest (active l’installation et l’icône sur l’écran d’accueil) et HTTPS (requis pour les deux). Cette combinaison déverrouille l’installabilité, les notifications push et l’accès hors ligne — des capacités qui étaient exclusives aux apps natives jusqu’il y a peu. L’utilisateur peut ajouter une PWA à son écran d’accueil directement depuis Safari ou Chrome, et elle s’ouvre dans une fenêtre autonome sans chrome de navigateur, ressemblant et se comportant comme une app native. Vous la déployez toujours comme une URL ; le navigateur s’occupe du reste.
Ce que les PWA peuvent et ne peuvent pas faire sur iOS & Android aujourd’hui
L’idée reçue la plus fréquente que nous entendons de la part des clients américains et européens en 2026 est toujours « les PWA ne fonctionnent pas sur iPhone ». C’était en grande partie vrai avant 2023. Ce n’est plus vrai aujourd’hui. Voici l’état actuel, plateforme par plateforme.
iOS (Safari 17+, 2026)
- Web Push : Pris en charge depuis iOS 16.4 (mars 2023). Les utilisateurs qui ajoutent une PWA à leur écran d’accueil peuvent recevoir des notifications push via le standard Web Push. Safari sur iOS (PWA non installées) requiert toujours une invite d’autorisation, comme pour les apps natives.
- Installation : « Ajouter à l’écran d’accueil » fonctionne ; la PWA installée s’ouvre dans une fenêtre autonome avec une icône personnalisée. iOS 17+ prend en charge l’API BeforeInstallPrompt pour les invites d’installation internes à l’app, bien que l’implémentation de Safari présente des particularités par rapport à Chrome.
- Hors ligne : Les service workers fonctionnent pleinement. La mise en cache, la synchronisation en arrière-plan et IndexedDB sont tous disponibles.
- Lacunes sur iOS : Pas de NFC, pas d’ARKit/RealityKit, pas d’APIs HealthKit ou Motion & Fitness, pas d’audio en arrière-plan en mode écran verrouillé, pas de couplage Bluetooth LE. Ces fonctionnalités restent exclusives aux apps natives sur iOS en 2026.
Android (Chrome, 2026)
Android dispose depuis des années de la prise en charge PWA la plus complète, et elle ne fait que s’améliorer. Web Push, installation, hors ligne, Bluetooth LE, NFC (expérimental sous flag dans Chrome), synchronisation en arrière-plan et accès au système de fichiers sont tous disponibles. L’écart entre une PWA bien construite et une app React Native est réellement faible sur Android pour la plupart des cas d’usage. L’élément manquant principal reste les intégrations OS profondes : Android Auto, Wear OS, emplacements de widgets et canaux de notifications avec catégories granulaires.
Coût & délai de mise sur le marché comparés
Ces chiffres sont basés sur nos propres données de livraison pour des clients américains et européens sur la période 2024–2026 et nos benchmarks de coût de développement d’applications mobiles 2026. Configuration d’équipe : 1 PM, 1 designer, 2–3 ingénieurs, 1 QA. Périmètre : 8–12 écrans, auth, push, paiements, analytics.
| Dimension | Web App | PWA | Natif (iOS + Android) |
|---|---|---|---|
| Coût de développement (fourchette typique) | 30 000–80 000 € | 40 000–100 000 € | 80 000–250 000 € |
| Délai avant le premier build utilisable | 4–6 semaines | 5–8 semaines | 8–14 semaines |
| Bases de code à maintenir | 1 | 1 | 1–2 (multiplateforme ou natif) |
| Délais de validation App Store | Aucun | Aucun | 24–72 h par release |
| Déploiement de correctif urgent | Immédiat | Immédiat (mise à jour service worker) | OTA pour JS (RN) ; validation pour Flutter/natif |
| Découverte organique App Store | Aucune | Limitée (Google Play Trusted Web Activity) | SEO complet App Store & Play Store |
| Friction d’installation | Zéro (URL) | Faible (invite du navigateur) | Élevée (téléchargement App Store) |
L’écart de coût entre une web app et une PWA est faible — souvent seulement la configuration du service worker et du manifest, ce qui ajoute une à deux semaines de travail d’ingénierie à un projet existant. L’écart entre une PWA et le natif est là où la vraie décision se joue. Consultez aussi notre page sur notre service de développement d’applications web pour voir comment nous cadrons ces projets.
Offline, push & fonctionnalités de l’appareil
La capacité hors ligne et les notifications push sont les deux raisons les plus souvent citées pour choisir le natif plutôt qu’une web app. En 2026, les deux sont réalisables avec une PWA pour la plupart des cas d’usage. Voici la situation réaliste.
Accès hors ligne
Un service worker peut pré-mettre en cache toutes les ressources et même les réponses API, rendant une PWA pleinement fonctionnelle sans connexion. Cela fonctionne également bien sur iOS et Android. Le défi de conception consiste à décider ce qu’il faut mettre en cache et comment gérer les conflits d’écriture — un utilisateur soumettant un formulaire de commande hors ligne a besoin d’une synchronisation en arrière-plan pour mettre l’écriture en file et la transmettre au retour de la connectivité. Des librairies comme Workbox (de Google) facilitent considérablement la création de service workers pour les apps React et Vue. Si votre app est un lecteur de contenu statique, un catalogue de produits ou un tableau de bord avec des données en lecture seule, « hors ligne » est une fonctionnalité d’un sprint dans une PWA.
Notifications push
Web Push (RFC 8030) est désormais pris en charge par Chrome (Android), Safari (iOS 16.4+, macOS Ventura+) et Firefox. L’UX des autorisations est presque identique au push natif — les utilisateurs voient une invite au niveau système et peuvent gérer les autorisations dans les paramètres OS. Les taux de livraison dans nos campagnes e-commerce EU 2025 ont atteint en moyenne 78–85 % de ce que le push natif équivalent a réalisé, ce qui reste dans une plage acceptable pour la plupart des produits. La principale lacune : le push ne fonctionne pas si la PWA est ouverte dans un onglet de navigateur sans être installée sur l’écran d’accueil iOS.
Fonctionnalités de l’appareil : le tableau honnête
| Fonctionnalité | PWA (iOS) | PWA (Android) | Natif |
|---|---|---|---|
| Caméra & microphone | Oui | Oui | Oui |
| Géolocalisation | Premier plan seulement | Premier plan seulement | Arrière-plan + premier plan |
| Notifications push | Oui (PWA installée) | Oui | Oui |
| NFC | Non | Expérimental | Oui |
| ARKit / ARCore | Non | Non | Oui |
| Bluetooth LE | Non | Oui (Web Bluetooth) | Oui |
| Authentification biométrique | WebAuthn / Face ID | WebAuthn / empreinte digitale | Biométrie complète de la plateforme |
| Achats internes à l’app | Non (politique Apple) | Payment Request API | Facturation complète App Store / Play |
Distribution, App Stores & découverte
La distribution est là où le natif dispose toujours d’un avantage structurel qu’une PWA ne peut pas entièrement reproduire.
Découverte sur l’App Store
L’App Store et Google Play entraînent ensemble une part significative des nouvelles installations d’applications, notamment pour les apps grand public aux États-Unis. La recherche sur l’App Store représente 65–70 % de la découverte d’applications aux États-Unis selon plusieurs études 2025. Une PWA n’apparaît pas dans ces résultats de recherche à moins de l’encapsuler dans une Trusted Web Activity (TWA) et de la soumettre à Google Play — ce que certaines équipes font avec succès. Apple n’autorise pas les soumissions de PWA à l’App Store.
Pour les produits B2B et entreprise, cela importe beaucoup moins. Les utilisateurs trouvent les outils B2B via la recherche Google, les conversations commerciales et les boucles de croissance basées sur le produit — pas l’App Store. Une web app ou PWA est ici réellement avantageuse car zéro installation raccourcit le temps de la sensibilisation à la première valeur.
Le volet réglementaire européen
Le Règlement européen sur les marchés numériques (DMA) a imposé à Apple d’autoriser des distributions alternatives d’applications dans l’UE depuis mars 2024. En pratique, le chargement latéral via des pages web et des marchés alternatifs est maintenant légalement autorisé pour les utilisateurs EU sur iOS. Cela modifie le calcul de la découverte pour les produits centrés sur l’UE — un référencement App Store n’est plus nécessaire pour atteindre les utilisateurs iPhone avec une expérience installée. La mise en oeuvre pratique est encore en cours de maturation, mais elle vaut la peine d’être prise en compte dans la stratégie produit à long terme.
Si votre produit cible les marchés grand public américains et européens avec une forte présence organique App Store comme levier de croissance, le natif est le bon choix. Si vous construisez un SaaS B2B, un outil interne ou un produit où la recherche et les liens directs pilotent l’acquisition, une PWA couvre vos besoins. Lisez notre comparaison de iOS vs Android : quelle plateforme lancer en premier pour le contexte de la répartition US-vs-EU des plateformes.
Matrice de décision
Utilisez ce tableau pour évaluer votre situation. Pour chaque ligne, indiquez quelle colonne s’applique. La colonne avec le plus de marques est probablement votre réponse — mais pondérez les lignes selon leur importance pour votre produit spécifique.
| Facteur de décision | Web App | PWA | Natif |
|---|---|---|---|
| Canal d’acquisition principal | Recherche, liens, commercial | Recherche + re-engagement | Recherche organique App Store |
| Budget | 30 000–80 000 € | 40 000–100 000 € | 80 000 €+ |
| Type d’audience | B2B, interne, entreprise | B2C, e-commerce, médias | Grand public, apps à forte rétention |
| Notifications push nécessaires | Non | Oui (standard) | Oui (contrôle maximal) |
| Usage hors ligne requis | Non | Oui (la plupart des scénarios) | Oui (synchronisation complexe) |
| API matérielles (NFC, AR, BLE, GPS arrière-plan) | Non | Partiel (Android) | Complet |
| Priorité time-to-market | Le plus rapide | Rapide | Plus lent |
| Monétisation via achats internes | Non (utiliser Stripe) | Paiements web uniquement | Facturation complète de la plateforme |
| Agilité de déploiement (vitesse des correctifs) | Immédiat | Immédiat | 24–72 h de validation |
Un schéma que nous observons régulièrement chez les startups américaines et européennes : elles construisent en natif trop tôt. Une PWA lancée au mois 3 pour 60 000 € qui valide l’adéquation produit-marché est bien plus précieuse qu’une app native à 180 000 € lancée au mois 9 que personne n’utilise. Le natif se justifie une fois que les données de rétention prouvent que l’usage quotidien actif et la découverte App Store valent l’investissement — pas comme hypothèse de départ.
FAQ
Une PWA est-elle moins chère qu’une application native ?
Oui, dans la plupart des cas. Une PWA repose sur des technologies web partagées, ce qui permet de maintenir une seule base de code plutôt que des builds iOS et Android séparés. Le coût de développement est généralement 40–60 % inférieur à celui de deux apps natives. Si vous avez besoin d’une intégration matérielle profonde ou d’une forte présence App Store, l’investissement natif se justifie.
Une PWA peut-elle fonctionner hors ligne ?
Oui. Un service worker peut mettre en cache les ressources, les réponses API et les pages entières pour que l’app fonctionne sans connexion. Les apps à forte lecture (contenu, tableaux de bord, catalogues) peuvent être entièrement disponibles hors ligne. Les apps à forte écriture ont besoin d’une synchronisation en arrière-plan pour mettre les écritures en file et les transmettre au retour de la connectivité.
Les PWA fonctionnent-elles sur iOS en 2026 ?
Mieux que jamais. Apple a introduit la prise en charge de Web Push dans Safari dès iOS 16.4 et continue de l’améliorer. Les PWA installées sur iOS reçoivent les notifications push, apparaissent sur l’écran d’accueil et s’exécutent dans une fenêtre autonome. Des lacunes subsistent — NFC, ARKit et HealthKit sont exclusifs au natif — mais iOS n’est plus un obstacle pour la plupart des cas d’usage PWA.
Quand devrait-on créer une PWA plutôt qu’une application native ?
Créez une PWA lorsque votre audience est large et orientée acquisition, lorsque le budget est contraint ou lorsque les cas d’usage principaux fonctionnent sans accès matériel profond. Les PWA excellent pour l’e-commerce, les médias, les tableaux de bord B2B et les outils SaaS. Restez en natif lorsque vous avez besoin d’ARKit/ARCore, de localisation en arrière-plan, de paiements NFC ou d’intégrations OS étroites comme CarPlay.
Une web app est-elle suffisante à la place d’une app mobile ?
Pour la plupart des SaaS B2B et des outils internes, une web app responsive est le bon premier choix — elle atteint chaque appareil, ne nécessite aucune installation et est la plus facile à faire évoluer. La question se pose lorsque la rétention devient importante : les notifications push, la présence sur l’écran d’accueil et l’accès hors ligne améliorent considérablement l’usage quotidien actif. Si ce KPI est critique dès le premier jour, investissez au minimum dans une PWA.
Puis-je transformer ma web app en PWA ultérieurement ?
Oui, et c’est souvent la bonne progression. Ajouter un service worker, un Web App Manifest et HTTPS à une web app existante peut prendre une à deux semaines pour un ingénieur senior. Si votre app est déjà construite sur React, Vue ou Angular, Workbox facilite considérablement la création du service worker. La principale prérequis est HTTPS sur chaque page.
Dernière mise à jour le 1er juin 2026. Les données sur les capacités PWA reflètent Chrome 124, Safari 17.4 et la base de référence W3C Web Platform. La prise en charge des plateformes évolue rapidement — vérifiez MDN pour l’état actuel par API.
