Notifications push silencieuses : fonctionnement, configuration iOS et Android, cas d'usage

La plupart des guides sur les notifications push se concentrent sur les messages que vos utilisateurs voient. Les notifications push silencieuses, elles, ne sont jamais affichées — et elles remplissent une tout autre mission.

Une notification push silencieuse réveille votre application en arrière-plan, exécute une tâche, puis la remet en veille. Aucune alerte, aucun son, aucun badge. L’utilisateur ouvre l’application et y trouve un contenu déjà actualisé. Il ne soupçonne même pas qu’une notification a été envoyée. C’est précisément l’objectif.

Ce guide explique comment fonctionnent les notifications push silencieuses sur iOS et Android, à quoi ressemble leur implémentation dans le code, et comment les exploiter de manière stratégique au sein de vos parcours client automatisés. Vous découvrirez au passage comment Pushwoosh gère la diffusion cross-plateforme des push silencieuses et l’intègre dans des workflows automatisés — un atout pour les équipes mobile-first du marché français, où la parité iOS/Android impose de maîtriser les deux environnements.

Qu’est-ce qu’une notification push silencieuse ?

Les notifications push silencieuses sont des messages initiés par le serveur qui réveillent une application en arrière-plan sans rien afficher à l’utilisateur. Aucune alerte, aucun son, aucun badge. Le système d’exploitation reçoit la notification, active brièvement l’application, celle-ci exécute sa tâche en arrière-plan, puis se remet en veille.

Le contraste avec une notification standard est simple : une push visible est un message adressé à l’utilisateur ; une push silencieuse est une instruction adressée à l’application.

Que peut faire une application pendant ces quelques secondes en arrière-plan ?

• Récupérer du nouveau contenu. Charger les derniers articles, un catalogue produit mis à jour ou un fil d’actualité rafraîchi, afin qu’ils soient prêts à l’ouverture de l’application.
• Synchroniser les données. Mettre à jour l’état local avec les changements survenus côté serveur ou via d’autres canaux — un achat réalisé sur le site web, un changement de statut dans un système back-end.
• Évaluer la localisation. Vérifier si l’utilisateur est entré ou sorti d’une zone géographique, sans qu’une notification visible serve de déclencheur.
• Mettre à jour les tags ou les données de segment. Renvoyer les derniers signaux comportementaux vers la CDP pour que le ciblage reste précis.
• Préparer le contenu d’une notification visible à venir. Configurer un message in-app ou un payload de rich push pour qu’il s’affiche instantanément au déclenchement.

L’intérêt pratique : l’utilisateur ouvre une application déjà à jour. Pas de roue de chargement, pas de données obsolètes. Cette perception de rapidité et de fraîcheur a un effet mesurable sur la rétention, même lorsque l’utilisateur ne saurait expliquer pourquoi l’application lui semble si agréable à utiliser.

Comment fonctionnent les notifications push silencieuses

La chaîne de diffusion est identique à celle d’une notification push classique : votre serveur envoie un payload à APNs (iOS) ou FCM (Android), le service le transmet à l’appareil, le système d’exploitation l’exécute. Ce qui change, c’est la structure du payload et la réaction du système à sa réception.

Le flux de diffusion

1. Le serveur envoie le payload. Votre back-end ou Pushwoosh envoie un message spécialement construit à APNs ou FCM.
2. Le service le transmet à l’appareil. APNs ou FCM achemine le payload vers le bon appareil grâce au device token stocké.
3. Le système réveille l’application. En reconnaissant les indicateurs de push silencieuse dans le payload, le système active brièvement l’application en arrière-plan.
4. L’application exécute la tâche en arrière-plan. Votre code s’exécute : récupération de données, synchronisation d’état, vérification de localisation, mise à jour d’un tag.
5. L’application signale la fin de la tâche. Sur iOS, l’application appelle un completion handler. Sur Android, onMessageReceived() retourne. Le système remet l’application en veille.

La fenêtre d’exécution en arrière-plan est limitée. iOS accorde environ 30 secondes. Sur Android, la durée varie selon l’appareil et son état d’alimentation. Les tâches en arrière-plan doivent être rapides ou conçues pour fonctionner dans ces contraintes.

Différences de payload : iOS vs Android

L’erreur la plus fréquente sur iOS consiste à oublier de définir apns-priority: 5 en plus de apns-push-type: background. Si la priorité est fixée à 10 (la valeur par défaut des push visibles), Apple peut rejeter le message ou l’afficher visuellement, même sans corps d’alerte. C’est la priorité basse qui signale à APNs qu’il s’agit d’une tâche d’arrière-plan, et non d’une notification urgente.

