Mémoire conversationnelle des chatbots IA : se souvenir, corriger et oublier à temps

« Retenez mon adresse de livraison préférée » peut rendre un chatbot de site web très pratique. Mais ce même mécanisme peut aussi véhiculer des informations anciennes, erronées ou sensibles dans des conversations ultérieures. On confond souvent trois éléments : le contexte à court terme d'une session, le résumé synthétique pour la reprise d'une conversation et le profil utilisateur permanent. Ils répondent pourtant à des objectifs, des risques et des durées de conservation bien distincts.

Une mémoire conversationnelle efficace ne cherche donc pas à tout enregistrer. Elle conserve un petit nombre de faits clairement justifiés, accompagnés de leur origine, de leur durée de validité et d'un contrôle visible. Ce guide présente un modèle technique et rédactionnel conciliant utilité, exactitude et protection des données.

Séparer clairement trois types de mémoire

Le contexte de session contient les derniers messages afin de maintenir la compréhension des questions de suivi. Il prend fin après une courte période d'inactivité ou lors de la fermeture explicite du chat. Les résumés de reprise réduisent un historique plus long au strict état de travail nécessaire, par exemple un ticket d'assistance encore ouvert. Les préférences permanentes s'appliquent d'une session à l'autre, comme un choix de langue délibérément enregistré par l'utilisateur.

Cette séparation évite qu'un journal de chat complet ne se transforme en un profilage illimité. Chaque type de mémoire bénéficie de sa propre finalité, de ses règles d'accès, d'une durée de conservation et d'une procédure de suppression dédiées. Une table technique comportant un champ unique « memory » sans cette distinction s'avère difficile à auditer et encore plus complexe à nettoyer de façon fiable.

Ne retenir que des faits explicites et pertinents

Un chatbot ne doit pas déduire automatiquement une caractéristique permanente de chaque déclaration. Dire « J'ai besoin d'une facture en anglais aujourd'hui » ne signifie pas nécessairement que l'anglais soit la préférence à long terme. N'enregistrez de manière durable que les informations dont l'utilité au-delà de la session en cours est évidente et dont la conservation reste prévisible pour l'utilisateur.

Les informations particulièrement sensibles, les données de santé en texte libre, les détails de paiement, les mots de passe et les codes d'authentification à usage unique n'ont pas leur place dans la mémoire générale d'un chat. Pour les opérations commerciales, le système métier dédié constitue généralement le bon emplacement de stockage. Le chatbot peut consulter une référence autorisée au lieu de maintenir une seconde copie fantôme.

Un fait mémorisé nécessite des métadonnées

Enregistrez les faits sous forme d'un enregistrement structuré plutôt que comme un bloc de texte non contrôlé. Les champs utiles comprennent :

• Valeur et type : par exemple, la langue préférée ou la catégorie de produit sélectionnée.
• Origine : saisie explicite de l'utilisateur, résumé confirmé ou système métier vérifié.
• Finalité : la raison pour laquelle cette valeur sera nécessaire lors de la prochaine conversation.
• Périmètre de validité : utilisateur, organisation, site web et, le cas échéant, paramètre régional.
• Date et expiration : quand l'information a été enregistrée, confirmée pour la dernière fois et supprimée automatiquement.
• Niveau de confiance : déduction non confirmée, validée ou vérifiée.

Les résumés générés librement par le modèle peuvent être utiles, mais doivent être identifiables comme tels. Ils ne doivent jamais devenir silencieusement des données clients vérifiées.

Demander l'accord de manière transparente avant d'enregistrer

Si une information doit être réutilisée au-delà de la session en cours, l'interface doit proposer un choix clair. Précisez la valeur exacte, sa finalité et les modalités de suppression. Une simple confirmation telle que « Enregistrer cette langue pour les futurs échanges ? » est bien plus claire qu'un consentement générique pour des services personnalisés.

Selon la finalité visée, la base juridique peut varier et doit faire l'objet d'une analyse au cas par cas. L'interface ne doit pas l'imposer par des pièges à conviction (dark patterns). Un refus ne doit pas empêcher inutilement l'accès normal au chat. Consignez le choix de l'utilisateur séparément du contenu stocké.

Se souvenir implique toujours une recherche ciblée

Lors de la conversation suivante, l'intégralité du profil ne doit pas être injectée aveuglément dans chaque prompt. Vérifiez d'abord l'identité et le compte, puis ne chargez que les attributs nécessaires à l'intention actuelle. Une question sur une facture peut nécessiter la langue et le numéro de client, mais pas une ancienne réclamation concernant un produit.

Fournissez également au modèle l'origine et l'ancienneté de la donnée. Un résumé ancien et non confirmé doit inciter le système à poser une question de clarification. En revanche, une valeur issue d'un système faisant autorité peut être utilisée directement. On évite ainsi de masquer les incertitudes derrière une formulation fluide.

