Fréquence des notifications push : combien un site d’info doit-il en envoyer ?

La réponse honnête, c’est que cela dépend, et la partie utile, c’est de quoi cela dépend.

Il n’existe pas de chiffre publiable pour la fréquence à laquelle un site d’information devrait envoyer des notifications push. Quiconque vous cite « deux à cinq par jour pour les éditeurs » répète un blog de fournisseur sans échantillon nommé, ou fait la moyenne de sites qui n’ont rien en commun avec le vôtre. Ce qui existe, et sur quoi vous pouvez agir dès aujourd’hui, c’est un plafond que le navigateur impose, un budget que vos lecteurs détiennent, et un seuil défini par ce que vaut réellement chaque envoi.

Deux fréquences qu’on confond

Presque toutes les discussions stériles sur la fréquence du push viennent de la confusion entre ces deux-là.

Une rédaction qui envoie 20 fois par jour mais où un lecteur type en reçoit deux est un produit complètement différent de celle qui en envoie quatre et où chaque lecteur reçoit les quatre. La seconde est plus agressive, et le nombre d’envois dans le tableau de bord dit le contraire.

La question « à quelle fréquence devons-nous envoyer » est donc en réalité deux questions, et seule la seconde a une réponse en termes de fatigue. Fixez d’abord le chiffre par abonné. La fréquence du site devient alors une question éditoriale et de ciblage, plutôt qu’une question de confiance de l’audience.

Le plafond que Chrome impose vraiment

Cette partie n’est pas une opinion, ni une prévision. C’est en vigueur depuis janvier 2026.

Chrome a commencé à déployer des limites de débit sur la Push API pour les sites qui envoient beaucoup de notifications avec peu d’engagement sur le site. Un site jugé perturbateur est limité à pas moins de 1 000 messages par minute, et les requêtes au-delà reçoivent un HTTP 429. Les facteurs quotidiens que Chrome nomme sont les messages push rapportés au temps passé sur le site, les demandes d’autorisation rapportées au temps passé sur le site, et l’engagement, mesuré par le score d’engagement du site et les minutes au premier plan. L’escalade va d’un jour à sept jours, puis à quatorze, et l’état se réinitialise après 42 jours consécutifs sans perturbation. Cela s’applique uniquement à la Push API, pas à la Notifications API. Chrome indique que la quasi-totalité des sites ne sera pas touchée.

Par ailleurs, depuis octobre 2025, Chrome retire automatiquement l’autorisation de notifications aux sites avec lesquels une personne n’a pas interagi récemment, lorsque l’engagement est très bas et le volume de notifications élevé. Chrome en informe la personne, qui peut redonner l’autorisation dans Safety Check ou sur le site, ou désactiver la révocation automatique. Les applications web installées ne sont pas concernées. Desktop et Android.

Deux conséquences en découlent, et toutes deux changent la façon de penser le chiffre.

D’abord, la mesure appliquée est un ratio, pas un nombre. Messages push par temps passé sur le site. Demandes d’autorisation par temps passé sur le site. Un site dont les lecteurs restent et reviennent a plus de marge qu’un site avec le même nombre d’envois et aucun engagement, ce qui veut dire que « combien par jour » est la mauvaise unité et que « combien par unité d’attention méritée » est la bonne.

Ensuite, l’application se fait par site, mais la révocation automatique se fait par personne. Une fréquence acceptable en moyenne peut quand même retirer discrètement l’autorisation au tiers le moins engagé de votre liste.

Vous ne pouvez pas calculer votre position par rapport au seuil de Chrome. Le score interne n’est pas publié, et le modéliser relève de la devinette. Fixez votre propre plafond bien en deçà du leur et arrêtez de chercher la limite.

Pourquoi cette page n’a pas de tableau de benchmarks par secteur

Je pourrais mettre ici un tableau avec une ligne par secteur et un chiffre plausible dans chaque case. Il serait bien référencé. Il serait aussi inventé.

Nous ne publions des faits sur les navigateurs et le marché qu’à partir d’un registre de sources daté, avec une source primaire, et il n’existe aucune source approuvée pour « les sites d’info envoient X notifications par jour ». Les blogs de fournisseurs qui publient des taux d’opt-in et des fréquences d’envoi par pays ne nomment pas de dénominateur, ne décrivent pas d’échantillon, et mesurent surtout leur propre base de clients. Les instantanés de détection de technologies vous disent quels sites utilisent une plateforme push, pas à quelle fréquence ces sites envoient.

Cette page vous donne donc une méthode plutôt qu’un chiffre, et le résultat qu’elle produit est le vôtre. Tout chiffre que nous publions vient avec sa méthode et sa source à côté, tirées du registre.

Une méthode pour trouver votre chiffre

1. Partir du plafond par abonné

