Le durcissement des notifications en 2026 : vos notifications push seront-elles toujours livrées ?

Au cours des dix-huit derniers mois, les plateformes ont cessé de demander aux expéditeurs de bien se comporter et ont commencé à l'appliquer. Chrome limite désormais le débit des sites qu'il classe comme perturbateurs et révoque silencieusement l'autorisation de notification des sites que les utilisateurs ignorent. Android 16 réduit par défaut le bruit des notifications, regroupe tout de force et, sur les Pixels les plus récents, classe les envois promotionnels dans un paquet silencieux et réduit. Google Messages plafonne le nombre de nouveaux utilisateurs qu'un expéditeur RCS de faible réputation peut atteindre. Si vous avez recherché « réglementation des notifications Chrome » ou « pourquoi mes notifications push ne sont pas délivrées », cette page est la référence : chaque changement, la source principale derrière, qui est touché et les solutions spécifiques qui garantissent la délivrance à l'expéditeur.

Ce document est évolutif. Nous le mettons à jour lorsqu'une plateforme publie ou annonce un changement, et chaque révision est consignée dans le journal des modifications en bas. Dernière mise à jour : 17 août 2026.

Une note de cadrage avant les détails, car elle explique chaque entrée du tableau ci-dessous. Aucune de ces plateformes ne supprime les notifications. Toutes divisent les notifications en deux classes : les envois à haut volume et à faible engagement sont limités, mis en silence, regroupés ou désabonnés — tandis que les notifications pertinentes et basées sur des événements conservent une livraison complète, et dans certains cas obtiennent un meilleur placement qu'auparavant. La répression ne porte pas sur le push. Elle porte sur le "blast".

Ce qui a changé : le calendrier de la réglementation des notifications de 2026

Plateforme	Changement	Qui est affecté	En vigueur	Source
Chrome (ordinateur + Android)	UI d'autorisation plus silencieuse : invite muette pour les utilisateurs qui bloquent habituellement et pour les sites ayant de faibles taux d'acceptation des invites ; étendue plus tard aux sites avec des invites ou du contenu trompeurs	Sites qui invitent dès la première page vue ou qui poussent du contenu trompeur	Chrome 80, février 2020 (application étendue jusqu'en 2020)	Blog Chromium
Safari / iOS	Web Push déclaratif : web push sans service worker, pas de pénalité de push silencieux pour les charges utiles déclaratives	Expéditeurs de web push ciblant les utilisateurs Apple	iOS/iPadOS 18.4 (mars 2025) ; Mac dans Safari 18.5 (mai 2025)	Blog WebKit
Chrome sur Android	Le ML sur l'appareil signale les notifications web push suspectes comme « potentiellement trompeuses ou indésirables » avec une désinscription en un clic	Expéditeurs dont le modèle de copie de notification correspond à du spam	Mai 2025	Blog Chromium
Android 16	Refroidissement des notifications (rafales progressivement réduites, activées par défaut) et regroupement forcé de toutes les notifications d'une application	Expéditeurs de notifications push d'applications à haute fréquence ; rafales de toute sorte	Stable 10 juin 2025	Android Authority ; notre analyse approfondie
Chrome (ordinateur + Android)	Révocation automatique des autorisations de notification via Safety Check pour les sites à faible engagement et à volume élevé	Sites envoyant beaucoup de notifications sur lesquelles les utilisateurs ne cliquent jamais	Annoncé le 10 oct. 2025 ; déploiement progressif	Blog Chromium
Google Messages	Regroupement des « expéditeurs inconnus » ; coches de vérification pour les entreprises et image de marque standardisée pour RCS	Les entreprises contactent les utilisateurs qui ne les ont pas enregistrées	À partir de mi-octobre 2025 (déploiement progressif)	Android Authority
Android 16 QPR2 (Pixel)	Organisateur de notifications : l'IA sur l'appareil classe par défaut les notifications de promotions et d'actualités dans un groupe silencieux et réduit ; résumés IA pour les conversations	Envoi de notifications push d'applications promotionnelles sur les Pixels actuels (6 pays, anglais)	Déc. 2025	9to5Google
Chrome (ordinateur + Android)	Limites de débit de l'API Push : les sites classés comme perturbateurs sont limités à 1 000 messages push/minute avec un code HTTP 429 au-delà ; échelle de pénalité de 1 → 7 → 14 jours	Expéditeurs à haut volume avec un faible engagement par utilisateur	Déploiement progressif à partir de janv. 2026	Chrome pour les développeurs
RCS pour les entreprises	Limites de trafic basées sur la réputation : plafonds d'utilisateurs uniques par période glissante de 28 jours pour les agents promotionnels à faible réputation (en vigueur en Inde ; les nouveaux agents commencent avec une faible réputation) ; analyses des tendances de spam et des raisons de désabonnement	Expéditeurs RCS promotionnels, en particulier les nouveaux agents	7 janv. / 16 févr. / 1er avr. 2026	Notes de publication RCS pour les entreprises

Maintenant le détail par plateforme, dans l'ordre où il apparaîtra sur votre tableau de bord.

Chrome : limites de débit, autorisations révoquées automatiquement et filtrage anti-spam par apprentissage automatique

Chrome est l'endroit où la plupart des équipes de rétention ressentent d'abord la répression, car le web push est le canal propriétaire le plus utilisé par la plupart des marques d'e-commerce. Trois mécanismes distincts sont maintenant en place, et ils se cumulent.

Limites de débit de l'API Push pour les sites « perturbateurs »

Depuis janvier 2026, Chrome évalue chaque jour chaque site selon trois facteurs : messages push envoyés par rapport au temps passé par les utilisateurs sur le site, invites d'autorisation affichées par rapport au temps passé sur le site, et le niveau d'engagement de l'utilisateur avec le site (score d'engagement du site plus minutes au premier plan). Un site qui échoue au test est classé comme perturbateur et limité à 1 000 messages push par minute. Tout ce qui dépasse le plafond reçoit une réponse HTTP 429 du service push.

