Notifications push : les bonnes pratiques

Une notification push réussie est attendue : elle apporte une information que l’utilisateur veut recevoir, au moment où elle lui sert. Les bonnes pratiques tiennent en trois idées : demander l’autorisation au bon moment, n’envoyer que ce qui est utile, et laisser à chacun le choix de ce qu’il reçoit. Le reste de cet article détaille comment faire, sur iPhone comme sur Android.

Qu’est-ce qu’une notification push, et à quoi sert-elle ?

Une notification push est un message envoyé par votre serveur vers le téléphone de l’utilisateur, même quand l’application est fermée. Elle s’affiche sur l’écran verrouillé, dans le centre de notifications, parfois avec un son ou une vibration. Sur iPhone, elle passe par le service d’Apple (APNs) ; sur Android, en général par Firebase Cloud Messaging, le service de Google.

Elle sert à trois choses :

• informer d’un événement qui concerne la personne : une commande prête, un rendez-vous confirmé, un message reçu ;
• rappeler quelque chose que l’utilisateur a lui-même demandé : prendre un traitement, arroser une plante, renouveler un document ;
• alerter quand une situation change : une pharmacie de garde qui ouvre, un pic de pollution, un colis retardé.

Elle peut aussi servir à relancer ou à promouvoir, et c’est là que la plupart des erreurs se commettent.

Quand demander l’autorisation d’envoyer des notifications ?

Sur iPhone, une application doit demander la permission avant d’envoyer la moindre notification. Sur Android, c’est aussi le cas depuis Android 13 : la documentation Android précise que les notifications d’une application fraîchement installée sont désactivées par défaut tant que l’utilisateur ne les a pas autorisées.

Cette demande est précieuse, parce qu’on n’a souvent qu’une seule chance. Une personne qui refuse doit ensuite aller dans les réglages du téléphone pour changer d’avis, ce que peu de gens font.

La pire façon de demander l’autorisation, c’est au premier lancement, avant que l’utilisateur ait compris à quoi sert l’application.

Les bonnes pratiques :

1. Attendre un moment qui a du sens. Une application de prise de rendez-vous demande l’autorisation juste après la première réservation : « Voulez-vous être prévenu la veille de votre rendez-vous ? ». La réponse est évidente.
2. Expliquer avant la fenêtre système. Un écran à vous, avec vos mots, dit ce que la personne recevra et à quelle occasion. La fenêtre d’Apple ou d’Android n’apparaît que si elle accepte le principe.
3. Ne pas insister. Si la personne dit non, l’application continue de fonctionner normalement. Vous pourrez reproposer plus tard, à une occasion qui justifie vraiment la demande.

Sur iPhone, Apple propose aussi une autorisation provisoire : les notifications arrivent discrètement dans le centre de notifications, sans son ni bannière, et l’utilisateur décide ensuite s’il les garde. C’est une bonne option pour une application dont l’intérêt des notifications se comprend en les voyant.

Quelles notifications envoyer, et lesquelles éviter ?

Le critère le plus simple : si l’utilisateur voyait cette notification sans savoir qu’elle vient de vous, serait-il content de l’avoir reçue ?

Type de notification	Exemple	À envoyer ?
Suite d’une action de l’utilisateur	« Votre commande est prête »	Oui, c’est la plus utile
Rappel qu’il a programmé	« Rendez-vous demain à 10 h »	Oui
Alerte sur un sujet qu’il suit	« Pollution élevée dans votre ville »	Oui, s’il l’a choisie
Nouveauté réelle de l’application	« Vous pouvez maintenant payer en ligne »	Rarement, et seulement si elle le concerne
Relance sans contenu	« Ça fait longtemps ! Revenez nous voir »	Non
Promotion	« -20 % ce week-end »	Seulement avec un accord explicite

Pour la promotion, Apple fixe une règle précise. La règle 4.5.4 des App Review Guidelines interdit d’utiliser les notifications pour la promotion ou le marketing direct sans le consentement explicite de l’utilisateur, recueilli dans l’application, avec un moyen de se désinscrire depuis l’application. La même règle précise que l’application doit fonctionner sans notifications et qu’elles ne doivent pas transporter d’informations personnelles sensibles.

Combien de notifications envoyer ?

Il n’existe pas de bon chiffre universel, et méfiez-vous de ceux qui en donnent un. Une application de messagerie peut envoyer des dizaines de notifications par jour sans gêner personne, parce que chacune correspond à un message attendu. Une application de boutique qui en envoie une par jour sera désactivée en une semaine.

Le bon repère est la valeur de chaque envoi. Quelques réflexes aident :

