Comment un compagnon IA peut-il éviter les rappels pour une mauvaise date importante ?

Pourquoi se souvenir d'une date n'équivaut pas à programmer un rappel

Une conversation peut contenir un fait utile sans pour autant contenir l'autorisation de créer une alerte. « Le récital de Maya a lieu le 14 mai » peut être une note partagée par l'utilisateur, un projet incertain ou une date déduite d'une formulation ambiguë. Cela ne précise pas en soi si un rappel est souhaité, quelle année s'applique, à quelle heure l'envoyer ou quel fuseau horaire utiliser.

Une conception fiable traite donc ces éléments comme des enregistrements distincts :

**Fait mémorisé :** ce qui a été dit ou fourni, avec sa source et toute incertitude éventuelle.

**Date confirmée :** la personne ou l'événement et la date calendaire que l'utilisateur a vérifiés.

**Notification programmée :** une alerte explicitement approuvée par l'utilisateur, avec une heure de distribution, un fuseau horaire et un état actuel.

Cette séparation est une recommandation de conception pour les compagnons IA. Les pages d'aide de Google Agenda décrivent comment créer des événements et gérer les notifications dans l'Agenda ; elles ne décrivent pas la mémoire d'un compagnon IA et ne mettent pas en œuvre le flux de travail proposé ici. À titre d'exemple d'agenda uniquement, les instructions de Google traitent la création d'un événement comme une action comprenant des détails sur l'événement et une étape d'enregistrement ([Google Calendar: Create an event](https://support.google.com/calendar/answer/72143?hl=en)).

Quels détails doivent être confirmés avant la programmation ?

Confirmez les détails qui déterminent la signification de l'alerte et le moment où elle peut se déclencher. Un court écran récapitulatif ou un résumé conversationnel doit présenter :

**Personne ou événement :** À qui ou à quoi la date fait-elle référence ?

**Date complète :** Jour, mois et année. Un mois et un jour sans année peuvent être incomplets, d'autant plus qu'ils pourraient faire référence à un événement passé ou futur.

**Origine de la date :** D'où provient la date — par exemple, d'une déclaration de l'utilisateur, d'une entrée de calendrier importée ou d'une déduction ? Mettez clairement en évidence l'incertitude plutôt que de présenter une supposition comme acquise.

**Heure du rappel :** Le délai de prévenance demandé et l'heure locale, par exemple « un jour avant à 9h00 ».

**Fuseau horaire :** Le fuseau qui doit régir la distribution, en particulier si l'utilisateur voyage ou si la date concerne une personne située dans un autre lieu.

**Autorisation et distribution :** Si l'utilisateur souhaite effectivement une alerte, et où elle apparaîtra si le produit propose plusieurs canaux de diffusion.

Google Agenda permet aux utilisateurs de définir des notifications pour les événements et de modifier les paramètres de notification ; les paramètres de son compte et de ses événements déterminent le fonctionnement de ces notifications d'Agenda ([Google Calendar: Change notifications](https://support.google.com/calendar/answer/37242?hl=en)). C'est un exemple utile pour traiter une notification comme une action configurée disposant de ses propres commandes, et non comme la conséquence automatique de la simple connaissance d'une date. Cela ne doit pas être interprété comme la preuve que l'Agenda dispose d'une mémoire de type compagnon.

Un exemple fictif : du détail mémorisé à l'alerte confirmée

Supposons qu'un utilisateur dise : « Le récital de Maya a lieu le 14 mai ». Le compagnon peut conserver cela comme un **fait mémorisé non confirmé** : la personne, l'événement et le mois/jour sont présents, mais l'année, le fuseau horaire et l'autorisation de notifier ne le sont pas. Il ne doit pas programmer d'alerte à partir de cette seule phrase.

Le compagnon pourrait demander : « J'ai noté que le récital de Maya pourrait avoir lieu le 14 mai. De quelle année s'agit-il, quel fuseau horaire dois-je utiliser et souhaitez-vous un rappel ? » L'utilisateur répond : « Le 14 mai 2027, America/Los_Angeles. Merci de me le rappeler la veille à 9h00, heure du Pacifique. » Le compagnon résume : « Je vous rappellerai le récital de Maya le 13 mai 2027 à 9h00 America/Los_Angeles, un jour avant le récital du 14 mai. Faut-il le programmer ? »

Ce n'est qu'après confirmation par l'utilisateur que le système doit créer un enregistrement de notification tel que : **Récital de Maya — 14 mai 2027 — rappel le 13 mai 2027 à 9h00 America/Los_Angeles — actif**. La date et l'heure ci-dessus sont des exemples fictifs et ne correspondent pas à une personne ou à un événement réel. Nommer explicitement le fuseau horaire évite de considérer « 9h00 » comme universel. Les instructions de Google Agenda sur les fuseaux horaires expliquent que les heures d'événements sont affichées dans les fuseaux locaux et que les changements de fuseau peuvent affecter l'affichage des éléments de l'agenda ; il s'agit d'un exemple de comportement de l'Agenda, pas d'une affirmation sur les rappels d'une IA ([Google Calendar: Use Calendar in different time zones](https://support.google.com/calendar/answer/37064?hl=en)).

Le récapitulatif présenté à l'utilisateur est essentiel car il offre une dernière occasion de repérer une inversion de jour et de mois, une mauvaise année, une personne incorrecte ou une mauvaise interprétation de « la veille ». Si l'utilisateur modifie le résumé, le compagnon doit reformuler les détails modifiés et obtenir confirmation pour le calendrier qui en résulte.

Que doit-il se passer lorsqu'une date est non résolue ou conflictuelle ?

N'envoyez pas d'alerte basée sur une date que le système ne peut pas identifier avec certitude. Par exemple, si une note indique que le récital de Maya a lieu le 14 mai 2027 et qu'une autre indique le 21 mai 2027, les dates sont en conflit. Le compagnon peut signaler le conflit et demander quelle date est correcte, mais l'état de la notification doit rester **non programmée** jusqu'à ce que l'utilisateur résolve le problème et confirme un horaire.

La même règle s'applique lorsqu'un détail essentiel est manquant. « Rappelle-moi avant le récital » ne précise pas quand a lieu le récital, combien de temps à l'avance le rappel doit intervenir, ni éventuellement de quel récital l'utilisateur veut parler. Posez une question ciblée de suivi. Si l'utilisateur ne répond pas, conservez l'élément comme une note non résolue sans notification active. Cela évite de transformer une déduction en une alerte que l'utilisateur n'a jamais approuvée.

Un modèle de statuts pertinent rend ce comportement compréhensible : **non confirmé**, **nécessite clarification**, **programmé**, **en pause**, **annulé** ou **terminé**. « Non confirmé » et « nécessite clarification » ne doivent pas se comporter comme « programmé ». Un système peut conserver le fait mémorisé sous-jacent si approprié, mais il ne doit pas laisser entendre qu'une alerte existe tant qu'elle n'a pas été réellement configurée.

Comment doivent fonctionner les corrections, les mises en pause et les annulations ?

**Correction :** Si l'utilisateur indique que le récital a lieu le 21 mai et non le 14 mai, mettez à jour la date et réaffichez l'heure de rappel proposée. Demandez confirmation avant d'activer le calendrier corrigé. Si un rappel était déjà programmé, identifiez clairement quelle alerte active la correction va modifier et confirmez la date révisée avant de la remplacer. Conservez un historique visible suffisant pour expliquer l'état actuel, sans masquer l'ancienne date d'une manière qui pourrait induire l'utilisateur en erreur.

**Mise en pause :** La mise en pause doit suspendre temporairement la distribution tout en préservant la date et les détails du rappel. Indiquez que la notification est en pause et précisez si elle reprendra automatiquement ou si elle nécessite une réactivation manuelle par l'utilisateur. Ne qualifiez pas d'actif un rappel mis en pause. La mise en pause est particulièrement utile lorsque l'utilisateur souhaite clarifier un détail plus tard sans pour autant qu'une alerte se déclenche entre-temps.

**Annulation :** L'annulation doit désactiver la notification programmée, et non se contenter de supprimer une note de conversation ou de masquer l'élément. Confirmez quel rappel est annulé lorsque plusieurs éléments pourraient correspondre, puis affichez un statut annulé. Si la date mémorisée reste utile, gardez-la séparée de l'alerte annulée et proposez des options compréhensibles pour modifier ou supprimer ce fait. L'Agenda fournit des commandes pour modifier les paramètres de notification, y compris pour un événement individuel ; il s'agit d'un exemple restreint de gestion des notifications, et non d'une preuve de la manière dont un compagnon IA stocke ou annule les rappels ([Google Calendar notification help](https://support.google.com/calendar/answer/37242?hl=en)).

Après toute modification, affichez l'état obtenu ainsi que les détails importants : la date à laquelle le rappel fait référence, l'heure à laquelle il se déclencherait, son fuseau horaire et s'il est actif, en pause ou annulé. Une modification silencieuse est difficile à vérifier pour l'utilisateur et peut laisser subsister une hypothèse dépassée.

Une courte liste de contrôle pour les utilisateurs

Avant de vous fier à un rappel de date, vérifiez l'élément lui-même :

La personne ou l'événement est-il correctement nommé ?

La date complète, y compris l'année, est-elle confirmée ?

Puis-je savoir d'où vient la date, et toute incertitude est-elle visible ?

Ai-je explicitement approuvé une alerte, au lieu de simplement mentionner la date ?

Le délai de prévenance, l'heure et le fuseau horaire du rappel sont-ils corrects ?

L'élément indique-t-il qu'il est programmé et actif, ou nécessite-t-il encore des clarifications ?

Si je l'ai corrigé, mis en pause ou annulé, l'état affiché correspond-il à ce que j'ai demandé ?

Si une réponse n'est pas claire, examinez ou traitez l'élément avant de le considérer comme une notification programmée. Le principe pratique de conception est simple : conserver les informations incertaines comme étant incertaines, rendre l'alerte proposée facile à inspecter, et ne créer ou modifier une notification active qu'une fois que l'intention de l'utilisateur et les détails pertinents de la date sont parfaitement clairs.

Continuer sur ce thème