La pénalité s'aggrave. Le premier jour perturbateur entraîne une limite de 1 jour. Un deuxième jour consécutif l'étend à 7 jours. À partir du troisième jour, la limite s'applique par périodes de 14 jours, et le compteur ne se réinitialise qu'après 42 jours consécutifs de comportement irréprochable. Google n'a pas publié de numéro de version de Chrome pour le déploiement ; le mécanisme est évalué côté serveur et est arrivé discrètement.

Faites le calcul par rapport à votre propre liste. À 1 000 messages par minute, un envoi à 500 000 abonnés prend plus de huit heures. Une notification de vente flash qui devait arriver en quinze minutes arrive maintenant sur une journée de travail complète, et la fenêtre de revenus qu'elle était censée toucher a disparu. C'est le coût réel : pas une interdiction, une érosion — vos revenus de panier récupéré et vos chiffres de clics vers revenus s'érodent tandis que votre tableau de bord de livraison indique toujours « envoyé ».

Notez la portée. La limite s'applique uniquement à l'API Push en arrière-plan ; les notifications déclenchées depuis un onglet ouvert via l'API Notifications ne sont pas affectées. Google présente cela en disant que « la quasi-totalité des sites web ne seront pas affectés » — la cible est le petit ensemble d'expéditeurs qui envoient un volume élevé à une audience qui a cessé de répondre. Savoir si vous faites partie de cet ensemble est une question mesurable, et l'auto-audit ci-dessous vous guide à travers cela.

Révocation automatique des autorisations

Le deuxième mécanisme supprime les abonnés que vous pensiez posséder. Annoncé le 10 octobre 2025, la vérification de sécurité de Chrome révoque automatiquement l'autorisation de notification des sites qui combinent un très faible engagement utilisateur avec un volume élevé de notifications envoyées — le même traitement qu'il appliquait déjà aux autorisations de caméra et de localisation inutilisées. L'équipe produit de Chrome a justifié cela par un chiffre : moins de 1 % de toutes les notifications reçoivent une quelconque interaction de la part des utilisateurs.

