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

Que sont les notifications Push?

Les notifications Push sont des messages courts que le serveur de l’application envoie à l’appareil de l’utilisateur sans demande explicite. Elles apparaissent sous forme de bannières, de badges d’icône ou de signaux sonores, attirant l’attention de l’utilisateur vers l’application et l’informant des événements importants.

Définition et objectif

Une notification Push se compose d’un titre, d’un corps de message et de données facultatives (payload). Contrairement aux SMS, les notifications Push sont gratuites pour l’utilisateur et sont livrées via l’infrastructure de services cloud — FCM pour Android et APNS pour iOS. Les principaux objectifs des notifications Push sont : augmenter l’engagement, informer des événements et ramener l’utilisateur dans l’application.

Les statistiques d’utilisation montrent que les notifications Push correctement configurées augmentent la rétention de l’application de 30 à 60%. Cependant, une fréquence excessive de notifications entraîne des désabonnements — plus de 60% des utilisateurs désactivent les notifications si elles sont envoyées plus de trois fois par jour.

Architecture du système Push

Un système Push comprend trois composants : le serveur d’application, le service de plateforme (FCM/APNS) et l’application cliente sur l’appareil. Le serveur envoie une requête au service de plateforme, qui livre la notification à l’appareil cible via une connexion persistante avec le système d’exploitation.

Comment fonctionnent les notifications Push?

Le mécanisme de livraison des notifications Push est basé sur une connexion persistante entre l’appareil et le service de plateforme. Le système d’exploitation maintient un canal de communication chiffré par lequel transitent tous les messages Push.

Inscription et obtention du jeton

Au premier lancement, l’application demande l’autorisation d’envoyer des notifications et reçoit un jeton d’appareil unique de FCM ou APNS. Ce jeton est une chaîne allant jusqu’à 4 Ko qui identifie de manière unique l’instance de l’application. Le jeton change lors de la réinstallation de l’application ou de la restauration de l’appareil à partir d’une sauvegarde.

class FirebaseMessagingService :
    FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        sendTokenToServer(token)
    }

    override fun onMessageReceived(
        message: RemoteMessage
    ) {
        showNotification(message.notification)
    }
}

Envoi via le serveur d’application

Le serveur d’application envoie une requête HTTP à l’API FCM ou à l’API APNS, en spécifiant le jeton cible, le titre, le corps et les données supplémentaires. Le service de plateforme répond avec un statut de livraison : succès, jeton invalide (l’appareil a désinstallé l’application) ou limite de débit dépassée.

fetch("https://fcm.googleapis.com/fcm/send", {
    method: "POST",
    headers: {
        "Authorization": "key=AIzaSy...",
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        to: "device_token_here",
        notification: {
            title: "Nouveau message",
            body: "Vous avez une nouvelle notification!"
        }
    })
})

FCM vs APNS: Comparaison des plateformes

Le choix entre FCM et APNS dépend de la plateforme cible. FCM prend en charge Android et iOS, tandis qu’APNS ne prend en charge que l’écosystème Apple. Examinons les principales différences importantes pour le développement d’applications mobiles multiplateformes.

Firebase Cloud Messaging (FCM)

FCM est un service Google fonctionnant sur Google Play Services. Il prend en charge deux schémas de livraison : les notifications avec affichage automatique et les notifications de données que l’application gère elle-même. FCM est gratuit et n’a pas de limite sur le nombre de messages envoyés.

Apple Push Notification Service (APNS)

APNS est le service d’Apple avec prise en charge des pièces jointes multimédias (images, vidéo, audio) jusqu’à 10 Mo. L’envoi via APNS nécessite un certificat TLS ou une clé d’authentification. APNS limite la fréquence d’envoi à un seul appareil — pas plus de 150 notifications par minute, après quoi la limitation de débit s’active.

Types de notifications Push

Les notifications Push sont classées par méthode d’affichage et objectif. Comprendre les types aide à choisir la bonne stratégie pour chaque scénario d’interaction utilisateur.

Notifications d’affichage (Display Notifications)

Le type le plus courant — une notification affichée avec un titre et un corps. Le système d’exploitation l’affiche automatiquement dans le panneau de notifications, sur l’écran de verrouillage et sous forme de bannière. Le développeur peut configurer le son, la vibration, le badge d’icône et les boutons d’action pour des actions directes (répondre, ouvrir, ignorer).

Notifications de données (Data Notifications)

