notification push iphone

La notification push est le canal le plus direct entre une application mobile et son utilisateur : un message qui s’affiche sur l’écran du téléphone, même quand l’application est fermée. Bien utilisée, elle ramène les gens dans l’app au bon moment et fait vendre. Mal utilisée, elle agace, puis elle finit en désinstallation. Nous développons des applications mobiles depuis 2014 et nous avons vu les deux scénarios de près. Ce guide couvre les deux faces du sujet : la mécanique technique (Firebase Cloud Messaging côté Google, APNs côté Apple) et l’usage, c’est-à-dire quand notifier, et surtout quand s’abstenir.

Notification push reçue sur l'écran verrouillé d'un iPhone

Notification push : définition et fonctionnement

Une notification push, c’est quoi ?

Une notification push est un message envoyé par le serveur d’une application (ou d’un site web) vers l’appareil d’un utilisateur, sans que celui-ci ait besoin d’ouvrir l’app. Elle sert à transmettre une information au moment où elle est utile : un colis livré, un message reçu, une commande prête, une offre qui expire ce soir.

Selon l’appareil et les réglages, elle prend la forme d’une bannière en haut de l’écran, d’une alerte sur l’écran verrouillé, d’une pastille sur l’icône de l’app, ou d’une vibration sur une montre connectée. Sur iPhone, elle peut aussi alimenter la Dynamic Island et les Live Activities, ces affichages qui suivent en direct une livraison ou un score de match.

FCM et APNs : les deux passages obligés de toute notification push

Point technique essentiel : votre serveur n’envoie jamais une notification directement au téléphone. Il passe par le service de push de la plateforme, qui maintient en permanence une connexion avec chaque appareil.

Il en existe deux qui comptent. APNs (Apple Push Notification service) est le service d’Apple pour iPhone, iPad, Mac et Apple Watch : aucune notification n’atteint un appareil Apple sans transiter par lui. Firebase Cloud Messaging (FCM) est le service de Google : il livre nativement sur Android et sur le web, et il sait aussi relayer vers les appareils Apple en s’appuyant sur APNs. C’est pour cela que la plupart des projets utilisent FCM comme point d’entrée unique : une seule intégration côté serveur pour toucher Android, iOS et le navigateur.

Dans les deux cas, chaque installation de l’application reçoit un jeton unique (registration token chez FCM, device token chez APNs). C’est cet identifiant que votre backend stocke et utilise pour cibler un appareil précis.

La permission d’abord : l’utilisateur décide, sur iOS comme sur Android

Sur iOS, rien de nouveau : l’application doit demander explicitement l’autorisation, et l’utilisateur peut refuser. Sur Android, la donne a changé avec Android 13 : depuis cette version, les notifications sont soumises à une permission runtime (POST_NOTIFICATIONS) que l’app doit demander, exactement comme pour la géolocalisation. Fini l’époque où une app Android notifiait par défaut.

Conséquence directe sur vos projets : sur toutes les plateformes, il faut désormais convaincre l’utilisateur d’accepter les notifications. Notre recommandation, appliquée sur les applications que nous livrons : ne jamais déclencher la demande de permission à la première ouverture. On la présente au moment où elle a du sens, par exemple juste après une commande (« être prévenu quand c’est prêt ? »). Le taux d’acceptation change du tout au tout.

À quoi servent les notifications push dans une application mobile

Les notifications push ont d’abord servi à signaler les mises à jour importantes. Elles sont devenues un levier marketing à part entière : relance de panier abandonné, offre flash, réactivation d’utilisateurs dormants, information de suivi en temps réel. Quatre usages reviennent sur la quasi-totalité de nos projets.

La personnalisation

Une notification générique envoyée à toute la base est le meilleur moyen de générer des désabonnements. En segmentant les destinataires selon leurs préférences et leur comportement dans l’app, on envoie moins de messages, mais des messages qui concernent vraiment la personne qui les reçoit. C’est plus de travail côté conception, et c’est ce qui fait la différence entre un canal rentable et un repoussoir.

La géolocalisation

Couplée à la position de l’utilisateur, une notification peut se déclencher à l’approche d’un point de vente : un commerce peut inviter les clients qui passent à proximité à pousser la porte. Ce mécanisme de geofencing demande une intégration soignée, entre précision, consommation de batterie et consentement. Nous détaillons le sujet dans notre article sur la géolocalisation dans une application mobile.

Le temps réel et l’automatisation

Une notification push part en quelques secondes. C’est le canal du temps réel : statut de commande, alerte de disponibilité, rappel de rendez-vous. Ces envois sont presque toujours automatisés, déclenchés par un événement métier côté backend ou programmés à l’avance, ce qui garantit que le message part au moment exact où il est pertinent.