Les détails qui comptent pour un expéditeur :

• Les applications web installées sont exemptées. Un abonné qui a ajouté votre site à son écran d'accueil ou à son bureau conserve l'autorisation.
• L'utilisateur est informé lorsque Chrome supprime une autorisation, et peut la restaurer via la vérification de sécurité ou en revisitant votre site et en se réinscrivant.
• Google a rapporté que lors des tests, la surcharge de notifications a considérablement diminué avec « seulement un changement minime dans le nombre total de clics sur les notifications » — et que les sites envoyant des volumes plus faibles ont vu leurs taux de clics augmenter.

Relisez ce dernier point, car il résume toute la répression en une seule phrase. Les clics n'ont jamais été dans la queue de la liste. Les sites qui envoyaient moins gagnaient plus par envoi. Chrome applique désormais l'hygiène de liste que les expéditeurs performants pratiquaient déjà : votre segment inactif n'est plus un chiffre de vanité sur le compteur d'abonnés, c'est une responsabilité qui déclenche l'application.

Google n'a pas publié les seuils numériques pour « faible engagement » ou « volume élevé », donc aucun fournisseur ne peut vous promettre un plafond sûr. Ce que vous pouvez contrôler, c'est le ratio que le système mesure clairement : interactions par notification délivrée.

Filtrage ML sur l'appareil sous Android

Le troisième mécanisme, actif depuis mai 2025, place un modèle d'apprentissage automatique entre votre notification et les yeux de l'utilisateur. Chrome sur Android analyse le contenu des notifications push web entrantes sur l'appareil (les notifications push web sont chiffrées de bout en bout, donc l'analyse doit être locale — le modèle lit le titre, le corps et les libellés des boutons d'action). Les notifications qui correspondent à des schémas de tromperie ou de spam sont affichées avec un avertissement et une option de désabonnement en un clic.

Les habitudes de rédaction qui font échouer les classificateurs de spam sont celles sur lesquelles les expéditeurs de faible qualité s'appuient : fausse urgence, lacunes de clickbait, style trompeur de messages système. Si la copie de votre notification pouvait être confondue avec un modèle d'arnaque à un prix, sur certains téléphones, elle est désormais livrée avec une étiquette d'avertissement et une porte de sortie attachée.

Ce que l'historique de Chrome vous dit sur la suite

Rien de tout cela n'est un détournement. Chrome a mis en sourdine l'invite de permission pour les sites à faible acceptation en février 2020, puis a étendu l'application aux invites abusives et au contenu abusif plus tard la même année. La vague 2025-2026 déplace l'application du moment d'opt-in vers la relation d'envoi elle-même. La direction est à sens unique depuis six ans : chaque version rend l'engagement plus porteur. Prévoyez que les seuils se resserrent, pas qu'ils se relâchent.

Android 16 : délai, regroupement forcé et le bundle silencieux Promotions

Les changements d'Android affectent les notifications push des applications plutôt que le navigateur, et ils modifient ce que signifie « livré » plutôt que si la livraison a lieu.

Délai de notification, activé par défaut lorsque Android 16 est devenu stable le 10 juin 2025, cible les rafales. La première notification d'une rafale alerte à plein volume avec une bannière complète ; chaque notification suivante dans environ une minute est progressivement plus silencieuse et visuellement minimisée, et la rafale s'effondre sous une seule bannière. Les appels, les alarmes et les conversations prioritaires sont exemptés ; les notifications marketing et transactionnelles ne le sont pas. Rien n'est supprimé et les rapports de livraison ne bougent pas — c'est précisément pourquoi le changement est dangereux. Votre tableau de bord indique trois livrées ; le téléphone de l'utilisateur en a présenté une. Nous avons publié une analyse complète des mécanismes et des corrections de conception d'envoi dans notre guide du délai de notification Android 16.