Sur Android, la règle critique est plus simple : aucun objet notification dans le payload FCM. Si un objet notification est présent, Android le traite comme une notification push classique et l’affiche. Push silencieuse = data uniquement.

Implémentation iOS

Configuration dans Xcode

Activez les Background Modes dans Xcode avant d’écrire la moindre ligne de code :

1. Ouvrez votre projet et sélectionnez la cible de votre application.
2. Rendez-vous dans ‘Signing & Capabilities’ et cliquez sur ’+ Capability’.
3. Ajoutez ‘Background Modes’ et cochez ‘Remote Notifications’.

Votre App ID sur l’Apple Developer Portal doit avoir les Push Notifications activées. Régénérez vos provisioning profiles après cette modification.

Enregistrement pour les notifications distantes

Les push silencieuses nécessitent toujours l’enregistrement de l’appareil auprès d’APNs. Gérez cela dans AppDelegate :

import UIKit
import UserNotifications

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions:
            [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        UNUserNotificationCenter.current().delegate = self
        UNUserNotificationCenter.current().requestAuthorization(
            options: [.badge, .sound, .alert]
        ) { granted, _ in
            if granted {
                DispatchQueue.main.async {
                    application.registerForRemoteNotifications()
                }
            }
        }
        return true
    }

    func application(_ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        let token = deviceToken.map {
            String(format: "%02.2hhx", $0) }.joined()
        // Le SDK iOS de Pushwoosh gère automatiquement la soumission du token
    }
}

Traiter la push silencieuse

Voici la méthode appelée par iOS lorsqu’une push silencieuse arrive :

extension AppDelegate {

    func application(_ application: UIApplication,
        didReceiveRemoteNotification userInfo: [AnyHashable: Any],
        fetchCompletionHandler completionHandler:
            @escaping (UIBackgroundFetchResult) -> Void) {

        guard let aps = userInfo["aps"] as? [String: AnyObject],
              aps["content-available"] as? Int == 1 else {
            completionHandler(.noData)
            return
        }

        // Exécutez ici votre tâche en arrière-plan
        fetchLatestContent { success in
            completionHandler(success ? .newData : .noData)
        }
    }
}

Appelez toujours completionHandler avant la fermeture de la fenêtre de 30 secondes. Faute de quoi, iOS peut arrêter l’application et limiter les futures push silencieuses. Transmettez .newData si vous avez récupéré quelque chose, .noData si rien n’a changé, .failed si la tâche a échoué.

Payload APNs pour une push silencieuse

{
    "aps": {
        "content-available": 1
    },
    "update_type": "content_refresh",
    "content_id": "latest_feed"
}

En-têtes APNs requis avec ce payload :

• apns-push-type: background
• apns-priority: 5

Implémentation Android

Configuration FCM et manifeste

Ajoutez le FirebaseMessagingService à votre AndroidManifest.xml :

<service
    android:name=".MyFirebaseMessagingService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>

Traiter les data messages en Kotlin

Étendez FirebaseMessagingService et implémentez onMessageReceived :

class MyFirebaseMessagingService : FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        // Le SDK Android de Pushwoosh gère automatiquement la soumission du token
    }

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        // Push silencieuse = payload data uniquement, aucun objet notification
        if (remoteMessage.data.isNotEmpty()
            && remoteMessage.notification == null) {
            handleSilentPush(remoteMessage.data)
        }
    }

    private fun handleSilentPush(data: Map<String, String>) {
        when (data["update_type"]) {
            "content_refresh" -> {
                // Récupère le nouveau contenu depuis votre serveur
                refreshContentFeed(data["content_id"])
            }
            "segment_update" -> {
                // Renvoie les tags mis à jour vers Pushwoosh
                syncUserSegmentData()
            }
            "location_check" -> {
                // Évalue le statut de la zone géographique courante
                evaluateGeofences()
            }
        }
    }
}

Payload FCM pour une push silencieuse

Le payload doit contenir un objet data et aucun objet notification :

{
    "to": "DEVICE_TOKEN",
    "data": {
        "update_type": "content_refresh",
        "content_id": "latest_news_feed"
    }
}

Ne définissez la priorité sur ‘high’ que pour les tâches d’arrière-plan urgentes. La priorité standard convient à la plupart des cas de rafraîchissement de contenu et évite un impact inutile sur la batterie.

Push silencieuses cross-plateforme avec Pushwoosh

