Passer au contenu principal

​
Exigences du push web

Votre site web doit répondre à toutes les conditions suivantes pour que le push web fonctionne : API de navigateur requises Sécurité et connexion
  • ✅ HTTPS uniquement (avec certificat SSL valide)
  • ✅ Service worker OneSignal installé
  • ✅ Le navigateur doit atteindre :
    • Serveurs push du navigateur (par ex., FCM, Mozilla)
    • api.onesignal.com
État de l’utilisateur
  • ✅ Autorisation de notification accordée par l’utilisateur
  • ❌ Pas en mode Incognito/Privé/Invité
  • ❌ Données du site non effacées (supprime les abonnements)
L’effacement des données du navigateur (cookies, stockage du site) désabonne automatiquement les utilisateurs des notifications push.

​
Exigences iOS/iPadOS

Pour recevoir des push sur iOS ou iPadOS :
  • iOS 16.4+ ou iPadOS 16.4+
  • Le site doit être ajouté à l’écran d’accueil et ouvert depuis là
  • Fichier manifest.json valide avec les champs requis
  • Les utilisateurs doivent accepter les autorisations de notification après ouverture en tant qu’application web

Configuration du push web iOS

Suivez les étapes spécifiques à Apple pour activer le push web sur les iPhones et iPads exécutant iOS 16.4+.

​
Support des navigateurs et plateformes

​
Compatibilité des navigateurs par système d’exploitation

NavigateurPC WindowsmacOSAndroidiOS (iPhone, iPad)
Chrome 50+OuiOuiOuiOui ¹
Firefox 47+OuiOuiOuiOui ¹
Safari 10+NonOuiNonOui ¹
Microsoft Edge 18+ ²OuiOuiOuiOui ¹
Opera ²OuiOuiOuiOui ¹
Samsung Internet ²NonNonOuiOui ¹
Yandex ²OuiOuiOuiOui ¹
UC Browser ²OuiNonOuiOui ¹
Internet Explorer ³NonNonNonNon
DuckDuckGoNonNonNonNon
  • ¹ iOS nécessite l’installation de l’application web (voir les exigences de configuration du push web iOS ci-dessus)
  • ² Les navigateurs basés sur Chromium apparaissent comme “Chrome” dans les analyses OneSignal
  • ³ Internet Explorer est déprécié et ne reçoit plus de mises à jour
Le mode Incognito, le mode de navigation privée et le mode de navigateur invité ne prennent pas en charge le push web sur aucune plateforme.

​
Changements de domaine et migration

​
Comprendre la politique d’origine du navigateur