Regroupement forcé supprime un choix que les développeurs avaient auparavant : Android 16 regroupe toutes les notifications de la même application, que l'application ait opté ou non. Combiné au délai, les deuxième et troisième notifications de toute séquence rapide sont maintenant silencieuses, des éléments de ligne regroupés plutôt que des bannières.

L'Organisateur de notifications est le plus pointu des trois. Déployé depuis décembre 2025 avec Android 16 QPR2 sur les téléphones des séries Pixel 9 et 10 (9to5Google), il utilise un modèle sur appareil pour classer les notifications en Promotions, Actualités, Social et Suggérées — et les catégories Promotions et Actualités sont activées par défaut, classant les notifications correspondantes dans un bundle regroupé dans la section silencieuse de l'ombre. Le déploiement est actuellement limité (récents Pixels, six pays, anglais), mais le défaut est important : sur les appareils que Google contrôle entièrement, une notification promotionnelle ne sonne plus, ne fait plus de bannière et reste repliée jusqu'à ce que l'utilisateur la recherche. Parallèlement, des résumés d'IA sur appareil compressent les notifications de conversation.

Le même cycle de système d'exploitation a également construit le canal opposé. Les notifications axées sur la progression d'Android 16 (le modèle Live Updates) offrent des événements en temps réel, suivis par l'utilisateur — une livraison en cours, un statut de commande — avec un placement persistant et élevé. Les versions 2026 de Google ont continué à étendre ce canal de contenu en direct, bien que les détails de ce qui sera expédié au-delà d'Android 16 soient encore en cours de définition et méritent d'être vérifiés par rapport aux notes de version actuelles d'Android avant de vous y fier. L'intention de conception est déjà sans ambiguïté : le contenu que l'utilisateur suit activement est promu ; le contenu que l'expéditeur veut que l'utilisateur remarque est organisé à l'écart.

Sous la couche du système d'exploitation, les plafonds de longue date par appareil de Firebase Cloud Messaging s'appliquent toujours — 240 messages par minute et 5 000 par heure vers un seul appareil, avec des expéditeurs soutenus près de la limite risquant un drapeau d'abus. Chaque système que votre entreprise exécute contre la même application partage ce budget.

iOS et Safari : un type de porte plus discret

L'histoire d'Apple en 2025-2026 est moins une répression qu'une ouverture contrôlée, car Apple a intégré ses portes dès le départ : le web push sur iOS a toujours nécessité que l'utilisateur ajoute d'abord votre site à son écran d'accueil (un filtre délibéré à haute intention, en place depuis iOS 16.4), et la politique de l'App Store a longtemps limité le marketing push.

Ce qui a changé :

• Web Push déclaratif a été expédié dans iOS/iPadOS 18.4 en mars 2025 et est arrivé sur Mac dans Safari 18.5 (WebKit). Il vous permet d'exécuter le web push à partir d'une charge utile JSON standardisée sans service worker, et il supprime la pénalité de push silencieux pour les messages déclaratifs car la charge utile elle-même garantit une notification visible. Le push de service worker hérité continue de fonctionner ; le format déclaratif est la voie que Apple souhaite que les expéditeurs empruntent.
• iOS 26 remplacerait par défaut les sites de l'écran d'accueil par l'ouverture en tant qu'applications web, ce qui élargit la surface sur laquelle le web push iOS peut s'exécuter. Nous n'avons vu cela documenté que de seconde main jusqu'à présent ; traitez-le comme directionnel jusqu'à ce que la documentation d'Apple soit explicite.
• La politique est inchangée et stricte. La ligne directrice 4.5.4 de l'examen des applications exige toujours que le push ne soit pas requis pour que votre application fonctionne, ne contienne aucune donnée personnelle sensible et — pour les promotions ou le marketing direct — ne soit envoyé qu'aux utilisateurs qui ont explicitement choisi de participer par le biais d'un langage de consentement dans l'interface utilisateur de votre application, avec une option de retrait dans l'application. L'abus « peut entraîner la révocation de vos privilèges ».