Gérer les push silencieuses manuellement sur iOS et Android, c’est maintenir deux formats de payload distincts, deux jeux d’en-têtes de diffusion et deux intégrations SDK. Pushwoosh fait abstraction de cette complexité — un avantage déterminant sur un marché français où la base d’appareils se répartit à parts quasi égales entre iOS et Android, et où les deux plateformes doivent être traitées à parité.

Lorsque vous déclenchez une push silencieuse via Pushwoosh — depuis l’interface ou l’API — la plateforme génère automatiquement le payload adapté à chaque plateforme cible. APNs reçoit content-available: 1 avec les bons en-têtes. FCM reçoit un message data-only. Vous configurez la campagne une seule fois.

La gestion des device tokens est centralisée. Les tokens iOS, les tokens Android et les abonnements web push sont tous stockés et mis à jour au même endroit. Lorsqu’un token change (réinstallation, mise à jour de l’OS), Pushwoosh gère le rafraîchissement.

Pour les membres non techniques de l’équipe, Pushwoosh propose une interface permettant de planifier et de déclencher des push silencieuses sans écrire de payload. Il devient ainsi possible d’intégrer les push silencieuses dans les workflows du Customer Journey Builder, aux côtés des notifications visibles et des messages in-app.

Cas d’usage stratégiques

Les notifications push silencieuses sont les plus utiles lorsque la visibilité jouerait en réalité contre vous. Voici les scénarios où elles s’imposent face à une push standard.

Préchargement de contenu pour les apps médias et de presse

Le secteur des médias et de l’édition numérique connaît une forte croissance en France, et les applications de presse en sont un cas d’usage emblématique. Une app d’actualité qui envoie une alerte « breaking news » a tout intérêt à la faire précéder d’une push silencieuse 30 secondes plus tôt. Cette push silencieuse réveille l’application, qui récupère l’article et le met en cache localement. Lorsque l’alerte visible se déclenche, un simple appui ouvre l’article instantanément. Plus besoin d’attendre le chargement du sujet — un atout décisif pour un quotidien numérique qui rivalise sur la vitesse de publication.

Pour les applications à fil personnalisé, une push silencieuse envoyée aux heures de réveil habituelles précharge le contenu du matin avant même que l’utilisateur n’ouvre l’application. L’app paraît rapide parce qu’elle l’est réellement — les données sont déjà là.

Évaluation de géofence sans déclencheur visible

Un utilisateur passe à proximité d’un magasin. L’approche standard : envoyer une notification push géolocalisée. Le problème : l’utilisateur doit avoir donné son consentement, le timing peut être inopportun, et il risque de se sentir surveillé — une sensibilité particulièrement marquée sur le marché français, où la culture du RGPD et la vigilance à l’égard du suivi sont élevées.

L’approche par push silencieuse : le serveur envoie une push silencieuse lorsque l’utilisateur se trouve dans une région donnée. L’application vérifie la géofence précise côté client. Si les conditions sont réunies, l’application active un message in-app ou une notification locale au bon moment. La communication visible n’a lieu que si la logique le valide — elle n’est pas le déclencheur en soi. Ce modèle respecte mieux le sentiment de maîtrise des données auquel le public français est attaché.

Maintenir des données de segment exactes après une activité hors app

Un utilisateur effectue un achat sur votre site web. Son segment RFM devrait se mettre à jour immédiatement. Mais l’application ne le sait pas tant que l’utilisateur ne l’ouvre pas.

Une push silencieuse envoyée après l’achat web réveille l’application en arrière-plan, qui synchronise le dernier événement d’achat avec Pushwoosh. L’utilisateur bascule dans le bon segment RFM en temps réel. Une campagne de relance — récompense de fidélité, cross-sell, séquence de remerciement — se déclenche alors sur la base de données exactes. C’est un mécanisme précieux pour l’e-commerce français lors des temps forts comme les Soldes, les French Days ou le Black Friday, où la cohérence entre achat web et application conditionne la pertinence des relances.

Préchargement du contenu des messages in-app

Les messages in-app qui nécessitent une requête serveur pour s’afficher peuvent accuser une latence notable. Une push silencieuse envoyée avant le déclenchement attendu du message in-app précharge le contenu et le stocke localement. Au déclenchement, le message s’affiche immédiatement.

Ce modèle fonctionne particulièrement bien pour les parcours d’onboarding, les annonces de fonctionnalités et les overlays promotionnels, lorsque le contenu est personnalisé et ne peut pas être codé en dur dans le binaire de l’application.