L’engagement et la fidélisation

C’est l’usage qui justifie l’investissement : ramener l’utilisateur dans l’application. Un message non lu, un nouveau contenu, des points de fidélité qui vont expirer. La notification push est l’un des piliers d’une stratégie de fidélisation client efficace, à condition de respecter une règle simple.

Notre position, assumée : une notification inutile est une désinstallation en sursis. Chaque envoi doit répondre à la question « qu’est-ce que l’utilisateur y gagne, là, maintenant ? ». Si la réponse est « rien, mais nous voulions communiquer », on ne l’envoie pas. Mieux vaut une notification pertinente par semaine que trois génériques par jour.

Comment envoyer une notification push avec Firebase (FCM)

Passons au concret. Voici les étapes pour envoyer des notifications push avec Firebase Cloud Messaging, le service de Google utilisable sur Android, iOS et le web.

Créer un projet Firebase

Tout commence dans la console Firebase : création du projet, puis enregistrement de votre application (Android, iOS ou les deux) pour récupérer les fichiers de configuration à intégrer au code. Pour les notifications vers les appareils Apple via FCM, il faut aussi renseigner votre clé APNs dans les paramètres du projet. Si besoin, suivez notre tutoriel complet pour créer un projet Firebase.

Configurer le backend avec l’API HTTP v1 (la seule encore en service)

