Tous les autres canaux vous pardonnent. Un e-mail ignoré reste dans une boîte de réception. Un message in-app qui a raté son moment est fermé puis oublié. Une notification push qui agace quelqu'un fait couper le canal entier, définitivement, d'un simple geste, sur un écran du système d'exploitation où votre produit n'a pas son mot à dire et pas de seconde chance.
Toute la discipline tient dans cette asymétrie. Le push n'est pas une version plus bruyante de vos autres messages : c'est un petit budget d'interruptions, non renouvelable, que l'utilisateur vous a confié, et votre travail consiste à ne le dépenser que pour ce qui méritait vraiment une interruption.
Ce guide explique comment fonctionne réellement l'autorisation, la règle d'aiguillage qui sépare le push des messages in-app, à quoi ressemble un message sur lequel on tape, à quelle fréquence vous pouvez envoyer, ce qu'il faut mesurer, et les schémas d'échec qui tuent discrètement un programme push bien avant que quiconque ne s'en aperçoive.
Points clés
- L'autorisation ne se demande qu'une fois. Un utilisateur qui refuse la fenêtre système est quasiment perdu pour ce canal : préparez la demande avant de la déclencher.
- La règle d'aiguillage : si le message peut attendre la prochaine session, ce n'est pas un push. C'est un message in-app ou un élément du fil de notifications.
- Le déclenché bat le planifié. Un message envoyé au moment où quelque chose est devenu vrai est pertinent par construction.
- Plafonnez la fréquence par utilisateur, pas par campagne. L'utilisateur subit le total, pas votre organisation en campagnes.
- Des catégories valent mieux qu'un interrupteur unique. Celui qui peut couper un type de notification ne les coupera pas toutes.
- Le taux de désinscription est le vrai KPI. Le taux de clic mesure le message ; la désinscription mesure les dégâts.
Ce qu'est vraiment une notification push
Notification push : définition
Une notification push est un message affiché par le système d'exploitation en dehors de votre produit (sur l'écran de verrouillage, dans le centre de notifications ou sous forme de bannière sur ordinateur) et délivré que votre application soit ouverte ou non. Sur mobile, elle transite par le service push de la plateforme ; sur le web, elle nécessite un service worker et une autorisation explicite. Ce qui la définit, c'est son modèle d'autorisation, pas son format : accordée une fois, révocable d'un simple geste, et rarement reconsidérée.
Deux conséquences découlent de cette définition, et la plupart des erreurs en matière de push viennent de ce qu'on ne les prend pas au sérieux :
Le destinataire est en réunion, dans le train ou endormi. Rien dans ce moment ne vous appartient, et c'est pourquoi la pertinence doit venir d'un événement, pas d'un calendrier.
Les utilisateurs ne répondent pas « merci d'arrêter ». Ils désactivent les notifications, et vous perdez tous les messages futurs, y compris ceux qui sont vraiment urgents. Il n'existe aucun parcours de récupération pour cela.
Push ou message in-app : la décision d'aiguillage
La plupart des équipes n'ont pas un problème de push. Elles ont un problème d'aiguillage : des messages qui avaient leur place dans le produit ont été envoyés en push parce que le push semblait plus important. La distinction est simple, et elle tient même sous pression.
Seul le quadrant en haut à gauche justifie de dépenser l'autorisation.
La moitié in-app de ce schéma, c'est là que se trouve en réalité l'essentiel des messages d'un SaaS, et nous la détaillons dans nos guides consacrés aux messages in-app et aux notifications in-app et fils de notifications. Le push est le canal étroit du haut ; il doit le rester.
Le test qui met fin aux débats : ce message justifierait-il qu'un collègue vienne taper sur l'épaule du destinataire ? Si ce n'est pas le cas, il ne justifie pas non plus une interruption sur l'écran de verrouillage, aussi important qu'il paraisse dans le calendrier des campagnes.
Le problème de l'autorisation : mériter l'opt-in
Tout ce qui suit dépend d'une seule boîte de dialogue que vous ne pouvez pas personnaliser, pas tester en A/B et, en pratique, pas afficher deux fois. La demander au premier lancement, avant que l'utilisateur ne sache ce que fait votre produit (et encore moins ce que vous allez lui envoyer), est le réglage par défaut le plus coûteux de toute la catégorie.
Le schéma qui fonctionne est un opt-in en deux temps : d'abord votre propre message, puis la fenêtre système uniquement pour ceux qui ont déjà dit oui.
L'étape de préparation est répétable et gratuite. La fenêtre système n'est ni l'un ni l'autre.
Trois détails font fonctionner l'étape de préparation :
-
Demandez à un moment qui prouve la valeur
Juste après que l'utilisateur a fait quelque chose dont il voudra connaître le résultat : lancer une tâche longue, configurer une alerte, inviter un collègue. La demande s'explique d'elle-même, et c'est le seul argument qui fonctionne de façon fiable.
-
Dites exactement ce que vous enverrez
« Nous vous préviendrons quand un export sera terminé » obtient un oui. « Activez les notifications pour rester informé » obtient un non, car l'utilisateur y lit, à juste titre, la permission de lui envoyer n'importe quoi, pour toujours.
-
Proposez des catégories, pas un interrupteur unique
Alertes, mentions, nouveautés produit. Celui qui peut couper la catégorie bruyante garde la catégorie utile. Un interrupteur tout ou rien transforme une seule mauvaise campagne en perte totale.
Les messages de préparation sont de simples messages in-app déclenchés par le comportement, c'est-à-dire la même mécanique que les déclencheurs d'onboarding ; la seule différence, c'est ce à quoi mène le oui.
L'étape de préparation se joue dans le produit, là où vous maîtrisez la formulation et pouvez redemander plus tard.
Anatomie d'un push sur lequel on tape
Une notification push se lit en une seconde environ, sur un écran de verrouillage, tronquée. La contrainte est si forte que la structure est presque imposée :
| Élément | Rôle | Règle empirique |
|---|---|---|
| Titre | Dire ce qui s'est passé | Placez le sujet en tête. Considérez que tout ce qui dépasse une quarantaine de caractères est invisible. |
| Corps | Ajouter le détail qui décide s'il faut agir maintenant | Qui, quoi, combien. Pas une deuxième phrase pour convaincre. |
| Lien profond | Mener à l'élément concerné, pas à l'écran d'accueil | Un tap qui atterrit sur un tableau de bord a gâché la notification. |
| Actions | Permettre de terminer sans ouvrir l'application | Valider, reporter, marquer comme lu, seulement quand l'action tient vraiment en une étape. |
✅ Comme ceci
- « Dana a validé votre demande de budget »
- « Export prêt : 4 812 lignes »
- « Échec de la synchro de nuit à 02:14 »
- « 3 personnes ont répondu à votre commentaire »
❌ Pas comme cela
- « Vous avez une nouvelle notification »
- « Ne manquez pas les nouveautés de la semaine ! »
- « 👋 Ça fait longtemps, vous revenez ? »
- « Information importante concernant votre compte » (sans rien d'important)
Remarquez ce que les exemples de gauche ont en commun : chacun nomme une chose précise qui a changé. Tout le savoir-faire est là. Une notification est un fait, pas un argumentaire, la même discipline qui distingue une microcopie UX utile du remplissage.
Timing, fréquence et heures de silence
Le plus gros gain possible en push ne vient pas du texte. Il vient du passage des campagnes planifiées aux déclencheurs événementiels : envoyer parce que quelque chose est devenu vrai, et non parce qu'on est mardi.
- Déclenchez sur l'événement. Une tâche terminée, une mention, un seuil franchi, une validation en attente. La pertinence est structurelle, pas éditoriale.
- Utilisez le fuseau horaire du destinataire. Pas celui de vos bureaux. Un envoi planifié qui respecte l'heure locale n'est pas le même message que le même envoi à 3 heures du matin.
- Respectez des heures de silence. Les envois nocturnes génèrent des désinscriptions, pas des ouvertures, et pour ce qui est vraiment urgent, l'utilisateur a généralement déjà configuré une alerte.
- Plafonnez par utilisateur, pas par campagne. Trois campagnes qui « n'envoient que deux fois par semaine » chacune, cela fait six interruptions pour la personne qui les reçoit.
- Regroupez ce qui peut l'être. Cinq commentaires sur un même document, c'est une notification, pas cinq. Le regroupement est la bienveillance la moins chère du canal.
- En B2B, privilégiez les heures de bureau. Les benchmarks grand public sur les pics de soirée ne s'appliquent pas à un logiciel que l'on utilise au travail.
Une correction structurelle vaut mieux qu'une douzaine d'expériences d'optimisation : un plafond de fréquence appliqué par utilisateur sur l'ensemble des campagnes, avec une seule personne responsable. Sans lui, chaque équipe optimise son propre calendrier d'envoi et l'utilisateur subit la somme, que personne ne mesure.
Ce qu'il faut mesurer
Par défaut, les statistiques push affichent des chiffres flatteurs. Voici ceux qui vous apprennent vraiment quelque chose :
Part des utilisateurs éligibles qui ont accordé l'autorisation, ventilée selon l'endroit où vous l'avez demandée. C'est là que la préparation fait ses preuves, et c'est le plafond de tout le reste.
Autorisations accordées moins les révocations, désinstallations et jetons expirés. L'écart entre « abonnés » et utilisateurs réellement joignables est généralement bien plus grand que ce que les équipes imaginent.
Par type de notification, jamais en moyenne globale. Une seule alerte transactionnelle peut porter la moyenne de tout un programme alors que chaque campagne en dessous est ignorée.
Le tap a-t-il mené à l'action que la notification annonçait ? Un fort taux de clic vers une impasse est un pire résultat que d'être ignoré.
Le chiffre le plus important du push, et celui qui manque le plus souvent au tableau de bord. Suivez-le par campagne et par semaine, en regard du volume.
Le chiffre que le destinataire vit réellement. Des envois en hausse pour des résultats stables, c'est la signature d'un canal en train de brûler.
Lisez-les avec le reste de votre vision de l'engagement plutôt que dans un tableau de bord réservé au push ; le cadre présenté dans notre guide sur les indicateurs d'engagement utilisateur s'applique directement, et le cas de la réactivation a ses propres subtilités, détaillées dans reconquérir les utilisateurs inactifs.
Six façons dont les programmes push meurent
-
Demander au premier lancement
L'autorisation est dépensée avant que le produit ait démontré quoi que ce soit. Tout ce qui suit est plafonné par cette unique décision, et elle ne se rejoue pas.
-
Traiter le push comme un canal marketing
Les calendriers de campagne génèrent des envois qu'il se soit passé quelque chose ou non. Le canal glisse de « quelque chose que vous devez savoir » à « quelque chose que nous voulons vous montrer », et les utilisateurs réagissent en conséquence.
-
Personne ne pilote la fréquence
Trois équipes qui envoient chacune « juste une ou deux par semaine » produisent un flux que personne n'a conçu. La fréquence doit être plafonnée de façon centralisée, par utilisateur, sinon elle ne l'est pas.
-
Des préférences tout ou rien
Sans catégories, une seule campagne hors sujet vous coûte toutes les futures notifications à cet utilisateur, y compris les notifications transactionnelles sur lesquelles il compte vraiment.
-
Des liens profonds qui ne mènent nulle part
Taper sur « Dana a validé votre demande » et arriver sur un écran d'accueil apprend à l'utilisateur que taper n'en vaut pas la peine. C'est le moyen le plus rapide d'habituer toute une population à vous ignorer.
-
Ne jamais mesurer les désinscriptions
Le taux de clic figure dans le reporting ; les mises en sourdine et les révocations, non. Le programme paraît stable jusqu'au jour où l'audience joignable a discrètement fondu de moitié, et à ce stade il n'est plus récupérable.
Bien faire la moitié in-app
Appliquez honnêtement la matrice d'aiguillage et la plupart de vos messages quittent le push : annonces de fonctionnalités, guidage d'onboarding, conseils, enquêtes, entrées de changelog, incitations à terminer une configuration inachevée. Ils ont leur place là où l'utilisateur travaille déjà, et ce sont les messages qui font le plus pour l'adoption, car ils arrivent avec l'interface dont ils parlent directement à l'écran.
C'est la moitié que couvre Kompassify : annonces in-app, infobulles, checklists et enquêtes, ciblées par segment et par comportement, conçues dans un éditeur visuel plutôt que dans une mise en production. Y compris le message de préparation qui permet d'obtenir l'autorisation push, et les annonces de fonctionnalités qui n'avaient jamais leur place sur un écran de verrouillage.
Tout ce qui peut attendre la prochaine session a sa place ici, pas sur un écran de verrouillage.
Envoyez moins, touchez plus juste
Kompassify permet aux équipes produit, onboarding et customer success de gérer la moitié in-app : annonces, guides, checklists et enquêtes, ciblés par segment, avec des données d'adoption pour chacun et sans ticket pour l'équipe technique. Gratuit jusqu'à 100 utilisateurs actifs mensuels, offres à partir de 129 $/mois, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →En une phrase
Le push est une autorisation limitée : préparez-la avant de la demander, ne la dépensez que pour des messages à la fois urgents et personnels, plafonnez la fréquence par utilisateur plutôt que par campagne, et envoyez tout le reste en in-app, là où le message arrive avec le contexte qui le rend utile.
Questions fréquentes
Qu'est-ce qu'une notification push ?
Une notification push est un message affiché par le système d'exploitation en dehors de votre produit (sur l'écran de verrouillage, dans le centre de notifications ou sous forme de bannière sur ordinateur), délivré que l'application soit ouverte ou non. Sur mobile, elle transite par le service push de la plateforme ; sur le web, elle nécessite un service worker et une autorisation explicite. Ce qui la définit n'est pas son format mais son modèle d'autorisation : l'utilisateur l'accorde une fois, peut la révoquer définitivement d'un simple geste et revient rarement sur sa décision. C'est ce qui fait du push le seul canal de messagerie où un mauvais mois vous coûte le canal lui-même, et pas seulement un message ignoré.
Quelle est la différence entre une notification push et un message in-app ?
Le push atteint les utilisateurs qui ne sont pas dans votre produit ; le message in-app atteint ceux qui y sont. Cette seule différence détermine tout le reste. Le push interrompt la journée de quelqu'un : il doit donc valoir cette interruption et porter sur quelque chose d'urgent ou de personnel, comme une validation en attente, une tâche terminée ou un compte en danger. Le message in-app arrive quand l'utilisateur est déjà en contexte : il peut donc se permettre d'expliquer, d'annoncer et de guider, et il ne coûte rien en autorisation. La règle d'aiguillage qui garde les équipes honnêtes : si le message peut attendre la prochaine session, ce n'est pas un push.
Comment augmenter le taux d'opt-in aux notifications push ?
Ne demandez pas l'autorisation au premier lancement. En pratique, la fenêtre d'autorisation du système ne peut s'afficher qu'une seule fois, et un utilisateur qui refuse est quasiment perdu pour ce canal. Préparez plutôt la demande : attendez un moment où les notifications servent clairement l'utilisateur, par exemple quand il vient d'inviter un collègue, de lancer une tâche longue ou de configurer une alerte. Affichez alors votre propre explication in-app de ce que vous enverrez exactement et à quelle fréquence, et ne déclenchez la fenêtre système que pour ceux qui y répondent oui. Proposez des catégories détaillées plutôt qu'un choix tout ou rien, et rendez les réglages faciles à trouver, car un utilisateur qui peut couper un type de notification ne les coupera pas toutes.
Quel est le meilleur moment pour envoyer une notification push ?
Le meilleur moment est celui où le message est devenu vrai, pas un créneau dans un calendrier. Les notifications déclenchées par un événement (le rapport est prêt, la validation est arrivée, le déploiement a échoué) font mieux que les campagnes planifiées, car elles sont pertinentes par construction. Quand vous planifiez malgré tout, respectez le fuseau horaire du destinataire plutôt que le vôtre, appliquez des heures de silence la nuit et plafonnez le nombre d'envois par utilisateur et par semaine plutôt que par campagne, puisque l'utilisateur subit le total, pas votre organisation en campagnes. Pour un logiciel B2B, les heures de bureau dans le fuseau du destinataire sont un bien meilleur choix par défaut que les pics de soirée cités dans les benchmarks grand public.
À partir de combien de notifications push est-ce trop ?
La réponse honnête dépend du produit plutôt que d'un chiffre universel, et elle se découvre dans les taux de désinscription au lieu de se fixer à l'avance. Suivez chaque semaine la part d'utilisateurs qui désactivent les notifications en regard du nombre d'envois qu'ils ont reçus, et vous verrez le point où la courbe s'infléchit. C'est votre plafond, et il est généralement plus bas que ce qu'espère le marketing. Deux règles structurelles aident davantage que n'importe quel chiffre : plafonner la fréquence par utilisateur plutôt que par campagne, et séparer les catégories pour que l'on puisse faire taire le type bruyant sans faire taire le type utile.
Les notifications push fonctionnent-elles pour un SaaS B2B ?
Pour un ensemble restreint de messages, oui : tout ce qui est réellement urgent et personnel, comme une validation qui bloque le travail de quelqu'un d'autre, une tâche en échec ou une alerte que l'utilisateur a lui-même configurée. Pour tout le reste, les produits B2B sont généralement mieux servis par les messages in-app et un fil de notifications, car pendant les heures de travail l'attention de l'utilisateur est déjà dans le produit et son budget d'interruptions est consommé par ses collègues, pas par vous. Les annonces de fonctionnalités, le guidage d'onboarding et la formation ne justifient presque jamais un push ; ils justifient un message affiché la prochaine fois que l'utilisateur est dans le produit, là où vous pouvez aussi lui montrer quoi faire ensuite.