Notifications push web : comment elles fonctionnent et comment bien les utiliser

Les notifications push web sont le seul canal marketing où une seule mauvaise décision de conception peut vous fermer définitivement l’accès à un client. Demandez la permission au mauvais moment, la personne clique sur Bloquer, et ce navigateur vous est fermé pour toujours. Pas de seconde demande, pas de seconde campagne, pas d’e-mail de reconquête. Cette asymétrie explique pourquoi le mécanisme mérite d’être compris avant d’écrire le moindre message.

Ce que sont les notifications push web

Une notification push web est un message envoyé depuis votre serveur vers le navigateur d’une personne abonnée, affiché par le centre de notifications du système d’exploitation, et délivré même quand votre site est fermé. Ce dernier point est tout l’intérêt : contrairement à une fenêtre affichée sur la page, le push web atteint quelqu’un qui n’est pas en train de regarder votre site.

Il repose sur trois API de la plateforme web qui travaillent ensemble, et la répartition entre elles explique l’essentiel du comportement du canal : la Service Worker API, la Push API et la Notifications API.

Le fonctionnement du push web sous le capot

Le service worker

Un service worker est un worker JavaScript qui agit comme un proxy entre votre web app, le navigateur et le réseau. Il s’exécute sur son propre fil, n’a pas accès au DOM et continue d’exister après la fermeture de la page qui l’a enregistré. C’est cette persistance qui lui permet de recevoir un message push et d’afficher une notification alors que personne n’a votre onglet ouvert. Les service workers ne s’exécutent que dans des contextes sécurisés, c’est-à-dire en HTTPS, http://localhost étant considéré comme sécurisé pour le développement.

L’abonnement : un endpoint et deux clés

Une fois le service worker actif, la page appelle registration.pushManager.subscribe(). Le navigateur dialogue avec le service push de son éditeur et renvoie un objet PushSubscription contenant :

• endpoint, une URL de capacité unique sur laquelle le service push accepte les messages
• keys.p256dh, une clé publique Diffie-Hellman à courbe elliptique sur la courbe P-256
• keys.auth, un secret d’authentification

Votre serveur stocke les trois et traite l’endpoint comme un secret, car quiconque le détient peut écrire à cette personne abonnée. Les clés existent parce que les charges utiles sont chiffrées de bout en bout. La RFC 8291 précise comment : un échange ECDH sur P-256 établit un secret partagé, HKDF en dérive des clés, et la charge utile est scellée avec AES-128-GCM sous l’encodage de contenu aes128gcm. Le service push relaie un texte chiffré qu’il ne peut pas lire.

Le service push

Vous n’envoyez pas les messages push directement à un appareil. Vous les envoyez à un service push exploité par l’éditeur du navigateur : les endpoints FCM de Google pour Chrome, autopush de Mozilla pour Firefox, le service push d’Apple pour Safari. La RFC 8030, « Generic Event Delivery Using HTTP Push », définit le protocole. Votre serveur fait un POST vers l’endpoint d’abonnement, et le service push prend en charge les parties difficiles de la distribution mobile : une seule connexion économe en batterie vers l’appareil, la mise en file d’attente hors ligne, le réveil du navigateur à l’arrivée d’un message. C’est aussi pourquoi la distribution ne peut pas être garantie. Si l’appareil reste éteint assez longtemps, les messages expirent selon leur TTL et sont abandonnés.

VAPID : prouver qui envoie

Le fait que l’endpoint soit secret constitue une sécurité mince. La RFC 8292 ajoute la Voluntary Application Server Identification, ou VAPID, pour qu’un service push puisse savoir de quel serveur applicatif provient un message.

Vous générez une fois une paire de clés ECDSA sur la courbe NIST P-256. La clé publique est passée dans applicationServerKey lorsque le navigateur s’abonne, ce qui lie l’abonnement à votre serveur. Pour chaque envoi, votre serveur transmet un JWT signé avec la clé privée correspondante en ES256, portant une revendication aud pour l’origine du service push, une revendication exp à moins de 24 heures, et éventuellement une revendication sub avec des coordonnées de contact. Le service push vérifie la signature : un endpoint volé ne suffit donc plus à spammer vos personnes abonnées.

Le chemin de distribution, de bout en bout

1. La page enregistre un service worker puis, une fois la permission accordée, appelle subscribe() avec votre clé publique VAPID.
2. Votre serveur stocke l’endpoint et les clés retournés en les rattachant à l’enregistrement de la personne abonnée.
3. Pour envoyer, votre serveur chiffre la charge utile avec p256dh et auth, signe un JWT VAPID et fait un POST vers l’endpoint.
4. Le service push authentifie la requête et distribue le message chiffré.
5. Le navigateur réveille le service worker avec un événement push, qui déchiffre la charge utile et appelle ServiceWorkerRegistration.showNotification().
6. Un clic déclenche notificationclick dans le service worker, où vous ouvrez l’URL de destination.

