Notifications locales dans le développement mobile : essence, types et fonctionnement

Qu’est-ce qu’une notification locale ?

Une notification locale est un message de déclenchement généré et affiché par le système d’exploitation sur le même appareil où l’application est installée. Contrairement aux notifications push, les notifications locales ne passent pas par un serveur externe — toute la logique de planification s’exécute sur le client.

Ces notifications fonctionnent indépendamment de l’état de l’application : active, réduite ou complètement fermée. Le système d’exploitation assure la livraison à l’heure prévue, tandis que le développeur spécifie uniquement le contenu et le déclencheur.

Le système garantit la livraison de la notification locale même sans accès au réseau. C’est un avantage clé par rapport aux notifications push, qui nécessitent une connexion Internet stable et un serveur fonctionnel.

Composants principaux d’une demande

Chaque notification locale se compose de trois parties : le contenu (titre, corps, son), le déclencheur (condition temporelle ou géographique) et l’identifiant de la demande. L’identifiant permet d’annuler ou de mettre à jour la notification avant sa livraison.

Un développeur peut planifier jusqu’à 64 notifications locales par application sur iOS et un nombre illimité sur Android. Cette différence est due à des contraintes architecturales des systèmes d’exploitation.

Comment fonctionnent les notifications locales sur iOS et Android ?

Les deux plateformes fournissent leurs propres API pour travailler avec les notifications locales. Sur iOS, le composant central est UNUserNotificationCenter, sur Android — NotificationManager. Malgré des interfaces différentes, la logique est la même : l’application crée une demande, l’enregistre dans le système, et l’OS délivre la notification à l’heure prévue.

iOS utilise UNCalendarNotificationTrigger pour les événements de calendrier, UNTimeIntervalNotificationTrigger pour les intervalles et UNLocationNotificationTrigger pour la géolocalisation. Android propose AlarmManager, WorkManager et une planification précise via setExact.

Depuis Android 12 — SCHEDULE_EXACT_ALARM nécessite une autorisation spéciale de l’utilisateur. Sur iOS, l’autorisation est demandée une fois via UNUserNotificationCenter.requestAuthorization, et l’utilisateur choisit le niveau d’accès : bannières, sons, badges.

Types de notifications locales

Les notifications locales sont classées par type de déclencheur, et non par contenu. Chaque type détermine quand et dans quelles conditions la notification sera affichée à l’utilisateur.

Comparaison des déclencheurs par plateforme

Sur iOS et Android, les types de déclencheurs sont implémentés différemment, bien que la classification logique soit la même. iOS utilise UNCalendarNotificationTrigger pour les dates, UNTimeIntervalNotificationTrigger pour les intervalles et UNLocationNotificationTrigger pour la géolocalisation. Android propose AlarmManager avec setExact et setRepeating, ainsi que WorkManager pour les tâches différées.

iOS prend également en charge UNNotificationAttachment — joindre une image, un audio ou une vidéo au corps de la notification. Android prend en charge les modèles personnalisés avec des boutons et de grandes images via NotificationCompat.Style.

Le choix du déclencheur dépend du scénario : les rappels de calendrier fonctionnent mieux avec les déclencheurs de calendrier, les rappels géographiques avec la géolocalisation. Les déclencheurs d’intervalle conviennent aux événements récurrents avec une période fixe.

Comportement des déclencheurs en arrière-plan

Sur iOS, les notifications locales sont délivrées par le système même lorsque l’application est fermée — UNUserNotificationCenter gère la file d’attente de manière indépendante. Sur Android, la livraison dépend du mécanisme choisi : AlarmManager se déclenche même écran éteint, tandis que WorkManager tient compte des économies d’énergie.

Cas d’utilisation dans les applications mobiles

Les notifications locales résolvent des tâches où l’infrastructure externe est excessive ou indisponible. Principaux scénarios : rappels, minuteries, conseils d’intégration et actions différées.

• Rappels — une application de calendrier crée une notification locale pour la date d’événement spécifiée
• Conseils d’intégration — un jour après l’installation, l’application affiche un conseil à l’écran
• Minuteries — une minuterie de cuisine se déclenche après un temps défini même avec l’application fermée
• Progression des opérations — notification de téléchargement terminé ou d’exportation de données

Les recherches de Localytics montrent que les applications utilisant des rappels locaux retiennent 35 % d’utilisateurs supplémentaires la première semaine après l’installation. Cela fait des notifications locales un outil d’intégration puissant.

Il est important de ne pas abuser de la fréquence — le système regroupe les notifications d’une même application et l’utilisateur peut désactiver toutes les notifications locales si elles deviennent gênantes. La fréquence optimale est de 2 à 3 notifications par jour maximum pour les événements non critiques.

Exemple de planification sur Android

