Comment configurer les notifications push Webpushr pour WordPress

Webpushr est une plateforme de notifications push web qui envoie des notifications navigateur en temps réel aux utilisateurs abonnés, même lorsque ces utilisateurs ont complètement quitté votre site. Contrairement à l’e-mail ou aux SMS, le push web ne nécessite aucune information de contact personnelle — les abonnés reçoivent les notifications directement via le système de notification natif de leur navigateur via le Web Push Protocol et la Push API.

Ce guide décrit le processus de configuration complet : de la création du compte et de la configuration du plugin WordPress à la segmentation avancée, l’automatisation basée sur des déclencheurs et l’analyse des abonnés. Il couvre également les cas limites techniques — conflits de service worker, exigences HTTPS, lacunes de compatibilité iOS et considérations de performance — que la plupart des tutoriels ignorent complètement.

Prérequis avant de commencer

Avant de toucher au tableau de bord WordPress, vérifiez que votre environnement satisfait aux exigences strictes suivantes :

• HTTPS est obligatoire. La Push API et les service workers sont limités aux origines sécurisées. Un site fonctionnant en HTTP simple ne peut pas enregistrer un service worker et ne peut donc pas envoyer de notifications push web. Si votre site n’est pas encore sécurisé, vous avez besoin d’un certificat SSL valide — AlexHost fournit des Certificats SSL qui couvrent cette exigence.
• WordPress 5.0 ou supérieur est recommandé pour une compatibilité complète avec l’éditeur de blocs Gutenberg et la méta-boîte Webpushr.
• PHP 7.4 ou supérieur côté serveur pour éviter les avertissements de fonctions obsolètes qui peuvent silencieusement interrompre l’initialisation du plugin.
• Connaissance de la compatibilité navigateur : Chrome, Firefox et Edge sur ordinateur et Android prennent en charge le Web Push Protocol. Safari sur macOS a ajouté la prise en charge dans Safari 16 (macOS Ventura). iOS Safari a ajouté une prise en charge limitée dans iOS 16.4 pour les PWA en écran d’accueil uniquement — le push web standard basé sur navigateur sur iOS reste peu fiable à l’heure actuelle.
• Aucun service worker en conflit. Si vous utilisez déjà un plugin PWA ou un autre service de notifications push, leurs service workers peuvent entrer en conflit avec celui de Webpushr. Auditez vos service workers actifs sur chrome://serviceworker-internals/ avant de continuer.

Étape 1 : Créer et configurer votre compte Webpushr

Accédez à webpushr.com et créez un nouveau compte. Lors de l’intégration, il vous sera demandé le domaine de votre site web. Saisissez le domaine exact tel qu’il apparaît dans la barre d’adresse de votre navigateur, y compris le préfixe www ou son absence — cette valeur est utilisée pour délimiter le service worker et toute discordance entraînera des échecs d’abonnement.

Après l’inscription, Webpushr fournit deux identifiants critiques :

• Clé API — utilisée par le plugin WordPress pour authentifier les appels API REST lors de l’envoi de notifications.
• Jeton d’authentification — utilisé pour les requêtes API côté serveur si vous créez ultérieurement des intégrations personnalisées.

Localisez les deux valeurs sous Compte > Clés API dans le tableau de bord Webpushr et stockez-les en toute sécurité. La clé API n’est pas un secret au sens traditionnel (elle est intégrée dans les requêtes côté client), mais le jeton d’authentification doit rester privé.

Limites des plans gratuit et payant de Webpushr

Pour la plupart des petits sites WordPress, le niveau gratuit est suffisant pour valider le canal avant de s’engager dans un plan payant.

Étape 2 : Installer le plugin WordPress Webpushr

Connectez-vous à votre panneau d’administration WordPress et suivez ce chemin :

1. Allez dans Extensions > Ajouter.
2. Recherchez Webpushr.
3. Localisez le plugin officiel publié par Webpushr Inc. — vérifiez le nom de l’éditeur pour éviter d’installer un plugin portant un nom similaire.
4. Cliquez sur Installer maintenant, puis sur Activer.

Vous pouvez également installer via WP-CLI si vous gérez WordPress depuis la ligne de commande :

wp plugin install webpushr-web-push-notifications --activate

Après l’activation, un nouvel élément de menu Webpushr apparaît dans la navigation gauche de WordPress.

Ce que le plugin fait réellement au niveau du serveur

