> ## Documentation Index > Fetch the complete documentation index at: https://documentation.onesignal.com/llms.txt > Use this file to discover all available pages before exploring further. # Gestion de la barre de notifications > Comment les notifications push mobiles OneSignal se comportent dans la barre de notifications sur Android et iOS : gestion des clics et des rejets, notifications restaurées, badges, effacement des notifications par programmation et extensions de service. Utilisez ce guide pour comprendre et contrôler ce qui arrive à vos notifications push après leur affichage sur un appareil : ce que font le clic et le rejet, quand Android réaffiche les notifications, comment les badges restent synchronisés, et quels outils du SDK vous permettent de gérer la barre depuis le code de votre application. Cette page couvre le push mobile (Android et iOS). Pour le comportement du web push, consultez [Comportement des notifications web push](./push). *** ## Cycle de vie des notifications dans la barre Chaque notification OneSignal affichée sur un appareil est suivie par le SDK. Ce qui se passe ensuite détermine si elle peut réapparaître un jour : | Événement | Ce qui se passe | Peut-elle réapparaître ? | | -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | **L'utilisateur clique dessus** | Retirée de la barre, marquée comme cliquée, le [listener de clic](./mobile-sdk-reference#addclicklistener-push) se déclenche, l'URL de lancement ou l'intent s'exécute. | Non | | **L'utilisateur la rejette** (balayage ou Tout effacer) | Marquée comme rejetée. | Non | | **Votre application l'efface** avec les [méthodes du SDK OneSignal](#effacement-des-notifications-par-programmation) | Retirée de la barre et marquée comme rejetée. | Non | | **Votre application l'annule** avec le `NotificationManager` natif d'Android | Retirée de la barre, mais **pas** marquée comme rejetée. | Oui, sur Android elle est restaurée au prochain redémarrage de l'application | | **Android la retire de force** (redémarrage de l'appareil, mise à jour de l'application, fermeture forcée) | Retirée par l'OS sans action de l'utilisateur. | Oui, consultez [Notifications restaurées](#notifications-restaurées-android) | Sur Android, effacez toujours les notifications avec les méthodes du SDK OneSignal plutôt qu'avec les méthodes natives `NotificationManager.cancel()` ou `cancelAll()` d'Android. Les notifications annulées avec les API natives ne sont pas marquées comme rejetées, donc le SDK les restaure au prochain redémarrage de l'application. *** ## Comportement de clic et de rejet **Cliquer** sur une notification ouvre votre application (ou l'URL de lancement de la notification), retire la notification de la barre et déclenche le callback [`addClickListener()`](./mobile-sdk-reference#addclicklistener-push) avec la charge utile de la notification et l'ID du bouton d'action cliqué. Si la notification cliquée appartient à un groupe, le SDK met à jour ou supprime le résumé du groupe. Les notifications cliquées ne sont jamais restaurées. **Rejeter** une notification (la balayer ou appuyer sur Tout effacer dans la barre) la marque comme rejetée et met à jour le compteur de badge ainsi que tout résumé de groupe. Les notifications rejetées ne sont jamais restaurées. Le SDK ne fournit pas de listener de rejet ; le rejet est suivi en interne. Les notifications affichées pendant que votre application est en premier plan passent d'abord par le [listener de cycle de vie en premier plan](./mobile-sdk-reference#addforegroundlifecyclelistener-push), où vous pouvez empêcher l'affichage. *** ## Notifications restaurées (Android) Android peut retirer de force des notifications sans action de l'utilisateur : lors d'un redémarrage de l'appareil, d'une mise à jour de l'application et d'une fermeture forcée (y compris les gestionnaires de batterie agressifs sur certains appareils). Le SDK Android réaffiche (restaure) automatiquement les notifications concernées au prochain démarrage à froid de l'application, afin que les messages livrés que l'utilisateur n'a jamais vus ni rejetés ne soient pas perdus. Les notifications restaurées réapparaissent silencieusement dans la [catégorie Restored](./android-notification-categories#restored) de faible importance. Seules les notifications qui n'ont pas été cliquées ni rejetées, qui sont dans leur TTL et qui ont été reçues au cours des 7 derniers jours sont restaurées, jusqu'à 49 notifications. Les règles d'éligibilité complètes et les contrôles se trouvent dans [Notifications restaurées (Android)](./osnotification-payload#restored-notifications-android). Pour réduire les restaurations, utilisez un `ttl` plus court lors de l'envoi ou effacez les notifications consommées avec les [méthodes du SDK ci-dessous](#effacement-des-notifications-par-programmation). iOS n'a pas de comportement de restauration. *** ## Comportement des badges Sur **iOS**, les badges sont définis par la charge utile de la notification (`ios_badgeType` et `ios_badgeCount`) et nécessitent un App Group pour que l'extension de service puisse mettre à jour les compteurs avec précision. Par défaut, le SDK efface le badge lorsque l'application s'ouvre. Sur **Android**, le badge de l'icône de l'application reflète le nombre de notifications OneSignal actives dans la barre et est géré via les [catégories de notification](./android-notification-categories). Le SDK met à jour le compteur automatiquement lorsque les notifications sont affichées, rejetées, cliquées ou effacées, et le réinitialise à `0` lorsque vous appelez `clearAllNotifications()`. La configuration, les options par plateforme et le dépannage sont couverts dans [Badges](./badges). *** ## Effacement des notifications par programmation Effacez les notifications lorsque leur contenu a été consommé dans votre application, pas lors d'événements du cycle de vie de l'application. Les schémas courants : * **Synchronisation contenu-consommé** : l'utilisateur ouvre l'écran vers lequel pointent les notifications (une boîte de réception, un centre de messages ou un fil d'activité), donc les notifications sont désormais redondantes. Effacez-les toutes, ou utilisez les méthodes ciblées si seule une partie du contenu a été consommée. * **Déconnexion** : effacez tout pour que les notifications de l'utilisateur précédent ne soient pas visibles par l'utilisateur suivant. Évitez d'effacer à chaque lancement ou passage au premier plan de l'application pour « garder la barre propre ». Les notifications dans la barre stimulent le réengagement, et les effacer supprime ce point d'entrée. Si vous gérez une accumulation de notifications, utilisez `collapse_id` lors de l'envoi pour remplacer les notifications au lieu de les empiler, ou un TTL plus court pour faire expirer celles qui ne sont pas livrées. ### `clearAllNotifications()` Retire les notifications de votre application de la barre et réinitialise le compteur de badge à `0`. Sur Android, cela retire uniquement les notifications créées par OneSignal et les marque comme rejetées afin qu'elles ne soient pas restaurées. Sur iOS, cela retire **toutes** les notifications livrées de votre application, y compris les notifications locales et les push d'autres fournisseurs. Consultez la [référence complète de la méthode](./mobile-sdk-reference#clearallnotifications). Si vous effacez au lancement de l'application pour empêcher les notifications restaurées, limitez l'appel à Android dans les applications multiplateformes. Sur iOS, cela retire également les notifications locales et les push d'autres fournisseurs. ### `removeNotification()` et `removeGroupedNotifications()` (Android) Retirez une seule notification par son ID de notification Android, ou toutes les notifications d'un groupe par sa clé de groupe. Les notifications retirées sont marquées comme rejetées et ne sont pas restaurées. Utilisez ces méthodes lorsque seule une partie du contenu de la barre a été consommée, comme une conversation parmi plusieurs. Consultez la [référence de la méthode](./mobile-sdk-reference#removenotification-removegroupednotifications-android). *** ## Rejeter automatiquement les notifications après un délai Il n'existe pas de paramètre à l'envoi qui retire une notification affichée après un temps donné. Ce qui est possible diffère selon la plateforme : * **Android 8.0 (API 26) et versions ultérieures** : définissez un délai d'expiration dans une [extension de service de notification](./service-extensions) en utilisant `setTimeoutAfter()`. Android retire la notification du volet lorsque le délai expire. Sur les appareils sous API 26, l'appel est ignoré et la notification reste jusqu'à ce que l'utilisateur interagisse avec elle. * **iOS** : non pris en charge. iOS n'a aucun moyen de faire expirer automatiquement une notification livrée. Les options les plus proches sont de la remplacer par une notification plus récente via [`collapse_id`](./push#collapse-id-mobile-push), ou de la retirer depuis une Notification Service Extension avec la méthode d'Apple [`removeDeliveredNotifications(withIdentifiers:)`](https://developer.apple.com/documentation/usernotifications/unusernotificationcenter/removedeliverednotifications\(withidentifiers:\)) lorsqu'un push ultérieur arrive. ```kotlin Kotlin theme={null} class NotificationServiceExtension : INotificationServiceExtension { override fun onNotificationReceived(event: INotificationReceivedEvent) { event.notification.setExtender { builder -> // Retirer cette notification du volet après 10 minutes (API 26+ uniquement) builder.setTimeoutAfter(10 * 60 * 1000L) } } } ``` ```java Java theme={null} public class NotificationServiceExtension implements INotificationServiceExtension { @Override public void onNotificationReceived(INotificationReceivedEvent event) { event.getNotification().setExtender(builder -> // Retirer cette notification du volet après 10 minutes (API 26+ uniquement) builder.setTimeoutAfter(10 * 60 * 1000L) ); } } ``` Pour rendre le délai propre à chaque message plutôt que fixé dans le code, envoyez la durée dans [`additionalData`](./osnotification-payload) et lisez-la depuis l'événement dans votre extension de service. Une notification retirée par `setTimeoutAfter()` est rejetée par le système, donc le SDK OneSignal ne la restaure pas. Ne confondez pas cela avec `ttl`, qui contrôle combien de temps un message non livré attend un appareil hors ligne et ne retire jamais une notification affichée. *** ## Personnalisation des notifications avec les extensions de service Les [extensions de service](./service-extensions) s'exécutent avant l'affichage d'une notification, vous permettant de modifier son apparence, de recevoir des données en arrière-plan ou d'empêcher entièrement l'affichage : * Sur **Android**, implémentez `INotificationServiceExtension` et utilisez `setExtender()` pour modifier les options `NotificationCompat`, ou appelez `event.preventDefault()` pour supprimer l'affichage. * Sur **iOS**, utilisez une `UNNotificationServiceExtension` (la `OneSignalNotificationServiceExtension` créée lors de la configuration) pour les médias enrichis, les incréments de badge et la livraison confirmée. Sur Android, votre extension de service s'exécute également pour les [notifications restaurées](#notifications-restaurées-android). Les effets de bord dans `onNotificationReceived` (appels d'analyse, requêtes API, écritures en base de données) se réexécutent lorsque les notifications sont restaurées, et les modifications de l'extender comme `setChannelId()` s'appliquent aussi aux restaurations, ce qui peut les faire alerter bruyamment. Concevez votre extension pour que les options d'alerte ne s'appliquent qu'aux notifications fraîchement livrées. *** ## FAQ ### Pourquoi d'anciennes notifications réapparaissent-elles à l'ouverture de l'application sur Android ? Le SDK Android restaure les notifications qui ont été retirées de force de la barre, par exemple après un redémarrage de l'appareil, une mise à jour de l'application ou une fermeture forcée. Les notifications que l'utilisateur a rejetées ou cliquées ne sont pas restaurées. Consultez [Notifications restaurées (Android)](./osnotification-payload#restored-notifications-android) pour les règles d'éligibilité et les contrôles. ### Le TTL retire-t-il une notification de la barre après son expiration ? Non. Le TTL contrôle combien de temps un message non livré attend un appareil hors ligne, et sur Android il délimite également quelles notifications peuvent être restaurées. Il ne retire jamais une notification déjà affichée dans la barre. Pour retirer les notifications affichées, utilisez les [méthodes d'effacement](#effacement-des-notifications-par-programmation). Pour les retirer après un temps donné sur Android, consultez [Rejeter automatiquement les notifications après un délai](#rejeter-automatiquement-les-notifications-après-un-délai). ### Puis-je effacer le badge sans effacer la barre ? Oui sur iOS : le badge s'efface automatiquement lorsque l'application s'ouvre (sauf si désactivé), laissant le contenu de la barre en place. Sur Android, le badge reflète les notifications actives dans la barre, il ne peut donc pas être défini indépendamment d'elles. Consultez [Badges](./badges). ### Existe-t-il un listener pour le rejet d'une notification par l'utilisateur ? Non. Le SDK suit le rejet en interne pour éviter de restaurer les notifications rejetées, mais n'expose pas d'événement de rejet. Le [listener de clic](./mobile-sdk-reference#addclicklistener-push) couvre uniquement les clics. *** Référence complète des méthodes et listeners de notification. Champs de la charge utile et règles des notifications restaurées. Interceptez et personnalisez les notifications avant l'affichage.