Choisissez un maximum qu’une seule personne peut recevoir par jour et par semaine. Choisissez-le délibérément, écrivez-le, et faites-en la contrainte dans laquelle tout le reste s’inscrit. Si la rédaction proteste, c’est que le chiffre fait son travail.

2. Fixer un seuil de valeur avant de fixer un nombre

Certains envois ne devraient partir à aucune fréquence. Définissez ce qu’un article doit franchir avant de devenir un Nudge : un seuil de confiance sur le contenu, une règle par type d’article, ce que votre desk acceptera. Un plafond qui a encore de la marge n’est pas une consigne de le remplir.

3. Séparer explicitement la routine de l’urgent

Les envois de routine restent dans le plafond, respectent les heures calmes et sautent les abonnés dormants. Les envois urgents peuvent dépasser le plafond par une dérogation nommée et journalisée. Si la dérogation n’est pas journalisée, tout devient urgent en moins d’un mois. Je l’ai vu arriver.

4. Piloter à la qualité par envoi, pas au nombre d’envois par jour

Le chiffre qui mérite d’être affiché au mur, c’est ce qu’un envoi coûte et rapporte, pas combien vous en avez fait.

Une version utilisable : pour chaque envoi, prenez les interactions pour 1 000 livraisons, et soustrayez les désabonnements et les endpoints invalides pour 1 000 livraisons. Vous obtenez un chiffre net par envoi qui baisse quand vous poussez un article faible à une large audience, ce qui est exactement le comportement que la mesure doit sanctionner. C’est notre méthode, pas un standard du secteur. Changez les pondérations si votre économie est différente, mais gardez la soustraction, parce qu’une mesure sans terme de coût plaidera toujours pour envoyer davantage.

5. Avancer d’un pas à la fois, puis tenir

Changez le plafond par abonné d’une unité, tenez-le deux à quatre semaines, et observez le mouvement net de la liste : nouvelles autorisations accordées, moins les désabonnements, moins les endpoints invalides. Une seule variable, assez longtemps pour voir la liste réagir. Les expériences de fréquence qui durent quatre jours mesurent le cycle de l’actualité, pas votre politique.

La partie propre aux éditeurs

Chaque journaliste veut que son article soit poussé. Ce n’est pas un défaut de la rédaction, c’est la rédaction qui fonctionne correctement, et chaque demande prise isolément est raisonnable.

Le problème, c’est que la personne responsable de l’audience argumente contre une pile de demandes raisonnables une à une, et que le seul chiffre dans la pièce est le nombre de clics du dernier envoi. Les clics plaident toujours pour envoyer davantage. Rien dans le tableau de bord standard ne montre ce que l’envoi a coûté en abonnés, donc la retenue arrive avec une opinion et perd.

C’est l’argument pour tenir un registre par envoi avant même de changer la moindre politique. Clics, désabonnements, endpoints invalides et mouvement net de la liste sur la semaine, une ligne par envoi. Le débat devient de l’arithmétique, et l’arithmétique est bien plus facile à gagner.

Limites et réserves sur les navigateurs

• Les limites de débit de Chrome s’appliquent à la Push API, pas à la Notifications API, et Chrome indique que la quasi-totalité des sites n’est pas touchée. Ne vous en servez pas pour faire peur à quelqu’un afin d’imposer un chiffre.
• Les plateformes d’Apple diffèrent. Declarative Web Push est arrivé avec Safari 18.4 le 31 mars 2025 pour les applications web ajoutées à l’écran d’accueil sur iOS et iPadOS. La tolérance à la fréquence et les signaux que vous récupérez ne sont pas identiques à ceux de Chrome.
• La répartition des navigateurs change ce que tout cela signifie pour vous. StatCounter a indiqué, pour juillet 2026, des parts de navigateurs dans le monde de 68,22 % pour Chrome et 16,47 % pour Safari ; en Europe, Chrome 60,71 % et Safari 18,67 % ; en Suède, Chrome 57,37 % et Safari 24,75 %. Une politique de fréquence réglée sur le comportement de Chrome couvre une part différente de votre liste selon les marchés.
• Aucun chiffre de cette page n’est une mesure d’EngageNudge. La méthode est la nôtre, les faits sur les navigateurs viennent de Chrome et de WebKit, et les chiffres de parts viennent de StatCounter, tous datés ci-dessus.

Comment EngageNudge gère la fréquence

Dans EngageNudge, la fréquence est une politique que l’envoi doit passer, pas un champ de la campagne. Plafonds quotidiens et hebdomadaires par abonné, espacement minimum entre les Nudges, heures calmes, règles de dormance et filtre des envois à faible valeur sont évalués avant la livraison, et un Nudge qui ne les passe pas est écarté, avec la raison enregistrée.

Les groupes témoins se trouvent en dessous, pour que la question « l’envoi supplémentaire a-t-il vraiment fait revenir quelqu’un » ait une réponse qui ne soit pas le nombre de clics.