• regrouper : trois mises à jour sur le même sujet font une seule notification ;
• respecter les heures : un rappel non urgent n’a rien à faire à 23 h, et l’heure doit être celle du fuseau de l’utilisateur ;
• ne pas doubler : si la personne a déjà vu l’information dans l’application, la notification est inutile ;
• s’arrêter quand il n’y a rien à dire : une semaine sans notification est souvent préférable à une notification vide.

Comment bien écrire une notification ?

Une notification se lit en une seconde, souvent sur un écran verrouillé, parfois tronquée. Le texte doit donc aller droit au but.

Un titre qui dit l’essentiel

« Commande n° 1042 prête » dit tout. « Bonne nouvelle ! » ne dit rien et oblige à ouvrir pour comprendre. Le titre porte l’information, le texte en dessous ajoute le détail utile (l’heure, le lieu, la prochaine étape).

Une notification qui mène au bon écran

Toucher une notification doit ouvrir l’écran concerné, pas l’accueil de l’application. Si la notification annonce un message, elle ouvre la conversation. C’est un détail technique (on parle de lien profond) qui fait une grande différence : sans lui, l’utilisateur doit chercher ce qu’on vient de lui annoncer.

Rien de sensible sur l’écran verrouillé

Un résultat d’analyse, un montant, le contenu d’un message privé : ces informations peuvent être lues par quelqu’un d’autre que le propriétaire du téléphone. Mieux vaut « Un nouveau document est disponible dans votre espace » que le document lui-même.

Laisser la main à l’utilisateur

Une personne qui ne peut pas choisir ce qu’elle reçoit finit par tout couper. À l’inverse, une page de réglages claire dans l’application permet de garder les notifications qui comptent pour elle.

Sur Android, le système prévoit pour cela des canaux de notification : chaque catégorie (commandes, rappels, offres) est un canal distinct que l’utilisateur peut couper ou rendre silencieux depuis les réglages du téléphone, comme l’explique la documentation sur les canaux. Sur iPhone, l’application gère elle-même ces préférences.

Dans les deux cas, prévoyez dans l’application :

• une liste des catégories de notifications, chacune avec un interrupteur ;
• pour les rappels, le choix du moment (la veille, une heure avant) ;
• un accès direct aux réglages du téléphone si l’utilisateur a tout refusé et veut revenir en arrière.

Mesurer ce qui marche, sans surveiller les gens

Pour savoir si vos notifications sont utiles, quelques indicateurs suffisent : la part de notifications ouvertes par catégorie, le nombre de personnes qui coupent une catégorie après un envoi, et les désinstallations qui suivent une campagne. Une catégorie qu’on désactive en masse est un signal clair.

Ces mesures peuvent rester globales. Inutile de suivre chaque utilisateur à la trace : ce qu’il faut savoir, c’est si un type d’envoi est apprécié ou rejeté. Moins vous collectez de données personnelles, moins vous avez à en justifier.

Ces choix gagnent à être faits dès la conception. Si vous préparez votre projet, notre article sur le cahier des charges d’une application mobile explique comment décrire ce type de fonctionnalité, et celui sur le MVP aide à décider si les notifications doivent être là dès la première version.

Questions fréquentes

Une application peut-elle fonctionner sans notifications ?

Oui, et sur iPhone elle le doit : Apple refuse les applications dont le fonctionnement dépend de l’acceptation des notifications. Concevez toujours l’application pour qu’elle reste utile à quelqu’un qui a dit non, par exemple avec un tableau de bord qui affiche les mêmes informations.

Peut-on envoyer des notifications publicitaires ?

Oui, mais seulement si l’utilisateur l’a accepté explicitement dans l’application, et avec un moyen simple de se désinscrire. C’est une exigence des règles d’Apple. Séparez bien ce consentement de l’autorisation générale des notifications : quelqu’un peut vouloir ses rappels sans vouloir vos offres.

Les notifications fonctionnent-elles de la même façon sur iPhone et Android ?

Le principe est le même, les détails diffèrent : services d’envoi distincts, canaux de notification propres à Android, autorisation provisoire propre à l’iPhone. Avec Flutter, nous écrivons la logique une seule fois et nous réglons ces différences pour chaque système.

Quelle est la différence entre une notification push et une notification locale ?

Une notification push vient de votre serveur, pour annoncer un événement extérieur (une commande, un message). Une notification locale est programmée par l’application elle-même sur le téléphone, par exemple un rappel quotidien choisi par l’utilisateur. Elle ne demande pas de serveur, mais elle a besoin de la même autorisation.

Les notifications font partie des fonctionnalités que nous concevons avec chaque application mobile, du texte de la demande d’autorisation jusqu’à la page de réglages. Si vous voulez en discuter pour votre projet, parlons-en.