Notifications push sur une application mobile, ce que vous contrôlez et ce que vous subissez
« On enverra une notification pour prévenir l'utilisateur » revient dans presque tous les cahiers des charges mobiles que nous recevons, et c'est la ligne que personne n'a chiffrée. Derrière elle : une autorisation que l'utilisateur peut refuser une fois pour toutes, une règle de revue d'Apple qui interdit d'en faire la condition du fonctionnement, et quatre postes de développement rarement provisionnés.
Deux usages qui ne portent pas le même risque
Il y a la notification de service et la notification de relance. La première transporte un fait que l'utilisateur attend : votre tournée de demain est prête, votre analyse est terminée, votre compte a un problème. La seconde cherche à ramener quelqu'un dans l'application. Les deux passent par le même tuyau technique. Elles n'ont ni le même cadre juridique, ni le même risque de refus au moment de la revue sur les boutiques, ni la même valeur.
Nous recommandons de ne financer que la première dans une version 1. Pas par principe moral : une notification de service se spécifie en une phrase vérifiable, quand une relance suppose une stratégie éditoriale, un calendrier d'envoi et une mesure, trois choses qui n'existent pas encore quand l'application n'a pas d'utilisateurs. Nous déconseillons de les mettre dans le même lot de développement.
AquaPro Manager est notre cas de notification de service. L'application Flutter équipe les techniciens de terrain, le back-office Next.js est tenu par les gérants et les managers, et la fiche du projet décrit un agenda visuel avec rappels automatiques et notifications push en temps réel : les techniciens reçoivent leur planning la veille. Cette notification-là ne se discute pas, parce que l'organisation du lendemain en dépend.
Pourquoi un utilisateur ne reçoit-il pas vos notifications ?
Dans l'ordre de fréquence : l'autorisation n'a jamais été accordée, elle a été retirée depuis les réglages du téléphone, ou le message a été envoyé en priorité normale alors que l'appareil dormait. Aucune des trois ne produit d'erreur visible côté serveur. Votre envoi est accepté, et rien n'arrive.
Sur Android, la bascule date d'Android 13 : « Android 13 (API level 33) and higher supports a runtime permission for sending non-exempt […] notifications from an app: POST_NOTIFICATIONS ». La documentation sépare ensuite deux populations. Pour une installation neuve, rien n'est acquis : « If a user installs your app on a device that runs Android 13 or higher, your app's notifications are off by default ». Pour un parc déjà en place, le système « automatically pre-grants the permission to all eligible apps when the user upgrades their device to Android 13 or higher », et ces utilisateurs « don't see a runtime permission prompt » (permission d'exécution des notifications, documentation Android). L'éligibilité tient à deux conditions, un canal de notification existant et des notifications que l'utilisateur n'avait pas déjà coupées à la main. Vos utilisateurs actuels éligibles gardent donc l'autorisation. Chaque nouvelle installation part de zéro.
Le troisième cas est le plus déroutant : le message existe, part, et se perd en route. Firebase Cloud Messaging propose deux priorités, et celle qui s'applique sans qu'on la demande est la moins pressée : « Normal priority. This is the default priority for data and notification messages. […] When the device is in Doze mode, delivery may be delayed to conserve battery until the device exits doze. » La même page recommande explicitement de ne pas s'en contenter, « setting most of your user visible notifications to high priority will ensure they are delivered promptly » (priorité des messages sur Android, documentation Firebase Cloud Messaging). Un planning reçu la veille au soir sur un téléphone posé en charge, c'est précisément le scénario où le réglage par défaut ne suffit pas.
Peut-on redemander l'autorisation après un refus ?
Sur iOS, non. Apple n'affiche l'invite qu'à la première demande et enregistre la réponse ; les demandes suivantes ne montrent plus rien. Vous avez une tentative, une seule, et elle se joue en deux secondes devant quelqu'un qui n'a encore rien vu de votre application.
Apple ne laisse aucune marge : « The first time your app makes this authorization request, the system prompts the person to grant or deny the request and records that response. Subsequent authorization requests don't prompt the person. » (demander l'autorisation d'utiliser les notifications, documentation Apple).
Android est plus sévère encore sur les applications qui n'ont pas suivi les échéances de niveau d'API. La documentation porte un encadré d'avertissement : « If your app targets 12L or lower and the user taps Don't allow, even just once, they aren't prompted again until they uninstall and reinstall your app, or you update your app to target Android 13 or higher. » Un geste réflexe sur une invite mal placée, et le canal reste fermé jusqu'à une réinstallation, ou jusqu'à ce que vous portiez la cible à Android 13 ou plus récent.
La conséquence pratique est que le moment de la demande est une décision de produit, pas une ligne de code. Apple donne lui-même la règle : « Make the request in a context that helps people understand why your app needs authorization », et tranche entre les deux moments possibles : « Sending the request in context provides a better experience than automatically requesting authorization on first launch, because people can see the purpose your apps notifications serve ». Sur un outil professionnel, le bon moment est évident, il suit la première action métier. Sur une application grand public, il se cherche.
La page d'Apple documente aussi une porte de sortie que les comparatifs français mentionnent rarement, l'autorisation provisoire. Avec l'option provisional, la première demande est accordée automatiquement, sans invite, et les notifications sont livrées en silence : « they don't interrupt the person with a sound or banner, or appear on the lock screen. Instead, they only appear in the notification center's history. » Chacune porte deux boutons, garder ou couper. L'utilisateur juge sur pièce au lieu de décider à l'aveugle. Le prix de ce confort est écrit juste à côté : s'il choisit de les garder en mode immédiat, le système autorise l'envoi mais ne donne pas la permission d'afficher une alerte, de jouer un son ni de pastiller l'icône. Nous la recommandons sur une application grand public dont la valeur des notifications se démontre à l'usage, et pas sur un outil de terrain où la bannière est le but.
Ce que la règle 4.5.4 d'Apple interdit de faire
Cette règle est courte et elle décide de l'architecture. La voici en entier : « Push Notifications must not be required for the app to function, and should not be used to send sensitive personal or confidential information. Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app's UI, and you provide a method in your app for a user to opt out from receiving such messages. Abuse of these services may result in revocation of your privileges. » (App Review Guidelines, règle 4.5.4).
Ses deux premières phrases portent trois obligations de conception, la troisième annonce la sanction. D'abord, toute information poussée doit rester atteignable dans l'application, puisque la notification ne peut pas être le seul chemin : une liste d'alertes, un badge, un écran d'historique. Nous le traitons comme un écran à part entière, dessiné au cadrage avec les autres.
Ensuite, rien de sensible ni de confidentiel dans le texte poussé. Une notification s'affiche sur un écran verrouillé, devant n'importe qui. Un résultat médical, un montant, un nom de client sur un téléphone partagé : le contenu se réduit à une invitation à ouvrir l'application, et le détail reste derrière l'authentification.
Enfin, la relance commerciale exige un consentement recueilli dans l'interface et un moyen de se désabonner depuis l'application. Un réglage dans votre back-office ne satisfait pas la règle : c'est un écran de préférences à développer, à traduire et à recetter. Côté données personnelles, ce consentement s'articule avec les obligations que nous avons détaillées pour les applications mobiles dans notre article sur le RGPD appliqué à une application mobile.
Ce qu'une notification coûte vraiment à construire
L'envoi est gratuit. Apple et Google ne facturent pas le transport, ce qui donne à la fonctionnalité une réputation de gratuité qu'elle ne mérite pas. La difficulté est en amont : déterminer qui déclenche quel message, pour quel destinataire et à quelle heure. Ce raisonnement se code sur un serveur, et c'est là que passent les jours.
Quatre postes reviennent sur nos devis mobiles.
- la logique d'envoi : la règle métier qui déclenche le message, et la fenêtre horaire dans laquelle il est acceptable de le recevoir ;
- les jetons d'appareil : un jeton change, un téléphone est remplacé, un compte se connecte sur deux appareils, et une base de jetons jamais nettoyée envoie dans le vide ;
- la langue : le texte étant composé côté serveur, c'est le serveur qui doit savoir dans quelle langue l'utilisateur lit, ce qui suppose de stocker cette préférence ;
- la recette : sur appareil réel, dans les deux systèmes, application fermée, écran verrouillé et autorisation refusée.
Le troisième poste est celui qu'on oublie le plus souvent, et Daiky montre pourquoi il vaut mieux le traiter tôt. L'application est en Flutter, publiée sur l'App Store, avec Firebase pour l'authentification, Firestore, le stockage, les notifications et App Check. Elle est bilingue français et anglais, et sa fiche note que l'internationalisation a été intégrée dès la conception plutôt qu'ajoutée après coup. Ce choix, pris pour l'interface, couvre aussi les messages poussés : une application traduite dont les notifications partent en une seule langue se voit immédiatement.
Pour un projet web, une réserve de plus : sur iOS, les notifications d'une application installée depuis un navigateur dépendent d'une condition d'installation qui change le parcours d'inscription. Nous l'avons traitée dans notre comparatif natif, hybride ou PWA.
Ce que nous ne savons pas vous promettre
Nous ne savons pas prouver qu'une notification est arrivée. Le serveur sait qu'il a remis le message au service d'Apple ou de Google, et s'arrête là. Ce qui se passe ensuite, veille prolongée, économiseur de batterie du constructeur, réglages par application, appartient au téléphone. Quand un gérant nous dit qu'un technicien n'a pas reçu son planning, nous pouvons vérifier l'envoi, la priorité et l'état de l'autorisation. Nous ne pouvons pas produire d'accusé de réception.
Nous ne faisons donc jamais reposer une obligation sur une seule notification. Quand l'information engage une responsabilité, elle part en plus par un canal qui, lui, donne un état de remise.
Deux choses nous ont coûté plus cher que prévu. La demande d'autorisation, chiffrée comme un appel de fonction alors que c'est un écran de maquette avec un texte à écrire et un moment à choisir. Et la recette, parce qu'un comportement qui dépend de l'état de veille d'un appareil ne se vérifie pas sur un simulateur.
Questions fréquentes
Pourquoi un utilisateur ne reçoit-il pas les notifications push de mon application ?
Peut-on redemander l'autorisation des notifications après un refus ?
Une notification push peut-elle porter une fonctionnalité de l'application ?
Combien coûte l'envoi de notifications push sur une application mobile ?
À votre place, nous n'écririons pas « l'application enverra des notifications ». Nous écririons, message par message, qui le déclenche, ce qu'il contient, à quelle heure il est acceptable, et ce que l'utilisateur voit dans l'application s'il ne l'a jamais reçu. Cette dernière colonne est celle que personne ne remplit, et c'est elle qui détermine si la règle 4.5.4 s'applique contre vous.
Si vous hésitez encore entre une notification de service et une relance commerciale, ce tableau tranchera avant la première maquette. Nous commençons nos missions de développement d'application mobile par le remplir avec vous.
