Les notifications push mobile, comment ça marche ?

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 ?

notification push

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 :

  1. À 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 ;
  2. Envoi de l’identifiant unique de la plateforme serveur à l’application mobile
  3. Transmission de l’identifiant à votre serveur d’envoi qui va être stocké (ou rafraîchi) dans une base de données ;
  4. 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é.
  5. Le serveur de la plateforme vérifie les paramètres push (autorisations et identité de l’application) et transmet la notification au mobile ciblé.
  6. 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.

 iOSAndroid
Nom du serviceAPNS : Apple Push Notification ServiceGCM : Google Cloud Messaging
Poids Maximum de la notification265k4k
Certificat d’envoi de la notification pushObligatoireNon mais il y a une clé d’API
AutorisationL’application envoie une seule pop-up de demande d’activationLors de l’installation de l’application mobile depuis le Playstore
DésactivationDepuis le centre de notificationsDans les paramètres de l’application mobile
Formats d’alerteMessage d’alerte Badge SonMessage d’alerte Son Voyant de notification (selon le modèle du mobile)