Les notifications de données contiennent uniquement le payload sans affichage visuel. L’application les traite en arrière-plan : synchronise les données, met à jour le cache ou lance des téléchargements. Sur Android, les notifications de données sont livrées de manière fiable ; sur iOS, uniquement lorsque l’application est active ou via l’actualisation en arrière-plan.

Notifications multimédias et enrichies

Les systèmes d’exploitation mobiles modernes prennent en charge les notifications enrichies et multimédias avec images, GIF, vidéo et audio. Sur iOS, cela est implémenté via UNNotificationAttachment ; sur Android, via BigPictureStyle et InboxStyle pour personnaliser l’apparence de la notification dans le panneau système.

Notifications silencieuses (Silent)

Les notifications silencieuses ne sont pas affichées à l’utilisateur et sont utilisées pour la synchronisation en arrière-plan. Sur iOS, elles ont une priorité élevée pour des tâches comme la mise à jour des données avant d’ouvrir l’application. Android les traite comme des notifications de données avec une priorité minimale.

Configuration des notifications Push dans un projet

La configuration des notifications Push nécessite des actions au niveau de l’infrastructure, du serveur et du code client. Examinons le processus typique pour un projet mobile multiplateforme.

Configuration FCM pour Android

Pour Android, vous devez créer un projet dans la Firebase Console, ajouter google-services.json au projet et configurer FirebaseMessagingService. Le jeton d’appareil est obtenu via FirebaseInstanceId ou FirebaseMessaging.getInstance().token, puis envoyé au serveur via l’API au premier lancement ou lors de son changement.

Configuration APNS pour iOS

Pour iOS, un abonnement Apple Developer Program, la création d’un certificat Push ou d’une clé APNS dans le Developer Portal, et l’activation de la capacité Push Notifications dans Xcode sont nécessaires. L’inscription aux notifications se fait via UIApplication.shared.registerForRemoteNotifications avec réception du deviceToken dans AppDelegate.

import UIKit
import UserNotifications

@main
class AppDelegate: UIResponder,
    UIApplicationDelegate {

    func application(
        _ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken
        deviceToken: Data
    ) {
        let token = deviceToken
            .map { String.format("%02x", $0) }
            .joined()
        // envoyer le jeton à votre serveur
    }
}

Envoi côté serveur

Côté serveur, les notifications Push sont envoyées via l’API REST ou le SDK Admin. FCM utilise le SDK Admin Firebase (disponible pour Node.js, Java, Python, Go), tandis qu’APNS utilise des bibliothèques pusher (pushy pour Java, apn2 pour Node.js). Il est recommandé de stocker les jetons dans une base de données avec un horodatage de la dernière mise à jour.

Sécurité des notifications Push

La sécurité des notifications Push est cruciale, car des données confidentielles peuvent être transmises via elles. Les deux plateformes fournissent des mécanismes de protection de base, mais le développeur doit les utiliser correctement.

Chiffrement du payload

Le payload d’une notification Push peut contenir des données personnelles des utilisateurs : noms, montants de transactions, liens de messages. Même si le canal de communication entre FCM/APNS et l’appareil est chiffré, les données peuvent être interceptées au niveau de l’application si un logiciel tiers intercepte la notification. Il est recommandé de chiffrer le payload sensible sur le serveur avec AES-256 et de le déchiffrer sur l’appareil avec une clé stockée dans Keychain (iOS) ou EncryptedSharedPreferences (Android).

Validation des jetons sur le serveur

Le jeton d’appareil est un identifiant de session qui peut être compromis en cas de piratage de l’appareil ou d’interception du trafic. Le serveur d’application doit valider les jetons avant l’envoi : les vérifier dans la base de données, suivre les jetons inactifs et les supprimer en cas d’erreurs InvalidToken répétées. FCM et APNS renvoient le statut InvalidRegistration pour les jetons invalides — ne l’ignorez pas.

Protection contre le spam de notifications

Sans contrôle de fréquence, les notifications Push peuvent devenir un outil de spam qui irrite les utilisateurs et réduit la rétention. Définissez des limites côté serveur : pas plus de 5 notifications par heure pour un seul utilisateur et pas plus de 3 messages identiques. Pour les notifications transactionnelles (confirmation de commande, changement de mot de passe), les limites peuvent être plus élevées — jusqu’à 10 par heure, car elles contiennent des informations critiques. Utilisez la limitation de débit au niveau de l’API d’envoi afin qu’un attaquant ne puisse pas déclencher des notifications de masse via votre serveur.