Comment permettre aux utilisateurs de choisir quand et à quelle fréquence une IA les contacte

Commencer par une adhésion claire et facultative

Demandez l'autorisation au moment où la personne est en mesure de comprendre ce qu'elle accepte. Décrivez les types de contact en des termes clairs et simples : par exemple, un rappel demandé par l'utilisateur ou une mise à jour périodique. Précisez où le message sera reçu et à quelle fréquence il pourra être envoyé. Évitez de vous limiter à une invite d'autorisation du système d'exploitation sans explication ; les utilisateurs doivent savoir ce que l'application souhaite envoyer avant de prendre une décision.

L'U.S. Web Design System conseille de ne recueillir les préférences de contact que pour les canaux que le service peut réellement prendre en charge, et recommande d'expliquer les conditions ainsi que les délais prévus de contact lorsque cela est possible. Appliqué à un produit d'IA, cela implique de n'afficher que les options de distribution réelles et de préciser l'utilité de chacune. Ne faites pas d'une préférence de notification une condition pour accéder à des fonctionnalités sans rapport. USWDS: Contact preferences

Traitez l'adhésion comme un choix que l'utilisateur peut modifier à tout moment. Les directives d'Apple relatives aux notifications recommandent de proposer une adhésion ou une désinscription explicite pour chaque type de notification, ainsi qu'un moyen de gérer ces réglages directement dans l'application. Un produit peut appliquer ce principe en intégrant une page de paramètres récapitulant les choix actuels, plutôt que d'obliger l'utilisateur à chercher dans les réglages généraux de son appareil pour comprendre la planification propre à l'application. Apple: Managing notifications

Rendre les horaires concrets

Permettez aux utilisateurs de choisir un créneau adapté à leur quotidien, comme les jours de semaine entre 18 h et 20 h, ou une heure récurrente certains jours choisis. Affichez ensemble les jours ainsi que les heures de début et de fin. Si le paramètre définit une « plage de contact », précisez si le message peut arriver à n'importe quel moment de cette plage ou à une heure fixe. S'il n'y a aucun message pertinent un jour donné, indiquez si le système ignore ce jour ou reporte le message au créneau suivant.

Une conception pratique peut proposer quelques préréglages simples, comme « une fois par semaine » ou « en semaine », tout en offrant la possibilité de personnaliser les horaires si le produit le permet. Un préréglage doit correspondre à un planning visible, et non à un libellé ambigu. Par exemple, « hebdomadaire » doit afficher le jour et l'heure choisis, et « jusqu'à trois fois par semaine » doit préciser si le chiffre trois est un plafond ou un objectif. Il s'agit d'une recommandation de conception : la documentation de la plateforme prend en charge les envois programmés, mais l'équipe produit doit elle-même définir et expliciter ses propres règles d'envoi.

Soyez précis quant aux fuseaux horaires. Indiquez sur le calendrier un lieu précis ou le fuseau horaire local actuel de l'appareil, et informez les utilisateurs si le calendrier s'adapte lorsqu'ils voyagent ou s'il reste fixé au fuseau horaire d'origine. Un simple décalage UTC peut prêter à confusion lors des passages à l'heure d'été/d'hiver ou en cas de modification des fuseaux par les autorités. La base de données des fuseaux horaires de l'IANA répertorie les règles par région et est mise à jour pour refléter les décisions politiques, y compris les changements de décalage et d'heure d'été. IANA: Time Zone Database

Une confirmation claire pourrait être formulée ainsi : « Le mardi à 19 h 00, selon votre heure locale actuelle. Ce calendrier suit le fuseau horaire de votre appareil. » Cette formulation n'est exacte que si l'implémentation suit réellement le fuseau actuel de l'utilisateur. Si le calendrier reste rattaché à une zone géographique définie, indiquez ce lieu à la place. Lorsqu'une personne voyage ou que le fuseau horaire de l'appareil change, affichez le calendrier effectif et prévoyez un moyen de le vérifier.

Séparer les types de messages et les canaux

Les utilisateurs peuvent souhaiter un certain type de contact mais pas un autre. Veillez à ce que les rappels facultatifs, les mises à jour de produits et les autres catégories distinctes puissent être sélectionnés séparément, au lieu de les regrouper sous une commande unique du type « Notifications de l'IA ». N'inventez pas de catégories qui ne correspondent à aucun comportement réel du produit, et ne créez pas de catégorie servant de prétexte pour envoyer des messages que l'utilisateur n'a pas demandés.

Cette séparation s'aligne également sur les fonctionnalités des plateformes. Sur les versions récentes d'Android, les notifications doivent être assignées à des canaux, et les utilisateurs peuvent en modifier le comportement ; les recommandations d'Android préconisent des canaux permettant de personnaliser les notifications reçues. L'application peut nommer ces canaux avec des termes explicites, comme « Rappels programmés », et décrire ce qui relève de chacun. Android Developers: Create and manage notification channels

Veillez à ce que la liste des canaux reste suffisamment courte pour demeurer claire. Chaque canal doit représenter un choix significatif qu'un utilisateur pourrait vouloir faire de manière autonome. Les paramètres de l'application doivent toujours expliquer le contenu et la fréquence : les réglages des canaux au niveau du système d'exploitation peuvent modifier l'affichage d'une notification, mais ils n'expliquent pas la politique d'envoi de l'application et ne remplacent pas une planification interne au produit.