Pourquoi le modèle de permission est aussi strict

Regardez ce qu’un abonnement accorde : un processus d’arrière-plan qui s’exécute sans que votre site soit ouvert, plus la capacité de dessiner sur la surface de notification du système d’exploitation. Les navigateurs le protègent donc derrière une permission explicite, par origine, accordée par la personne, et la plupart exigent que la demande suive un geste utilisateur véritable.

Une seconde contrainte surprend souvent. Chrome et Edge exigent userVisibleOnly: true lors de l’abonnement, c’est-à-dire la promesse que chaque envoi produira une notification visible : les envois silencieux en arrière-plan ne sont donc pas un usage pris en charge de l’API. Firefox applique en plus un quota aux messages push qui ne génèrent pas de notification.

Prise en charge par les navigateurs et les plateformes

Selon MDN, la Push API est largement disponible au sens Baseline depuis mars 2023, ce qui signifie qu’elle fonctionne sur les versions actuelles de Chrome, Edge, Firefox et Safari sur ordinateur, ainsi que sur Chrome et Firefox pour Android. Deux réserves comptent plus que le titre.

D’abord, la Notifications API n’est pas disponible de façon uniforme. MDN la signale en disponibilité limitée parce que le constructeur Notification() lève une TypeError sur la plupart des navigateurs mobiles. Pour tout ce qui doit fonctionner sur téléphone, utilisez les notifications persistantes via ServiceWorkerRegistration.showNotification(), qui est de toute façon le chemin du service worker que vous empruntez déjà.

Ensuite, les options de notification sont inégalement implémentées. Boutons d’action, badges, images et requireInteraction varient selon les navigateurs et les systèmes d’exploitation : concevez donc des notifications qui restent lisibles avec seulement un titre, un corps et une icône.

L’exigence propre à iOS et iPadOS

Cette réserve décide si le push web est viable pour une audience très mobile, et elle est énoncée de travers à peu près partout.

Apple a ajouté le Web Push dans iOS et iPadOS 16.4, et il ne fonctionne que pour les web apps ajoutées à l’écran d’accueil. Comme l’a formulé WebKit, « we are adding support for Web Push to Home Screen web apps », et « a web app that has been added to the Home Screen can request permission to receive push notifications ». La personne l’ajoute via le menu Partager et « Sur l’écran d’accueil », puis la permission doit être demandée en réponse à une interaction directe, par exemple un appui sur un bouton d’abonnement.

Un site ouvert dans un onglet Safari ordinaire sur iPhone ne peut pas créer d’abonnement push. C’est une vraie barrière : vous demandez une étape d’installation avant même de pouvoir demander la permission. Sur macOS, c’est plus simple, car Safari 16.1 sur macOS Ventura a ajouté le Web Push standardisé pour les sites ordinaires, sans aucune étape d’installation.

Un exemple d’abonnement minimal

Voici tout le flux côté client. Sa place est dans un gestionnaire de clic, pas au chargement de la page.

async function subscribeToPush(vapidPublicKey) {
  // Le push et les service workers exigent un contexte sécurisé (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

  const registration = await navigator.serviceWorker.register("/sw.js");

  // Doit être appelé depuis un geste utilisateur, et une seule fois par personne.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // clé publique P-256 encodée en base64url
  });

  // Conserver endpoint + clés côté serveur ; traiter l'endpoint comme un secret.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Dans sw.js, vous traitez l’événement push, appelez self.registration.showNotification(title, options) et gérez notificationclick pour ouvrir l’URL de destination.

UX de permission : là où la plupart des programmes échouent

Ne demandez jamais au chargement de la page

Lighthouse consacre un audit entier à ce point : « if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs ». Sa recommandation est de proposer un type de notification précis et de ne demander la permission qu’après l’adhésion à ce type. Safari 12.1 et d’autres navigateurs sont allés plus loin, en exigeant une interaction avec la page avant même qu’une demande puisse être formulée.

Utilisez une pré-demande douce

Affichez d’abord votre propre invitation dans la page. Elle nomme la proposition de valeur, elle peut être écartée sans coût définitif, et seul un clic dessus déclenche la véritable fenêtre du navigateur. Une personne qui ignore votre pré-demande aujourd’hui peut être sollicitée à nouveau le mois prochain. Une personne qui clique sur Bloquer, non. Deux règles la rendent efficace : décrivez ce que vous allez réellement envoyer plutôt que « recevez nos actualités », et ne provoquez jamais un clic par erreur, car une acceptation accidentelle produit un désabonnement immédiat.