Pour une équipe de rétention, la leçon à retenir d'iOS est qu'Apple a pré-filtré votre public pour vous. Un abonné au web push iOS a choisi d'installer votre site ; un abonné au push d'application a choisi de s'inscrire au marketing. Les deux listes sont petites et à haute intention — ce qui signifie que les épuiser avec une fréquence de diffusion est plus coûteux par abonné qu'ailleurs.

RCS : les plafonds de réputation arrivent sur le nouveau canal

Si vous ajoutez RCS ou WhatsApp à votre offre — et pour la récupération de panier et les mises à jour de commande, vous devriez évaluer les canaux de messagerie — Google a déjà installé la couche d'application que le web push a mis six ans à obtenir.

Selon la documentation RCS pour les entreprises de Google, chaque expéditeur d'entreprise (agent) a une réputation — Élevée, Moyenne ou Faible — déterminée par les commentaires des utilisateurs et les rapports de spam, et tous les nouveaux agents commencent avec un statut Faible. La réputation définit une limite de trafic : le nombre d'utilisateurs uniques avec lesquels l'agent peut initier des conversations sur une période glissante de 28 jours. Les réponses aux conversations initiées par l'utilisateur sont exemptées. L'application est entrée en vigueur pour les agents promotionnels en Inde le 7 janvier 2026, a été renforcée le 1er avril 2026 avec un plafond inter-agents pour les expéditeurs à faible réputation, et la console développeur signale désormais le niveau de réputation, la limite de trafic, la tendance du spam et les raisons de désabonnement sur des fenêtres de 7 et 28 jours.

Du côté du consommateur, Google Messages regroupe les messages des expéditeurs non enregistrés sous « Expéditeurs inconnus » depuis mi-octobre 2025 et déploie des coches de vérification et une image de marque d'entreprise standardisée — des preuves issues d'un démontage sur certains détails, mais la direction correspond à tout le reste de ce document. Sur RCS, vous n'avez pas de période de grâce pour prendre de mauvaises habitudes : la portée s'acquiert par l'engagement dès le premier message.

Êtes-vous à risque ? L'auto-audit {#self-audit}

Chrome et Google publient les facteurs mais pas les seuils, donc l'audit honnête est relatif : mesurez si vous ressemblez à l'expéditeur que ces systèmes ont été conçus pour arrêter. Exécutez ces huit vérifications sur vos envois des 30 derniers jours. Chaque « non » est une constatation. Plusieurs de ces vérifications n'ont de sens que par rapport aux numéros externes, alors exécutez-les en parallèle de nos benchmarks de notifications push 2026, où les répartitions en percentiles pour le taux de visualisation et le taux de clics vous montrent ce que le taux médian, p75 et p90 des expéditeurs atteignent réellement.