Comprendre l’architecture du plugin vous aide à résoudre les problèmes de manière intelligente. Lors de l’activation, le plugin :

1. Enregistre une règle de réécriture pour servir le fichier service worker (webpushr-sw.js) depuis la racine du site. C’est essentiel — les service workers doivent être servis depuis la portée racine pour contrôler l’ensemble de l’origine.
2. Injecte un extrait JavaScript dans chaque page front-end via wp_enqueue_scripts qui charge le SDK Webpushr et enregistre le service worker.
3. Se connecte aux actions WordPress publish_post et publish_page pour déclencher des notifications push automatiques lors de la publication de contenu.

Si votre plugin de mise en cache met agressivement en cache le fichier service worker, les abonnés peuvent recevoir des charges utiles push obsolètes ou échouer à s’enregistrer complètement. Excluez webpushr-sw.js de vos règles de mise en cache.

Étape 3 : Connecter le plugin à votre compte Webpushr

Accédez à Webpushr > Paramètres dans votre tableau de bord WordPress. Vous verrez un champ intitulé Clé API. Collez la clé API que vous avez récupérée depuis le tableau de bord Webpushr à l’étape 1.

Cliquez sur Enregistrer les modifications. Le plugin effectuera une requête de validation vers l’API Webpushr. Si la clé est valide, une confirmation de succès apparaît. Si vous voyez une erreur :

• Vérifiez qu’il n’y a pas d’espaces en début ou en fin de la clé collée.
• Vérifiez que votre serveur peut effectuer des requêtes HTTPS sortantes vers api.webpushr.com. Certaines configurations VPS renforcées bloquent les connexions sortantes par défaut. Sur un serveur Linux, testez avec :

curl -I https://api.webpushr.com

Une réponse 200 OK ou 301 confirme la connectivité. Si la connexion expire, vérifiez vos règles de pare-feu avec iptables -L OUTPUT ou l’ACL réseau de votre hébergeur.

Si vous exécutez WordPress sur un environnement d’Hébergement VPS, vous avez un contrôle total sur les règles de pare-feu et pouvez mettre en liste blanche le point de terminaison de l’API Webpushr directement.

Étape 4 : Configurer l’invite d’abonnement

L’invite d’abonnement est la boîte de dialogue de permission du navigateur qui demande aux utilisateurs d’autoriser les notifications. La boîte de dialogue de permission native du navigateur ne peut pas être stylisée — elle est rendue par le navigateur lui-même. Cependant, Webpushr fournit une invite de pré-permission (une superposition personnalisée qui apparaît avant la boîte de dialogue native) que vous pouvez entièrement personnaliser.

Configurez l’invite de pré-permission dans le tableau de bord Webpushr sous Paramètres > Invite d’abonnement :

• Style de l’invite : Choisissez entre un widget en cloche, une barre supérieure, une boîte coulissante ou une fenêtre modale personnalisée.
• Texte de l’invite : Rédigez un texte qui communique clairement la valeur de l’abonnement. Les invites vagues comme « Autoriser les notifications ? » obtiennent systématiquement de moins bons résultats que les invites qui précisent ce que les abonnés recevront, comme « Soyez notifié instantanément lorsque nous publions de nouveaux avis de sécurité. »
• Délai de l’invite : Définissez un délai (en secondes ou en pages vues) avant d’afficher l’invite. L’afficher immédiatement au chargement de la page produit des taux d’abonnement plus faibles qu’en attendant qu’un utilisateur ait interagi avec au moins un contenu.
• Intervalle de réaffichage : Définissez le nombre de jours devant s’écouler avant qu’un utilisateur ayant rejeté l’invite la voie à nouveau. Un réaffichage agressif nuit à l’expérience utilisateur et augmente le taux de rebond.

Benchmarks de taux d’abonnement par type d’invite

Les invites contextuelles — affichées après qu’un utilisateur a accompli une action significative comme lire un article jusqu’à la fin — surpassent systématiquement toutes les autres approches.

Étape 5 : Configurer les paramètres de livraison des notifications

Push automatique à la publication d’un article

Dans Webpushr > Paramètres, le bouton Notification push automatique contrôle si une notification push se déclenche automatiquement chaque fois que vous publiez un article. Lorsqu’il est activé, Webpushr récupère le titre de l’article, l’extrait et l’URL de l’image mise en avant et construit automatiquement la charge utile de la notification.