La correction intégrée comme un parcours produit standard

Les personnes changent d'avis et les modèles commettent des erreurs de synthèse. Proposez une vue « Ce que le chatbot a mémorisé » permettant la modification et la suppression. En cours de discussion, une remarque telle que « Ce n'est plus exact » doit permettre d'identifier la valeur concernée et d'en demander la confirmation avant modification.

Les corrections doivent se répercuter sur l'ensemble des couches concernées : profil, index de recherche, cache et résumés dérivés. Modifier le champ visible sans mettre à jour un ancien embedding qui continue de remonter dans les résultats crée des récurrences d'erreurs difficiles à expliquer. Conservez un journal d'audit des modifications sans immortaliser inutilement la donnée sensible supprimée dans les logs.

Appliquer rigoureusement les expirations et suppressions

L'article 5 du RGPD consacre les principes de minimisation des données et de limitation de la conservation. Traduisez ces exigences en règles automatisées. Le texte de la session peut disparaître rapidement, l'état de reprise après la clôture du dossier, et les préférences après une période d'inactivité prolongée mais définie. « Durée illimitée si cela s'avère utile plus tard » ne constitue pas un délai acceptable.

Une demande de suppression doit suivre une chaîne complète et traçable : enregistrement principal, embedding, cache, exports d'analyse et sauvegardes. Si les sauvegardes répondent à des délais techniques distincts, elles ne doivent en aucun cas réinjecter des données supprimées dans le service actif. Testez régulièrement vos procédures de suppression avec des données de test marquées.

Pas d'entraînement secret des modèles à partir des chats

La mémoire fonctionnelle du produit et l'entraînement du modèle répondent à des finalités distinctes. Accepter qu'une information soit conservée pour le prochain contact du support ne vaut pas consentement pour l'amélioration d'un modèle généralist. Séparez les jeux de données d'entraînement ou d'évaluation sur les plans organisationnel et technique, et n'anonymisez que si le processus est réellement irréversible.

Dans son avis sur les modèles d'IA, l'EDPB souligne que l'anonymat d'un modèle doit s'évaluer au cas par cas. Le simple retrait des noms visibles ne suffit pas nécessairement. Pour de nombreuses équipes web, la solution la plus simple et la plus sûre consiste à exclure par défaut les chats de production des corpus d'entraînement.

Mesurer la qualité et la sécurité

La mémoire requiert des tests dédiés. Vérifiez l'absence de fuites entre utilisateurs ou comptes, la bonne gestion des valeurs expirées, les déclarations contradictoires, la révocation du consentement, l'export et la suppression intégrale. Ne mesurez pas seulement la fréquence d'utilisation des souvenirs, mais aussi le taux de correction par les utilisateurs ou leurs réactions de surprise.

Un jeu de données de référence (Golden Set) peut simuler divers scénarios : deux personnes sur le même appareil, un changement de rôle dans une entreprise, une nouvelle adresse de livraison, une modification de la langue, un compte supprimé ou la saisie d'une donnée sensible qui ne doit jamais être conservée. Chaque version doit prouver que l'isolation et les mécanismes d'expiration fonctionnent toujours.

Un plan de déploiement pragmatique

1. Inventorier les types de mémoire et leurs finalités.
2. Définir l'origine, la durée de validité et le délai d'expiration pour chaque type.
3. Commencer par une préférence simple et explicitement confirmée.
4. Restreindre l'accès en fonction du compte, de l'identité et de l'intention en cours.
5. Proposer des interfaces d'affichage, de correction, d'exportation et de suppression.
6. Inclure les mémoires dérivées et les caches dans la chaîne de suppression.
7. Tester régulièrement l'isolation, l'expiration et la restauration.

Conclusion : une bonne mémoire sait expliquer la provenance de ce qu'elle sait

Une mémoire de chatbot pertinente reste concise, structurée et contrôlable. Elle distingue le contexte à court terme des caractéristiques permanentes, ne stocke que les faits appropriés et rend l'origine ainsi que l'expiration des données transparentes. Les utilisateurs peuvent corriger ou supprimer leurs informations sans avoir à contacter le support.

Ne commencez pas par vous demander quelles données sont techniquement enregistrables. Débutez par une seule information dont l'utilité future est avérée – et concevez simultanément la manière dont elle sera confirmée, rectifiée et définitivement oubliée.

Sources

• EUR-Lex : Règlement général sur la protection des données, notamment l'article 5
• EDPB : Opinion 28/2024 on AI Models and Personal Data
• EDPB : Fundamentals of Secure AI Systems with Personal Data
• NIST Privacy Framework