Quand demander la permission pour les notifications push (et quand ne pas le faire)

La plupart des applications demandent la permission pour les notifications push sur le premier écran que l'utilisateur voit, avant même qu'il ait fait quoi que ce soit qui mérite d'être notifié. Sur iOS, cette boîte de dialogue système n'apparaît qu'une seule fois : si l'utilisateur refuse, le seul chemin de retour passe par un détour dans les Réglages que presque personne ne fait. Nous avons observé des taux d'acceptation passer de moins de 30 % à plus de 70 % sur des applications clientes, en ne changeant qu'une seule chose : le moment où la fenêtre OS s'affiche. Le texte, l'icône, l'application elle-même sont restés identiques.

Si vous construisez ou refactorisez le parcours d'onboarding d'une application mobile, le timing de la demande de permission mérite autant d'attention de conception que le formulaire d'inscription.

Pourquoi la fenêtre native est une ressource à usage unique

iOS affiche la boîte de dialogue de permission système exactement une fois par installation. Il n'y a pas de « demander plus tard » : si l'utilisateur appuie sur Ne pas autoriser, votre seul recours est Linking.openSettings() et un utilisateur prêt à naviguer dans Réglages iOS > Notifications > Votre App. Android a historiquement été plus permissif (avant la version 13, la permission était implicite ; à partir de la version 13, une demande d'exécution explicite est requise, mais redemander reste possible sous certaines conditions), ce qui signifie que les équipes qui construisent leurs flux de permission en se basant d'abord sur le comportement Android se retrouvent souvent piégées lorsqu'elles livrent sur iOS.

Considérez la fenêtre native comme une ressource que vous dépensez une seule fois. Tout ce qui la précède doit exister pour que ce seul tir soit décisif.

Le pattern du soft-ask

La solution consiste en un écran de pré-permission que vous contrôlez entièrement — un élément d'interface in-app classique, pas une boîte de dialogue système — qui explique la valeur des notifications avant que la fenêtre OS n'apparaisse :

• « Soyez notifié lorsque votre commande est expédiée », avec une icône de cloche et deux boutons : Activer les notifications et Plus tard
• Seul un appui sur Activer les notifications déclenche la vraie demande de permission OS
• Appuyer sur Plus tard ferme l'écran sans toucher à l'état OS, la vraie fenêtre reste donc disponible ultérieurement

C'est important, car un refus du soft-ask ne coûte rien — vous pouvez le montrer à nouveau à la session suivante, après une action différente, avec un texte différent. Un refus de la demande OS (hard-ask) sur iOS est quasi-définitif.

```tsx import * as Notifications from 'expo-notifications';

async function requestPushPermission() { const { status: existing } = await Notifications.getPermissionsAsync(); if (existing === 'granted') return true;

const { status } = await Notifications.requestPermissionsAsync(); return status === 'granted'; }

// Only call requestPushPermission() after the user taps // "Enable Notifications" on your own in-app screen. ```

Timing : le contextuel surpasse le chronologique

« Jour 3 » ou « après l'onboarding » relève d'un timing chronologique — facile à implémenter, et c'est précisément pourquoi la plupart des applications demandent encore au lancement, à une étape fixe. Le timing contextuel lie la demande à un moment où la valeur est évidente :

• E-commerce : après que la première commande est passée, pas avant (« suivez votre livraison »)
• Applications SaaS/dashboard : après que l'utilisateur a créé la première chose qui mérite d'être surveillée (un projet, une alerte, un rapport)
• Social/messagerie : après l'envoi ou la réception du premier message, pas à la création du compte
• Réservation/planning : juste après la confirmation d'une réservation (« nous vous rappellerons avant le début »)

Si votre application n'a pas de « moment » évident, n'en fabriquez pas un de toutes pièces — une demande générique en session 2 ou 3 reste plus performante qu'en session 1, parce que l'utilisateur a au moins formé une première impression du produit.

Les différences entre plateformes qui cassent les implémentations naïves

• iOS : une seule chance par installation (jusqu'à ce que l'utilisateur supprime et réinstalle manuellement l'application, ce qui réinitialise l'état de la permission). L'autorisation provisoire (provisional: true dans les options de la requête) délivre les notifications discrètement dans le Centre de notifications sans aucune fenêtre — utile pour les types de notifications à faible enjeu et fort volume, où vous préférez gagner la confiance plutôt que de demander d'emblée.
• Android 13+ : POST_NOTIFICATIONS est une permission d'exécution comme la caméra ou la localisation, demandée de la même façon. En dessous d'Android 13, les notifications sont accordées par défaut à l'installation — tester uniquement sur des appareils Android récents peut donc masquer des bugs qui apparaissent pour une part réelle de votre base d'installation Android.
• État background/foreground : certaines API de permission se comportent différemment selon que la demande survient immédiatement au montage ou après un délai via useEffect — testez le timing exact que vous livrerez, pas seulement l'appel API de manière isolée.

C'est l'un des domaines où React Native vs. Flutter importe moins qu'on ne le pense : les deux encapsulent le même modèle de permission OS sous-jacent, et les deux vous piégeront de la même façon si vous demandez trop tôt.

Instrumentez avant d'optimiser

Vous ne pouvez pas affiner le timing de la permission sans données. Tracez, au minimum :

• Soft-ask affiché → Soft-ask accepté (votre entonnoir in-app)
• Soft-ask accepté → Permission OS accordée (ce que la fenêtre OS elle-même vous coûte)
• Temps jusqu'à la réception de la première notification (un indicateur indirect de l'utilité réelle de la notification une fois accordée)

Sans ces événements séparés, le « taux d'acceptation » en tant que chiffre unique masque si la perte se situe au niveau de votre texte, de votre timing ou de la fenêtre OS elle-même — trois corrections très différentes.

Une checklist simple

• Ne jamais déclencher la fenêtre de permission OS au premier lancement ou depuis une étape générique d'onboarding
• Construire un écran de soft-ask que vous contrôlez entièrement, avec un texte ancré dans un bénéfice concret
• Déclencher le soft-ask après une action contextuelle, et non après un nombre de jours ou d'étapes fixes
• Gérer explicitement le comportement « une seule chance » d'iOS — traiter le refus comme (quasi) définitif, et proposer un lien profond vers les Réglages après un refus plutôt que de redemander
• Tester spécifiquement sur des appareils Android 13+ ; ne pas supposer que le comportement pré-13 se généralise
• Instrumenter chaque étape de l'entonnoir séparément avant de changer quoi que ce soit

Ce type de détail est facile à négliger quand on course vers une date de lancement, mais il est peu coûteux à construire correctement dès le départ et onéreux à corriger une fois que votre base d'installation a déjà vu — et refusé — la mauvaise fenêtre. Si vous concevez une nouvelle application mobile ou auditez les performances et l'onboarding d'une application existante, parlons-en.