Une application mobile entreprise ne vaut que par ce qu'elle pousse au bon moment : une intervention réaffectée, un bon de livraison à signer, une rupture de stock. Quand la notification arrive deux heures plus tard, ou jamais, les équipes retournent au téléphone et l'application devient un registre que l'on remplit le soir. Bonne nouvelle : une notification perdue s'explique presque toujours par une règle système documentée, pas par un mystère réseau.

Une notification qui n'arrive pas n'est presque jamais un problème de réseau

Entre l'événement métier et la bannière affichée sur le téléphone, trois maillons distincts, chacun avec ses propres règles de rejet.

  • Votre serveur déclenche l'envoi et détient les jetons d'enregistrement : envois en double, jetons périmés, authentification expirée.
  • Le service de distribution : APNs chez Apple, Firebase Cloud Messaging chez Google. Aucune application ne parle directement au téléphone, tout transite par eux.
  • L'appareil et ses réglages : autorisation refusée, canal désactivé, mode Concentration actif, économie d'énergie agressive imposée par le constructeur.

Diagnostiquer une notification manquante revient donc à trancher trois questions dans l'ordre : le message a-t-il été émis, accepté par le service de distribution, et l'appareil avait-il le droit de l'afficher. Une chaîne qui ne journalise pas ces trois états condamne à chercher à l'aveugle.

Android : depuis Android 13, la notification est une permission comme une autre

