PWA sur site indépendant : accès hors ligne, invite d’installation, notifications push et taux de conversion
1. Les trois fonctions d’une PWA : lesquelles servent vraiment, lesquelles sont un argument creux
Une PWA repose sur trois fonctions clés : le Service Worker pour la mise en cache hors ligne, le manifeste d’application web pour l’installation sur le bureau et l’API Web Push pour les notifications. Sur le papier, c’est séduisant, mais dans les faits, les gains sur un site B2B indépendant sont très inégaux.
La mise en cache hors ligne (Service Worker) est la plus utile des trois. Elle stocke le HTML, le CSS et le JS du site sur l’appareil de l’utilisateur : à la prochaine ouverture, même hors connexion ou en réseau faible, le site s’affiche instantanément. Pour les marchés au réseau instable comme le Moyen-Orient, l’Asie du Sud-Est ou l’Amérique latine, le LCP peut passer de 4 secondes à moins de 2 secondes. Pour savoir comment mesurer les performances, voir Optimiser les Core Web Vitals.
L’intérêt de l’invite d’installation sur le bureau (API beforeinstallprompt) varie selon le site. Sur un site e-commerce B2C, l’utilisateur acceptera peut-être d’installer le site comme une application ; sur un site industriel B2B, il vient une fois demander un prix puis repart, et le taux d’installation ne dépasse généralement pas 2 % à 5 %. Le support des PWA par iOS Safari est particulièrement limité : l’invite d’installation ne s’affiche jamais automatiquement, il faut guider l’utilisateur pour qu’il ajoute le site à son écran d’accueil manuellement.
Les notifications push sont la fonction la plus surestimée. Dès la première visite, une fenêtre demande « Autoriser les notifications ? » et plus de 80 % des utilisateurs refusent. Même une fois l’autorisation accordée, le taux d’ouverture des push reste généralement inférieur à 5 %. En B2B, le client préfère recevoir un e-mail plutôt qu’une notification navigateur : l’apport direct de cette fonction à la conversion des demandes de devis est donc proche de zéro.
| Fonction PWA | Mise en œuvre technique | Apport réel à la conversion B2B | Charge de développement | Priorité recommandée |
|---|---|---|---|---|
| Mise en cache hors ligne | Pré-cache par Service Worker | LCP amélioré de 30 % à 50 % en réseau faible | 2 à 3 jours | Élevée |
| Installation sur le bureau | Manifest + beforeinstallprompt | Taux d’installation de 2 % à 5 %, gain limité sur les visites récurrentes | 1 jour | Moyenne |
| Notifications push | Web Push + planification côté serveur | Taux d’autorisation<20%，打开率<5% | 3 à 5 jours | Faible |
| Synchronisation en arrière-plan | Background Sync API | Aucune perte de formulaire en réseau faible | 2 jours | Moyenne |
| Icône sur l’écran d’accueil | Icône du manifeste + écran de démarrage | Image de marque renforcée, aucun effet direct sur la conversion | Une demi-journée | Moyenne |
2. Quand cela vaut la peine, quand c’est une perte de temps
Pour décider, regardez trois indicateurs : la part du trafic mobile, la fréquence de retour et la qualité du réseau dans la région de vos utilisateurs. Si les trois sont au vert, une PWA vaut l’investissement.
Cas 1 : un site de vannes industrielles ciblant le Moyen-Orient, avec 65 % de trafic mobile, des utilisateurs surtout en Arabie saoudite et aux Émirats, une couverture 4G instable et un taux de retour mensuel de 25 %. Ici, le gain du cache hors ligne via Service Worker est évident : un utilisateur saoudien consulte les caractéristiques d’un produit depuis son téléphone à l’usine, et la page s’ouvre instantanément même en réseau faible. Ce type de site mérite 2 à 3 jours de travail sur le pré-cache Service Worker. Pour l’articulation avec le CDN, voir Accélération mondiale par CDN.
Cas 2 : un site B2B d’équipements ciblant l’Europe et les États-Unis, avec 70 % de trafic desktop, 1,2 visite en moyenne par utilisateur et seulement 8 % de taux de retour. Ici, une PWA n’apporte quasiment rien. L’utilisateur arrive, remplit un formulaire de demande et repart ; il n’installera jamais l’application sur son bureau. Le taux d’autorisation des notifications push est faible, tout comme le taux d’ouverture : c’est du développement gaspillé. Consacrez ces deux semaines à l’optimisation du formulaire et au contenu, le retour sera 10 fois supérieur. Pour analyser le taux d’abandon du formulaire, voir Taux d’abandon du formulaire de demande.
| Critères de décision | PWA non rentable | Cache hors ligne envisageable | PWA complète recommandée |
|---|---|---|---|
| Part du trafic mobile | Moins de 30 % | 30 % à 60 % | Plus de 60 % |
| Taux de retour mensuel | Moins de 15 % | 15 % à 25 % | Plus de 25 % |
| Réseau dans la région des utilisateurs | Réseau stable Europe/États-Unis/Japon-Corée | Régions mixtes | Réseau faible Moyen-Orient/Asie du Sud-Est/Amérique latine |
| Nombre moyen de visites par utilisateur | 1 à 1,5 | 2 à 3 | Plus de 3 |
| Ressources front-end de l’équipe | 0 à 1 personne | 1 à 2 personnes | Plus de 2 |
III. Comment mettre en place le cache hors ligne sans tout casser
La panne la plus fréquente d’un Service Worker : « il a mis en cache une ancienne version, l’utilisateur voit éternellement l’ancienne page ». Ce n’est pas un problème de PWA, c’est une stratégie de cache mal configurée. La bonne approche est un cache par couches : les ressources statiques (CSS/JS/images) en cache-first, les pages HTML en network-first — on tente toujours le réseau d’abord, et on retombe sur le cache en cas d’échec. Ainsi l’utilisateur voit toujours le contenu le plus récent, et le cache ne sert de filet qu’en cas de coupure.
Autre détail pratique : la mise à jour de version du Service Worker. Quand vous publiez du nouveau code front-end, l’ancien Service Worker contrôle encore le cache sur l’appareil de l’utilisateur. Il faut écrire la logique skipWaiting et clients.claim dans le Service Worker, ou afficher sur la page un message du type « le site a été mis à jour, cliquez pour actualiser ». Sans cela, un utilisateur peut rester une semaine sur l’ancienne version.
Exemple concret : un site de mobilier à l’international lance sa PWA et découvre que des utilisateurs se plaignent : « pourquoi le site ne se met-il plus à jour ? ». Après diagnostic, le Service Worker mettait aussi en cache-first le HTML de la page d’accueil ; le service marketing avait modifié la bannière, mais une semaine plus tard les utilisateurs voyaient encore l’ancienne image. Après passage du HTML en network-first et des ressources statiques en cache-first, le problème a disparu, tout en conservant l’ouverture instantanée des sous-pages en réseau faible.
| Type de ressource | Stratégie de cache | Moment de mise à jour | Erreur fréquente |
|---|---|---|---|
| Pages HTML | Network-first, repli sur le cache en cas d’échec | Tenter le réseau à chaque requête | Le cache-first empêche la mise à jour du contenu |
| CSS/JS (avec hash) | Cache d’abord, cache longue durée | Mise à jour automatique quand le hash du nom de fichier change | Sans hash, l’ancien cache ne se renouvelle pas |
| Images | Cache d’abord, rafraîchissement en arrière-plan | Récupération de la nouvelle version en arrière-plan | Images trop lourdes, le pré-cache sature le stockage |
| Données API | Réseau d’abord, cache en secours | Tenter le réseau à chaque requête | Prix mis en cache, devis périmé affiché |
| Fichiers de police | Cache d’abord, cache longue durée | Mise à jour à chaque changement de version | CORS mal configuré |
4. Invite d’installation et notifications push : est-ce que ça vaut le coup ?
Si votre site a déjà franchi l’étape du cache hors ligne et que vous voulez ajouter une invite d’installation, la méthode consiste à écouter l’événement beforeinstallprompt, à masquer l’invite par défaut du navigateur et à la remplacer par une bannière ou un bouton que vous avez conçu. L’utilisateur clique sur le bouton, puis vous appelez prompt(). Le taux d’installation est alors 2 à 3 fois plus élevé qu’avec l’invite native du navigateur, parce que l’utilisateur clique en sachant à quoi s’attendre.
Mais en B2B, à quoi bon faire passer le taux d’installation de 3 % à 5 % ? Sur ces 3 % d’utilisateurs, combien reviendront vraiment une fois de plus parce qu’ils ont installé l’application ? Dans les données, ce gain de retour est généralement inférieur à 2 %. Le rapport coût-bénéfice n’est pas au rendez-vous.
Les notifications push demandent encore plus de prudence. Ne demandez pas « Autoriser les notifications ? » à la première visite : 80 % des utilisateurs refusent. Le bon moment, c’est après une action significative (envoi d’une demande de devis, téléchargement d’un livre blanc, par exemple), quand vous pouvez demander : « Souhaitez-vous recevoir nos notifications de mise à jour tarifaire ? » Le taux d’autorisation atteint alors 30 % à 40 %. Même une fois l’autorisation obtenue, il faut limiter la fréquence : pas plus d’une fois par semaine, sinon l’utilisateur désactive tout de suite dans les réglages du navigateur.
| Fonctionnalités | Expérience native du navigateur | Après une invite personnalisée | Gain réel en B2B |
|---|---|---|---|
| Moment de l’invite d’installation | À la visite, 90 % de refus | Après interaction, 60 % de refus | Taux d’installation en hausse de 1 à 3 points |
| Moment de la demande d’autorisation push | À la première visite, 80 % de refus | Après une action de conversion, 60 % de refus | Taux d’autorisation en hausse de 10 à 20 points |
| Taux d’ouverture des push | Non applicable | 4 % à 8 % après optimisation | Retours en hausse de 1 % à 3 % |
| Prise en charge sur iOS Safari | Pas d’invite automatique | Ajout manuel à l’écran d’accueil nécessaire | Quasiment aucun gain sur iOS |
FAQ — Questions fréquentes
Le PWA aide-t-il au SEO ?
Comment faire un PWA sur un site WordPress ? Faut-il écrire soi-même le Service Worker ?
Les notifications push PWA fonctionnent-elles sur iOS ?
Le Service Worker a mis en cache une ancienne version, que faire ? Comment forcer la mise à jour ?
Comment mesurer le taux d’installation d’une PWA ? Qu’est-ce qui est normal ?
Le cache hors ligne peut-il montrer aux utilisateurs des prix et des stocks obsolètes ?
Pour conclure
Dans le contexte d’un site B2B autonome, la PWA ressemble plus à une optimisation « un plus » qu’à une nécessité « vitale ». Le seul point qui vaut vraiment l’investissement, c’est le cache hors ligne du Service Worker, surtout quand des marchés à réseau faible comme le Moyen-Orient, l’Asie du Sud-Est ou l’Amérique latine représentent plus de 30 % de votre trafic. L’invite d’installation et les notifications push rapportent très peu, et leur absence ne pénalise pas l’activité principale.
Commencez petit : installez d’abord une seule extension PWA, activez uniquement le cache hors ligne, puis observez pendant 2 semaines l’évolution du LCP chez les visiteurs mobiles qui reviennent. Si, dans les zones à réseau faible, le LCP passe de 4 secondes à moins de 2,5 secondes, l’investissement en vaut la peine. L’invite d’installation et les notifications push, attendez de confirmer que le cache hors ligne fonctionne et que l’équipe a encore du temps, avant d’envisager de les ajouter. Ne faites pas tout le trio PWA d’un coup.
Une phrase à retenir : la valeur d’une PWA ne réside pas dans le “ajout à l’écran d’accueil”, mais dans le “chargement instantané même en réseau faible” — le premier est un argument marketing, le second est le vrai problème.