Mettre les commandes de pause, de reprise et de désactivation à portée de main

Proposez une option de pause temporaire ainsi qu'une option d'arrêt définitif. Une mise en pause doit préciser clairement sa durée — par exemple jusqu'à une date définie ou jusqu'à ce que l'utilisateur la réactive — et indiquer si les messages programmés sont ignorés ou conservés en attente. Une commande de désactivation doit préciser les catégories ou canaux concernés et confirmer immédiatement le changement d'état. La reprise ne doit pas réactiver discrètement un calendrier antérieur sans indiquer ce qui va se passer ensuite.

Rendez ces réglages accessibles depuis l'écran des paramètres de notification et, lorsque c'est pertinent, via une action directement dans la notification ou un lien direct vers les paramètres. Android prend en charge les actions au sein des notifications et fournit des outils au niveau du système pour gérer les futures notifications ; ces commandes varient selon l'appareil et la version d'Android. Par conséquent, un accès intégré à l'application demeure indispensable pour afficher l'ensemble du calendrier et modifier les préférences du produit. Android Developers: Notifications

Les réglages au niveau de l'appareil restent prépondérants. Un utilisateur peut désactiver les notifications d'une application ou modifier le comportement d'un canal directement dans les paramètres du système d'exploitation, indépendamment de la planification propre à l'application. L'interface ne doit pas laisser entendre qu'un paramètre dans l'application prévaut sur ces choix. Si les notifications du système sont désactivées, affichez un statut clair lorsque l'utilisateur consulte les paramètres, et évitez de lui demander sans cesse de les réactiver.

Définir une limite de fréquence que le système peut appliquer

Offrez un choix clair en matière de fréquence : par exemple, un message par jour au maximum, une limite hebdomadaire ou un nombre de jours choisi par l'utilisateur. Définissez la période prise en compte et ce qui constitue un message. Si plusieurs catégories permettent d'envoyer des messages, précisez si la limite s'applique par catégorie ou à l'ensemble du produit. Une limite définie par catégorie pouvant tout de même générer un volume global trop élevé, une conception pertinente prévoit souvent un plafond global supplémentaire.

Un plafond n'est efficace que si chaque canal d'envoi le respecte. Vérifiez que les rappels programmés, les relances, les messages différés et les messages déclenchés par différentes fonctionnalités respectent tous le même état de préférences. Si un message prend du retard, déterminez s'il expire, s'il est remis plus tard au cours du créneau autorisé ou s'il est purement annulé ; détaillez le comportement qui a de l'importance pour l'utilisateur. Évitez d'envoyer d'un coup plusieurs messages en attente lorsqu'un appareil se reconnecte, à moins que l'utilisateur n'ait expressément choisi cette option.

La distribution par la plateforme ne correspond pas à la décision d'envoi du produit. Firebase Cloud Messaging indique que les messages sont généralement remis immédiatement, mais un appareil peut être indisponible ou l'envoi retardé ; le service peut conserver un message et tenter de le remettre plus tard, dans la limite de sa durée de vie configurée. Le produit ne doit donc pas garantir qu'une notification s'affichera à une minute précise. Il peut promettre de programmer l'envoi dans un intervalle défini, tout en précisant que l'état de l'appareil et de la plateforme peut influer sur le moment de sa réception. Firebase: Set the lifespan of a message

Cette distinction se répercute également sur la fréquence. Si une notification a été mise en file d'attente et arrive avec du retard, le système doit vérifier si l'utilisateur a entre-temps mis en pause ou désactivé cette catégorie, et si cet envoi ne dépasserait pas le plafond actuel. Une conception rigoureuse annule ou bloque les messages obsolètes en file d'attente dès lors que les derniers choix de l'utilisateur les rendent inéligibles.

Une logique de décision simple pour la conception

Suivez cette chronologie pour faire des paramètres un engagement clair vis-à-vis de l'utilisateur :

Identifiez les types de messages que le produit peut concrètement envoyer, et rendez chaque catégorie optionnelle facile à comprendre.

Invitez l'utilisateur à accepter activement (opt-in) chaque catégorie et canal de distribution souhaités. Ne présélectionnez aucun contact facultatif.

Permettez à l'utilisateur de choisir les jours, une heure ou un créneau, ainsi qu'une fréquence maximale. Précisez si le plafond est global ou par catégorie.

Affichez le fuseau horaire et indiquez si le planning s'ajuste lorsque le fuseau de l'appareil change.

Rendez bien visibles les commandes de pause, de reprise et d'arrêt, puis présentez l'état actuel ainsi que la prochaine échéance de contact autorisée.

Avant tout envoi, vérifiez à nouveau la planification, le plafond, l'état de mise en pause et les préférences de catégorie. Considérez que la distribution sur l'appareil peut être différée, et décrivez l'engagement du produit en vous limitant aux éléments qu'il contrôle.

Un récapitulatif compact des réglages facilite la vérification des choix : « Rappels programmés : activés. Les mardis et jeudis, de 19 h à 20 h, heure locale. Maximum : deux par semaine toutes catégories confondues. Vous pouvez suspendre ou désactiver ces notifications à tout moment. » Les options proposées doivent correspondre aux capacités techniques réelles ; si un produit ne peut pas faire respecter le plafond affiché ou suivre l'heure locale de manière fiable, il convient d'adapter l'implémentation ou de limiter les options présentées avant d'afficher ces réglages.

Continuer sur ce thème