1. Ratio d'interaction. Votre taux de clics sur le web push est-il significativement supérieur à la base de référence d'interaction de moins de 1 % de l'écosystème que Chrome a citée lorsqu'il a justifié la révocation automatique ? Si votre CTR a un zéro après la virgule, vous êtes dans le profil que Chrome applique.
2. Volume vs. visites. Le premier facteur de site perturbateur de Chrome est le nombre de notifications push envoyées par temps passé sur le site. Envoyez-vous plus de notifications à un abonné type par semaine que cet abonné n'a de sessions avec vous par semaine ? Un abonné qui visite mensuellement et reçoit des notifications quotidiennement échoue à ce ratio.
3. Queue inactive. Quelle part de votre liste n'a cliqué sur aucune notification depuis 90 jours ? Si plus de la moitié de vos envois vont à cette queue, votre taux d'engagement global est déterminé par des personnes qui sont déjà parties — et les plateformes notent l'ensemble.
4. Discipline des invites. Demandez-vous la permission de notification dès la première vue de page, avant que le visiteur n'ait rien fait ? Le taux d'acceptation des invites est à la fois un critère d'inscription d'interface utilisateur discrète et un facteur de perturbation du site. Inviter après une action démontrée (deuxième vue de page, ajout au panier, création de compte) est la solution, et cela se reflète directement dans votre taux d'opt-in.
5. Partage massif. Quel pourcentage de votre volume d'envoi mensuel correspond à des envois de masse non ciblés à toute la liste, par rapport aux notifications déclenchées par quelque chose que le destinataire a fait (panier abandonné, prix baissé, article de retour en stock, commande expédiée) ? Au-dessus d'environ la moitié d'envois de masse, vous êtes lourd en volume exactement dans le schéma que chaque mécanisme de cette page pénalise.
6. Limites de fréquence et heures de silence. Appliquez-vous un plafond par abonné sur toutes les campagnes et tous les systèmes qui peuvent envoyer — marketing, transactionnel, RSS et tout autre outil ? Le refroidissement et le regroupement forcé d'Android signifient que les expéditeurs non coordonnés se cannibalisent désormais visiblement sur le même appareil.
7. Honnêteté de la copie. Une notification récente survivrait-elle au test « est-ce trompeur ? » d'un lecteur sceptique — pas d'urgence feinte, pas de déguisement en message système, pas d'appâts ? Le classificateur sur appareil de Chrome exécute déjà ce test sur Android.
8. Tendance de désabonnement. Votre taux de désabonnement par envoi est-il stable ou en baisse ? Sur RCS, il alimente désormais un score de réputation avec un plafond de trafic strict attaché ; sur les notifications push web, c'est votre premier avertissement. Notre guide pour réduire les taux de désabonnement aux notifications push couvre le diagnostic en profondeur.

Évaluez-vous honnêtement. Cinq réponses ou plus claires et la répression est principalement un vent arrière pour vous — les envois en « spray and pray » de vos concurrents sont limités tandis que vos envois continuent d'atterrir. Trois conclusions ou plus et vous devriez supposer que vous perdez déjà une portée que vous ne pouvez pas voir dans un rapport de livraison.

Le manuel de conformité : des correctifs qui tiennent

Chaque mécanisme ci-dessus mesure la même quantité sous-jacente — valeur par notification — donc les correctifs convergent. Ces six mouvements, par ordre de priorité.

1. Coupez la queue inactive avant que les plateformes ne le fassent pour vous. Créez un segment de clients inactifs (pas de clic en 90 jours), exécutez une séquence de reconquête honnête, puis arrêtez d'envoyer aux non-répondants. C'est contre-intuitif pour les équipes qui considèrent la taille de la liste comme l'indicateur clé de performance, mais les mathématiques sont unidirectionnelles maintenant : un abonné dormant ne contribue aucun revenu et dégrade activement le ratio d'engagement sur lequel Chrome vous évalue. Dans PushEngage, la segmentation dynamique maintient le compartiment des inactifs automatiquement, et comme la tarification ne compte que les abonnés actifs, la suppression du poids mort réduit votre facture plutôt que votre portée.

2. Déplacez le volume d'envoi des diffusions vers les déclencheurs. Une notification d'abandon de panier, une alerte de baisse de prix, un avis de réapprovisionnement — ceux-ci génèrent des clics car le comportement du destinataire les a planifiés. Déplacer même la moitié de votre volume mensuel des diffusions basées sur le calendrier vers des campagnes déclenchées augmente votre ratio d'interaction sur chaque facteur mesuré par Chrome, et c'est là que se trouvaient les revenus de toute façon : les envois déclenchés sont attribués aux paniers récupérés et aux commandes complétées, pas aux impressions. Nous avons développé l'argument complet, avec les définitions de classes de campagne et les calculs de revenus par envoi, dans pourquoi l'ère de la diffusion de masse est terminée.