Cas limite : Si vous utilisez un flux de travail de mise en scène vers production où les articles sont importés ou leur statut est modifié par programmation (par exemple, via WP-CLI ou un script de migration), le hook publish_post se déclenchera pour chaque article importé, inondant potentiellement vos abonnés de dizaines de notifications en quelques secondes. Désactivez le push automatique avant d’exécuter des importations en masse :

wp option update webpushr_auto_push 0

Réactivez-le après la fin de l’importation.

Push manuel depuis l’éditeur d’articles

Pour un contrôle granulaire, désactivez le push automatique globalement et utilisez la méta-boîte Webpushr par article dans l’éditeur d’articles. Cette méta-boîte apparaît sous l’éditeur de contenu principal et expose les contrôles suivants :

• Envoyer une notification push : Une case à cocher qui, lorsqu’elle est cochée, met en file d’attente une notification lors de la publication ou de la mise à jour.
• Titre de notification personnalisé : Remplacez le titre de l’article par un titre plus accrocheur pour la notification.
• Message de notification personnalisé : Remplacez l’extrait généré automatiquement.
• URL de notification personnalisée : Redirigez les abonnés vers une page de destination spécifique plutôt que vers le permalien de l’article — utile pour les campagnes promotionnelles.
• Icône de notification personnalisée : Remplacez l’icône du site par défaut par une image spécifique à la campagne.

Anatomie de la charge utile d’une notification

Une charge utile de notification push web comprend :

• title — affiché en gras en haut de la notification.
• body — le texte descriptif sous le titre.
• icon — une image carrée (192×192 px recommandé) affichée à côté de la notification.
• image — une grande image bannière affichée sous le corps sur les plateformes prises en charge (Chrome sur Android, Chrome sur Windows).
• badge — une petite icône monochrome affichée dans la barre d’état Android.
• url — l’URL de destination lorsque l’utilisateur clique sur la notification.
• actions — jusqu’à deux boutons d’action avec des libellés et des URL personnalisés (pris en charge sur Chrome et Edge).

Garder le title sous 50 caractères et le body sous 120 caractères évite la troncature sur la plupart des plateformes.

Étape 6 : Tester les notifications push de bout en bout

Tester dans la même session de navigateur où vous êtes connecté à WordPress ne vous donnera pas une image précise de l’expérience de l’abonné. Utilisez un profil de navigateur séparé ou une fenêtre de navigation privée :

1. Ouvrez votre site web dans une fenêtre privée/de navigation privée.
2. L’invite de pré-permission devrait apparaître après votre délai configuré.
3. Cliquez sur l’appel à l’action de l’invite, puis cliquez sur Autoriser dans la boîte de dialogue de permission native du navigateur.
4. Retournez dans votre tableau de bord WordPress et publiez un article de test, ou utilisez le bouton Envoyer une notification de test dans le tableau de bord Webpushr.
5. Vérifiez que la notification apparaît avec le titre, le corps, l’icône corrects et que le fait de cliquer dessus vous redirige vers la bonne URL.

Modes d’échec courants lors des tests :