Demandez en contexte

La recommandation de Chrome est de « let your users take the initiative and turn on notifications at their own pace », en plaçant discrètement des interrupteurs dans les surfaces d’interface existantes, et d’éviter « showing prompts and/or overlays without context or immediately after a user lands on the site ».

Les moments qui fonctionnent dans le commerce sont précis : un bouton « prévenez-moi du retour en stock » sur un produit épuisé, une page de confirmation de commande qui propose le suivi de livraison, un interrupteur de veille tarifaire sur un produit souvent consulté. La permission est échangée contre un bénéfice nommé plutôt que récoltée.

Un refus est de fait définitif

Quand quelqu’un bloque les notifications, le navigateur mémorise cette décision pour votre origine. Les appels ultérieurs à Notification.requestPermission() se résolvent avec la valeur denied stockée sans rien afficher, et c’est pourquoi l’exemple de MDN vérifie Notification.permission avant même d’appeler requestPermission(). Revenir sur un blocage suppose de fouiller dans les paramètres du site, ce que pratiquement personne ne fait.

Ce que font les navigateurs quand vous vous y prenez mal

Les conséquences ne se limitent plus à un faible taux d’opt-in.

• Chrome bascule automatiquement les origines à très faible taux d’acceptation vers une interface de permission plus discrète, séparément par type d’appareil, ce qui supprime la fenêtre pour tout le monde.
• Chrome applique des limites de débit aux sites qui combinent un volume élevé et un faible engagement, en renvoyant un HTTP 429. L’escalade dure un jour, puis sept, puis quatorze, et ne se réinitialise qu’après 42 jours consécutifs sans envoi perturbateur.
• Chrome révoque désormais automatiquement la permission de notification pour les sites avec lesquels une personne n’a pas interagi récemment, là où il constate « very low user engagement and a high volume of notifications being sent ». La justification de Google est sans détour : « Less than 1% of all notifications receive any interaction from users. »

Vous pouvez perdre des personnes abonnées déjà acquises simplement en envoyant mal.

Le push web comparé à l’e-mail et au SMS

La différence de propriété qui change la stratégie

Un abonnement push est une URL de capacité liée à un profil de navigateur sur un appareil. Ce n’est pas une personne. Le même client sous Chrome sur un portable et sous Firefox sur un téléphone représente deux abonnements sans lien, et vous ne pouvez pas savoir qu’il s’agit du même être humain tant qu’il ne s’identifie pas.

Ce n’est pas non plus portable. Vous pouvez exporter une liste e-mail et la charger demain dans une autre plateforme. Vous ne pouvez pas déplacer des abonnements push entre fournisseurs, parce que les clés et le lien VAPID ont été créés face à une clé de serveur applicatif précise.

Traitez donc le push web comme un accélérateur d’un canal que vous possédez, jamais comme un remplacement. Utilisez le moment du push pour obtenir une adresse e-mail ou un numéro de téléphone, et non l’inverse. Le guide complet du marketing automation explique comment câbler plusieurs canaux dans un même parcours.

Les cas d’usage qui fonctionnent vraiment

Le canal récompense les messages sensibles au temps, personnellement pertinents et actionnables en une seule pression.

• Panier abandonné. Un push dans l’heure, renforcé par un e-mail plus tard. Le guide de l’e-mail de panier abandonné traite le séquencement.
• Alertes de retour en stock. Le cas le plus fort, parce que la personne a explicitement demandé à être prévenue.
• Baisses de prix sur des articles suivis. Même logique, pertinence choisie par la personne.
• Livraison et statut de commande. Forte intention d’ouverture, faible risque de plainte.
• Actualités urgentes sur un sujet suivi. Informations, résultats, fenêtres de disponibilité.

Ce qui échoue est tout aussi clair : les diffusions génériques du type « nous avons publié un nouvel article », les offres quotidiennes indifférenciées, tout ce qui demande plus qu’un titre et une ligne, les vagues de réactivation vers des personnes qui ont ignoré les vingt dernières notifications, et les contenus transactionnels qui exigent une trace durable.

Fréquence, moment d’envoi et segmentation

Commencez prudemment : une à trois notifications par personne abonnée et par semaine, en n’augmentant que si les taux de désabonnement et de clic tiennent. La lassitude apparaît plus vite qu’en e-mail, car couper le son coûte une seule pression sur une notification que le système a déjà affichée.