Bonnes pratiques

Respecter les limites de throttling de l’OS

iOS limite les push silencieuses qui arrivent trop fréquemment. Les recommandations d’Apple tournent autour de 2 à 3 par heure, soit une toutes les 21 minutes au plus. Les applications qui dépassent ce seuil voient leurs push silencieuses retardées ou supprimées, sans la moindre erreur.

Le mode Doze et l’App Standby d’Android restreignent l’exécution en arrière-plan lorsque l’appareil est inactif. Les messages FCM en priorité haute peuvent réveiller l’application pendant le Doze, mais doivent être utilisés avec parcimonie. Les messages en priorité standard sont différés jusqu’à la sortie du mode Doze.

La règle pratique : n’envoyez des push silencieuses que lorsque la tâche d’arrière-plan est réellement urgente. Précharger du contenu à un rythme naturel (le matin, ou après une mise à jour côté serveur) est tout à fait acceptable. En envoyer une toutes les 10 minutes pour garder les données fraîches ne l’est pas.

Garder des payloads légers et des tâches rapides

Le payload d’une push silencieuse doit être un signal, pas un transfert de données. Envoyez le strict nécessaire pour indiquer à l’application quoi récupérer et où. La récupération effective des données se fait à l’intérieur de l’application, une fois la push arrivée.

Les tâches d’arrière-plan doivent s’achever bien avant la limite de temps. Si une tâche requiert plus de quelques secondes, concevez-la comme interruptible : enregistrez la progression, appelez le completion handler, et reprenez à la prochaine occasion. Les tâches d’arrière-plan trop longues risquent l’arrêt par l’OS et peuvent affecter l’autonomie au point que les utilisateurs le remarquent.

Tester selon les états d’alimentation et les variantes constructeurs

Le comportement des push silencieuses varie considérablement selon les constructeurs Android. Xiaomi, Huawei et OnePlus appliquent tous une optimisation agressive de la batterie, susceptible d’empêcher totalement l’exécution en arrière-plan pour les applications non mises en liste blanche. Testez sur de vrais appareils de ces fabricants, et pas seulement sur des émulateurs Android standard.

Sur iOS, testez en mode économie d’énergie et avec l’application forcée à quitter. La diffusion des push silencieuses dans ces états est moins fiable, et votre logique d’arrière-plan doit gérer le cas où la tâche ne s’est pas exécutée avant l’ouverture de l’application par l’utilisateur.

Mesurer l’efficacité via les événements en aval

Les push silencieuses ne produisent pas de métriques de clic. Mesurez leur efficacité à travers les événements qu’elles sont censées déclencher : content_refreshed, segment_updated, geofence_evaluated. Si ces événements cessent de se déclencher au rythme attendu après une campagne de push silencieuses, c’est que la diffusion est limitée ou que le handler d’arrière-plan échoue.

Pushwoosh Analytics fait apparaître les événements de l’application aux côtés des données de campagne. Reliez les événements de fin de tâche d’arrière-plan aux envois de push silencieuses pour confirmer que le pipeline fonctionne.

Intégrer dans l’automatisation des parcours, pas en envois ponctuels

Une push silencieuse envoyée isolément est une opération technique. Une push silencieuse intégrée à un Customer Journey est une opération stratégique. Les modèles les plus utiles emploient les push silencieuses comme une étape qui prépare une meilleure interaction visible en aval : mettre à jour le segment avant la push promotionnelle, précharger le contenu avant le message in-app, évaluer la géofence avant l’alerte géolocalisée.

Le Customer Journey Builder de Pushwoosh prend en charge les push silencieuses comme étapes de parcours, aux côtés des notifications visibles et des messages in-app.

Améliorez la fraîcheur de votre app et la précision de vos campagnes avec Pushwoosh

Les notifications push silencieuses constituent la couche d’infrastructure qui sous-tend de meilleures expériences utilisateur. Contenu frais à l’ouverture, données de segment exactes, interactions déclenchées par géofence sans accroc — rien de tout cela ne fonctionne de façon fiable sans mises à jour de l’application en arrière-plan.

Pushwoosh gère la diffusion cross-plateforme des push silencieuses, le formatage des payloads, la gestion des tokens et l’intégration au Customer Journey — le tout avec une conformité RGPD native et des centres de données en UE, un prérequis pour les secteurs sensibles comme la FinTech sur le marché français. Les développeurs bénéficient d’abstractions SDK propres ; les équipes marketing disposent de la push silencieuse comme étape à part entière de leurs workflows automatisés.