Augmenter la valeur des notifications push Web grâce aux limites de débit

Rob Kochman
Rob Kochman

Publié le : 6 janvier 2026

À partir de ce mois-ci, Chrome commencera à déployer des limites de fréquence des messages de l'API Push pour les sites qui envoient de nombreuses notifications sans générer beaucoup d'engagement. Cet article explique ce changement et les sites susceptibles d'être concernés.

Le Web ouvert est une plate-forme puissante pour interagir avec les utilisateurs, et l'API Push a joué un rôle transformateur à cet égard. En association avec l'API Notifications, l'API Push permet aux sites d'envoyer des notifications en temps opportun, même lorsque le site Web n'est pas en cours d'exécution dans le navigateur. Cela permet d'établir un lien durable et précieux entre les utilisateurs et les sites qui leur tiennent le plus à cœur.

Cependant, comme c'est souvent le cas avec les technologies puissantes, il existe un risque d'utilisation abusive. Nous en avons tous fait l'expérience : un site Web qui nous bombarde de notifications non pertinentes ou inutiles. Cela peut être dû à des problèmes tels qu'un site Web qui modifie son comportement depuis que l'autorisation a été accordée ou un utilisateur qui s'est fait piéger et a accepté une demande d'autorisation. Ces notifications indésirables perturbent le workflow de l'utilisateur et peuvent entraîner une perception négative des notifications et du Web en général. Nous pensons que la puissance des notifications push doit s'accompagner d'une responsabilité de les utiliser à bon escient.

Notre engagement continu à améliorer l'expérience de notification

Nous avons travaillé dur pour donner plus de contrôle aux utilisateurs et lutter de front contre le spam de notifications. Dans Chrome 80, nous avons introduit des demandes d'autorisation de notification plus discrètes. Elles s'affichent de manière plus subtile pour les sites dont le taux d'acceptation est faible ou pour les utilisateurs qui bloquent fréquemment les demandes de notification. Plus récemment, pour Chrome sur Android, nous avons commencé à utiliser le machine learning sur l'appareil pour identifier les notifications potentiellement associées à du spam ou malveillantes, et avertir les utilisateurs. Cela permet de les protéger contre les tentatives d'hameçonnage et d'autres contenus dangereux, sans compromettre leur confidentialité. Nous révoquons également automatiquement les autorisations de notification des sites que la navigation sécurisée Google identifie comme ayant un comportement abusif. Enfin, en octobre, nous avons annoncé que Chrome supprimerait automatiquement l'autorisation de notification pour chaque utilisateur pour les sites avec lesquels il n'a pas interagi récemment. Ce ne sont là que quelques exemples de notre engagement continu à créer une expérience de notification plus sûre et plus agréable pour tous.

Une nouvelle couche : les limites de débit de l'API Push

Pour mieux protéger les utilisateurs de Chrome contre le volume excessif de notifications et pour s'assurer que les notifications restent un outil utile pour tous, nous allons introduire un mécanisme de limitation du débit pour l'API Push en fonction de l'engagement des utilisateurs. Notre objectif est de créer un Web plus performant, où les utilisateurs ont le contrôle et où les développeurs sont en mesure d'établir des liens significatifs. Cette modification vise à limiter les pratiques abusives en matière de notifications, sans affecter les sites Web légitimes.

Fonctionnement

Dans un premier temps, notre décision de limiter le débit d'un site sera basée sur trois facteurs clés, calculés quotidiennement :

  • Nombre de notifications push envoyées par un site par rapport au temps passé sur ce site.
  • Nombre d'invites d'autorisation affichées par durée passée sur le site.
  • Niveau d'engagement de l'utilisateur avec le site (basé sur le score d'engagement avec le site et le nombre de minutes au premier plan).

Lorsqu'un site est identifié comme envoyant un volume élevé de notifications avec très peu d'engagement utilisateur, nous le considérons comme perturbateur et limitons sa capacité à envoyer des messages à une valeur d'au moins 1 000 par minute. Les requêtes dépassant cette limite génèrent une réponse HTTP 429.

Pour empêcher les sites perturbateurs d'alterner rapidement entre un comportement perturbateur et non perturbateur, la logique de suppression de la limite de fréquence est plus complexe :

  • Après le premier jour de comportement perturbateur, la limite de fréquence s'appliquera pendant un jour.
  • Après le deuxième jour de comportement perturbateur, la limite de fréquence s'appliquera pendant sept jours.
  • À partir du troisième jour de comportement perturbateur, la limite de fréquence s'appliquera pendant 14 jours.
  • Le compteur sera réinitialisé après 42 jours consécutifs de comportement non perturbateur.

Bien que cela décrive notre approche initiale, les spécificités de ce calcul peuvent évoluer au fil du temps à mesure que l'écosystème évolue, afin de mieux servir à la fois les utilisateurs et la communauté des développeurs.

Cela aura-t-il un impact sur mon site ?

Il est important de souligner que cette modification n'affectera que l'API Push. Les sites pourront toujours envoyer des notifications lorsqu'ils sont ouverts à l'aide de l'API Notifications.

Ce changement n'aura pas d'impact sur la quasi-totalité des sites Web. Cette initiative s'adresse à un petit nombre de sites qui envoient un nombre excessif de notifications à faible valeur. Pour la communauté de développeurs au sens large qui s'efforce d'envoyer des notifications pertinentes, intéressantes et en temps opportun, ce changement permettra de préserver l'intégrité et l'efficacité de ce puissant canal de communication.

Nous pensons que cette étape est nécessaire pour assurer un avenir sain et durable aux notifications Web. En encourageant une approche plus réfléchie et axée sur l'utilisateur, nous pouvons collectivement créer une meilleure expérience de notification pour tous les utilisateurs du Web.