Progressive Web Apps : le meilleur des sites web et des applications mobiles

Progressive Web Apps, commonly known as PWAs, are web applications that use modern browser capabilities to deliver an experience indistinguishable from a native mobile app. They load in a browser like any website, but they can be installed on a home screen, work offline, send push notifications, and access device hardware — features that were once exclusive to apps downloaded from the App Store or Google Play. The term was coined by Google engineers in 2015, but the technology has matured dramatically since then, and 2026 marks a tipping point where PWAs are no longer experimental but mainstream.

At their core, PWAs are built with the same technologies that power every website: HTML, CSS, and JavaScript. What sets them apart is a layer of modern APIs, service workers, web app manifests, and the Cache API, that bridge the gap between web and native. This means any team capable of building a web application can build a PWA without learning Swift, Kotlin, or platform-specific toolchains. The result is a single codebase that runs everywhere, from desktop browsers to Android phones to iPads.

For businesses evaluating their digital strategy, PWAs represent a compelling middle ground. They eliminate the friction of app store downloads while retaining the engagement advantages of native apps. Companies like Starbucks, Pinterest, and Uber have reported significant gains in conversion rates and user engagement after launching PWAs, and the trend is accelerating as browser support continues to expand.

The engine behind every PWA is the service worker, a JavaScript file that runs in a separate thread from the main page. Think of it as a programmable network proxy that sits between your application and the internet. When a user visits your PWA, the service worker intercepts every network request and decides how to handle it, serve a cached response for instant loading, fetch fresh data from the server, or fall back to an offline page when the network is unavailable. This mechanism is what enables PWAs to load in under two seconds even on flaky 3G connections.

The web app manifest is a JSON file that tells the browser how to present the application when installed. It defines the app name, icons at various resolutions, theme colors, display mode (fullscreen, standalone, or minimal UI), and the start URL. When a user taps the install prompt and adds the PWA to their home screen, the manifest ensures it launches with a splash screen and no browser chrome, creating an experience that feels indistinguishable from a native app.

Together, these two technologies form the foundation of the PWA architecture. The service worker handles the runtime behavior, caching, offline support, background sync, push notifications, while the manifest handles the installable experience. Both are declarative and standards-based, meaning they work across Chrome, Edge, Firefox, and Safari without vendor lock-in. For teams already building modern web applications, adopting these APIs is a matter of days, not months.

Traditional websites are universally accessible but lack the engagement features that keep users coming back: push notifications, offline access, and home screen presence. Native apps excel at engagement but impose enormous friction, users must discover the app in a store, download it, grant permissions, and wait for installation before they see a single screen. Research from Google shows that every step in this funnel loses roughly 20% of users, meaning a native app loses over 60% of potential users before they even open it.

PWAs sit in the sweet spot between these two extremes. They are instantly accessible via a URL, indexable by search engines, and shareable through a simple link, all advantages of the web. But they also offer push notifications, offline caching, background data sync, and home screen installation — all advantages of native apps. The trade-off is that PWAs cannot access every device API (NFC and Bluetooth support varies by browser), and iOS has historically lagged behind Android in PWA support, though Apple has closed much of this gap in 2025 and 2026.

From a cost perspective, the difference is stark. Building separate iOS and Android apps requires two codebases, two development teams, and ongoing app store maintenance. A mobile application built as a PWA uses a single codebase with one team, eliminates app store fees, and deploys updates instantly without waiting for store review. For most businesses, the 5% of native features a PWA cannot replicate are far less valuable than the 50% reduction in development and maintenance costs.

Starbucks launched its PWA to reach customers in emerging markets with unreliable connectivity. The result was a 2x increase in daily active users, and the PWA itself was 99.84% smaller than the native iOS app, just 233KB versus over 100MB. This size difference matters enormously in markets where data costs are high and storage is limited. Users who would never download a 100MB app happily use a PWA that loads in seconds.

Pinterest rebuilt its mobile web experience as a PWA and saw core engagement metrics skyrocket. Time spent on the platform increased by 40%, ad revenue climbed 44%, and user-generated pin creation jumped 401%. The key was reducing load times from 23 seconds on mobile web to under 5 seconds with the PWA, combined with push notifications that brought users back daily. Twitter Lite, Alibaba, and Trivago have reported similar gains, with conversion rate improvements ranging from 50% to 104%.