3. Segmentez tout ce qui est encore diffusé. Certains envois sont légitimement larges — une vente dans tout le magasin, une actualité urgente d'un éditeur. Large ne signifie pas non segmenté. Diviser une diffusion par comportement, historique d'achat ou affinité de catégorie augmente les clics sur chaque tranche et maintient le ratio de notifications push par visite de chaque abonné défendable. La segmentation est maintenant une exigence de délivrabilité, pas une simple personnalisation — cet article présente l'argument complet en faveur de la délivrabilité.

4. Appliquez un seul plafond de fréquence sur tous les canaux et systèmes. Le ralentissement d'Android 16 l'a rendu concret : votre CRM, votre couche transactionnelle et votre calendrier promotionnel partagent un seul budget d'attention sur l'appareil, qu'ils partagent ou non un tableau de bord. Définissez un plafond par abonné et des heures de silence au niveau de la plateforme, couvrant le push web, le push d'application et WhatsApp ensemble, afin que quatre systèmes raisonnables ne puissent pas se combiner en un seul schéma abusif. Cela ne fonctionne que si un seul moteur de segmentation voit chaque envoi — l'argument pratique le plus solide pour consolider les canaux plutôt que d'exécuter un outil par canal.

5. Corrigez le moment de l'opt-in. Déplacez l'invite de permission derrière une action qui signale une intention, utilisez une invite en deux étapes afin que la demande au niveau du navigateur ne se déclenche qu'en cas de oui, et acceptez une liste plus petite et plus propre. Le taux d'acceptation des invites alimente le score de Chrome aux deux extrémités — l'inscription via une interface utilisateur discrète et l'évaluation du site perturbateur — et une liste consentie est également simplement la liste qui clique.

6. Faites en sorte que la copie survive à un classificateur. Affirmations simples, urgence réelle uniquement lorsque la date limite est réelle, identité de l'expéditeur évidente. Sur Android, un modèle ML lit votre titre et votre corps avant l'utilisateur. Une copie honnête a toujours été une meilleure pratique de rétention ; maintenant, c'est aussi une exigence de livraison.

Si vous exécutez ces six points sur PushEngage, le résumé honnête de l'aide apportée par le produit : les campagnes déclenchées, les segments RFM et comportementaux, les plafonds de fréquence inter-canaux, les heures de silence et l'attribution des revenus par notification sont tous intégrés, sur des plans qui facturent uniquement les abonnés actifs — le modèle de tarification pointe d'ailleurs dans la même direction que les plateformes imposent désormais. Ce qu'aucun outil ne peut faire, c'est décider d'arrêter les diffusions ; cette partie relève de la politique, et elle est la vôtre.

FAQ

Pourquoi mes notifications push ne sont-elles pas délivrées en 2026 ? Vérifiez quatre suspects dans l'ordre. Premièrement, la révocation automatique de Chrome : si le nombre de vos abonnés diminue silencieusement, les abonnés à faible engagement perdent peut-être l'autorisation via Safety Check. Deuxièmement, les limites de débit de Chrome : si les envois vers de grandes listes prennent soudainement des heures ou si votre service push enregistre des réponses HTTP 429, vous avez probablement été classé comme perturbateur. Troisièmement, la présentation Android : sur Android 16, la livraison se produit toujours mais les rafales sont atténuées et regroupées, et sur les nouveaux Pixel, les envois promotionnels atterrissent dans un paquet silencieux — livrés, non vus. Quatrièmement, les causes ennuyeuses qui précèdent la répression : abonnements expirés, erreurs de service worker et paramètres de notification au niveau du système d'exploitation.

Chrome a-t-il interdit les notifications push ? Non. Chrome limite les sites qu'il classe comme perturbateurs (volume élevé, faible engagement) et révoque les autorisations que les utilisateurs ignorent de manière démontrable. Un expéditeur dont les notifications sont cliquées n'est affecté par aucun de ces mécanismes, et les tests de Google ont révélé que les expéditeurs à plus faible volume voyaient leurs taux de clics augmenter.

