Rendre sa landing page installable (PWA) : sur quelles pages ça sert vraiment la conversion

Une landing page publicitaire classique se visite une fois, convertit ou ne convertit pas, et disparaît de la mémoire du visiteur dans l'heure. Sur ce genre de page, l'installer comme une application n'a aucun sens : personne n'a de raison de rouvrir l'icône d'une page qu'il a déjà remplie ou quittée. Mais un sous-ensemble de landing pages fonctionne différemment — le visiteur revient volontairement, plusieurs fois, avant de se décider ou avant qu'un événement arrive. C'est sur ce sous-ensemble précis que rendre la page installable en PWA (Progressive Web App) a un effet mesurable, et c'est un choix binaire qui se décide page par page, pas au niveau du site entier.

Sur quelles landing pages l'installation a un sens

Le critère n'est pas la sophistication technique, c'est la fréquence de retour attendue. Trois profils de parcours la justifient :

• La liste d'attente SaaS — l'utilisateur s'inscrit, puis revient consulter sa position ou attendre l'ouverture ; une icône sur l'écran d'accueil vaut mieux qu'un email retrouvé trois semaines plus tard dans une boîte de réception saturée.
• L'inscription à un webinaire — entre la confirmation et l'événement, la page de compte à rebours peut être rouverte volontairement plusieurs fois ; associée à une notification, elle réduit le taux de no-show.
• La décision à cycle long — une estimation immobilière ou un devis de courtier que le visiteur compare avant de trancher, parfois sur plusieurs jours.

À l'inverse, une page de vente d'ebook, une landing page publicitaire éphémère ou n'importe quelle page conçue pour une seule session n'a rien à gagner à proposer une installation : la friction de l'invite (même minime) pèse sur 100 % des visiteurs pour un bénéfice que la quasi-totalité d'entre eux n'utilisera jamais.

Ce que l'installation change réellement, et ce qu'elle ne change pas

Installer une landing page en PWA ne la transforme pas en application hors-ligne complète : dans l'immense majorité des cas, il s'agit simplement d'ajouter une icône sur l'écran d'accueil qui ouvre la page en plein écran, sans barre d'adresse, via display: "standalone". C'est un raccourci plus visible et plus engageant qu'un signet ou un onglet épinglé, rien de plus — et c'est justement pour ça que la sélectivité compte. Böhmer et Krüger, dans une étude publiée en 2013 aux actes de la conférence CHI (disponible sur Google Scholar), ont analysé plus de 1 400 captures d'écran d'écrans d'accueil de smartphones et montré que les utilisateurs organisent leurs icônes principalement selon la fréquence d'usage réelle des applications. Une icône installée qui ne sert jamais se retrouve reléguée dans un dossier ou désinstallée — l'invite d'installation n'est donc pas un espace publicitaire gratuit, c'est une place que la page doit mériter par une raison concrète d'y revenir.

Les critères techniques d'installabilité

Pour que Chrome propose l'installation (l'événement beforeinstallprompt), la page doit être servie en HTTPS, exposer un manifest valide avec au minimum name, short_name, start_url, un display à standalone ou fullscreen, et des icônes 192×192 et 512×512, et enregistrer un service worker qui écoute au moins l'événement fetch. Chrome ajoute une heuristique d'engagement : le visiteur doit avoir interagi une fois avec la page (clic ou tap) et y avoir passé un minimum de temps, de l'ordre d'une trentaine de secondes, avant que l'invite ne devienne disponible — ce qui exclut de fait les pages consultées en quelques secondes.

