Notifications push : ce qui marche, et ce qui fait désinstaller

Les notifications sont le seul mécanisme qui permet à une application d’interrompre quelqu’un. C’est un pouvoir considérable, et c’est aussi la façon la plus rapide de se faire désinstaller.

Voici ce que j’ai appris en construisant et en corrigeant ces systèmes.

Le moment de la demande décide de tout

Sur iOS, l’autorisation d’envoyer des notifications se demande explicitement. Sur Android, c’est également le cas depuis plusieurs versions. Dans les deux cas, la règle est la même : on ne peut la demander qu’une fois.

Si l’utilisateur refuse, la fenêtre système ne réapparaît plus. Il faut alors le convaincre d’aller dans les réglages du système, ce que presque personne ne fait.

L’erreur la plus fréquente : demander l’autorisation au premier lancement, avant que l’utilisateur ne sache ce que fait l’application. À ce moment, il n’a aucune raison d’accepter, et le taux de refus est très élevé.

Ce qui fonctionne : demander au moment où la valeur est évidente. Après que l’utilisateur a créé sa première alerte, suivi son premier dossier, passé sa première commande. À cet instant, la demande a du sens et le taux d’acceptation change du tout au tout.

Une pratique utile : afficher d’abord un écran explicatif de l’application — « nous vous préviendrons quand votre intervention est validée » — avec un bouton pour continuer. Si l’utilisateur n’est pas convaincu, on n’appelle jamais la fenêtre système, et on garde la possibilité de redemander plus tard.

Ce qui mérite une notification

Un critère unique, et il élimine la plupart des envois : cela concerne-t-il personnellement cette personne, et appelle-t-il une action ou une décision de sa part ?

Ce qui passe ce test : une intervention assignée, une validation attendue, un message reçu, une échéance qui approche, un incident sur un dossier suivi.

Ce qui ne le passe pas : les nouveautés de l’application, les rappels d’usage — « vous n’êtes pas venu depuis trois jours » —, les communications qui concernent tout le monde, et à peu près tout ce qui relève de la promotion.

Ce dernier point est celui où la pression interne est la plus forte, parce qu’une notification générale produit toujours un pic de fréquentation. Ce pic est réel et coûteux : le taux de désactivation qui l’accompagne est définitif, alors que le pic dure un jour.

Sur une application métier, la question ne se pose même pas. Une notification qui n’appelle pas d’action apprend à l’utilisateur à ignorer les suivantes — y compris celle qui comptait.

Le réglage fin plutôt que l’interrupteur unique

Une erreur de conception qu’on paye longtemps : ne proposer qu’un seul réglage, tout ou rien.

Un utilisateur agacé par un type de notification n’a alors qu’une option : tout couper. Et il ne reviendra pas en arrière.

Ce qu’il faut prévoir dès la première version : une liste par catégorie, avec un réglage indépendant pour chacune. « Interventions assignées », « validations en attente », « messages ». L’utilisateur coupe ce qui le dérange et garde le reste.

Android propose pour cela un mécanisme intégré : les canaux de notification, que le système affiche dans ses propres réglages. Les définir correctement dès le départ est important, car un canal ne peut plus être modifié une fois créé — pour en changer l’importance ou le son, il faut en créer un nouveau, et les utilisateurs existants gardent l’ancien réglage.

Photo : domaine public (CC0).

Les détails techniques qui provoquent des incidents

Quatre points qui reviennent systématiquement.

Le fuseau horaire. Une notification programmée sur l’heure du serveur réveille les utilisateurs d’un autre fuseau. Sur une application utilisée hors de France, cela arrive à la première campagne.

Les heures de repos. Toute notification non urgente doit être retenue en dehors d’une plage définie. Les systèmes proposent des mécanismes pour cela ; il faut aussi une règle côté serveur, sinon un traitement nocturne enverra à trois heures du matin.

Les jetons d’appareil qui expirent. Le jeton qui identifie un appareil change — réinstallation, restauration de sauvegarde, mise à jour du système. Un serveur qui n’écoute pas les retours du service d’envoi accumule des jetons morts, et son taux de succès se dégrade lentement. Les jetons invalides doivent être supprimés à la première erreur signalée.

Le regroupement. Cinq notifications en cinq minutes pour cinq événements liés sont vécues comme du harcèlement. Il faut regrouper : « 5 nouvelles interventions » plutôt que cinq messages. Les deux systèmes savent le faire, encore faut-il le prévoir.

Ce que la notification doit contenir

Trois exigences, et elles sont plus contraignantes qu’il n’y paraît.

Être compréhensible sur l’écran verrouillé, sans contexte. L’utilisateur voit deux lignes. « Mise à jour disponible » ne dit rien. « Intervention 4821 validée par le client » dit tout.

Ne contenir aucune information sensible. Le contenu s’affiche sur un écran verrouillé, visible par n’importe qui. Un nom de patient, un montant, un motif médical n’ont rien à y faire. La règle que j’applique : la notification signale, elle ne divulgue pas.

Ouvrir directement au bon endroit. Une notification qui ouvre l’écran d’accueil oblige l’utilisateur à retrouver ce dont on lui a parlé. C’est le défaut le plus courant, et il annule une bonne partie de l’intérêt du mécanisme. Cela suppose de gérer le cas où l’application était fermée, et celui où l’utilisateur n’est plus connecté.

Photo : domaine public (CC0).

Ce que je mesure

Trois indicateurs suffisent à piloter, et le troisième est le plus important.

Le taux d’ouverture par type de notification. Il indique lesquelles servent réellement. Un type sous 5 % doit être remis en question.

Le taux de désactivation, suivi dans le temps et rapproché des campagnes d’envoi. C’est là qu’on voit le coût réel d’un envoi général.

Le taux d’acceptation de l’autorisation, selon le moment où elle est demandée. C’est l’indicateur sur lequel un changement simple produit le plus gros effet — déplacer la demande de l’écran d’accueil vers un moment de valeur fait couramment doubler l’acceptation.

Ne jamais compter sur la notification pour transmettre l’information

Un principe d’architecture que j’applique sans exception : une notification n’est jamais le seul canal.

La raison est technique. Les services d’envoi des deux plateformes ne garantissent pas la livraison. Un appareil éteint, un mode économie d’énergie agressif, un système qui décide de retarder l’envoi, une notification effacée par l’utilisateur sans être lue : dans tous ces cas, l’information n’arrive pas, et le serveur ne le sait pas.

Cela a une conséquence concrète : tout ce qui est signalé par notification doit aussi être visible dans l’application. Une liste des éléments en attente, un compteur sur l’écran d’accueil, un historique consultable.

Une notification est un raccourci vers une information qui existe ailleurs. Dès qu’on la traite comme le porteur de l’information, on construit un système qui perd des messages sans le savoir — et c’est le genre de défaut qui ne se manifeste qu’au moment où cela compte.

Le principe que je garde en tête

Une notification emprunte l’attention de quelqu’un. Cet emprunt se rembourse : si l’utilisateur y gagne, il en acceptera d’autres ; sinon, il coupe tout, et l’application perd définitivement son canal le plus direct.

C’est pour cela que je défends toujours d’en envoyer moins. Une application qui notifie peu et juste garde ses autorisations pendant des années. Une application qui notifie beaucoup les perd en quelques semaines — et personne ne les lui rendra.