Ouvrez presque n'importe quel produit B2B : en haut à droite, une cloche avec un chiffre rouge. Cliquez dessus et vous trouvez le commentaire d'un collègue, quatre messages de statut automatiques, une promotion pour une offre à laquelle vous êtes déjà abonné, et quelque chose qui date de mars. Le chiffre disparaît. Vous n'avez rien appris. La semaine suivante, le chiffre est revenu, et plus personne ne regarde.
Les notifications in-app font partie des rares surfaces produit capables de tomber à une valeur nulle tout en paraissant parfaitement saines sur un tableau de bord. Le flux est toujours ouvert, parce que le badge l'exige. Le badge est toujours vidé, parce qu'il agace. Aucun de ces deux faits ne prouve que quelqu'un a lu quoi que ce soit.
Ce guide porte spécifiquement sur la couche de notifications : la partie persistante, adressée et consultée à l'initiative de l'utilisateur de votre communication in-app. Les messages diffusés qui interrompent (modales, bandeaux, panneaux coulissants, infobulles) forment un autre système, avec d'autres règles, traité dans notre guide de la messagerie in-app. Savoir lequel des deux vous construisez, c'est déjà résoudre l'essentiel du problème de conception.
À retenir
- Les notifications sont adressées et persistantes ; les messages sont diffusés et interruptifs. C'est le mélange des deux qui détruit le flux.
- Quatre catégories ont leur place dans un flux : personnelle, workflow, système et nouveautés produit pertinentes. Tout le reste, c'est du marketing déguisé en cloche.
- Le badge est une promesse. Un chiffre qui ne revient jamais à zéro apprend aux utilisateurs à l'ignorer pour de bon.
- Regroupez par objet ou par jour. Cinq événements sur le même document font une notification, pas cinq.
- Rédigez acteur–action–objet, faites de tout l'élément un lien vers la destination exacte et affichez un horodatage relatif.
- Le taux de désactivation est la métrique honnête. Le taux de clic reste correct jusqu'au moment où les gens coupent la catégorie.
Ce que sont vraiment les notifications in-app
La notification in-app en un paragraphe
Une notification in-app est un message transmis à l'intérieur de votre produit à un utilisateur précis, à propos de quelque chose qui s'est produit ou qui demande son attention. Elle se trouve normalement dans un centre de notifications persistant, ouvert depuis une icône de cloche, porte un état lu/non lu et reste disponible jusqu'à ce que l'utilisateur la traite. Ses propriétés déterminantes : elle est adressée, elle concerne cette personne, et persistante : elle attend au lieu d'interrompre, et c'est l'utilisateur qui choisit quand regarder.
Trois surfaces sont sans cesse confondues, et la distinction n'a rien de théorique : elle détermine où une communication doit vivre et quelles règles s'y appliquent.
| Notification in-app | Message in-app | Notification push | |
|---|---|---|---|
| Audience | Un utilisateur, adressée personnellement | Un segment, diffusé | Un utilisateur, hors du produit |
| Livraison | Attend dans un flux, l'utilisateur va la chercher | Apparaît à l'écran, interrompt | Au niveau du système, autorisation requise |
| Durée de vie | Persistante jusqu'à lecture ou suppression | Affiché une fois, puis disparaît | Éphémère, souvent manquée |
| Usage typique | Commentaire, validation, tâche terminée, nouveauté pertinente | Étape d'onboarding, annonce, incitation | Faire revenir un utilisateur inactif |
| Risque principal | Devenir du bruit que personne ne lit | Interrompre au mauvais moment | Autorisation refusée, ou désinstallation |
La règle d'aiguillage. Si l'utilisateur doit le voir maintenant pour que l'écran actuel ait du sens, c'est un message. S'il a besoin d'en garder une trace et peut agir plus tard, c'est une notification. Si ce n'est ni l'un ni l'autre, s'il s'agit de quelque chose que vous voulez qu'il sache plutôt que de quelque chose dont il a besoin, sa place est probablement dans votre changelog et nulle part ailleurs.
Deux modèles de livraison : interruption et boîte de réception
Tout système de notifications doit choisir, élément par élément, entre exiger l'attention tout de suite et attendre d'être trouvé. La plupart des produits se mettent en difficulté en appliquant l'un des deux par défaut à tout.
Interruption (poussée au premier plan)
- Toast, snackbar ou bandeau qui apparaît sur place
- Adapté à : ce qui vient de se produire suite à une action de l'utilisateur lui-même, ou ce qui est urgent
- Coût : l'attention, immédiatement et sans négociation
- Budget : quelques-unes par session avant que cela ne ressemble au chaos
Boîte de réception (attend dans le flux)
- Centre de notifications derrière une cloche, avec état lu et historique
- Adapté à : tout ce que l'utilisateur peut traiter plus tard, et tout ce qu'il voudra peut-être retrouver
- Coût : presque nul, jusqu'à ce que le flux perde sa crédibilité
- Budget : généreux, mais seulement tant que le taux de pertinence reste élevé
Un petit nombre d'éléments méritent les deux : une validation qui bloque le travail de quelqu'un d'autre, un paiement échoué, un export que l'utilisateur attend devant son écran. Le schéma qui fonctionne : un toast éphémère au moment de l'événement, plus une entrée permanente dans le flux, pour qu'un utilisateur qui a manqué le toast en garde une trace. Le schéma qui ne fonctionne pas : le toast seul, c'est-à-dire une notification que vous avez délibérément jetée.
L'anatomie d'un centre de notifications
Un flux qui garde la confiance des utilisateurs comporte sept éléments, et ceux que les équipes négligent sont systématiquement les trois derniers.
Quatre éléments, quatre catégories, un événement regroupé, et chaque ligne dit qui a fait quoi sur quel objet.
- Le point d'entrée et le badge. Une icône cohérente et facile à repérer, avec un état qui a un sens. Un nombre pour les éléments qui demandent une attention individuelle, un simple point pour tout le reste.
- Des éléments structurés. Acteur, action, objet, horodatage, et toute la ligne cliquable vers la destination exacte, pas vers un tableau de bord à partir duquel l'utilisateur doit ensuite naviguer.
- Un état lu qui tient. Le non-lu doit sauter aux yeux, les éléments lus doivent rester accessibles, et l'ouverture du panneau ne doit pas tout marquer comme lu en silence : c'est ainsi que les gens perdent des choses.
- Le regroupement. Cinq commentaires sur un document, c'est un élément qui se déplie, pas cinq lignes. Pour tout ce qui est collaboratif, regrouper par objet vaut mieux que regrouper par période.
- Des catégories ou des filtres. Au-delà d'environ trois types de notifications, les utilisateurs ont besoin de séparer « ce qui m'attend » de « ce qui s'est passé ».
- Un état vide qui n'est pas le néant. « Vous êtes à jour » accompagné d'un lien vers les préférences est un très bon état vide ; consultez notre guide des états vides pour le principe général.
- Un accès visible aux préférences. Les utilisateurs qui peuvent désactiver une catégorie ne désactivent pas tout. Le lien a sa place dans le panneau lui-même, pas trois niveaux plus bas dans les paramètres.
Ce qui a sa place dans le flux, et ce qui ne l'a pas
| Catégorie | Exemples | Doit-elle faire monter le badge ? |
|---|---|---|
| Personnelle | Mention, commentaire, réponse, partage, attribution | Oui, toujours |
| Workflow | Validation en attente, relecture demandée, échéance d'une tâche, passation | Oui, c'est la catégorie qui a le plus de valeur |
| Système | Export prêt, import échoué, intégration déconnectée, quota atteint | Seulement si une action est nécessaire |
| Nouveautés produit | Une nouvelle fonctionnalité dans le domaine où cet utilisateur travaille réellement | Rarement : un point, pas un nombre |
| Promotionnelle | Incitations à passer à l'offre supérieure, webinars, lancements sans rapport | Non, cela n'a rien à faire dans le flux |
C'est la quatrième ligne qui demande du discernement. Les nouveautés produit peuvent légitimement figurer dans un flux (c'est l'un des rares endroits où un utilisateur qui revient cherchera ce qui a changé), mais seulement si elles concernent cet utilisateur, et seulement comme élément de faible priorité. Dès que les annonces de version font monter un badge chiffré, le badge cesse de signifier « quelque chose a besoin de vous » pour signifier « nous avons publié quelque chose », et c'est le début de la fin. Notre méthode pour annoncer une nouvelle fonctionnalité explique comment orchestrer un lancement sur plusieurs surfaces, et notre guide des notes de version couvre la trace durable vers laquelle le flux doit renvoyer plutôt que la remplacer.
La dérive promotionnelle. Tous les flux surchargés en sont arrivés là de la même façon : une équipe sans rien à annoncer a remarqué que le centre de notifications avait de bons taux d'ouverture, et s'en est servie. Les taux d'ouverture sont une propriété du badge, pas du contenu ; ils tiennent pendant des mois pendant que la confiance s'effrite, et quand la métrique finit par bouger, les utilisateurs qui ont tout coupé ne reviennent pas. C'est le même mécanisme que la cécité aux bannières, appliqué à un composant que l'on ne peut pas simplement faire défiler.
Rédiger la notification
Le texte d'une notification a une mission particulièrement exigeante : il est lu en moins d'une seconde, hors contexte, à côté de neuf autres lignes. Trois règles font l'essentiel du travail.
1. Acteur, action, objet, dans cet ordre
L'utilisateur ne parcourt que les premiers mots. Placez-y la personne et le verbe, et nommez l'objet précis plutôt que son type.
2. Faites de tout l'élément un lien vers la destination exacte
Pas vers le module, pas vers une liste dans laquelle l'utilisateur doit ensuite chercher. Créez un lien profond vers le commentaire, la validation, le fichier. Une notification qui oblige à naviguer après le clic a reporté le travail sur l'utilisateur sans rien lui apporter.
3. Utilisez le vocabulaire de l'utilisateur, pas celui du système
Les noms d'objets internes s'infiltrent dans les modèles de notification plus vite que partout ailleurs dans un produit, parce que les notifications sont en général rédigées par la personne qui a développé l'événement. « Synchronisation des entités terminée » ne signifie rien pour la personne qui le lit. Notre guide de la microcopie UX détaille les techniques de réécriture ; le raccourci consiste à lire la ligne à voix haute et à se demander si un nouveau client la comprendrait.
Fréquence, regroupement et badge
Il n'existe pas de limite quotidienne universelle, car le volume tolérable dépend entièrement du taux de pertinence. Un flux où quatre éléments sur cinq méritent d'être ouverts peut tourner à plein régime ; un flux où trois sur quatre sont du bruit finit coupé à presque n'importe quel volume. Trois mécanismes maintiennent un bon ratio.
1. Regroupez par objet, puis par période
Cinq commentaires sur un document deviennent « 3 personnes ont commenté Plan d'onboarding T3 », dépliable. Un récapitulatif de tout ce qui s'est passé pendant l'absence de quelqu'un vaut mieux qu'un mur de lignes individuelles qu'il effacera sans les lire. Le regroupement est le changement le plus rentable que l'on puisse apporter à un flux trop bruyant.
2. Donnez à chaque catégorie sa propre règle de badge
Les éléments personnels et de workflow font monter le nombre. Les éléments système ne le font monter que si l'utilisateur doit agir. Les nouveautés produit ont droit à un point, au maximum. Posée sous forme de tableau, c'est une décision de cinq minutes qui évite la forme la plus courante de dégradation d'un flux.
3. Respectez le moment et le contexte de l'utilisateur
Les notifications générées par une action de l'utilisateur lui-même doivent apparaître immédiatement ; tout le reste peut attendre une pause naturelle. Si vous envoyez aussi un e-mail ou un push pour les mêmes événements, supprimez le doublon quand l'utilisateur est actif dans le produit : recevoir la même information de trois façons, c'est ainsi qu'un système utile devient irritant. Notre guide des déclencheurs présente les règles générales de timing des interruptions dans le produit.
Un flux de nouveautés produit fonctionne quand il est pertinent et de faible priorité : un point, pas un chiffre rouge.
Les préférences : la fonctionnalité de rétention la moins chère du système
Les réglages fins ressemblent à un bonus et se comportent comme une assurance. Un utilisateur agacé par une catégorie qui n'a le choix qu'entre tout et rien choisira rien, et vous aurez alors perdu les notifications de validation en même temps que le marketing. Trois niveaux suffisent en général : activation ou désactivation par catégorie, choix du canal par catégorie quand il en existe plusieurs, et une mise en sourdine temporaire.
Le taux de désactivation par catégorie est aussi l'instrument le plus honnête dont vous disposerez jamais pour juger si cette catégorie mérite d'exister. Ce n'est pas une métrique de vanité, et elle n'a pas de retard : les gens coupent ce qui les agace dans la semaine.
Mesurer les notifications in-app
| Métrique | Ce qu'elle vous apprend | Point de vigilance |
|---|---|---|
| Taux d'ouverture du flux | Si le point d'entrée est facile à trouver et si l'on croit au badge | Reste élevé sous la seule pression du badge, bien après l'effondrement de la qualité du contenu |
| Taux de clic / d'action par élément | Si les notifications individuelles valent la peine d'agir | À lire par catégorie : une catégorie forte en masque trois faibles |
| Délai avant action | Si le flux débloque réellement le travail | N'a de sens que pour les éléments de workflow où quelqu'un attend |
| Taux de désactivation / désinscription | Si une catégorie est la bienvenue | Le seul chiffre impossible à embellir : traitez toute hausse comme un verdict |
| Effacé sans être ouvert | Si les gens écartent les notifications au lieu de les lire | Un taux élevé ici avec un taux d'ouverture sain signifie que le flux est du théâtre |
Suivez tous ces indicateurs par catégorie plutôt qu'en global, et comparez les catégories entre elles plutôt qu'à des benchmarks publiés par d'autres produits : la performance d'un flux dépend presque entièrement de ce que vous avez choisi d'y mettre, ce qui rend toute comparaison entre entreprises dénuée de sens.
Six façons de tuer un centre de notifications
- Du marketing dans le flux. Le chemin le plus rapide vers une cloche ignorée pour toujours, et le plus difficile à inverser, car la confiance ne revient pas quand les promotions s'arrêtent.
- Un badge qui ne se vide jamais. Si atteindre zéro est impossible, les utilisateurs arrêtent d'essayer, et le badge devient du papier peint coloré.
- Aucun regroupement. Un document actif qui génère vingt lignes rend le flux inutilisable pour tout le reste.
- Des liens sans issue. Cliquer sur une notification et atterrir sur un tableau de bord, c'est l'équivalent interactif de « débrouillez-vous ».
- Le marquage automatique comme lu à l'ouverture. Tout marquer comme lu dès l'ouverture du panneau fait disparaître des éléments pour de bon et donne l'impression que le produit cache des choses.
- Des préférences tout ou rien. L'utilisateur qui voulait couper une seule catégorie coupe tout, y compris celles qui faisaient un vrai travail.
Notifications in-app : à faire et à éviter
✅ À faire
- Rédiger acteur–action–objet et nommer l'objet précis
- Faire pointer toute la ligne vers la destination exacte
- Regrouper les événements liés en un seul élément dépliable
- Donner à chaque catégorie sa propre règle de badge
- Placer les préférences à un clic du panneau
- Suivre le taux de désactivation par catégorie et agir en conséquence
❌ À éviter
- Mettre des promotions dans le flux de notifications
- Laisser un badge chiffré compter des éléments de faible valeur
- Tout marquer comme lu dès l'ouverture du panneau
- Envoyer le même événement par e-mail, push et flux à la fois
- Utiliser des noms d'objets internes dans le texte
- Juger le flux sur son seul taux d'ouverture
Ajouter une couche de notifications sans la développer
Un système de notifications complet (modèle d'événements, état lu, regroupement, préférences, liens profonds) est un vrai projet d'ingénierie, et c'est le bon investissement quand les notifications sont générées par les workflows de votre propre produit. Mais une grande partie de ce que les équipes attendent de la cloche n'a rien d'un workflow : il s'agit de dire aux utilisateurs ce qui a changé, dans le produit, à un endroit où ils pourront le retrouver plus tard.
Cette partie-là ne demande pas de projet d'ingénierie. Un widget d'annonces in-app vous donne une liste de mises à jour persistante, consultée à l'initiative de l'utilisateur, ciblée sur le segment concerné par chaque mise à jour et publiée sans release : il couvre correctement la catégorie des nouveautés produit et la tient à l'écart du badge de workflow, où elle fait des dégâts. Associez-le à une courte visite guidée pour tout ce que les utilisateurs doivent apprendre, et l'annonce cesse d'être une simple annonce pour devenir de l'adoption.
Dites aux bons utilisateurs ce qui a changé, là où ils le verront
Kompassify vous offre un widget d'annonces in-app, des infobulles ciblées et des visites guidées par-dessus votre produit existant, pour que les nouveautés produit atteignent le segment concerné sans concurrencer les notifications sur lesquelles vos utilisateurs comptent. Gratuit jusqu'à 100 utilisateurs actifs mensuels, offres à partir de 129 $/mois, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →L'essentiel en un paragraphe
Les notifications in-app sont adressées, persistantes et consultées à l'initiative de l'utilisateur, ce qui fait du flux une surface à la fois précieuse et fragile. Réservez-le à ce dont un utilisateur précis a besoin de garder une trace, regroupez sans hésiter, ne laissez que le vrai travail faire monter un badge chiffré, rédigez acteur–action–objet avec un lien profond, proposez des préférences par catégorie, et surveillez le taux de désactivation plutôt que le taux d'ouverture. Les nouveautés diffusées à tous méritent leur propre surface d'annonces, à côté de la cloche plutôt qu'à l'intérieur.
Questions fréquentes
Qu'est-ce qu'une notification in-app ?
Une notification in-app est un message transmis à l'intérieur d'un produit à un utilisateur précis, à propos de quelque chose qui s'est produit ou qui demande son attention : le commentaire d'un collègue, un export terminé, une validation en attente, une nouvelle fonctionnalité dans le domaine où il travaille. Elle se trouve généralement dans un centre de notifications persistant, accessible depuis une icône de cloche, porte un état lu ou non lu et reste disponible jusqu'à ce que l'utilisateur la traite. C'est cette persistance qui la distingue d'un message in-app diffusé, comme une modale ou un bandeau, qui apparaît une fois, interrompt, puis disparaît.
Quelle est la différence entre les notifications in-app et les notifications push ?
Les notifications push sont envoyées par le système d'exploitation à un utilisateur qui n'est pas dans votre produit à ce moment-là, et elles exigent une autorisation explicite que beaucoup de gens refusent. Les notifications in-app sont affichées dans votre interface à un utilisateur qui s'y trouve déjà : elles ne demandent aucune autorisation, ne peuvent pas être révoquées au niveau du système et peuvent être bien plus riches, mais elles n'atteignent que les personnes qui reviennent. En pratique, les deux sont complémentaires : le push sert à faire revenir quelqu'un, le flux in-app sert à tout ce qu'il a manqué pendant son absence.
Quelle est la différence entre les notifications in-app et les messages in-app ?
Un message in-app est diffusé et interruptif : une modale, un bandeau, une infobulle ou un panneau coulissant montré à un segment d'utilisateurs à un moment choisi, en général pour annoncer, guider ou inciter. Une notification in-app est adressée et persistante : elle concerne un seul utilisateur, attend dans un flux avec un état lu, et c'est l'utilisateur qui choisit quand l'ouvrir. La règle empirique : tout ce que l'utilisateur doit traiter plus tard va dans le flux, tout ce qu'il doit voir tout de suite pour comprendre l'écran actuel va dans un message.
Que faut-il mettre dans un centre de notifications ?
Quatre catégories couvrent presque tout : les notifications personnelles (quelqu'un agit sur votre travail), les notifications de workflow (quelque chose vous attend), les notifications système (tâches et changements de statut) et les nouveautés produit liées à ce que vous faites. Tout le reste, c'est du marketing déguisé en cloche. Le test : l'élément est-il adressé à cet utilisateur précis, et voudrait-il raisonnablement en garder une trace ? Si la réponse à l'une des deux questions est non, sa place est dans un message, un e-mail, ou nulle part.
Comment rédiger une notification ?
Commencez par l'acteur et l'action, nommez l'objet précis et faites de l'élément entier un lien vers l'endroit exact où l'utilisateur doit aller. « Sam a validé votre demande de budget T3 » vaut mieux que « Vous avez une nouvelle validation ». Tenez-vous à une ligne quand c'est possible, ajoutez un horodatage relatif et évitez le jargon produit qui n'a de sens qu'en interne. Chaque notification doit répondre instantanément à trois questions : qui a fait quoi, sur quel objet, et que se passe-t-il si je clique.
Combien de notifications in-app, c'est trop ?
Le volume qui compte ne se mesure pas par jour mais par unité de valeur. Un flux où la plupart des éléments méritent d'être ouverts peut supporter un volume élevé ; un flux où trois éléments sur quatre sont du bruit finit coupé à presque n'importe quel volume. Regroupez les événements liés en un seul élément au lieu d'en envoyer cinq, groupez par objet ou par jour, et soyez strict sur les catégories autorisées à faire monter le badge. Si le taux de désactivation d'une catégorie grimpe, cette catégorie est la réponse à la question.
Un badge de notification doit-il afficher un nombre ?
Affichez un nombre uniquement pour les éléments qui méritent vraiment une attention individuelle, et un simple point pour tout le reste. Un badge chiffré promet qu'il y a autant de choses distinctes à traiter ; quand ce nombre est gonflé par des éléments de faible valeur, les utilisateurs apprennent qu'il ne vaut pas la peine d'être vidé et finissent par l'ignorer pour de bon. Un badge qui ne revient jamais à zéro n'est plus un signal, c'est une décoration.
Quelles métriques suivre pour les notifications in-app ?
Suivez quatre indicateurs par catégorie plutôt qu'en global : le taux d'ouverture du flux lui-même, le taux de clic ou d'action sur chaque élément, le délai entre la livraison et l'action, et le taux de désactivation ou de désabonnement. Ce dernier est la mesure honnête de l'accueil réservé à une catégorie. Le taux de clic peut rester correct jusqu'au moment où les gens coupent tout. Comparez les catégories entre elles plutôt qu'à des benchmarks externes, car la performance d'un flux dépend presque entièrement de ce que vous choisissez d'y mettre.