Cette page a été traduite par l'API Cloud Translation.

Présentation des notifications push

Présentation des notifications push, de leur utilité et de leur fonctionnement.

Kayce Basques

Matt Gaunt

Que sont les notifications push ?

Les messages push vous permettent de porter des informations à l'attention de vos utilisateurs, même lorsqu'ils n'utilisent pas votre site Web. Ils sont appelés messages push, car vous pouvez "pusher" des informations vers vos utilisateurs même lorsqu'ils ne sont pas actifs. Comparez la technologie push à la technologie pull pour mieux comprendre ce concept.

Les notifications présentent de petits éléments d'informations à l'utilisateur. Les sites Web peuvent utiliser des notifications pour informer les utilisateurs d'événements importants et urgents, ou d'actions qu'ils doivent entreprendre. L'apparence des notifications varie selon les plates-formes :

Exemples de notifications sur macOS et Android.

Les messages push et les notifications sont deux technologies distinctes, mais complémentaires. La technologie push permet d'envoyer des messages depuis votre serveur aux utilisateurs, même lorsqu'ils n'utilisent pas activement votre site Web. Les notifications sont la technologie permettant d'afficher les informations transmises sur l'appareil de l'utilisateur. Il est possible d'utiliser des notifications sans messagerie push. Il sera peut-être possible un jour d'utiliser des messages push sans notifications visibles par l'utilisateur (push silencieux), mais les navigateurs ne le permettent pas pour le moment. En pratique, ils sont généralement utilisés ensemble. Un utilisateur non technique ne comprendra probablement pas la différence entre les messages push et les notifications. Dans cette collection, lorsque nous parlons de notifications push, nous entendons la combinaison de l'envoi d'un message suivi de son affichage sous forme de notification. Lorsque nous parlons de messages push, nous faisons référence à la technologie push en elle-même. Et quand nous parlons de notifications, nous faisons référence à la technologie de notification en soi.

Pourquoi utiliser les notifications push ?

