Notifications Push dans le développement mobile : essence, types et fonctionnement

Que sont les notifications push ?

Une notification push est un message que le serveur envoie à un appareil mobile sans demande de l'application. Le message passe par un service cloud (FCM ou APNS) qui le délivre à l'appareil même si l'application est fermée. Les notifications sont divisées en deux types : les notifications d'affichage (montrées à l'utilisateur) et les notifications de données (transmettent des données pour un traitement en arrière-plan).

L'architecture des notifications push comprend trois composants : (1) le serveur de l'application — envoie une requête à FCM/APNS ; (2) le service cloud — achemine la notification ; (3) l'application cliente — reçoit et traite la notification. Le serveur doit connaître le Device Token de l'appareil pour lui envoyer une notification spécifiquement. Pour les envois massifs, on utilise Topic Subscription — l'abonnement des appareils à des canaux thématiques (actualités, promotions, météo).

Sur chaque appareil, les notifications sont traitées par le système d'exploitation : Android — via NotificationManager et NotificationChannel, iOS — via UNUserNotificationCenter. L'utilisateur peut configurer le comportement des notifications pour chaque canal : autoriser le son, les bannières, l'affichage sur l'écran de verrouillage ou désactiver complètement. Une configuration correcte des canaux augmente l'engagement et réduit les taux de désabonnement.

Chez IT Sectr, nous concevons le système de notifications push en tenant compte des spécificités de la plateforme dès le début. Décisions clés : choix entre FCM et APNS direct, format du payload, fréquence d'envoi et mécanique d'abonnement. Cela permet d'éviter les situations où les notifications n'arrivent pas ou sont bloquées par le système.

FCM vs APNS

Firebase Cloud Messaging (FCM) est le service multiplateforme de Google pour la livraison de notifications. FCM prend en charge Android, iOS, Web et Flutter. Sur iOS, FCM fonctionne via APNS : FCM envoie une requête à APNS, qui délivre la notification à l'appareil. Avantages de FCM : une API unique pour les deux plateformes, analyses intégrées, tests A/B, sujets et segments d'audience.

Apple Push Notification Service (APNS) est le service natif d'Apple. Il fonctionne uniquement sur les appareils Apple (iOS, macOS, watchOS, tvOS). Il nécessite une autorisation directe via un certificat TLS ou un jeton (JWT). APNS fournit une latence de livraison minimale et une intégration directe avec les fonctionnalités iOS : PushKit, Notification Service Extension et les alertes critiques.

Le choix entre FCM et APNS dépend de l'architecture du projet. Si l'application est uniquement pour iOS — APNS offre plus de contrôle. Si elle est multiplateforme — FCM est plus pratique avec une API unique. De nombreux projets utilisent FCM comme service principal et configurent en plus PushKit pour VoIP sur iOS. Une approche hybride permet d'obtenir le meilleur des deux systèmes.

Types de notifications (Rich, Silent, Interactive)

Rich Notification (Notification enrichie)

Une Rich Notification est une notification qui contient non seulement du texte mais aussi du contenu multimédia : images, vidéos, audio et boutons d'action. Sur Android, elle est implémentée via les styles NotificationCompat : BigPictureStyle (grande image), BigTextStyle (texte réduit/développé), InboxStyle (liste de messages), MediaStyle (contrôle de lecture). Sur iOS, on utilise Notification Content Extension — une cible séparée avec une UI personnalisée pour la notification développée.

Silent Push (Notification silencieuse)

Silent Push (content-available sur iOS) est une notification livrée sans être affichée à l'utilisateur. Elle est destinée à la mise à jour des données en arrière-plan : synchronisation de contenu, préchargement, mise à jour des widgets. Sur iOS, Silent Push nécessite l'activation de Background Modes → Remote notifications. Sur Android, FirebaseMessagingService avec onMessageReceived est utilisé pour gérer les notifications en arrière-plan. Important : sur iOS, Silent Push a des limitations de fréquence et ne garantit pas la livraison si l'application n'est pas au premier plan.

Interactive Notification (Notification interactive)

Une Interactive Notification permet à l'utilisateur d'effectuer une action sans ouvrir l'application. Sur Android, ce sont des boutons (Action) dans la notification : "Répondre", "Approuver", "Refuser". Les actions sont traitées via PendingIntent, qui lance un BroadcastReceiver ou Service. Sur iOS, Notification Action est enregistrée via UNNotificationAction et UNNotificationCategory. Les boutons peuvent être foreground (ouvre l'application), background (exécute en arrière-plan) ou destructive (action irréversible — supprimer, bloquer).

