Que sont les notifications push (APNs et FCM) ?

Une notification push est un message initié par le serveur que les services push de la plateforme livrent à l’appareil, même quand l’application est fermée. Les équipes produit connaissent le push comme canal d’engagement ; cette entrée couvre la machinerie de livraison — parce que la machinerie explique chacune des bizarreries dont les équipes produit se plaignent. Le fait central : votre serveur ne parle jamais au téléphone. Chaque OS mobile maintient exactement une connexion persistante, optimisée pour la batterie, vers la passerelle push de son fournisseur — APNs (Apple Push Notification service) pour les appareils Apple, FCM pour Android — et chaque notification de chaque application emprunte ce tuyau partagé.

Points clés

La chaîne de livraison, de bout en bout

1  L'application demande à l'OS de s'enregistrer pour le push
2  Le service push de la plateforme émet un DEVICE TOKEN (l'adresse)
3  L'application envoie le token à VOTRE backend, qui le stocke
4  Un événement survient → le backend POSTe { token, payload ≤4 Ko } à APNs / FCM
5  Le service push trouve la connexion persistante de l'appareil → livre
6  L'OS affiche la notification — ou réveille brièvement l'application pour un push silencieux

Le second métier de FCM : avec des identifiants APNs déposés, il accepte une requête
et en réémet une conforme à APNs pour les appareils Apple —
une seule surface d'API pour les deux plateformes. Un BaaS abstrait même cela.

Les deux moitiés en code — le client qui enregistre son adresse, le backend qui envoie sur un canal :

// JavaScript — Cloud Code (cloud/main.js)
// One send call reaches both platform push services
await Parse.Push.send({
  channels: ['scores'], // or `where:` with an Installation query
  data: {
    alert: 'Kickoff! Follow the match live.',
    badge: 'Increment',
    uri: 'app://match/8fk2',
  },
}, { useMasterKey: true });
// Back4app routes to APNs for Apple devices and FCM for Android — one API

// Flutter / Dart — Back4app Flutter SDK
// Register this install for push: token + channels live in an Installation
final installation = await ParseInstallation.currentInstallation();
installation
  ..set('channels', ['scores']) // subscribe to a topic-like channel
  ..set('user', currentUser);   // enables targeting by user later
await installation.save();
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs or FCM directly.

// iOS / Swift — Back4app Swift SDK
// Register this install for push: token + channels live in an Installation
var installation = ParseInstallation.current
installation?.channels = ["scores"] // topic-like channel
installation?.user = currentUser    // enables targeting by user later
try await installation?.save()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs directly.

// Android / Kotlin — Back4app Android SDK
// Register this install for push: token + channels live in an Installation
val installation = ParseInstallation.getCurrentInstallation()
installation.put("channels", listOf("scores")) // topic-like channel
installation.put("user", ParseUser.getCurrentUser()) // target by user later
installation.saveInBackground()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching the push services directly.

Les tokens d’appareil : l’adresse qui n’arrête pas de changer

Le cycle de vie du token est le vrai travail du backend, et la partie que les pages explicatives sautent. Enregistrer : l’OS émet un token par installation d’application. Stocker : l’application le synchronise avec votre backend à chaque lancement — les tokens changent silencieusement à la réinstallation, à la restauration et à l’effacement des données. Cibler : les envois adressent des tokens, individuellement ou via le registre. Invalider : les envois vers des tokens morts reviennent avec des erreurs précises — 410 Gone côté APNs, erreurs de token non enregistré côté FCM — et FCM périme les tokens inutilisés pendant environ neuf mois. Élaguer : supprimez sur ces erreurs, immédiatement. Les backends qui sautent la dernière étape accumulent des tables de tokens pourrissants qui gaspillent des envois, faussent les métriques de livraison et ralentissent les campagnes — le problème des tokens périmés est ennuyeux, cumulatif, et c’est le bug de push le plus courant dans la vraie vie.

APNs vs. FCM

La conséquence pratique de la première ligne : tout backend multiplateforme soit intègre les deux services, soit utilise FCM comme surface unique (en y déposant les identifiants APNs), soit confie tout le problème à une plateforme qui détient les deux jeux d’identifiants — ce qui nous amène à la section BaaS.

Ce que le push ne promet pas

Le contrat honnête, rassemblé en un seul endroit. Un 200 du service push signifie accepté pour livraison, pas livré. Les appareils hors ligne n’accumulent pas une file fidèle : APNs ne garde que la notification la plus récente par application ; la file de FCM expire selon un TTL. Les optimiseurs de batterie sur Android reportent la livraison d’une manière que vous ne contrôlez pas ; les utilisateurs peuvent faire taire un canal ou l’application entière au niveau de l’OS, invisiblement pour votre backend. Les pushs silencieux — des réveils d’arrière-plan sans alerte visible — tournent sur un budget horaire minuscule et sont abandonnés sans erreur au-delà, d’après les recommandations d’Apple elles-mêmes ; ce sont des indices de rafraîchissement, pas un protocole de synchronisation. La règle de conception qui en découle : le push est la tape sur l’épaule — les données elles-mêmes voyagent par votre API à l’ouverture de l’application, et tout ce qui doit absolument arriver obtient un second canal.

Le web push, en bref

Les navigateurs ont normalisé leur propre chaîne : la page s’abonne via la Push API en utilisant votre paire de clés VAPID (RFC 8292 — le serveur s’identifie avec un token signé, sans enregistrement chez un fournisseur), le service push du navigateur renvoie un abonnement (URL d’endpoint + clés de chiffrement), et votre serveur envoie en POST des payloads chiffrés à cet endpoint selon le Web Push Protocol. Un service worker reçoit l’événement push et affiche la notification — site fermé, navigateur peut-être fermé sur ordinateur. Chaque éditeur de navigateur exploite son propre service push ; l’URL d’endpoint indique à votre serveur où faire le POST. La réserve honnête : sur iOS, le web push ne fonctionne que pour les applications web installées sur l’écran d’accueil.

Push vs. WebSockets vs. live queries

Ce sont des compléments avec une seule frontière : le socket sert l’utilisateur qui regarde l’écran ; le push atteint celui qui a posé son téléphone. Les applications de chat démontrent l’hybride tous les jours — les messages circulent sur la connexion tant que l’application est ouverte, et le même message devient un push dès qu’elle ne l’est plus.

Cas d’usage courants

• Messages et mentions — le push canonique : quelqu’un a besoin de vous, l’application est fermée.
• Alertes transactionnelles — commande expédiée, course qui arrive, paiement validé : des résumés d’une ligne avec un lien profond vers l’application.
• Déclencheurs sensibles au temps — changements de score, alertes de prix, moments « X est en direct » proches de la présence.
• Réengagement — à utiliser avec parcimonie, avec des désinscriptions par canal, sinon les utilisateurs désactivent tout.
• Badges et indices d’état — le budget silencieux dépensé à pousser l’application à se rafraîchir avant que l’utilisateur ne l’ouvre.

Devriez-vous pousser ? Matrice de décision

Limites et trade-offs

• La livraison est une probabilité, pas une promesse. Concevez des flux qui survivent à un push manqué ; réconciliez à l’ouverture de l’application.
• La permission ne se demande vraiment qu’une fois. L’invite de l’OS (explicite sur iOS et sur le web, à l’exécution sur Android moderne) convertit mieux quand elle est demandée en contexte — et un refus est quasi irréversible.
• Le registre de tokens est un jeu de données vivant. Synchronisez au lancement, élaguez sur erreur, ou regardez la délivrabilité se dégrader en silence.
• Les payloads sont quasi publics. Les notifications s’affichent sur les écrans verrouillés et traversent une infrastructure tierce — des résumés et des identifiants, jamais des secrets.
• Deux systèmes d’identifiants, une seule fonctionnalité. Clés .p8, identifiants de console, expiration et rotation — la douleur de configuration est réelle, une fois par plateforme, et c’est exactement ce que les couches gérées absorbent.

Le push sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Le service push de Back4app transforme toute la chaîne en données : chaque installation s’enregistre comme un objet Installation — token d’appareil, plateforme, canaux et Pointer vers l’utilisateur capturés automatiquement, comme le montrent les onglets client — et un seul appel d’envoi adresse des canaux (façon topic) ou n’importe quelle requête sur les Installation (« tous ceux du canal scores sur Android qui n’ont pas ouvert l’application cette semaine »), la plateforme détenant vos identifiants APNs et FCM et routant par appareil. Les envois partent de Cloud Code — un afterSave sur Message qui pousse vers le destinataire est la moitié de repli du pattern hybride —, de jobs planifiés, ou de la console du dashboard pour des campagnes ponctuelles. L’hygiène des tokens, les identifiants doubles et les bizarreries de payload par plateforme deviennent un comportement de plateforme ; votre code décide qui et quoi, pas comment.