Une seule commande de livraison peut déclencher 5 à 7 notifications push entre « confirmée » et « livrée ». Multipliez cela par quelques commandes par semaine et l’application finit par ressembler à du spam. L’utilisateur smartphone moyen reçoit déjà 46 notifications push par jour ; 43 % les désactivent lorsque les apps en envoient seulement 2 à 5 par semaine.
Les utilisateurs veulent savoir ce qui se passe à tout moment, sans être interrompus cinq fois en chemin. La différence entre l’engagement et le désabonnement, c’est de savoir quels moments nécessitent vraiment une notification push et lesquels doivent simplement rester visibles.
Ce guide explique la distinction entre alerts et live state, la règle des 3 messages, un cas pratique concret issu de la livraison de repas, ainsi qu’un plan de migration en trois étapes. En chemin, vous verrez comment Pushwoosh orchestre notifications push et iOS Live Activities dans un Customer Journey Builder conforme RGPD, avec données hébergées en UE.
Alerts vs. live state : la seule distinction qui compte
La plupart des équipes traitent les notifications push comme le canal par défaut pour tout ce qui est en temps réel. Commande confirmée : push. Chauffeur assigné : push. Chauffeur en route : push. Chauffeur qui arrive : push. Commande livrée : push. Cinq interruptions pour un seul événement que l’utilisateur a lui-même initié et qu’il attend déjà.
Chacune de ces mises à jour a son importance, mais toutes ne méritent pas une notification push. Dans les scénarios temps réel, il existe deux missions de communication fondamentalement différentes :
Alerts. Elles disent : « Quelque chose vient d’arriver ! Regardez maintenant. » Elles interrompent et exigent l’attention. Leur place, ce sont les moments qui demandent réellement une décision ou un changement de comportement : votre porte d’embarquement vient de changer, votre paiement a échoué, votre VTC est arrivé.
Live state. Il dit : « Voici ce qui se passe en ce moment, consultez quand vous voulez. » C’est ambiant et continuellement mis à jour. Le live state couvre tout ce que les utilisateurs veulent suivre sans avoir à réagir : position du chauffeur, temps de préparation, ETA de livraison, score d’un match, distance d’un entraînement.
Les notifications push ont été conçues pour les alerts. Les Live Activities ont été conçues pour le live state. Utiliser une notification push pour du suivi d’état, c’est interrompre les utilisateurs pour leur annoncer quelque chose qu’ils n’ont pas demandé à être interrompus pour apprendre.
La règle des 3 messages
Pour tout scénario temps réel, il vous faut au maximum 3 notifications push.
Démarrage. Confirmez que le processus a commencé. « Votre commande est confirmée. » « Paiement initié. » « Votre VTC est en route. » Cela pose le cadre, rassure l’utilisateur et active la Live Activity qui portera la suite.
Exception. Quelque chose ne va pas ou nécessite une action. « Article indisponible. » « Votre livreur ne trouve pas l’entrée. » « Paiement refusé, mettez à jour votre carte. » « Vol retardé de 2 heures. » Ce sont de véritables interruptions, car elles exigent une action.
Clôture. Le processus est terminé. « Votre commande a été livrée. » « Paiement reçu. » « Vous êtes arrivé. » Cela boucle la boucle et met fin à la Live Activity.
Entre le démarrage et la clôture, tout se joue sur l’écran de verrouillage sous forme de Live Activity : le temps de préparation qui s’écoule, le livreur qui avance sur la carte, le score qui évolue, l’ETA recalculé. Mis à jour automatiquement, sans aucune interruption.
Le cas pratique : une commande de livraison de repas
Prenez un parcours de livraison standard, avant et après.
Avant (approche tout-push), 5 notifications en ~45 minutes :
- 🔔 « Votre commande est confirmée »
- 🔔 « Votre commande est en préparation »
- 🔔 « Votre livreur a récupéré votre commande »
- 🔔 « Votre livreur est à proximité »
- 🔔 « Votre commande a été livrée »
Cinq interruptions pour un seul déjeuner commandé. Multipliez par deux ou trois commandes par semaine et une seule application envoie déjà 10 à 15 notifications. C’est le seuil à partir duquel les utilisateurs désactivent complètement les notifications.
Après (règle des 3 push + Live Activity) :
- 🔔 Push : « Votre commande est confirmée » → démarrage de la Live Activity
- 📱 La Live Activity se met à jour silencieusement : préparation → récupérée → position du livreur → décompte ETA
- 🔔 Push (si nécessaire) : « Le livreur n’arrive pas à accéder à l’immeuble, merci de consulter votre téléphone »
- 📱 Live Activity : le décompte ETA continue
- 🔔 Push : « Votre commande a été livrée » → fin de la Live Activity
L’utilisateur passe de 5 interruptions à 2, ou à 3 en cas de problème. L’écran de verrouillage reste propre, et la visibilité temps réel est en réalité meilleure. Au lieu de cinq pings déconnectés, l’utilisateur voit un tracker live et continu avec position du livreur et ETA, rafraîchi toutes les quelques secondes.
Le résultat : moins de désabonnements, moins de tickets « où en est ma commande ? » au support, et l’application reste visible sur l’écran de verrouillage pendant 30 à 45 minutes d’affilée au lieu de clignoter cinq fois et de disparaître.
Adaptez la règle à votre application
La même règle fonctionne partout où les utilisateurs suivent quelque chose en temps réel. Voici comment elle se décline sur les verticales clés du marché français — VTC (Uber, Bolt, Free Now), e-commerce (Veepee, Cdiscount, La Redoute, Vinted), FinTech (Boursorama, Lydia, Qonto), gaming et médias (Le Monde, Les Échos, L’Équipe) :
| Application | Push : démarrage | Live Activity | Push : exception | Push : clôture |
|---|---|---|---|---|
| VTC / mobilité (type Uber, Bolt, Free Now) | Chauffeur assigné | Localisation, ETA, détails du véhicule | Chauffeur annulé / re-routage | Course terminée + tarif |
| E-commerce (type Vinted, Veepee, Cdiscount) | Commande expédiée | Préparation → en transit → en cours de livraison → à proximité | Retard ou tentative échouée | Livrée |
| FinTech (type Boursorama, Lydia, Qonto) | Transaction initiée | Statut de traitement (virement SEPA, vérification) | Paiement refusé / activité inhabituelle | Transaction finalisée |
| Gaming | Début du tournoi / énergie pleine | Position au classement, minuteur de boss, progression | Adversaire trouvé / série en péril | Résultat du match |
| Presse & médias (type Le Monde, L'Équipe) | Alerte info / événement en direct | Ticker live : score, comptage des votes, titres | Développement majeur | Événement terminé |
Dans chaque cas, la notification push marque les transitions qui comptent. La Live Activity porte l’état entre les deux.
Comment démarrer sans refondre votre stack
L’objection habituelle : « Il nous faudrait un refactor majeur pour ajouter les Live Activities. » En pratique, une approche en trois étapes tient dans un seul sprint :
-
Auditez votre flux push actuel
Choisissez un parcours temps réel (suivi de commande, une course, un match) et listez chaque notification push qu'il déclenche. Marquez chacune : exige-t-elle que l'utilisateur fasse quelque chose ou sache quelque chose de nouveau, ou s'agit-il d'une mise à jour de statut qu'il pourrait consulter de lui-même ? En général, seulement 2 à 3 push sur 5 à 7 passent ce filtre.
-
Supprimez et remplacez
Désactivez les push de mise à jour de statut. Lancez une Live Activity au push de démarrage, terminez-la au push de clôture. Mettez-la à jour via API à chaque point où vous envoyiez auparavant une notification push.
-
Mesurez
Suivez trois indicateurs sur 2 à 4 semaines. Le taux de désabonnement doit baisser. Le volume de tickets de support pour les questions « où en est ma commande ? » diminue à mesure que les Live Activities offrent une visibilité en libre-service. Et la fréquence des sessions augmente souvent plutôt qu'elle ne baisse : les utilisateurs avec une Live Activity active ont tendance à ouvrir l'application plus souvent, car l'écran de verrouillage devient un point de ré-entrée.