• La notification n’apparaît pas : Vérifiez que les notifications du navigateur ne sont pas bloquées au niveau du système d’exploitation (Windows Focus Assist, macOS Ne pas déranger, canaux de notification Android).
• Le service worker ne s’enregistre pas : Ouvrez DevTools > Application > Service Workers et confirmez que webpushr-sw.js est répertorié comme actif. S’il apparaît comme « en attente », un autre service worker bloque l’activation.
• L’icône ne se charge pas : L’URL de l’icône doit être absolue (commençant par https://) et l’image doit être servie avec des en-têtes CORS permissifs si elle est hébergée sur un CDN.

Étape 7 : Fonctionnalités avancées — Segmentation, planification et déclencheurs

Segmentation de l’audience

Le moteur de segmentation de Webpushr vous permet de taguer les abonnés en fonction de :

• Segments basés sur l’URL : Taguez automatiquement les abonnés qui visitent des URL spécifiques ou des modèles d’URL (par exemple, tous les utilisateurs qui visitent /category/security/ sont tagués security-readers).
• Attributs personnalisés : Transmettez des paires clé-valeur arbitraires via le SDK JavaScript pour créer des segments basés sur les propriétés utilisateur que votre application suit déjà.
• Segments d’engagement : Webpushr suit automatiquement les horodatages de dernière visite, vous permettant de créer des campagnes de réengagement ciblant les abonnés qui n’ont pas reçu de notification depuis plus de 30 jours.

La segmentation nécessite un plan payant et est configurée dans le tableau de bord Webpushr sous Segments.

Notifications planifiées

La planification vous permet de composer une notification maintenant et de la livrer à une date et une heure futures, avec prise en charge des fuseaux horaires. C’est particulièrement utile pour :

• Les promotions urgentes avec une date limite fixe.
• Le contenu publié en dehors des heures de pointe que vous souhaitez livrer pendant les fenêtres d’engagement élevé.
• Les notifications de résumé récurrentes (par exemple, les récapitulatifs hebdomadaires).

Notifications basées sur des déclencheurs personnalisés

Les déclencheurs personnalisés envoient des notifications basées sur des événements JavaScript sur votre site. Par exemple, vous pouvez envoyer une notification 24 heures après qu’un utilisateur a abandonné un panier d’achat, ou lorsqu’un utilisateur atteint une profondeur de défilement spécifique. Les déclencheurs sont configurés via le SDK JavaScript Webpushr et nécessitent un travail de développement personnalisé au-delà des capacités par défaut du plugin WordPress.

Tests A/B du contenu des notifications

Sur les plans payants, Webpushr prend en charge les tests fractionnés des titres et du corps des notifications entre les segments d’abonnés. Exécutez des tests A/B pour déterminer quel message génère des taux de clics plus élevés avant de lancer une campagne complète.

Étape 8 : Surveiller les analyses des abonnés

Le tableau de bord Webpushr fournit les métriques suivantes :

• Total des abonnés : Nombre de points de terminaison actifs, désabonnés et expirés.
• Taux de livraison : Pourcentage de notifications envoyées qui ont été livrées avec succès au service push du navigateur (FCM pour Chrome/Edge, Mozilla Autopush pour Firefox).
• Taux de clics (CTR) : Pourcentage de notifications livrées ayant entraîné un clic.
• Croissance des abonnements dans le temps : Tendances d’acquisition d’abonnés quotidiennes et hebdomadaires.

Note technique importante sur « livré » vs « reçu » : Une notification est marquée comme livrée lorsque le service push du navigateur (par exemple, FCM de Google) accepte la charge utile. Si l’appareil de l’utilisateur est hors ligne, FCM met la notification en file d’attente et la livre lorsque l’appareil se reconnecte — mais uniquement dans la fenêtre TTL (Time to Live) que vous configurez. Le TTL par défaut est de 28 jours. Pour les notifications urgentes, définissez un TTL plus court pour éviter de livrer du contenu obsolète.

Matrice de compatibilité des plateformes et navigateurs

« Prise en charge complète » signifie que le Web Push Protocol, les service workers et les actions de notification sont tous pris en charge. Les utilisateurs iOS sur des sessions de navigateur standard restent hors de portée du push web, ce qui représente un écart d’audience significatif pour les sites à forte fréquentation mobile.

Considérations relatives à l’infrastructure d’hébergement

La livraison des notifications push web est largement gérée par des services push tiers (FCM, Mozilla Autopush), donc le débit brut de votre serveur n’est pas un goulot d’étranglement pour la livraison. Cependant, votre environnement d’hébergement affecte :

• Vitesse de service du service worker : Le fichier webpushr-sw.js doit être récupéré rapidement à chaque chargement de page pour que les navigateurs vérifient que le service worker est à jour. Un serveur lent augmente le Time to First Byte (TTFB) pour ce fichier.
• Temps de réponse de l’API : Lorsqu’un nouvel article est publié, le plugin effectue un appel API synchrone vers Webpushr. Sur un hébergement mutualisé avec des limites de connexions sortantes restrictives, cet appel peut expirer et échouer silencieusement.
• Fiabilité des webhooks : Si vous configurez des webhooks Webpushr pour notifier votre serveur des événements d’abonnement, votre serveur doit accepter de manière fiable les requêtes POST entrantes.

Exécuter WordPress sur un VPS avec cPanel vous donne le contrôle pour ajuster les délais d’exécution PHP, configurer les règles de pare-feu sortantes et surveiller la livraison des service workers sans les restrictions des environnements mutualisés. Pour les sites à fort trafic où les campagnes de notifications push génèrent des pics de trafic simultanés importants, un Serveur Dédié garantit que votre origine peut absorber la charge de clics résultante sans limitation.

Pour les équipes gérant plusieurs propriétés WordPress, l’Hébergement E-mail associé à Webpushr crée une stratégie de réengagement sur deux canaux — le push pour l’immédiateté, l’e-mail pour la profondeur.

Matrice de décision technique : quand utiliser Webpushr plutôt que les alternatives

Le niveau gratuit de Webpushr est plus limité que celui de OneSignal, mais son implémentation de service worker est nettement plus propre et moins sujette aux conflits avec d’autres plugins WordPress — un avantage pratique sur les installations WordPress complexes.

Liste de contrôle pratique avant la mise en ligne

• HTTPS est actif et le certificat SSL est valide et non auto-signé.
• Le service worker webpushr-sw.js est accessible à https://yourdomain.com/webpushr-sw.js et retourne un statut 200.
• Le fichier service worker est exclu des règles de cache de votre plugin de mise en cache.
• Le délai de l’invite d’abonnement est défini à au moins 5 secondes ou une page vue.
• Le push automatique est désactivé si vous exécutez des importations en masse planifiées ou des migrations de contenu.
• Une notification de test a été reçue de bout en bout dans une session de navigateur propre.
• Les dimensions de l’icône de notification sont de 192×192 px et l’URL est en HTTPS absolu.
• Le TTL est configuré de manière appropriée en fonction de la sensibilité temporelle de votre contenu.
• La base de référence des analyses est enregistrée avant votre première campagne afin d’avoir un point de comparaison significatif.
• La politique de confidentialité/RGPD est mise à jour pour divulguer la collecte de données des notifications push.

FAQ

Webpushr fonctionne-t-il sans HTTPS ?

Non. La Web Push API et les service workers sont limités aux origines sécurisées par la spécification du navigateur. Tout site fonctionnant en HTTP ne peut pas enregistrer un service worker et ne peut donc pas envoyer ou recevoir de notifications push web. Un certificat SSL est une exigence technique stricte, pas une bonne pratique optionnelle.

Pourquoi mes notifications push ne sont-elles pas livrées à certains abonnés ?

Les causes les plus courantes sont : l’appareil de l’abonné était hors ligne au-delà de la fenêtre TTL de la notification ; l’utilisateur a révoqué les permissions de notification au niveau du navigateur ou du système d’exploitation ; ou le point de terminaison du service push du navigateur (FCM, Mozilla Autopush) a retourné un enregistrement expiré ou invalide. Le tableau de bord Webpushr marque ces cas comme des livraisons « échouées » et supprime automatiquement les points de terminaison qui retournent une réponse 410 Gone, ce qui est le comportement correct selon la spécification du Web Push Protocol.

Puis-je envoyer des notifications push aux utilisateurs iOS ?

Depuis iOS 16.4, le push web est pris en charge uniquement pour les Progressive Web Apps (PWA) qui ont été ajoutées à l’écran d’accueil. Les utilisateurs naviguant sur votre site dans Safari ou tout autre navigateur iOS sans l’ajouter à leur écran d’accueil ne recevront pas de notifications push web. Il s’agit d’une restriction au niveau de la plateforme imposée par Apple, pas d’une limitation de Webpushr.

Le service worker Webpushr entrera-t-il en conflit avec mon PWA existant ou mon plugin de mise en cache ?

C’est possible. Un seul service worker peut contrôler une portée donnée à la fois. Si un plugin PWA (par exemple, Super PWA) ou un autre service push a déjà enregistré un service worker à la portée racine, le service worker de Webpushr se mettra en file d’attente dans un état « en attente » et ne s’activera jamais. La résolution consiste à utiliser un service worker qui importe les deux scripts, ou à choisir un seul fournisseur de push et à désactiver les autres. Vérifiez chrome://serviceworker-internals/ pour auditer tous les workers enregistrés sur votre domaine.

La désactivation du plugin Webpushr désabonne-t-elle mes abonnés existants ?

Non. La désactivation du plugin supprime le SDK JavaScript de votre front-end, ce qui empêche les nouveaux abonnements et arrête les notifications automatiques. Cependant, les enregistrements de points de terminaison push existants restent valides dans le navigateur jusqu’à ce que l’utilisateur révoque explicitement la permission ou que le point de terminaison expire. Si vous réactivez le plugin avec la même clé API, ces abonnés seront à nouveau accessibles immédiatement.