Passer au contenu principal

​
Pourquoi utiliser une invite de permission push ?

Pour envoyer des notifications push qui apparaissent sous forme de bannières, s’affichent sur l’écran de verrouillage et émettent des sons, votre application doit d’abord demander la permission à l’utilisateur. Sur iOS, Android, Huawei, Amazon et Web, cela implique d’afficher une invite de permission au niveau système.
iOS and Android system-level push permission prompts side by side
Ce guide est destiné aux abonnés push d’applications mobiles. Pour le push web, voir Invites de permission web push. Prérequis : Un compte OneSignal, une application mobile avec le SDK OneSignal installé, et les messages in-app activés.
iOS n’autorise l’invite de permission système qu’une seule fois. Android l’autorise deux fois. Si l’utilisateur refuse, il devra activer manuellement les notifications dans les paramètres système. Une invite mal synchronisée peut vous faire perdre définitivement un abonné.
Sur iOS, vous pouvez également utiliser les notifications provisionnelles, qui sont livrées discrètement au Centre de notifications sans inviter l’utilisateur — idéal pour les tests ou l’intégration à faible friction.
Comme l’invite système est limitée, Apple et Google recommandent fortement d’expliquer la valeur de vos notifications avant de l’afficher. Vous pouvez déclencher l’invite à tout moment en utilisant la méthode SDK requestPermission(), mais sans contexte approprié, les utilisateurs sont plus susceptibles de refuser — et sur iOS, une invite refusée ne peut pas être affichée à nouveau. L’approche recommandée est une “invite douce” — un message in-app personnalisé qui présente la demande avant l’invite système. Si l’utilisateur accepte, l’invite système apparaît. S’il refuse, rien ne se passe et vous pouvez demander à nouveau plus tard.
In-app message leading to system push permission prompt

​
Configurer une invite de permission push in-app

1

Supprimer toutes les invites de permission automatiques

Avant de commencer, assurez-vous que votre application ne déclenche pas déjà automatiquement l’invite push native :
  • Supprimez les méthodes requestPermission() ou optIn() si vous les appelez au démarrage de l’application.
  • Supprimez les appels iOS natifs à requestAuthorizationWithOptions et toutes les méthodes générant des jetons push.
  • Supprimez les appels Android à requestPermissions et toutes les méthodes générant des jetons push.
Assurez-vous également d’utiliser la dernière version du SDK OneSignal dans votre application.
2

Créer ou modifier le message in-app

Allez dans Messages > In-App, puis soit :
  • Modifiez le modèle d’invite de permission push par défaut, ou
  • Cliquez sur Nouveau message pour créer le vôtre.
OneSignal in-app messages list showing the Push Permission Prompt template
Définissez l’audience sur Afficher à tous les utilisateurs. OneSignal filtre automatiquement ce message pour ne s’afficher qu’aux utilisateurs qui ne se sont pas abonnés au push, en fonction de l’action de clic Invite de permission push.
Audience setting configured to show to all users
3

Personnaliser le design du message

Personnalisez l’apparence, le ressenti et le libellé pour correspondre à votre application. Informez les utilisateurs du type de notifications qu’ils recevront et pourquoi elles sont précieuses.Voir Concevoir des messages in-app avec glisser-déposer ou Concevoir des messages in-app avec HTML pour plus de détails.
In-app message block editor with a push opt-in prompt
4

Ajouter l'action de clic invite de permission push

Ajoutez une action de clic Invite de permission push à n’importe quel bouton ou image dans votre message. Lorsqu’elle est tapée, l’invite système est affichée.
Click action dropdown with Push Permission Prompt selected
iOS native push notification permission prompt
Si un utilisateur a déjà refusé la permission, le bouton le dirigera vers les paramètres de notification de votre application.
Les messages in-app avec une action Invite de permission push ne sont pas affichés aux utilisateurs qui ont déjà autorisé les notifications.
5

Choisir un déclencheur

L’audience contrôle qui est éligible pour voir le message. Les déclencheurs contrôlent quand il est affiché.
In-app message trigger configuration panel
Vous pouvez déclencher le message :
  • À l’ouverture de l’application
  • Après une durée de session définie
  • Sur un événement utilisateur spécifique
  • Par programmation, en utilisant les méthodes SDK de message in-app pour un contrôle total sur le moment et le contexte
