Les canaux de notification Android en 2026 : concevoir des niveaux d'importance que les utilisateurs ne couperont pas

Le moyen le plus rapide de perdre définitivement l’attention d’un utilisateur n’est pas une mauvaise notification — c’est de le forcer à choisir entre toutes vos notifications ou aucune. Sur Android, ce choix se fait au niveau de l’application, à moins d’avoir réparti vos notifications en canaux. Et une fois que l’utilisateur a basculé l’interrupteur système pour toute votre application, plus aucune notification envoyée par la suite n’arrive nulle part. Voici comment les canaux fonctionnent réellement en 2026, et les quelques décisions qui déterminent si vos notifications restent activées.

L’erreur qui fait couper toute votre application

Depuis Android 8.0+, chaque notification appartient à un NotificationChannel, que vous en ayez créé un explicitement ou non — sautez l’étape et le système regroupe tout dans un canal par défaut unique. C’est le piège. Si une application de rappel de médicaments envoie des alertes de dose urgentes et un résumé hebdomadaire d’observance via le même canal, un utilisateur légèrement agacé par le résumé n’a aucun moyen de couper uniquement celui-ci. Il ouvre les Paramètres, trouve votre application et désactive entièrement les notifications — y compris les alertes de dose qui, elles, fonctionnaient bien.

La solution n’est pas de réduire le nombre de notifications. C’est de donner à chaque type de notification son propre canal, pour que les contrôles par canal du système fassent exactement le filtrage que l’utilisateur souhaite :

val doseChannel = NotificationChannel(
    CHANNEL_DOSE_ALERTS,
    "Dose reminders",
    NotificationManager.IMPORTANCE_HIGH
).apply {
    description = "Time-sensitive medication reminders"
    enableVibration(true)
}

val summaryChannel = NotificationChannel(
    CHANNEL_WEEKLY_SUMMARY,
    "Weekly adherence summary",
    NotificationManager.IMPORTANCE_LOW
).apply {
    description = "A once-a-week recap of your adherence"
}

notificationManager.createNotificationChannel(doseChannel)
notificationManager.createNotificationChannel(summaryChannel)

Désormais, un utilisateur qui souhaite garder les alertes mais pas le résumé peut couper exactement un canal depuis les paramètres système, et vos notifications importantes n’entrent jamais dans cette discussion.

Les réglages d’un canal se figent dès sa création

Voici la partie qui surprend le plus : une fois que createNotificationChannel() s’est exécuté pour un ID de canal donné, vous pouvez encore mettre à jour son nom et sa description plus tard, mais vous ne pouvez plus changer son importance, son son ou son motif de vibration par code — même en rappelant createNotificationChannel() une seconde fois avec des valeurs différentes. Le système considère le choix de l’utilisateur au niveau du canal (y compris la valeur par défaut que vous avez définie à la création) comme définitif à partir de ce moment-là.

C’est un choix de conception délibéré, pas un bug. Android veut que la décision d’un utilisateur de couper ou de rétrograder un canal survive à vos mises à jour, donc il verrouille les réglages que l’utilisateur a pu modifier. La conséquence pour vous : livrer IMPORTANCE_DEFAULT aujourd’hui puis décider le mois prochain qu’il faudrait vraiment IMPORTANCE_HIGH ne fonctionne pas avec le même ID de canal — rien ne se passe, silencieusement, et vous passerez un après-midi à comprendre pourquoi votre changement n’a eu aucun effet sur les installations existantes.

Migrer un canal sans perdre la confiance de l’utilisateur

La vraie solution consiste à versionner l’ID du canal et à migrer :

private const val CHANNEL_DOSE_ALERTS_V1 = "dose_alerts"
private const val CHANNEL_DOSE_ALERTS_V2 = "dose_alerts_v2"

fun ensureChannels(context: Context, prefs: SharedPreferences) {
    val nm = context.getSystemService(NotificationManager::class.java)

    if (!prefs.getBoolean("migrated_dose_channel_v2", false)) {
        nm.deleteNotificationChannel(CHANNEL_DOSE_ALERTS_V1)
        prefs.edit().putBoolean("migrated_dose_channel_v2", true).apply()
    }

    nm.createNotificationChannel(
        NotificationChannel(
            CHANNEL_DOSE_ALERTS_V2,
            "Dose reminders",
            NotificationManager.IMPORTANCE_HIGH
        )
    )
}

Supprimer l’ancien canal est optionnel — si vous le laissez, les notifications en attente encore étiquetées avec l’ancien ID continuent de se déclencher selon les anciens réglages jusqu’à ce que vous cessiez de l’utiliser. Mais si un utilisateur avait déjà coupé l’ancien canal et que le nouveau niveau d’importance doit vraiment l’atteindre, supprimer puis recréer est la seule voie. Faites-le avec parcimonie. Un utilisateur qui a coupé votre canal a fait un choix ; le réinitialiser à chaque version ne fait que l’habituer à couper aussi le nouveau.

Groupes de canaux, pour les applications qui en ont plusieurs

Dès qu’une application dépasse deux ou trois canaux, l’écran des paramètres de notification par application d’Android se transforme en une liste plate et sans étiquette — exactement ce que vous cherchiez à éviter. NotificationChannelGroup corrige cela en donnant aux canaux une section étiquetée dans les paramètres système :

nm.createNotificationChannelGroup(
    NotificationChannelGroup("reminders_group", "Reminders")
)
nm.createNotificationChannelGroup(
    NotificationChannelGroup("summaries_group", "Summaries & reports")
)

doseChannel.group = "reminders_group"
summaryChannel.group = "summaries_group"

Pour Hydrame, c’est la différence entre une liste plate de cinq canaux et deux groupes clairement étiquetés — les rappels d’hydratation sous « Rappels », le récapitulatif de l’objectif quotidien sous « Résumés ». Les utilisateurs qui parcourent les paramètres système peuvent voir d’un coup d’œil quel interrupteur fait quoi, plutôt que de deviner à partir d’un nom de canal tronqué à vingt caractères.

Tester les canaux sur un vrai appareil, pas seulement en revue de code

Le comportement des canaux varie suffisamment selon les surcouches constructeur pour que tester sur l’image d’émulateur standard ne suffise pas — Samsung, Xiaomi et OnePlus superposent tous leur propre interface de gestion des notifications par-dessus AOSP. Deux vérifications valent la peine d’être faites avant chaque version touchant au code de notification :

adb shell dumpsys notification --noredact

Cela affiche l’importance, le son et le groupe en direct de chaque canal pour l’installation en cours — utile pour confirmer qu’une migration a réellement pris effet plutôt que de faire confiance sans vérifier. Complétez-le par un passage manuel dans Paramètres → Applications → [votre application] → Notifications sur au moins un appareil réel, car c’est exactement l’écran sur lequel vos utilisateurs atterriront au moment où ils décideront que l’une de vos notifications était de trop.

La vraie question de conception

Le modèle mental utile n’est pas « combien de types de notifications mon application a-t-elle », mais « qu’est-ce qu’un utilisateur voudrait désactiver indépendamment, sans perdre autre chose sur lequel il compte ». Chaque endroit où ces deux choses divergent est une frontière de canal qui vous manque. Faites-le correctement et un utilisateur agacé par une notification coupe exactement celle-là et continue de faire confiance au reste. Faites-le mal et une seule mauvaise notification vous les coûte toutes.