Votre serveur doit ensuite pouvoir parler à FCM. Attention si vous reprenez un projet ancien : Google a définitivement coupé ses API legacy (l’ancienne API HTTP avec « server key » et l’API XMPP) à l’été 2024. Depuis, seule l’API HTTP v1 fonctionne. Elle s’authentifie avec des jetons d’accès OAuth 2.0 de courte durée générés depuis un compte de service, ce qui est nettement plus sûr que l’ancienne clé serveur statique. Les SDK Admin Firebase (Node.js, Python, Java, Go, PHP, C#) gèrent tout cela pour vous.

Le symptôme classique : une application dont les notifications ont « cessé de marcher » sans que le code de l’app ait changé. Neuf fois sur dix, c’est un backend resté sur l’API legacy ou un certificat expiré. C’est exactement le type de dérive que couvre un contrat de TMA et maintenance d’application mobile : les services de push évoluent, votre app doit suivre.

Collecter les jetons d’enregistrement

À son lancement, l’application demande un registration token au SDK FCM et l’envoie à votre backend, qui l’associe au compte utilisateur. Ces jetons ne sont pas éternels : ils changent lors d’une réinstallation ou d’une restauration d’appareil. Un backend propre les rafraîchit et purge les jetons périmés, sous peine d’envoyer des notifications dans le vide et de fausser toutes vos statistiques.

Construire et envoyer le message

Le message est un objet JSON. L’API HTTP v1 permet de définir un socle commun (titre, corps) puis de surcharger par plateforme : son et canal de notification côté Android, badge et options APNs côté iOS, icône et lien côté web. Vous pouvez cibler un jeton précis, un groupe d’appareils ou un topic auquel les utilisateurs sont abonnés. Et pour les campagnes marketing ponctuelles, la console Firebase permet d’envoyer et de programmer des notifications sans écrire une ligne de code serveur.

Pour voir l’interface en situation réelle, voici une démonstration d’envoi depuis Firebase sur Fidelatoo, l’application de carte de fidélité que nous éditons : créer une push notification sur Firebase (vidéo). La documentation officielle FCM détaille les fonctionnalités avancées : abonnements aux topics, messages de données, analytics d’ouverture.

Comment envoyer une push notification iPhone avec APNs

Si votre backend attaque directement le service d’Apple, sans passer par FCM, voici le parcours. Prérequis non négociable : être inscrit à l’Apple Developer Program et disposer d’un identifiant d’app (bundle ID) avec la capacité Push Notifications activée.

Créer une clé d’authentification .p8

Historiquement, on s’authentifiait auprès d’APNs avec des certificats par application, à renouveler chaque année. Apple recommande aujourd’hui l’authentification par jeton, basée sur une clé privée .p8 générée dans le portail développeur. Ses avantages sont concrets : une seule clé sert pour toutes vos applications, elle couvre les environnements de développement et de production, et elle n’expire pas (elle reste révocable en cas de fuite). Sur nos projets, c’est systématiquement cette méthode que nous mettons en place : plus aucun réveil en sursaut pour un certificat push expiré.

Configurer le serveur : HTTP/2 et JWT

APNs expose une API en HTTP/2. Votre serveur signe un jeton JWT avec la clé .p8 (accompagné du Key ID et du Team ID) et l’envoie dans l’en-tête de chaque requête. En pratique, personne ne code cela à la main : des bibliothèques éprouvées existent pour tous les langages courants, et le SDK Admin de Firebase peut aussi servir de couche d’abstraction unique au-dessus d’APNs et de FCM.

Construire et envoyer la notification

Le payload est un JSON contenant un dictionnaire aps : titre, corps, badge, son, catégorie pour les actions rapides. Les notifications peuvent embarquer une image ou une pièce jointe via une extension de notification, et Apple impose de choisir un niveau d’interruption (passif, actif, sensible au temps ou critique) qui conditionne la façon dont la notification perce les modes de concentration de l’utilisateur.

Live Activities et diffusion de masse

APNs ne sert plus uniquement aux alertes classiques. Depuis iOS 16.1, il pilote les Live Activities, ces cartes qui affichent en continu l’état d’une livraison ou d’un match sur l’écran verrouillé et dans la Dynamic Island, mises à jour par push via ActivityKit. Et depuis iOS 18, les canaux de diffusion (broadcast push) permettent de mettre à jour la même Live Activity chez des milliers d’utilisateurs avec une seule requête, sans stocker le moindre jeton individuel. La documentation Apple sur les notifications reste la référence pour les limites et les règles à respecter.

Exemple de notification push : l’application Fidelatoo

Pas besoin d’attendre de posséder votre propre application pour tester le canal. Des applications disponibles sur les stores permettent déjà d’envoyer des notifications à vos clients. Avec Fidelatoo Commerçant, l’app de fidélité que nous avons conçue et que nous maintenons, un commerçant envoie en quelques secondes une notification push aux clients qui possèdent sa carte de fidélité :

Écran de l'application Fidelatoo Commerçant pour préparer une notification push aux clients fidèles Rédaction d'une notification push dans l'application mobile Fidelatoo Envoi de la notification push aux clients depuis l'application Fidelatoo Commerçant

Et voici la même notification côté client, reçue sur une montre connectée. Envoyée à 11 h avec le plat du jour, elle invite les habitués à passer commande pour le déjeuner. Rapide à envoyer, reçue au bon moment, directement utile : c’est exactement le type de notification qui fait revenir en boutique au lieu de faire désinstaller.

Exemple de notification push Fidelatoo reçue sur une montre connectée

Notifier sans lasser : les règles que nous appliquons

La technique n’est que la moitié du sujet. L’autre moitié, c’est la discipline d’envoi, et c’est là que la plupart des applications se sabordent. Les règles que nous intégrons dès la conception des applications que nous développons :

  • demander la permission au bon moment, jamais à la première ouverture ;
  • segmenter chaque envoi : un message pour tout le monde n’est un message pour personne ;
  • laisser l’utilisateur régler ses préférences dans l’app (types de notifications, fréquence), plutôt que de le pousser vers le seul bouton « tout couper » du système ;
  • respecter les heures : une promo à 23 h 40 se paie en désabonnements dès le lendemain ;
  • mesurer, envoi par envoi : taux d’ouverture, mais aussi taux de désactivation dans les jours qui suivent.

Ces choix se préparent dès le cadrage du projet : les notifications ne sont pas une brique qu’on visse à la fin, elles structurent le backend, le parcours d’onboarding et le plan de communication. C’est un des points que nous traitons systématiquement quand nous accompagnons un client pour créer une application mobile.

Questions fréquentes sur les notifications push

Faut-il l’accord de l’utilisateur pour envoyer des notifications push ?

Oui, partout. Sur iOS, l’autorisation explicite a toujours été requise. Sur Android, depuis Android 13, une permission runtime (POST_NOTIFICATIONS) doit être acceptée par l’utilisateur. Et il peut retirer son accord à tout moment dans les réglages : la pertinence de vos envois est votre seule vraie protection contre le désabonnement.

Combien coûte l’envoi de notifications push ?

Les services eux-mêmes, FCM et APNs, sont gratuits, sans facturation au volume. Le coût réel se situe dans l’intégration (SDK dans l’app, gestion des jetons côté backend, écrans de préférences) et, éventuellement, dans un outil marketing tiers pour la segmentation avancée. Sur un projet neuf, c’est un lot de développement à part entière, à chiffrer dès le devis.

Peut-on envoyer des notifications push sans application mobile ?

Oui, avec le web push : un site web peut envoyer des notifications via le navigateur, y compris sur iPhone depuis iOS 16.4, à condition que le site soit installé sur l’écran d’accueil comme une web app. C’est une option intéressante pour tester le canal, mais l’expérience et les taux d’acceptation restent en deçà d’une vraie application native.

Un projet d’application mobile avec des notifications push ? Estimez votre budget en quelques minutes avec notre simulateur gratuit, ou parlons directement de votre stratégie d’engagement.

Estimer mon projet
Comments are closed.