C'est le changement le plus souvent ignoré dans les projets d'entreprise. Depuis Android 13 (niveau d'API 33), l'envoi de notifications est soumis à une permission d'exécution, POST_NOTIFICATIONS. La documentation Android est explicite : sur une installation neuve, les notifications sont désactivées par défaut et l'application doit attendre que l'utilisateur accorde la permission. Lors d'une simple montée de version du système, en revanche, elle est pré-accordée aux applications éligibles.

La conséquence est concrète : votre parc historique reçoit tout, et les nouveaux arrivants ne reçoivent rien. Le problème n'apparaît pas dans les journaux d'envoi, seulement dans le taux d'autorisation par cohorte d'installation. Deux réflexes : demander la permission au moment où l'utilisateur comprend ce qu'il y gagne, et non au premier écran, puis prévoir un écran de rattrapage vers les réglages du système.

Deuxième règle : depuis Android 14, la notification en plein écran, celle qui réveille l'appareil comme un appel entrant, n'est plus ouverte à tous. La permission USE_FULL_SCREEN_INTENT n'est accordée par défaut qu'aux applications de téléphonie et de réveil, et le magasin la retire aux autres. Si votre application de supervision comptait dessus pour réveiller une astreinte, il faut la demander explicitement ou changer d'approche.

Enfin, l'utilisateur peut désactiver un canal sans couper l'application entière : répartissez vos messages en trois ou quatre canaux lisibles, du type Intervention urgente, Validation attendue, Information, plutôt qu'un canal unique qu'il coupera au premier trop-plein.

Apple : quatre niveaux d'urgence, dont un qui se demande

Sur iOS, chaque notification porte un niveau d'interruption qui détermine sa capacité à percer les réglages de l'utilisateur. Les quatre niveaux vont du plus discret, qui n'allume même pas l'écran, au plus intrusif. Le niveau dit sensible au facteur temps traverse les modes Concentration et la remise programmée des résumés : c'est celui d'une alerte métier qui perd toute valeur si elle est lue trois heures plus tard.

Le niveau critique, lui, passe outre tous les réglages, y compris le mode silencieux. Apple exige pour cela une autorisation spécifique, examinée au cas par cas et réservée aux usages de santé, de sécurité des personnes et d'urgence. Inutile de la demander pour une relance de validation.

Cartographiez vos types de messages sur cette échelle avant d'écrire la moindre ligne de code : une application qui envoie tout au niveau maximum obtient l'effet inverse, l'utilisateur finit par tout couper.

Le socle d'envoi : ce qui a changé côté serveur

Beaucoup d'applications d'entreprise vivent sur des réglages hérités d'un projet ancien. Quatre points méritent une vérification immédiate.

Côté Google. Les anciennes interfaces d'envoi de Firebase Cloud Messaging, en HTTP et en XMPP, ont été déclarées obsolètes le 20 juin 2023 et leur extinction a débuté le 22 juillet 2024. L'interface actuelle, HTTP v1, n'accepte plus la clé serveur statique que l'on collait dans un fichier de configuration : elle exige un jeton d'accès OAuth 2.0 de courte durée, dérivé d'un compte de service. C'est aussi une charge d'exploitation, puisque quelqu'un doit détenir cette clé, savoir où elle est stockée et la renouveler.

Côté Apple. Deux modes d'authentification coexistent. Le certificat au format .p12 est propre à une application et expire au bout d'un an : c'est la cause classique de la panne survenue un matin sans aucune mise en production. La clé par jeton, au format .p8, n'expire pas, couvre toutes les applications du compte développeur et vaut en développement comme en production.

Côté propriété. Le compte développeur Apple et le projet Firebase doivent appartenir à votre entreprise, pas à votre prestataire : sinon vous ne pouvez ni régénérer une clé, ni changer de partenaire sans reconstruire la chaîne.

Côté jetons. Chaque installation possède un jeton d'enregistrement, qui change plus souvent qu'on ne le croit : réinstallation, restauration sur un nouveau téléphone, effacement des données. Une base jamais nettoyée se remplit d'adresses mortes et le taux de réussite affiché devient une illusion. Trois règles suffisent : renvoyer le jeton au serveur à chaque démarrage, supprimer aussitôt tout jeton signalé invalide, et rattacher les jetons à un compte utilisateur pour purger ceux d'un appareil rendu au départ d'un salarié.

Concevoir la notification côté métier

Une chaîne technique impeccable ne sauve pas une notification mal pensée. Cinq principes font la différence :

  • Une notification, une action : le message ouvre l'écran concerné, pas l'accueil.
  • Un budget de messages par rôle. Une synthèse des huit dossiers en attente vaut mieux que huit alertes séparées.
  • Des heures de silence et une règle d'astreinte explicite : la première notification de 23 heures provoque une désactivation définitive.
  • Aucune donnée confidentielle dans le message, qui s'affiche sur un écran verrouillé, parfois devant un tiers.
  • Un canal de repli. Une alerte critique non ouverte dans un délai défini bascule vers un autre moyen, humain si nécessaire.

Piloter : trois indicateurs, cinq pièges

Mesurez peu de choses, mais par système d'exploitation : les causes de perte diffèrent entre iOS et Android.

  1. Le taux d'autorisation : part des installations actives ayant accordé les notifications, par cohorte.
  2. Le délai médian entre l'événement métier et l'ouverture, qui révèle les blocages d'économie d'énergie bien mieux qu'un journal d'envoi.
  3. Le taux d'action : part des notifications suivies du geste attendu dans le délai visé, le seul indicateur qui parle au métier.

Et les cinq erreurs qui reviennent le plus souvent :

  • Demander l'autorisation dès le premier lancement, avant tout bénéfice perçu.
  • Mélanger alertes urgentes et informations de confort dans un canal unique.
  • Laisser en place le certificat Apple annuel et découvrir son expiration un lundi matin.
  • Conserver le compte développeur ou le projet Firebase au nom du prestataire.
  • Traiter la notification comme une preuve de prise de connaissance, alors que seule une action horodatée dans l'application fait foi.

Questions fréquentes

Pourquoi mes notifications arrivent-elles sur Android et pas sur iPhone ?

Le plus souvent parce que l'authentification auprès du service Apple a expiré, ou parce que le niveau d'interruption retenu ne traverse pas un mode Concentration actif. Vérifiez le mode d'authentification, certificat annuel ou clé par jeton, avant de chercher côté application.

Faut-il payer pour envoyer des notifications push ?

Les services de distribution d'Apple et de Google ne facturent pas l'envoi. Le coût réel est ailleurs : développement de la chaîne d'envoi, hébergement et maintenance des clés et des jetons dans la durée.

Une application interne, non publiée sur les magasins, échappe-t-elle à ces règles ?

Non. Le canal de distribution change, mais les règles du système restent identiques : permission d'exécution sur Android, niveaux d'interruption et autorisation Apple pour les alertes critiques.

Peut-on garantir qu'une alerte urgente sera vue ?

Aucun mécanisme de notification ne le garantit, d'où l'escalade vers un autre canal pour les cas critiques. La notification accélère l'information, elle ne remplace pas une procédure d'astreinte.

Que faire quand un utilisateur a refusé les notifications ?

Le système ne permet pas de reposer la question indéfiniment. Prévoyez un bandeau signalant l'état désactivé et renvoyant vers les réglages, plus un affichage des éléments en attente à l'ouverture.

Nous concevons des applications métier et mobiles pour des PME, des associations et des collectivités. Si vos notifications arrivent mal, ou si vous démarrez une application métier sur mesure, nous auditons la chaîne existante.

Parlons de votre projet