Pour planifier une notification locale sur Android, utilisez NotificationManager avec AlarmManager. Sur Android 8+, vous devez d’abord créer un canal de notification, sinon la notification ne s’affichera pas.

val channelId = "reminder_channel"
val notificationId = "task_reminder_42"

val channel = NotificationChannel(
    channelId,
    "Rappels",
    NotificationManager.IMPORTANCE_HIGH
).apply {
    description = "Canal pour les rappels de tâches"
}

val manager = getSystemService(NotificationManager::class.java)
manager.createNotificationChannel(channel)

val intent = Intent(this, ReminderReceiver::class.java).apply {
    putExtra("notification_id", notificationId)
    putExtra("channel_id", channelId)
}

val pendingIntent = PendingIntent.getBroadcast(
    this, notificationId.hashCode(),
    intent, PendingIntent.FLAG_UPDATE_CURRENT
)

val alarmManager = getSystemService(AlarmManager::class.java)
alarmManager.setExact(
    AlarmManager.RTC_WAKEUP,
    triggerTimeMillis,
    pendingIntent
)

Sur Android 12+, vérifiez l’autorisation SCHEDULE_EXACT_ALARM avant d’appeler setExact. Si l’autorisation n’est pas accordée — utilisez setWindow, qui garantit la livraison dans une fenêtre de temps.

Traitement dans BroadcastReceiver

Lorsque AlarmManager se déclenche, le système envoie un Intent de diffusion reçu par BroadcastReceiver. À l’intérieur, vous devez créer et afficher la notification via NotificationManager. Assurez-vous que PendingIntent utilise FLAG_UPDATE_CURRENT, sinon les anciennes notifications continueront d’utiliser un Intent obsolète lorsque les données changeront.

Exemple de planification sur iOS

Sur iOS, les notifications locales sont créées via UNUserNotificationCenter avec UNMutableNotificationContent et l’un des déclencheurs. Avant la planification, vous devez demander l’autorisation de l’utilisateur.

import UserNotifications

let center = UNUserNotificationCenter.current()

center.requestAuthorization(options: [.alert, .sound, .badge]) { granted, error in
    guard granted else { return }
}

let content = UNMutableNotificationContent()
content.title = "Rappel de tâche"
content.body = "N’oubliez pas de terminer le rapport avant 18h00"
content.sound = .default
content.userInfo = ["task_id": "42"]

let trigger = UNTimeIntervalNotificationTrigger(
    timeInterval: 3600,
    repeats: false
)

let request = UNNotificationRequest(
    identifier: "task_reminder_42",
    content: content,
    trigger: trigger
)

center.add(request)

iOS prend en charge jusqu’à 64 demandes simultanées de notifications locales. Si la limite est dépassée, le système rejette les nouvelles demandes jusqu’à ce que les actives soient livrées ou annulées. Utilisez getPendingNotificationRequests pour vérifier la file d’attente actuelle.

Traitement de la réponse du délégué

Lorsqu’un utilisateur interagit avec une notification locale sur iOS, la méthode userNotificationCenter:didReceive response du délégué UNUserNotificationCenterDelegate est appelée. Cette méthode fournit l’identifiant de la demande, actionIdentifier (quel bouton a été pressé) et userInfo personnalisé. Cela permet de distinguer une simple ouverture de notification de l’appui sur un bouton d’action spécifique.

Bonnes pratiques pour les notifications locales

Pour que les notifications locales soient utiles plutôt qu’énervantes, suivez plusieurs règles clés. Premièrement : contrôlez la fréquence — pas plus de 2 à 3 notifications par jour pour les événements non critiques, sinon l’utilisateur désactivera toutes les notifications de l’application.

Deuxièmement : donnez le choix à l’utilisateur. Ajoutez dans l’interface la possibilité de désactiver certains types de notifications locales. Sur Android, utilisez un NotificationChannel séparé avec une importance faible ; sur iOS, une catégorie séparée dans les paramètres de l’application.

Troisièmement : pertinence contextuelle — la notification doit apparaître quand l’utilisateur en a besoin. Les déclencheurs géographiques sont idéaux pour les rappels près de chez soi, les déclencheurs de calendrier pour les réunions, les déclencheurs d’intervalle pour les activités régulières comme boire de l’eau ou s’étirer. Ne mélangez pas les types inutilement.

Quatrièmement : testez sur des appareils réels. Le simulateur iOS n’émule pas tous les scénarios de livraison des notifications locales, surtout en arrière-plan. Sur Android, utilisez adb shell dumpsys notification pour vérifier la file d’attente des notifications planifiées et leurs paramètres. Cinquièmement : offrez toujours à l’utilisateur la possibilité de désactiver les notifications via l’interface de l’application — c’est une exigence obligatoire d’UX et des directives de l’App Store.