Comment un compagnon IA devrait-il expliquer sa mémoire aux utilisateurs ?
Lorsqu'un compagnon IA enregistre ou utilise des informations sur une personne, son explication devrait permettre à cette dernière de répondre à six questions pratiques : ce qui a pu être mémorisé, d'où provient l'information, si l'enregistrement a été confirmé, où elle peut être réutilisée, combien de temps elle est conservée, et comment la vérifier, la corriger ou la supprimer. Le moment utile pour cette explication se situe lorsqu'un souvenir est suggéré, enregistré ou utilisé. La carte ci-dessous est une proposition de conception, et non une description de commandes déjà proposées par toutes les applications.
Que devrait indiquer une divulgation de mémoire à l'utilisateur ?
Une courte phrase telle que « Je garde cela à l'esprit » peut sembler claire tout en laissant l'état sous-jacent incertain. Cela signifie-t-il que le détail se trouve dans la conversation actuelle, qu'il est stocké pour plus tard, déduit d'une autre source ou simplement pris en compte dans la réponse suivante ? Une divulgation utile nomme cet état et offre à l'utilisateur un moyen de le vérifier.
Concevez la carte de sorte que chaque réponse soit visible à proximité de l'action concernée. Si un détail est simplement suggéré pour être enregistré, indiquez-le clairement comme une suggestion. Si l'application ne peut pas confirmer qu'une mémoire persistante a été enregistrée, dites-le sans détour ; ne sous-entendez pas qu'un changement a eu lieu. La formulation doit correspondre au comportement réel du système, y compris aux éventuels délais ou limites que le produit peut prouver.
Les six réponses
Question de l'utilisateur : Que peut-il devenir un souvenir ? — Ce que la carte doit indiquer : Le détail précis ou une description simple de sa catégorie, par exemple « Vous préférez des résumés de projet courts ». Évitez les termes vagues comme « personnalisation ».
Question de l'utilisateur : D'où cela provient-il ? — Ce que la carte doit indiquer : Identifiez la source : cette discussion, une discussion plus ancienne, une application connectée ou une autre source réellement utilisée par le produit. S'il s'agit d'une déduction, indiquez clairement qu'il s'agit d'une déduction.
Question de l'utilisateur : L'enregistrement a-t-il été confirmé ? — Ce que la carte doit indiquer : Précisez si l'élément est enregistré, en attente, suggéré ou non enregistré. Présentez des commandes de confirmation lorsque le produit les prend en charge.
Question de l'utilisateur : Où cela peut-il être réutilisé ? — Ce que la carte doit indiquer : Décrivez les destinations ou contextes concernés, tels que les discussions futures ou une fonctionnalité connectée désignée. Ne promettez pas que l'élément restera à un seul endroit à moins que cela ne soit vrai.
Question de l'utilisateur : Combien de temps cela restera-t-il ? — Ce que la carte doit indiquer : Indiquez une période de conservation prise en charge ou expliquez les conditions de suppression. Si la durée varie ou est inconnue, mentionnez-le et intégrez un lien vers la commande ou la politique applicable.
Question de l'utilisateur : Comment puis-je l'examiner, le corriger ou le supprimer ? — Ce que la carte doit indiquer : Intégrez un lien direct vers les commandes de mémoire ou d'activité applicables, et expliquez quelle action modifie quelle copie ou quelle source.
Il s'agit d'un modèle d'interaction proposé. Il ne doit pas être présenté comme une norme universelle ni comme l'affirmation que chaque compagnon dispose d'une mémoire par élément, d'une confirmation ou d'une période de conservation fixe. Si le produit ne propose pas l'une de ces commandes, la divulgation doit indiquer ce qui est disponible plutôt que de laisser entendre qu'une commande existe.
En quoi l'historique des discussions, la mémoire enregistrée et les données des applications connectées diffèrent-ils ?
Les utilisateurs ont besoin de savoir à quel type d'information ils ont affaire, car un même détail peut exister à plusieurs endroits. Une interface claire distingue au moins trois concepts :
**L'historique des discussions** est un enregistrement d'une conversation. Conserver ou supprimer cet enregistrement constitue une action unique, et son impact sur la personnalisation dépend de la conception du produit et des règles énoncées.
**La mémoire enregistrée** est une information que le produit conserve ou déduit pour une personnalisation ultérieure. Elle peut être liée à des discussions antérieures, mais elle est conceptuellement différente de la transcription visible. L'interface doit afficher l'élément ou expliquer pourquoi il ne peut pas être examiné séparément.
**La source d'application connectée** correspond aux informations accessibles depuis un autre service que l'utilisateur a associé. Déconnecter le service peut affecter les accès futurs, mais ne supprime pas nécessairement les informations déjà copiées, résumées ou incluses dans l'activité des discussions.
Ces distinctions sont essentielles dans les commandes réelles des produits. L'aide des applications Gemini de Google indique que la suppression des discussions passées peut prendre un court délai avant de cesser leur utilisation pour la personnalisation, et décrit la suppression ou la correction des informations associées aux discussions passées. Pour les informations mémorisées à partir d'une application connectée, elle précise que les utilisateurs peuvent devoir supprimer les discussions concernées et déconnecter l'application ; n'effectuer qu'une seule de ces actions peut laisser une autre source disponible. Il s'agit là de descriptions des commandes et du comportement de Gemini, et non de règles universelles pour les compagnons IA ([Aide des applications Gemini : mémoire des discussions passées](https://support.google.com/gemini/answer/16598469?co=GENIE.Platform%3DDesktop&hl=en)).
La page d'aide distincte de Google relative aux applications connectées indique également que déconnecter une application ou supprimer des données dans cette application ne supprime pas l'activité des applications Gemini, et que supprimer l'activité des applications Gemini ne supprime pas les données dans d'autres services. Cela illustre pourquoi une divulgation doit identifier la source et la copie concernée plutôt que d'utiliser un libellé générique « supprimer la mémoire » ([Aide des applications Gemini : applications connectées](https://support.google.com/gemini/answer/16836988?hl=en)).
À quoi ressemble une explication propre à chaque source ?
Prenons cet exemple fictif : Riley dit à un compagnon dans une discussion : « Je prévois un week-end à Portland », et a également connecté un calendrier contenant un événement à Portland. Le compagnon utilise plus tard à la fois la discussion et le contexte du calendrier pour suggérer un itinéraire. Riley supprime la discussion. Si le calendrier reste connecté, l'événement peut toujours constituer une source d'information indépendante ; la suppression de la conversation ne signifie pas logiquement que l'événement du calendrier a également été supprimé. Cet exemple illustre la séparation des sources. Il ne prétend pas qu'un produit particulier stocke ou réutilise ces informations fictives de cette manière.
Dans cette situation, une divulgation utile nommerait les sources séparément : « Cette suggestion a utilisé votre discussion passée sur Portland et un événement accessible depuis votre calendrier connecté. » Si Riley supprime la discussion, l'interface doit signaler l'état de cette source liée à la discussion et expliquer si la connexion au calendrier reste disponible. Si le produit ne peut pas déterminer si une source a été utilisée, il ne doit pas affirmer qu'elle l'a été.
La même règle s'applique à la correction. Si un utilisateur dit : « Cet événement n'est pas le mien », l'interface doit préciser si la correction met à jour une mémoire enregistrée, modifie la façon dont une discussion est utilisée ou laisse le calendrier connecté inchangé. Une correction apportée à un niveau ne doit pas être décrite comme corrigeant toutes les sources, à moins que ce ne soit réellement le cas.
Pourquoi « Je me souviens de vous » n'est-il pas suffisant ?
Supposons qu'une application réponde « Je me souviens de vous », mais ne puisse afficher un élément enregistré, identifier une source, confirmer un état persistant ni expliquer comment l'utilisateur peut le modifier. Cette formulation est peut-être naturelle dans une conversation, mais elle ne prouve pas qu'un souvenir a été enregistré. Elle pourrait décrire le contexte de la discussion actuelle, une réponse générée ou un enregistrement persistant ; sans informations sur l'état, l'utilisateur ne peut pas les distinguer.
Pour les concepteurs, il s'agit d'un contre-exemple utile : ne laissez pas un langage amical se substituer à une confirmation concrète. Après une action, affichez un statut explicite tel que « Enregistré », « Non enregistré » ou « Impossible de confirmer », mais utilisez uniquement des statuts que le système peut vérifier. Prévoyez un moyen d'examiner l'élément lorsqu'il est disponible. S'il n'existe pas d'enregistrement de mémoire distinct que l'utilisateur puisse examiner, expliquez ce que la phrase signifie dans ce produit et où sont gérées les informations qui s'y rapportent.
Comment les utilisateurs doivent-ils vérifier et gérer un souvenir ?
Lorsqu'un compagnon fait référence à un détail de manière inattendue, l'utilisateur devrait pouvoir suivre une courte séquence diagnostique :
**Demander quelles informations ont été utilisées.** Demandez le détail précis et sa source. Considérez la réponse comme une explication à vérifier par rapport aux commandes du produit, et non comme une preuve en soi.
**Ouvrir la source mentionnée.** Vérifiez la conversation concernée, les paramètres de mémoire, l'historique d'activité ou les paramètres des applications connectées. Ne supposez pas qu'il s'agit du même enregistrement.
**Corriger au bon niveau.** Si le détail enregistré est erroné, modifiez-le ou supprimez-le dans les commandes de mémoire lorsqu'elles sont disponibles. Si l'information provient d'un service connecté, examinez également cette connexion ou l'élément d'origine.
**Vérifier le résultat.** Recherchez un changement d'état ou une confirmation. Si le produit ne peut pas confirmer une suppression ou une correction, il doit le préciser et décrire tout délai ou limitation documenté pour cette action.
Les commandes disponibles varieront d'un produit à l'autre. Les pages d'aide de Gemini, par exemple, décrivent comment activer ou désactiver la mémoire des discussions passées, trouver et supprimer des discussions passées, et corriger des informations directement dans une discussion. Elles expliquent également que les données des applications connectées et l'activité de Gemini suivent des voies de gestion distinctes. Ces exemples sont utiles car ils rendent concrètes les distinctions entre sources ; ils ne doivent pas être transposés comme une garantie qu'une autre application propose les mêmes paramètres.
Placer l'explication à côté de l'action liée à la mémoire
Une carte en six réponses fonctionne au mieux lorsqu'elle apparaît au moment précis où l'utilisateur en a besoin : avant de confirmer une mémoire suggérée, après un enregistrement, ou lorsqu'une réponse utilise des informations issues d'une discussion passée ou d'une application connectée. Présentez un statut concis, nommez la source dans des termes familiers et fournissez à l'utilisateur un lien vers la commande permettant de modifier l'enregistrement concerné. Lorsque la conservation ou la réutilisation n'est pas connue avec précision, décrivez l'incertitude au lieu d'inventer une durée ou une garantie.
Le test est simple : après avoir lu l'explication, l'utilisateur peut-il déterminer quelles informations sont en jeu, d'où elles proviennent, si elles ont réellement été enregistrées, où elles peuvent être utilisées, ce qui permet de les conserver et comment les modifier ? Si ce n'est pas le cas, « Je me souviens de vous » n'est qu'une simple formule. Une divulgation utile rend compréhensible l'état réel du produit et offre à l'utilisateur une étape pratique à suivre.