Le moment d’envoi est à la fois un atout et un danger. Le push arrive immédiatement : un message envoyé à 02:00 arrive à 02:00. Stockez ou déduisez le fuseau horaire au moment de l’abonnement et retenez les envois dans une fenêtre définie.

La segmentation est limitée par ce que vous savez d’un abonnement plutôt que d’une personne : les dimensions exploitables sont donc comportementales, à savoir pages vues, produits suivis, état du panier, récence d’achat, plateforme. Le guide de la segmentation client va plus loin.

Mesurer le push web

Quatre métriques comptent, et elles ne se mesurent pas toutes de la même façon.

• Distribution. Le fait que le service push ait accepté la requête. Un 201 signifie accepté, pas distribué. Un 404 ou un 410 signifie que l’abonnement est mort.
• Affichage. Le fait que la notification ait été montrée. Vous ne le savez que si le service worker le remonte lorsque showNotification() se résout.
• Taux de clic. Clics divisés par affichages. C’est le chiffre qu’il vaut la peine d’optimiser.
• Taux de désabonnement. Désabonnements et révocations de permission par envoi. Surveillez-le de plus près que le taux de clic, car c’est l’indicateur avancé de la mort du canal.

Les pièges de l’attribution

L’attribution du push se flatte elle-même. La notification arrive sur un appareil que la personne tient déjà en main : elle s’attribue donc souvent une session qui allait avoir lieu de toute façon. Utilisez des groupes témoins plutôt que de présumer l’incrémentalité. Les affichages sont sous-comptés alors que chaque clic est enregistré : un taux de clic calculé sur les envois surestime donc la performance. Et comme un abonnement est un navigateur et non une personne, un push cliqué sur un téléphone qui se termine par un achat sur ordinateur ressemble à deux événements sans lien. Le guide des métriques de l’e-mail marketing traite l’hygiène de mesure sur tous les canaux.

Consentement, RGPD et désabonnement

La fenêtre de permission du navigateur est une barrière technique. Elle ne constitue pas automatiquement une base légale complète pour le marketing.

Lorsque vous vous adressez à des personnes dans l’Union européenne ou au Royaume-Uni, traitez le push comme vous traitez l’e-mail. Expliquez ce que vous allez envoyer avant l’apparition de la fenêtre, pour que le consentement soit éclairé et spécifique. Enregistrez quand et où l’abonnement a été créé, et n’associez jamais le consentement au push à une action sans rapport. Si vous rattachez les abonnements à des clients identifiés, ces données relèvent de vos obligations sur les données personnelles, y compris les demandes d’effacement.

L’hygiène du désabonnement compte tout autant. Proposez un réglage de préférences sur le site pour que les gens puissent réduire la fréquence au lieu de bloquer, appelez PushSubscription.unsubscribe() et supprimez l’enregistrement côté serveur quand ils le font, et purgez les abonnements sur un 404 ou un 410. La consigne de MDN est courte et juste : les personnes doivent se voir « offered an easy way to opt out of getting more in the future ».

La place du push web dans une stack de canaux

Le push web est un bon troisième canal et un mauvais premier : rapide, gratuit à la marge et sans rival pour les alertes urgentes, mais lié à l’appareil, non exportable et à un clic d’une perte définitive.

Le vrai problème devient donc l’orchestration. Quel message part sur quel canal, comment supprimer l’e-mail quand le push a déjà converti, et comment garder une vue unique du client sur des surfaces qui identifient les personnes différemment. Brevo propose le push web et mobile aux côtés de l’e-mail et du SMS, et Tajo se pose au-dessus de Brevo pour coordonner cette logique multicanale pour les boutiques Shopify. Pour le volet SMS, voyez le guide de l’automation SMS.

À retenir

• Le push web, ce sont trois API qui coopèrent : un service worker pour l’exécution en arrière-plan, la Push API pour l’abonnement et le transport, la Notifications API pour l’affichage. Un abonnement est un endpoint plus une clé p256dh et un secret auth, les charges utiles sont chiffrées de bout en bout, et VAPID prouve l’identité de l’expéditeur.
• Le push est largement disponible au sens Baseline depuis mars 2023, mais sur iOS et iPadOS il ne fonctionne que pour les web apps ajoutées à l’écran d’accueil.
• Ne demandez jamais la permission au chargement de la page. Utilisez une pré-demande douce, demandez en contexte, et rappelez-vous qu’un blocage est définitif pour cette origine.
• Chrome impose désormais des fenêtres plus discrètes, des limites de débit et une révocation automatique de permission : mal envoyer vous coûte donc des personnes abonnées déjà acquises.
• Un abonnement est un navigateur, pas une personne, et il ne s’exporte pas. Construisez d’abord la liste e-mail et servez-vous du push pour l’accélérer.