Pour les utilisateurs, les notifications push sont un moyen de recevoir des informations à temps, pertinentes et précises.
Pour vous (propriétaire d'un site Web), les notifications push permettent d'augmenter l'engagement utilisateur.

Comment fonctionnent les notifications push ?

Voici les principales étapes à suivre pour implémenter des notifications push :

Ajouter une logique client pour demander à l'utilisateur l'autorisation d'envoyer des notifications push, puis envoyer des informations d'identification client à votre serveur pour les stocker dans une base de données.
Ajout d'une logique de serveur pour transmettre des messages aux appareils clients.
Ajout d'une logique client pour recevoir les messages envoyés à l'appareil et les afficher sous forme de notifications.

Le reste de cette page explique ces étapes plus en détail.

Obtenir l'autorisation d'envoyer des notifications push

Tout d'abord, votre site Web doit obtenir l'autorisation de l'utilisateur pour envoyer des notifications push. Cela doit être déclenché par un geste de l'utilisateur, par exemple en cliquant sur un bouton Oui à côté d'une invite Do you want to receive push notifications?. Après cette confirmation, appelez Notification.requestPermission(). Le système d'exploitation ou le navigateur de l'appareil de l'utilisateur présentera probablement une interface utilisateur pour confirmer officiellement que l'utilisateur souhaite activer les notifications push. Cette interface utilisateur varie selon les plates-formes.

Abonner le client aux notifications push

Une fois l'autorisation obtenue, votre site Web doit lancer le processus d'abonnement de l'utilisateur aux notifications push. Pour ce faire, utilisez JavaScript et l'API Push. Vous devrez fournir une clé d'authentification publique lors du processus d'abonnement. Nous y reviendrons plus tard. Une fois que vous avez lancé le processus d'abonnement, le navigateur envoie une requête réseau à un service Web appelé service push. Nous y reviendrons également plus tard.

En supposant que l'abonnement a bien été souscrit, le navigateur renvoie un objet PushSubscription. Vous devrez stocker ces données à long terme. Pour ce faire, envoyez généralement les informations à un serveur que vous contrôlez, puis demandez au serveur de les stocker dans une base de données.

Obtenir l'autorisation d'envoyer des messages push Obtenir PushSubscription. Envoyez PushSubscription à votre serveur.

Envoyer un message push

Votre serveur n'envoie pas directement le message push à un client. Un service push effectue cette opération. Un service push est un service Web contrôlé par le fournisseur de navigateur de votre utilisateur. Lorsque vous souhaitez envoyer une notification push à un client, vous devez envoyer une requête de service Web à un service push. La requête de service Web que vous envoyez au service push est appelée requête de protocole de push Web. La requête du protocole de push Web doit inclure les éléments suivants :

Données à inclure dans le message
Client auquel envoyer le message.
Instructions sur la manière dont le service push doit transmettre le message. Par exemple, vous pouvez spécifier que le service de transfert doit cesser d'essayer d'envoyer le message au bout de 10 minutes.

Normalement, vous effectuez la requête de protocole Web push via un serveur que vous contrôlez. Bien entendu, votre serveur n'a pas besoin de créer lui-même la requête de service Web brute. Des bibliothèques peuvent s'en charger, comme web-push-libs. Cependant, le mécanisme sous-jacent est une requête de service Web via HTTP.

Votre serveur envoie une requête de protocole Web Push au service de push, qui envoie le message à l'appareil de l'utilisateur.

Le service de transfert de données reçoit votre requête, l'authentifie et achemine le message de transfert de données vers le client approprié. Si le navigateur du client est hors connexion, le service d'envoi met le message push en file d'attente jusqu'à ce que le navigateur se connecte.

Chaque navigateur utilise le service push de son choix. En tant que développeur de site Web, vous n'avez aucun contrôle sur ce point. Ce n'est pas un problème, car la requête du protocole Web Push est normalisée. En d'autres termes, vous n'avez pas à vous soucier du service push utilisé par le fournisseur du navigateur. Vous devez simplement vous assurer que votre requête de protocole Web Push respecte les spécifications. Entre autres, les spécifications indiquent que la requête doit inclure certains en-têtes et que les données doivent être envoyées sous forme de flux d'octets.

Vous devez toutefois vous assurer que vous envoyez la requête de protocole push Web au service push approprié. Les données PushSubscription que le navigateur vous a renvoyées lors du processus d'abonnement fournissent ces informations. Un objet PushSubscription se présente comme suit :

{
  "endpoint": "https://fcm.googleapis.com/fcm/send/c1KrmpTuRm…",
  "expirationTime": null,
  "keys": {
    "p256dh": "BGyyVt9FFV…",
    "auth": "R9sidzkcdf…"
  }
}

Le domaine de endpoint est essentiellement le service push. Le chemin d'accès de endpoint est une information d'identifiant client qui permet au service push de déterminer exactement à quel client transférer le message.

Les keys sont utilisés pour le chiffrement, comme expliqué ci-dessous.

Chiffrer le message push

Les données que vous envoyez à un service push doivent être chiffrées. Cela empêche le service push d'afficher les données que vous envoyez au client. N'oubliez pas que le fournisseur du navigateur décide du service de transfert de données par poussée à utiliser, et que ce service peut théoriquement être dangereux ou non sécurisé. Votre serveur doit utiliser le keys fourni dans le PushSubscription pour chiffrer ses requêtes de protocole Web Push.

Signer vos requêtes de protocole Web Push

Le service de push permet d'empêcher toute autre personne d'envoyer des messages à vos utilisateurs. Techniquement, vous n'avez pas besoin de le faire, mais l'implémentation la plus simple sur Chrome l'exige. Cette étape est facultative dans Firefox. D'autres navigateurs peuvent en avoir besoin à l'avenir.

Ce workflow implique une clé privée et une clé publique propres à votre application. Le processus d'authentification fonctionne à peu près comme suit :

Vous générez la clé privée et la clé publique en tant que tâche ponctuelle. La combinaison de la clé privée et de la clé publique est appelée clés de serveur d'applications. Elles sont parfois appelées clés VAPID. VAPID est la spécification qui définit ce processus d'authentification.
Lorsque vous abonnez un client aux notifications push à partir de votre code JavaScript, vous fournissez votre clé publique. Lorsque le service de transfert de données génère un endpoint pour l'appareil, il associe la clé publique fournie à endpoint.
Lorsque vous envoyez une requête de protocole Web Push, vous signez certaines informations JSON avec votre clé privée.
Lorsque le service de push reçoit votre requête de protocole de push Web, il utilise la clé publique stockée pour authentifier les informations signées. Si la signature est valide, le service de transfert par poussée sait que la requête provient d'un serveur avec la clé privée correspondante.

Personnaliser la diffusion du message push

La spécification de requête de protocole Web push définit également des paramètres qui vous permettent de personnaliser la manière dont le service push tente d'envoyer le message push au client. Vous pouvez par exemple personnaliser les éléments suivants:

Valeur TTL (Time-To-Live) d'un message, qui définit la durée pendant laquelle le service de diffusion doit tenter de transmettre un message.
L'urgence du message, qui est utile si le service de push préserve l'autonomie de la batterie du client en ne transmettant que des messages à priorité élevée.
Sujet d'un message, qui remplace les messages en attente du même sujet par le dernier message.

Recevoir et afficher les messages envoyés en tant que notifications

Une fois que vous avez envoyé la requête du protocole Web Push au service de push, celui-ci maintient votre requête dans la file d'attente jusqu'à ce qu'un des événements suivants se produise :

Le client se connecte et le service de messages push lui envoie le message.
Le message expire.

Lorsqu'un navigateur client reçoit un message envoyé, il déchiffre les données du message push et envoie un événement push à votre service worker. Un service worker est essentiellement un code JavaScript qui peut s'exécuter en arrière-plan, même lorsque votre site Web n'est pas ouvert ou que le navigateur est fermé. Dans le gestionnaire d'événements push de votre service worker, appelez ServiceWorkerRegistration.showNotification() pour afficher les informations sous forme de notification.

Le message arrive sur l'appareil. Le navigateur réveille le service worker. L'événement de transfert est distribué.