Vous avez probablement déjà utilisé une progressive web app sans le savoir. Quand une boutique en ligne vous propose « Ajouter à l'écran d'accueil », que l'icône apparaît sur votre téléphone à côté de vos autres applications, et qu'à l'ouverture il n'y a plus ni barre d'adresse ni onglet : c'est une PWA. Techniquement, vous êtes toujours sur un site web. Dans les faits, vous utilisez une application.
Ce guide donne la définition exacte d'une progressive web app, explique ce qui la distingue d'un simple site responsive, détaille ce qu'elle sait faire et ce qu'elle ne sait pas faire — notamment sur iPhone — et vous aide à décider si c'est le bon format pour votre projet.
Définition : qu'est-ce qu'une progressive web app ?
Une progressive web app (PWA) est une application web, construite avec les technologies standard du web (HTML, CSS, JavaScript), qui utilise des capacités modernes du navigateur pour offrir une expérience équivalente à celle d'une application mobile : installation sur l'écran d'accueil, lancement en plein écran, chargement rapide, fonctionnement partiel hors connexion et notifications push.
Le terme a été introduit par Google en 2015. L'adjectif « progressive » vient de l'amélioration progressive : la même URL fonctionne partout, et chaque navigateur en tire le maximum de ce qu'il sait faire. Sur un vieux navigateur, l'utilisateur voit un site web classique. Sur un navigateur récent, il obtient une application installable. Il n'y a jamais deux versions à maintenir.
Ce qui distingue une PWA d'un site mobile classique
Un site responsive s'adapte à la taille de l'écran, et c'est tout. Une progressive web app ajoute trois choses qu'un site classique n'a pas : elle est installable (elle a sa propre icône et son propre lancement), elle est fiable (elle affiche quelque chose d'utile même avec une connexion instable ou nulle), et elle est capable de fonctionner en arrière-plan (notifications, synchronisation).
- Site responsive : s'ouvre dans le navigateur, dépend du réseau, pas d'icône, pas de notification.
- Progressive web app : s'installe, se lance en plein écran, garde ses données en cache, peut notifier.
- Application native : se télécharge depuis un store, accède à tout le matériel du téléphone, développée spécifiquement pour iOS et Android.
Comment fonctionne une progressive web app
Trois briques transforment un site web en progressive web app. Elles sont indépendantes de votre framework : on peut « pwa-ifier » un site existant sans le reconstruire.
1. Le manifeste (web app manifest)
C'est un petit fichier JSON qui décrit votre application au système d'exploitation : son nom, son nom court affiché sous l'icône, ses icônes aux différentes tailles, sa couleur de thème, sa page de démarrage et son mode d'affichage. C'est lui qui permet au navigateur de proposer l'installation et qui fait disparaître la barre d'adresse au lancement.
2. Le service worker
C'est le cœur technique d'une PWA : un script qui s'exécute en arrière-plan, séparément de la page, et qui joue le rôle d'intermédiaire entre l'application et le réseau. Il intercepte les requêtes et décide de servir une version en cache ou d'aller chercher les données à jour. C'est ce qui permet un affichage quasi instantané au deuxième lancement, un écran utile en cas de perte de réseau, et la réception de notifications push quand l'application est fermée.
3. Le HTTPS
Un service worker ne fonctionne que sur une connexion sécurisée. Le HTTPS n'est donc pas une option pour une progressive web app : c'est un prérequis, au même titre que pour le référencement.
Checklist : les critères d'une vraie PWA
Beaucoup de sites se présentent comme des progressive web apps sans en remplir les conditions. Voici ce qu'il faut vérifier avant d'utiliser le terme.
- Le site est servi intégralement en HTTPS.
- Un manifeste valide est présent, avec au minimum un nom, une icône 512×512 et une page de démarrage.
- Un service worker est enregistré et gère au moins un scénario hors connexion.
- L'interface est utilisable sur mobile sans zoom ni défilement horizontal.
- Les performances mobiles sont maîtrisées (Core Web Vitals : LCP, INP, CLS).
- Chaque écran important reste accessible via une URL propre, indexable par Google.
Les avantages concrets d'une progressive web app
- Une seule base de code. Le même produit sert de site web, d'application Android et d'application iPhone, au lieu de trois projets à financer et à maintenir.
- Aucune friction d'installation. L'utilisateur arrive par un lien et utilise l'application immédiatement. Pas de détour par un store, pas de téléchargement de plusieurs dizaines de mégaoctets.
- Des mises à jour instantanées. Vous déployez, tout le monde a la nouvelle version au rechargement suivant. Pas de validation à attendre, pas de parc d'utilisateurs bloqué sur une vieille version.
- Le référencement conservé. Contrairement à une application native, invisible pour Google, une progressive web app reste un site indexable qui peut capter du trafic de recherche.
- Pas de commission de store. Les paiements passent par votre propre solution web, sans prélèvement sur les achats intégrés.
Les limites qu'il faut connaître avant de choisir
Une progressive web app n'est pas une application native déguisée. Trois limites structurent la décision.
- L'App Store reste fermé aux PWA. Apple n'accepte pas une progressive web app soumise telle quelle : une app jugée sans fonctionnalité propre au-delà d'un site web est refusée. Sur Android, en revanche, il est possible de publier une PWA sur le Play Store via une Trusted Web Activity. Si votre acquisition dépend de la visibilité sur l'App Store, la PWA seule ne suffira pas.
- iOS reste en retrait. Les notifications push web existent sur iPhone depuis iOS 16.4, mais uniquement si l'utilisateur a réellement ajouté l'application à son écran d'accueil — une étape supplémentaire, moins bien mise en avant par Safari que par Chrome sur Android. Plusieurs API avancées restent également indisponibles.
- L'accès au matériel est partiel. Caméra, micro et géolocalisation fonctionnent bien. Bluetooth, NFC, biométrie avancée, traitement vidéo lourd ou intégration profonde au système relèvent encore du natif.
PWA, application native ou WebView : le comparatif
| Critère | Progressive web app | WebView | Application native |
|---|---|---|---|
| Installation | Depuis le navigateur | Via les stores | Via les stores |
| Présence App Store | Non | Oui, sous conditions | Oui |
| Référencement Google | Oui | Partiel | Non |
| Accès au matériel | Partiel | Partiel | Complet |
| Mises à jour | Instantanées | Review store | Review store |
| Coût et délai initial | Faible | Moyen | Élevé |
| Bases de code à maintenir | Une | Deux | Deux à trois |
Quand la progressive web app est le bon choix
La PWA est rarement un compromis subi : pour toute une catégorie de produits, c'est objectivement le meilleur format.
- Un MVP ou un produit à valider vite, où le coût d'un double développement natif n'est pas justifiable.
- Un outil interne, un portail client ou un back-office métier, où personne ne cherchera l'application sur un store.
- Un e-commerce ou un service de réservation, où chaque étape supplémentaire avant l'achat fait chuter la conversion.
- Un média ou un service de contenu, dont l'acquisition repose sur le référencement naturel.
À l'inverse, orientez-vous vers le natif si votre produit dépend d'un usage matériel avancé, d'une expérience très animée, ou si la présence sur l'App Store est votre canal d'acquisition principal.
Comment créer une progressive web app
La démarche tient en cinq étapes, dans cet ordre.
- 1. Construire une base web solide. Interface mobile-first, navigation claire, performances soignées : une PWA lente reste une application lente.
- 2. Ajouter le manifeste. Nom, icônes, couleurs, mode d'affichage et page de démarrage.
- 3. Mettre en place le service worker. Définir ce qui est mis en cache et ce qui doit venir du réseau, puis prévoir l'écran hors connexion.
- 4. Servir le tout en HTTPS. Avec un nom de domaine propre, indispensable à la confiance comme au référencement.
- 5. Tester sur de vrais appareils. Vérifier l'installation sur Android et sur iPhone, le comportement hors connexion et les Core Web Vitals.
Progressive web app et SEO
C'est le principal atout stratégique de ce format : votre application reste un site. Chaque page conserve une URL indexable, des balises title et meta description propres, et peut être enrichie de données structurées. La rapidité apportée par le cache profite directement aux Core Web Vitals, qui font partie des signaux d'expérience de page. Une application native, elle, n'apporte aucune visibilité dans les résultats de recherche.
Un point de vigilance : si le contenu est intégralement rendu côté client, assurez-vous qu'il reste accessible aux robots. Un rendu côté serveur ou une génération statique évite de sacrifier le référencement à l'expérience applicative.
Où Cadrant intervient
Avec Cadrant, vous décrivez votre application en langage naturel et vous obtenez une base web réelle et mobile-first, avec le code qui vous appartient. Vous itérez prompt après prompt, vous publiez sur votre propre nom de domaine en HTTPS, et vous gardez un produit indexable par Google.
Et si votre projet finit par exiger une présence sur l'App Store, vous n'êtes pas enfermé : Cadrant génère aussi des applications mobiles avec une publication automatisée (certificat, profil de signature, build de production et envoi sur App Store Connect). Vous pouvez donc commencer par une progressive web app pour valider votre marché, puis ajouter le canal store quand il devient rentable.
Conclusion
Retenez la définition simple : une progressive web app est un site web qui s'installe et se comporte comme une application. Elle vous donne une base de code unique, un référencement préservé, des mises à jour immédiates et un coût d'entrée bien plus faible que le natif — au prix d'un accès matériel partiel et d'une absence sur l'App Store.
Pour la majorité des projets qui démarrent, c'est le format le plus rationnel : il permet de mettre le produit entre les mains d'utilisateurs réels sans immobiliser des mois de budget, et de garder ouverte l'option d'une application native le jour où elle se justifie vraiment.