Web Push API

La Web Push API est le standard W3C qui permet aux sites web d'envoyer des notifications push aux navigateurs — même si le site web n'est pas ouvert. Elle définit l'interaction entre le serveur d'application (backend), le service push (Mozilla, Google FCM, Apple) et le navigateur, avec un chiffrement de bout en bout selon la RFC 8291.

Qu'est-ce que la Web Push API ?

La Web Push API est une spécification W3C ouverte qui définit comment un serveur d'application délivre un message push à un navigateur. Elle complète deux standards connexes : la Push API (RFC 8030, décrit le protocole entre le serveur d'application et le service push) et l'API Service Worker (affiche le message reçu dans le navigateur).

Contrairement aux services push propriétaires comme APNs d'Apple ou FCM de Google, la Web Push API est indépendante des fournisseurs : chaque éditeur de navigateur exploite son propre point de terminaison de service push, qui parle le même protocole. Les serveurs d'application n'ont donc pas besoin de distinguer entre Mozilla, Google ou Microsoft — ils envoient à l'URL de point de terminaison que le navigateur a renvoyée lors de l'opt-in.

Processus de délivrance d'un push

  1. Souscription : Le site web enregistre un Service Worker lors de l'opt-in et appelle pushManager.subscribe(). Le navigateur génère une URL de point de terminaison et deux clés cryptographiques (p256dh et auth) et les renvoie au site web.
  2. Stockage : Le site web envoie l'objet de souscription au serveur d'application, qui l'associe à un enregistrement d'utilisateur.
  3. Envoi : Lorsque l'entreprise souhaite envoyer une notification push, le serveur d'application chiffre le payload avec les deux clés selon la RFC 8291 et l'envoie à l'URL de point de terminaison.
  4. Délivrance : Le service push de l'éditeur du navigateur transmet le message chiffré au navigateur de l'utilisateur final.
  5. Affichage : Le Service Worker reçoit l'événement push, déchiffre le payload et appelle showNotification() — la notification système apparaît.

VAPID — identification de l'expéditeur

VAPID (Voluntary Application Server Identification, RFC 8292) est le mécanisme par lequel un serveur d'application s'identifie auprès du service push. Le serveur signe chaque requête avec une paire de clés ECDSA (P-256). La clé publique est transmise au navigateur lors de l'appel de souscription, la clé privée reste dans le backend. Ainsi, le service push peut identifier l'expéditeur et prévenir les abus.

VAPID est obligatoire dans tous les principaux navigateurs depuis 2017. Pour construire ses propres implémentations push, on génère la paire de clés une seule fois (par ex. via la bibliothèque web-push pour Node.js ou pywebpush pour Python) et on l'utilise pour toutes les souscriptions.

Format du payload

La Web Push API transmet un payload chiffré arbitraire (généralement JSON). Le Service Worker décide comment afficher le message. Champs habituels :

{
  "title": "Commande expédiée",
  "body": "Votre colis arrive demain.",
  "icon": "/icon-192.png",
  "badge": "/badge-72.png",
  "url": "/orders/12345",
  "tag": "order-update"
}

Le payload est limité à quelques kilo-octets (selon le navigateur, généralement 4 Ko). Les contenus volumineux ne sont pas transmis dans le payload, mais chargés au clic sur la notification.

TTL et bonnes pratiques

Chaque message push a une durée de vie (TTL, en secondes) que le serveur d'application définit dans l'en-tête HTTP. Si le destinataire est hors ligne, le service push conserve le message pour la TTL indiquée. Pour les contenus urgents (par ex. codes 2FA), la TTL doit être réglée à 60–300 secondes ; pour les campagnes de réactivation, quelques heures peuvent être pertinentes.

Bonne pratique pour les PME : TTL par défaut à 24 heures, en-tête urgent uniquement pour les messages vraiment urgents. Cela préserve le rating qualité auprès du service push et évite les retards de délivrance.

Web Push API dans SendSeven

SendSeven utilise la Web Push API pour le canal push navigateur. Les clés VAPID, la gestion des souscriptions, le chiffrement et le contrôle TTL sont abstraits dans la plateforme. Le push est envoyé soit comme campagne planifiée via Reach vers un segment, soit par appel direct à l'API REST depuis votre propre système, qui contrôle également le timing. Le push navigateur n'est pas un canal dans le Flow Builder ; les étapes SMS ou e-mail suivantes peuvent toutefois y être orchestrées.