Par exemple, pour attendre que l’utilisateur ait passé au moins 5 minutes dans l’application :
Session duration trigger set to 5 minutes
6

Planification et fréquence

Contrôlez la fréquence d’apparition du message :
  • Une seule fois — Faible chance de convertir les utilisateurs qui n’étaient pas prêts la première fois.
  • Chaque fois que les conditions sont remplies — Trop agressif et peut ennuyer les utilisateurs.
  • Plusieurs fois (recommandé) — Définissez un maximum élevé (ex. 9999) avec un intervalle entre les affichages (ex. 2 semaines). Cela relance les utilisateurs non abonnés périodiquement sans être intrusif. Ajustez l’intervalle en fonction de votre cas d’utilisation.
Schedule configuration showing max displays and gap between views
Mettez à jour votre message et activez-le. Surveillez vos statistiques et ajustez l’intervalle entre les affichages selon les besoins.

​
Afficher l’invite de permission par programmation

Vous pouvez déclencher manuellement l’invite de permission push en utilisant les méthodes SDK requestPermission() ou optIn(). Cela est utile pour les flux personnalisés tels que :

​
Suivre les permissions push et les résultats des invites

Lors de l’utilisation de messages in-app pour inviter au push, vous pouvez suivre les actions de clic avec l’écouteur de clic de message in-app. Si le message in-app s’affiche mais que l’utilisateur ne clique pas sur le bouton, utilisez les événements de cycle de vie des messages in-app pour suivre les impressions et les fermetures. Pour suivre le résultat de l’invite de permission au niveau système elle-même, utilisez l’écouteur de permission push.
Vous pouvez envoyer ces événements SDK à votre backend ou outil d’analyse de votre choix.

​
FAQ

​
Que se passe-t-il si un utilisateur refuse l’invite de permission push ?

Sur iOS, refuser l’invite système désactive définitivement les notifications push de votre application — l’invite ne peut pas être affichée à nouveau. Sur Android, l’utilisateur a encore une chance (deux au total). Après avoir utilisé toutes les tentatives, l’utilisateur doit réactiver manuellement les notifications dans Paramètres > Notifications sur son appareil. La méthode requestPermission(fallbackToSettings: true) du SDK OneSignal peut rediriger les utilisateurs vers leurs paramètres de notification si la permission a été refusée précédemment.

​
Puis-je personnaliser l’invite de permission système native ?

Non. Les boîtes de dialogue de permission natives iOS et Android sont contrôlées par le système d’exploitation et ne peuvent pas être personnalisées. Vous ne pouvez contrôler que l’invite douce (le message in-app affiché avant l’invite système). Utilisez l’invite douce pour expliquer la valeur de vos notifications, définir les attentes et augmenter les chances d’un « Autoriser » sur l’invite système.

​
Puis-je toujours inviter les utilisateurs avec des notifications provisionnelles ?

Oui. Si vous utilisez les notifications push provisionnelles iOS, vous pouvez toujours afficher une invite douce pour convertir ces utilisateurs en abonnés push complets. Planifiez stratégiquement l’invite — après que l’utilisateur ait vu la valeur de vos notifications provisionnelles.

​
Comment puis-je relancer les utilisateurs qui ont précédemment refusé le push ?

Vous ne pouvez pas afficher à nouveau l’invite de permission système une fois que l’utilisateur a refusé sur iOS (ou deux fois sur Android). Utilisez plutôt la méthode SDK requestPermission(fallbackToSettings: true), qui ouvre la page des paramètres de notification de l’application pour que l’utilisateur puisse activer manuellement les notifications. Associez cela à un message in-app expliquant pourquoi les notifications sont précieuses.

​
Quand Android a-t-il commencé à exiger des invites de permission ?

Android 13 (niveau API 33) a introduit la permission de notification au moment de l’exécution, exigeant le consentement explicite de l’utilisateur pour les notifications push.

Notifications push provisionnelles iOS

Envoyez des notifications au Centre de notifications sans invite de permission préalable sur iOS 12+.