Les navigateurs lient les abonnements push web à une origine spécifique (domaine/URL du site) pour des raisons de sécurité. Vous ne pouvez pas transférer les abonnés entre différentes origines - c’est une limitation du navigateur, pas une restriction OneSignal. Les origines différentes incluent :
  • HTTP vs HTTPS (par ex., http://monsite.com → https://monsite.com)
  • www vs non-www (par ex., www.monsite.com vs monsite.com)
  • Différents domaines/sous-domaines (par ex., domaine1.com vs domaine2.com ou sous1.domaine.com vs sous2.domaine.com)

​
Options de migration

Lors du changement de l’origine de votre site, choisissez l’une de ces approches :
  • Nouvelle application OneSignal (recommandé)
  • Mettre à jour l'application et supprimer les anciens abonnés
Idéal pour : La plupart des changements de domaine, surtout lorsque vous voulez une migration propre
  1. Créez une nouvelle application OneSignal pour votre nouveau domaine
  2. Stratégie de double envoi : Continuez à envoyer depuis l’ancienne application, mais définissez “URL de lancement” vers votre nouveau domaine
  3. Transition graduelle :
    • Expéditeurs haute fréquence (1+ notification/jour) : 2 semaines de transition
    • Expéditeurs moyenne fréquence (2+ notifications/semaine) : 2 mois de transition
  4. Notifications de migration : Envoyez 1-2 messages comme “Nous avons déménagé ! Visitez notre nouveau site pour rester informé” au début et à la fin de la transition
L’envoi de messages identiques depuis les deux applications créera des notifications en double pour les utilisateurs abonnés aux deux.

​
Mise à niveau HTTP vers HTTPS

La mise à niveau de HTTP vers HTTPS crée une nouvelle origine. Suivez les étapes de migration de domaine ci-dessus car les navigateurs traitent les sites HTTPS comme complètement séparés de leurs versions HTTP.

​
Sites multiples et sous-domaines

​
Limitations d’une seule application

En raison de la politique de même origine du navigateur, vous ne pouvez pas utiliser une seule application OneSignal pour plusieurs origines comme :
  • https://monsite.com et https://www.monsite.com
  • https://principal.com et https://boutique.principal.com

​
Solutions pour plusieurs origines

  • Stratégie d'origine unique
  • Applications séparées
  • Abonnez les utilisateurs uniquement sur votre domaine principal
  • Redirigez les utilisateurs d’autres origines vers le domaine principal pour l’abonnement
  • Redirigez vers la page d’origine après l’abonnement

​
Scénarios de support linguistique

  • Même origine (recommandé)
  • Origines différentes

​
Configuration avancée

​
Plusieurs applications OneSignal sur le même site

  • Non recommandé - cause des conflits d’abonnement.
  • Ce qui se passe : OneSignal réabonne automatiquement les utilisateurs à l’ID d’application le plus récemment visité, causant un rebond des abonnés entre les applications et créant de nombreux appareils désabonnés.
  • Meilleure approche : Utilisez Tags de données pour segmenter les utilisateurs au sein d’une seule application.

​
Sites dans des sous-dossiers

Le push web fonctionne au niveau de l’origine. Pour les sites dans des sous-dossiers (par ex., https://exemple.com/blog), utilisez l’origine principale (https://exemple.com) pour la configuration.

​
Auto-hébergement des fichiers SDK

Fortement déconseillé. Les spécifications du push navigateur changent fréquemment, et OneSignal met à jour les fichiers immédiatement pour maintenir la compatibilité. Utilisez plutôt les URL CDN de OneSignal depuis vos paramètres Push Web.

​
Code d’initialisation personnalisé

Le code init personnalisé ne fonctionne qu’avec la configuration de code personnalisé. Utilisateurs de configuration typique ou de créateur de site web : Le code init personnalisé sera ignoré par le SDK OneSignal. Si vous devez retarder l’initialisation, utilisez les méthodes de confidentialité.

​
Développement et tests

​
Tests d’environnement local

Consultez Configuration du SDK Web > Tests locaux pour la configuration complète des tests locaux.

​
Intégration du service worker

OneSignal peut fonctionner aux côtés de service workers et PWA existants. Consultez Intégration de plusieurs Service Workers pour les détails d’implémentation.

​
Spam push

Les notifications push ne sont pas conçues pour être utilisées pour des publicités, le spam des utilisateurs ou des campagnes trompeuses. Si votre application est détectée comme envoyant des notifications spam, les navigateurs peuvent envoyer à vos utilisateurs une notification “Avertissement de spam”. Évitez d’envoyer des notifications qui :
  • Ne sont pas pertinentes pour les utilisateurs
  • Utilisent des mots comme “Publicités” ou renvoient vers une page qui n’est pas liée à l’application
  • Ne proviennent pas d’une source de confiance (par ex. une marque avec laquelle vous n’êtes pas associé)
Consultez Combattre les notifications indésirables avec l’apprentissage automatique dans Chrome pour plus d’informations.
Si votre application est signalée comme spam, vous pouvez :
  • Examiner le contenu de vos notifications et supprimer tout ce qui peut être considéré comme du spam. Cela inclut :
    • Les mots “Publicités” ou “Pub” dans le titre ou le corps
    • Les liens vers des pages qui ne sont pas liées à l’application
    • Les liens vers des pages qui ne proviennent pas d’une source de confiance (par ex. une marque avec laquelle vous n’êtes pas associé)
  • Continuer à envoyer et surveiller les rapports supplémentaires.

​
Dépannage

​
Timing de déploiement des mises à jour

  • Fichiers Service Worker : Cache de 24 heures
  • SDK Web : Cache de 3 jours
Planifiez en conséquence lors du déploiement de mises à jour critiques.

​
Problèmes de notification Chrome macOS

Pour les utilisateurs Chrome sur macOS, assurez-vous que les notifications sont activées pour les deux :
  1. L’application Google Chrome (Menu Apple > Réglages > Notifications)
  2. L’application Google Chrome Helper
Sans les deux activés, les notifications n’apparaîtront pas dans le centre de notifications.

​
Étapes suivantes après la configuration

  1. Testez minutieusement sur vos navigateurs et appareils pris en charge
  2. Implémentez une gestion appropriée des erreurs pour les demandes d’autorisation
  3. Configurez les analyses pour surveiller les taux d’abonnement
  4. Planifiez votre stratégie de notification pour éviter la fatigue des utilisateurs
  5. Envisagez les tests A/B pour le timing et la messagerie de vos demandes d’autorisation

​
Pièges courants de migration

  • L’effacement des données du navigateur désabonne automatiquement les utilisateurs
  • Notifications en double pendant les transitions à double application
  • iOS nécessite l’installation de l’application web avant que le push fonctionne
  • Les modes privé/incognito ne prennent jamais en charge les notifications push
  • Les service workers doivent être accessibles à la racine de votre site ou dans un sous-répertoire configuré

​
Étapes suivantes