Notification Content Extension et Service Extension

Notification Content Extension (iOS) — un contrôleur de vue personnalisé pour afficher le contenu étendu de la notification lors d'un appui long ou 3D Touch. Notification Service Extension (iOS) — middleware pour modifier le contenu de la notification avant l'affichage : déchiffrer les messages E2E, charger des images, obscurcir les données confidentielles. Sur Android, il n'y a pas d'analogue direct — toutes les modifications sont effectuées dans FirebaseMessagingService.

Configuration des notifications sur Android et iOS

Configuration sur Android

Pour Android, il faut : (1) ajouter le SDK Firebase au projet (google-services.json) ; (2) créer un NotificationChannel (Android 8+) pour chaque catégorie de notifications ; (3) implémenter FirebaseMessagingService pour recevoir les jetons et les messages entrants. Notification Channel est obligatoire — sans lui, les notifications ne s'afficheront pas sur Android 8+. Les canaux ont une priorité (IMPORTANCE_HIGH — son + popup, IMPORTANCE_LOW — sans son) et sont configurables par l'utilisateur dans les paramètres système.

Configuration sur iOS

Pour iOS, il faut : (1) activer la capacité Push Notifications dans Xcode ; (2) configurer la clé APNS sur l'Apple Developer Portal ; (3) demander l'autorisation via UNUserNotificationCenter.requestAuthorization — c'est une boîte de dialogue système qui s'affiche une fois. La réponse de l'utilisateur est critique : si l'autorisation n'est pas accordée, les notifications ne seront pas délivrées. Il est recommandé d'expliquer à l'utilisateur pourquoi les notifications sont nécessaires avant d'afficher la boîte de dialogue système (pre-permission prompt).

Outils et Token

Device Token (iOS) et Registration Token (Android) sont des identifiants uniques d'appareil pour les notifications push. Le jeton est généré au premier lancement de l'application et peut changer : lors de la réinstallation, de l'effacement des données ou de la réinitialisation des paramètres de confidentialité. Le serveur doit mettre à jour les jetons régulièrement. Firebase fournit une API pratique pour la gestion des jetons via onNewToken, ainsi qu'un panneau pour l'envoi de notifications de test (Firebase Console → Cloud Messaging).

Topic Subscription est l'un des mécanismes les plus efficaces de FCM. Un appareil s'abonne à un sujet (par exemple, "news", "promo_users_ios") et le serveur envoie des notifications par sujet sans avoir besoin de stocker une liste de jetons. Firebase Topics prend en charge jusqu'à un million d'abonnés par sujet et l'envoi conditionnel (Condition) via un langage d'expression : "'news' in topics && ('US' in topics || 'UK' in topics)".

Notification Payload est la structure JSON envoyée via FCM/APNS. Pour FCM : notification séparée (partie visible — titre, corps, image) et data (champs personnalisés pour l'application). Pour APNS : dictionnaire aps avec alert, badge, sound, category et content-available. La structure correcte du payload est critique : si notification + data arrivent simultanément, l'application en arrière-plan peut ne pas recevoir les données. Il est recommandé d'utiliser uniquement des messages data pour Android et de passer les champs visuels séparément via la FCM Console.