Sur iOS, Safari ne déclenche aucune invite automatique : l'utilisateur doit ouvrir le menu de partage puis choisir « Sur l'écran d'accueil » lui-même. Sur les pages où l'installation apporte une vraie valeur (liste d'attente, compte à rebours de webinaire), il vaut la peine d'ajouter une instruction visuelle discrète pour les visiteurs iOS plutôt que de compter sur une invite qui n'existera jamais chez eux.

Implémenter en Next.js (App Router)

Next.js expose une convention de fichier native pour le manifest, sans passer par un fichier JSON statique à maintenir à la main :

// app/manifest.ts
import type { MetadataRoute } from "next";

export default function manifest(): MetadataRoute.Manifest {
  return {
    name: "Facturo — Liste d'attente",
    short_name: "Facturo",
    start_url: "/",
    display: "standalone",
    background_color: "#0b0b0f",
    theme_color: "#0b0b0f",
    icons: [
      { src: "/icon-192.png", sizes: "192x192", type: "image/png" },
      { src: "/icon-512.png", sizes: "512x512", type: "image/png", purpose: "maskable" },
    ],
  };
}

Le service worker minimal n'a pas besoin de gérer un cache : un simple gestionnaire fetch suffit à satisfaire le critère d'installabilité. // public/sw.js
self.addEventListener("fetch", () => {}); Il s'enregistre depuis un composant client, après le premier rendu : useEffect(() => {
  if ("serviceWorker" in navigator) navigator.serviceWorker.register("/sw.js");
}, []);

Ne jamais mettre en cache une offre qui change

C'est le piège le plus coûteux, et il concerne directement tout site qui fait tourner des promotions datées. Un service worker qui répond depuis le cache sans revalider peut continuer à servir un prix barré expiré, un code promo dépassé ou un compte à rebours figé — exactement ce que ce site évite volontairement en calculant l'offre courante côté client au montage plutôt qu'en la figeant au build (voir notre approche du rendu statique face à un prix qui change). Le service worker minimal décrit ci-dessus ne pose pas ce problème puisqu'il n'intercepte rien : si vous ajoutez un jour une stratégie de cache pour les assets statiques (polices, images), gardez le HTML de la page en network-first ou hors du cache, jamais en cache-first.

Personnaliser le moment de l'invite

L'invite native de Chrome peut être interceptée avec e.preventDefault() sur l'événement beforeinstallprompt, stockée, puis déclenchée plus tard via un bouton propre au design de la page — par exemple sur l'écran de confirmation qui suit l'inscription à la liste d'attente, plutôt qu'à l'arrivée sur la page. Ce moment compte : proposer l'installation après un engagement réel (le visiteur vient de s'inscrire) plutôt qu'au chargement multiplie les chances d'acceptation, pour la même raison qu'une demande d'autorisation de notifications mal placée se solde par un refus quasi systématique. Sur une page de webinaire, coupler l'installation à une notification de rappel a un effet de rétention documenté : Bell, Garnett et coauteurs, dans un essai clinique randomisé publié en 2023 dans JMIR mHealth and uHealth (disponible sur Google Scholar), ont mesuré qu'une notification multipliait par 3,5 la probabilité que l'utilisateur rouvre l'application dans l'heure suivante, comparé à l'absence de notification — un effet obtenu hors contexte marketing, mais dont le mécanisme (le rappel visible déclenche le retour) transpose directement à un rappel de webinaire.

Pièges à éviter

• Proposer l'invite dès l'arrivée — outre l'heuristique d'engagement de Chrome qui l'empêche techniquement, un refus répété incite le navigateur à espacer les futures invites sur ce domaine ; mieux vaut une seule invite bien placée qu'une invite systématique ignorée.
• Un service worker qui met en cache la page elle-même — au-delà du prix ou de l'offre, cela peut aussi figer un correctif de bug ou une mise à jour de contenu déployée après coup, ce qui rend le suivi des changements du site invisible pour les visiteurs déjà installés.
• Oublier l'icône maskable — sans icône déclarée purpose: "maskable", Android peut rogner un logo non prévu pour être recadré en cercle ou en carré arrondi, avec un rendu approximatif sur l'écran d'accueil.
• Rendre une page à session unique installable par principe — sur une landing page publicitaire ou une page de vente ponctuelle, l'effort de mise en place et la friction de l'invite ne rapportent rien : gardez la PWA pour les pages où un retour réel est probable.

Le template SaaS Waitlist et le template Webinaire & Masterclass de LanderKit sont livrés en code source Next.js App Router : ajouter un app/manifest.ts et un service worker minimal se fait directement dans le projet, sans dépendre d'un plugin tiers ni recompiler l'ensemble du site. Pour la page de confirmation qui suit l'inscription — l'endroit le plus pertinent pour déclencher l'invite d'installation — voir aussi notre guide sur la page de remerciement.