Closer to our own experience at GRADAX, we have helped clients in e-commerce and SaaS deploy PWAs that eliminated their dependency on app stores entirely. One client saw mobile conversions increase by 38% after switching from a mobile-responsive website to a PWA, driven primarily by the offline catalog feature that let customers browse products without connectivity and sync their cart when back online.

A PWA is the right choice when your primary goal is reach. If you need the widest possible audience with the lowest friction, nothing beats a URL that works on every device and can be installed with a single tap. E-commerce businesses, content platforms, SaaS dashboards, internal tools, and service marketplaces are all excellent PWA candidates because their value proposition does not depend on deep hardware integration.

A PWA is not the right choice when your application requires heavy native capabilities that browsers do not yet support. Augmented reality apps, resource-intensive 3D games, and applications that need persistent Bluetooth connections are better served by native development or, at minimum, a hybrid approach that wraps native code around a web view. Similarly, if your business model depends on app store discoverability and in-app purchases, a native app gives you access to those revenue channels directly.

The decision often comes down to budget and timeline. If you have the resources to build and maintain separate iOS and Android apps alongside a website, a native approach gives you maximum capability. If you want to ship one product that works everywhere and iterate quickly, a PWA delivers 90% of the native experience at a fraction of the cost. For most of the businesses we work with at GRADAX, the PWA path is the pragmatic one.

Speed is the single most impactful metric for any digital product, and PWAs are engineered for it. Service worker caching means that after the first visit, subsequent loads pull assets from the local cache instead of the network. Our benchmarks consistently show sub-one-second load times for cached PWAs, compared to two to five seconds for traditional server-rendered pages. Google’s research shows that 53% of mobile users abandon sites that take longer than three seconds to load, which means PWAs retain users that traditional sites lose.

Beyond initial load time, PWAs enable app shell architecture, a pattern where the structural UI (header, sidebar, navigation) loads instantly from the cache while dynamic content is fetched in the background. This gives users an immediate sense of responsiveness. The skeleton appears first, then data populates smoothly, a technique used by virtually every major native app. With a PWA, you get the same perceived performance without writing a line of platform-specific code.

Push notifications add another performance dimension: re-engagement. Web push notifications have an average opt-in rate of 7-10% and a click-through rate of 12%, both higher than email marketing. For businesses that depend on repeat visits, news publishers, SaaS dashboards, e-commerce stores, this channel can meaningfully move retention metrics without the cost of maintaining a native app.

The tooling for building PWAs has matured dramatically. Frameworks like Next.js, Nuxt, and SvelteKit include service worker support through plugins or built-in APIs. Workbox, Google’s service worker library, automates the most complex caching strategies with a declarative configuration. And testing tools like Lighthouse audit PWA compliance across installability, performance, and accessibility in a single report, giving teams a clear checklist to follow.

At GRADAX, our typical PWA build starts with a Next.js foundation and adds a service worker through next-pwa or a custom Workbox configuration. We define the manifest, configure caching strategies for static assets and API responses, implement an offline fallback page, and integrate web push via a service like Firebase Cloud Messaging. The entire PWA layer adds roughly two to three days to a standard web application project, a trivial investment relative to the engagement gains.

The most common mistake teams make when building PWAs is treating the service worker as an afterthought. A poorly configured service worker can serve stale content, break form submissions, or cache API responses that should never be cached. We recommend defining your caching strategy before writing a single line of service worker code: which routes should be cache-first, which should be network-first, and which should bypass the cache entirely. Getting this right from the start prevents the frustrating bugs that give PWAs a bad reputation.

If your business depends on mobile engagement and you are not ready to invest in separate native apps, a PWA is almost certainly the right move. The technology is stable, browser support is comprehensive, and the cost-to-impact ratio is unmatched. You get offline support, push notifications, home screen installation, and sub-second load times while maintaining a single codebase that also serves desktop users through the browser.

The question is not whether PWAs are viable, that debate ended years ago, but whether your specific use case benefits from the web’s strengths (reach, shareability, instant access) more than it requires native capabilities (AR, NFC, advanced Bluetooth). For the vast majority of businesses, the answer is yes. Even companies with existing native apps are launching PWAs as their primary mobile web experience, using the native app for power users while the PWA captures the long tail of casual visitors.

If you are evaluating whether a PWA fits your product, we can help you map the decision. Our team has built PWAs for e-commerce, SaaS, and content platforms, and we understand the trade-offs at a technical level. Reach out for a consultation and we will walk you through the architecture, timeline, and expected impact for your specific situation.