Sur un mobile, une notification push est un message d’alerte reçu via une application que l’on peut ouvrir, supprimer, autoriser ou bloquer.
Mais qu’en est-il de l’architecture à mettre en place pour intégrer cette fonctionnalité dans une application mobile ? Et quel est le cheminement d’une notification push, de la création à l’affichage sur le mobile de l’utilisateur ?
Architecture technique
Voici les différents éléments nécessaires à la création, l’envoi et la réception d’une notification push mobile :
Le serveur push peut vous appartenir ou être hébergé chez le prestataire de votre application mobile. Une fois installé, l’envoi des notifications est gratuit, hormis les coûts de maintenance du serveur.
Pour créer vos notifications, deux méthodes s’offrent à vous :
- Passer par une interface type back-office ou une simple page web avec un CMS pour rédiger et envoyer manuellement vos notifications.
- Prévoir une automatisation des envois. Par exemple, vous pouvez programmer qu’à chaque fois qu’un de vos utilisateur reçoit un message privé, votre serveur lui envoie une notification.
Une fois créées, vos notifications passent par le serveur de push de la plateforme ciblée (Android ou iOS) qui les redistribuent aux mobiles de vos utilisateurs.
Fonctionnement de l’envoi d’une notification push mobile
Voyons plus précisément les opérations nécessaires pour l’envoi d’une notification mobile :
- À chaque ouverture de l’application mobile, demande d’un identifiant unique (token, URL, ID…) au serveur de sa plateforme pour identifier l’application sur un mobile spécifique ;
- Envoi de l’identifiant unique de la plateforme serveur à l’application mobile
- Transmission de l’identifiant à votre serveur d’envoi qui va être stocké (ou rafraîchi) dans une base de données ;
- Pour l’envoi d’une notification push, votre serveur d’envoi transmet la notification push au serveur plateforme. Pour cela il indique l’identifiant concerné et le message associé.
- Le serveur de la plateforme vérifie les paramètres push (autorisations et identité de l’application) et transmet la notification au mobile ciblé.
- Les serveurs des plateformes envoient immédiatement un rapport de réception des notifications pour mettre la base d’identifiants à jour (selon les désinstallations et la désactivation des notifications) et le serveur iOS fait des rapports moins fréquents à consulter grâce à un service dédié.
Réception sous conditions
Pour chaque requête d’envoi d’une notification par votre serveur, les opérations ci-dessus vont avoir lieu. Mais cela ne signifie pas que votre notification va forcément s’afficher sur le mobile de votre utilisateur. Aucun serveur de plateforme ne peut vous le garantir à 100%. En effet, les utilisateurs de votre application peuvent à tout moment refuser la réception des notifications. Dans ce cas, le processus d’envoi a tout de même lieu, le mobile reçoit bien la notification, mais il ne l’affiche pas.
De même, certaines notifications peuvent se perdre suite à une erreur informatique par exemple ou parce qu’un mobile reste éteint trop longtemps (les notifications peuvent expirer).
Réception push par OS
Pour conclure cet article, voici un tableau récapitulatif des différences qui doivent être prises en compte par rapport aux différentes plateformes.
iOS | Android | |
---|---|---|
Nom du service | APNS : Apple Push Notification Service | GCM : Google Cloud Messaging |
Poids Maximum de la notification | 265k | 4k |
Certificat d’envoi de la notification push | Obligatoire | Non mais il y a une clé d’API |
Autorisation | L’application envoie une seule pop-up de demande d’activation | Lors de l’installation de l’application mobile depuis le Playstore |
Désactivation | Depuis le centre de notifications | Dans les paramètres de l’application mobile |
Formats d’alerte | Message d’alerte Badge Son | Message d’alerte Son Voyant de notification (selon le modèle du mobile) |