J’ai découvert les notifications push en développant des applications mobiles. Plus tard, le même principe s’est étendu au web : un visiteur autorise les messages et le navigateur peut les afficher même lorsque le site n’est pas ouvert.
C’est techniquement intéressant. Du point de vue marketing, une autre question est plus importante : avons-nous quelque chose d’assez utile et urgent pour justifier d’interrompre quelqu’un ? Si ce n’est pas le cas, nous n’avons pas besoin d’un autre canal.
Ce que sont réellement les notifications push web
Une application web fonctionne généralement avec une autorisation de notification, un service worker et le service push du navigateur. Un abonnement est lié à un navigateur et à un appareil précis, et non automatiquement à une personne dans le CRM. L’API Push de MDN décrit les fondements techniques et le rôle du service worker.
Cela a une conséquence pratique : le nombre d’abonnements n’est pas le nombre de clients. Une personne peut avoir plusieurs appareils, réinstaller son navigateur ou retirer son autorisation à tout moment. Sans compte connecté et association rigoureuse, vous ne savez généralement pas qui possède un appareil. Je n’essaierais pas de dissimuler cette incertitude derrière un profil client trop précis.
Ne demandez l’autorisation qu’avec un contexte
La pire option consiste à afficher la demande système dès l’arrivée sur un site web. La personne ne sait pas encore ce que vous proposez et le navigateur lui demande une autorisation à long terme. Si elle choisit de bloquer les notifications, vous n’aurez souvent pas de seconde chance sans qu’elle modifie manuellement les paramètres.
J’explique donc d’abord un avantage précis : la notification d’un changement de statut de commande, d’un créneau disponible, du début d’une diffusion ou du retour d’un produit suivi. Ce n’est qu’après une action volontaire de l’utilisateur que j’ouvre la véritable demande du navigateur. La documentation de l’API Notifications sur MDN recommande elle aussi de lier la demande à une action de l’utilisateur.
Quand les notifications push sont pertinentes
- Statut et disponibilité : une commande, une réservation, un rendez-vous ou un produit a changé.
- Contenu urgent : une diffusion commence, une enchère se termine ou un événement choisi par la personne a eu lieu.
- Outil de travail récurrent : l’utilisateur s’attend à recevoir des alertes opérationnelles dans le cadre du service.
- Suivi volontaire : la personne a activé un sujet précis, plutôt que de vagues « actualités ».
Plus le message est proche d’un comportement que l’utilisateur a explicitement configuré, plus l’interruption est facile à justifier. Une remise générale pour tout le monde est une raison plus faible qu’une alerte demandée par quelqu’un.
Quand je privilégierais l’e-mail
L’e-mail convient mieux à une explication détaillée, à un document, à un récapitulatif et aux communications que l’on peut traiter plus tard. Une notification push offre peu d’espace, disparaît rapidement et ne devrait pas renvoyer au clic vers une page où l’utilisateur doit rechercher à nouveau le sens du message.
Si une entreprise ne parvient pas à gérer des e-mails pertinents, un autre canal ne fait souvent que multiplier le problème. Je commencerais par remettre en ordre la base de données, l’offre et le processus à l’aide de l’article sur l’e-mail marketing. Je choisirais ensuite les outils selon un scénario précis, et non selon le nombre d’icônes dans la grille tarifaire.
Ce que chaque message doit contenir
- une raison claire expliquant pourquoi il arrive maintenant ;
- un expéditeur identifiable ;
- un message concis, sans fausse urgence ;
- une page de destination qui correspond exactement au message ;
- la possibilité d’ajuster les sujets ou de mettre fin à l’abonnement ;
- une limite de fréquence et une période de silence adaptées à la situation de l’utilisateur.
Je n’enverrais pas le même message simultanément par notification push, e-mail, SMS et chat simplement parce que l’intégration existe. L’orchestration consiste à choisir le canal approprié, pas à les utiliser tous.
Comment mesurer les notifications push
La livraison et les clics sont des signaux opérationnels. La valeur commerciale n’apparaît qu’à l’étape suivante : terminer une réservation, revenir dans l’application, acheter un produit suivi ou réduire le nombre de demandes adressées au support.
Je suis également les signaux négatifs : autorisation retirée, désabonnements par sujet, retour rapide sans action et réclamations. Un taux de clic élevé peut résulter d’un texte agressif tout en détruisant le canal à long terme.
J’étiquette les liens avec des paramètres UTM cohérents, mais je tiens compte du fait qu’une partie de la mesure sera limitée par le navigateur, le consentement et le cycle de vie de l’appareil. La précision du tableau de bord ne justifie pas d’étendre la collecte de données sans bénéfice pour la personne.
Un petit projet pilote plutôt qu’un lancement sur tout le site
- Je sélectionne un seul scénario événementiel présentant une valeur claire.
- Je définis qui peut activer l’abonnement et à quel moment.
- Je fixe une limite de fréquence, une durée d’expiration des messages et une option de désactivation.
- Je teste différents navigateurs, appareils et la situation sans autorisation.
- Je mesure la tâche terminée ainsi que les réactions négatives.
- Après plusieurs cycles, je décide d’étendre, d’ajuster ou de désactiver le canal.
Ma conclusion
Les notifications push ne sont pas une newsletter moins chère. Ce sont de brèves interruptions justifiées. Elles fonctionnent bien pour un événement que la personne a elle-même choisi et dont elle doit être informée à temps. Elles fonctionnent mal comme support supplémentaire pour une promotion générale.
Si vous voulez décider si les notifications push ont leur place dans l’ensemble du parcours client, commencez par une analyse de votre système marketing. Vous pouvez décrire votre situation précise via le contact.