Quel taux d'engagement me protège de la révocation automatique de Chrome ? Google n'a pas publié de seuils, et tout fournisseur qui vous donne un chiffre sûr fait des suppositions. Les faits publiés : moins de 1 % de toutes les notifications reçoivent une interaction, et la révocation cible la combinaison d'un très faible engagement avec un volume d'envoi élevé. La stratégie défendable est de maintenir votre taux de clics bien au-delà de cette base et d'arrêter d'envoyer aux abonnés qui ont cessé de répondre.

Les limites de débit de Chrome affectent-elles tout mon compte ou juste un site ? Le langage d'évaluation de Chrome est par site — les messages, les invites et l'engagement sont tous mesurés par rapport à « un site ». Les expéditeurs utilisant une plateforme push sont évalués sur le comportement de leur propre domaine, pas sur l'agrégat de leur fournisseur. Google n'a pas publié de directives au-delà de cela, alors traitez les spécificités inter-domaines comme non confirmées.

Qu'est-ce qui a changé pour les notifications push dans Android 16 ? Trois choses : le refroidissement des notifications (les rafales sont progressivement atténuées pendant une minute, activées par défaut, appels et alarmes exemptés), le regroupement forcé des notifications de chaque application, et — à partir de la mise à jour QPR2 de décembre 2025 sur les Pixel récents — le Notification Organizer, qui classe par défaut les notifications de promotions et d'actualités dans un paquet silencieux et réduit. Mécanismes complets dans notre guide de refroidissement Android 16.

La répression s'applique-t-elle à iOS ? Les contraintes d'Apple les précèdent pour la plupart : le web push iOS exige que l'utilisateur ajoute votre site à son écran d'accueil, et la directive 4.5.4 de l'App Store exige un opt-in explicite plus un opt-out dans l'application pour le marketing push. Le changement de 2025 est Declarative Web Push (iOS 18.4 / Safari 18.5), un format plus simple, sans service worker, sans pénalité de push silencieux pour les messages déclaratifs.

Les messages RCS professionnels sont-ils également soumis à des limites de débit ? Oui, par réputation. Google attribue à chaque agent professionnel RCS une réputation Élevée/Moyenne/Faible basée sur les commentaires des utilisateurs et les signalements de spam ; les agents à faible réputation (y compris tous les nouveaux agents) sont soumis à des plafonds d’utilisateurs uniques initiés sur une période glissante de 28 jours. L’application est en vigueur pour les agents promotionnels en Inde depuis début 2026, avec des rapports sur la réputation et les tendances de spam dans la console développeur pour tous.

Les notifications push web en valent-elles toujours la peine en 2026 ? Pour les expéditeurs qui déclenchent et segmentent, plus qu’avant : le trafic limité de type « spray-and-pray » servait à concurrencer le même panneau de notifications que vous. Les plateformes renforcent le canal pour les expéditeurs pour lesquels le canal a été conçu — et repoussent les autres.

Dernière mise à jour et journal des modifications {#changelog}

Ce hub est maintenu comme une référence vivante. Convention : la date de « Dernière mise à jour » change uniquement pour les mises à jour de fond (une plateforme qui expédie, annonce ou documente un changement), pas pour les modifications de copie. Chaque mise à jour de fond obtient une ligne de journal des modifications avec une source. Si vous citez cette page, citez-la avec sa date de dernière mise à jour.

• 2026-09-21 — Publication initiale. Couvre : limites de débit de l’API Push de Chrome (janvier 2026), révocation automatique des autorisations par Chrome (annoncé en octobre 2025), filtrage des notifications par ML sur appareil de Chrome (mai 2025), délai de 16 jours + regroupement forcé d’Android (juin 2025), organisateur de notifications QPR2 d’Android 16 (décembre 2025), Web Push déclaratif (iOS 18.4 / Safari 18.5, 2025), limites de trafic basées sur la réputation RCS et analyses des tendances de spam (janvier-avril 2026), changements de messages inconnus et de marque vérifiée de Google Messages (à partir d’octobre 2025).

Quelque chose a changé et que nous n’avons pas enregistré ? Le moyen le plus rapide de nous le signaler est le widget de chat sur cette page.