Supprimer et exporter l'historique du chatbot : un contrôle utilisateur sécurisé

Un historique de chatbot est pratique pour les utilisateurs : ils peuvent relire des réponses, reprendre une conversation ultérieurement ou transmettre des informations au support. Cependant, cette même historique peut contenir des numéros de commande, des descriptions de problèmes, des coordonnées ou d'autres données sensibles. C'est pourquoi conserver des conversations exige plus qu'un simple bouton « Historique » discret. Les utilisateurs doivent comprendre quelles données existent, comment les emporter, les supprimer ou révoquer les accès ultérieurs.

Ce guide présente un modèle produit et technique opérationnel pour les chatbots de sites web. Il concilie convivialité, sobriété des données, vérification d'identité sécurisée et états de système intelligibles. Ces conseils ne constituent pas un conseil juridique personnalisé ; les obligations concrètes dépendent notamment de la finalité, de la base légale, de l'architecture du système et des données concernées.

Quatre fonctionnalités au lieu d'un seul bouton d'historique

« Gérer l'historique » est une notion trop floue. L'interface et le backend doivent distinguer clairement quatre intentions différentes :

• Consulter : Les utilisateurs lisent les conversations enregistrées, les pièces jointes et les métadonnées visibles selon une chronologie compréhensible.
• Exporter : Ils reçoivent une copie dans un format lisible et, si cela est pertinent pour le cas d'usage ou exigé par la loi, dans un format structuré et lisible par machine.
• Supprimer : Ils effacent des conversations individuelles ou l'intégralité de l'historique associé. L'interface explique le périmètre, les délais et les exceptions possibles.
• Révoquer l'accès : Ils invalident les liens de partage, les appareils connus ou les jetons de reprise, sans nécessairement supprimer immédiatement toutes les données de contenu.

Cette distinction évite des malentendus dangereux. « Se déconnecter » ne supprime pas les données de conversation. « Masquer l'historique » n'est pas une suppression. Et un lien expiré ne signifie pas automatiquement que les enregistrements sous-jacents ont disparu. En complément, consultez notre guide sur la reprise sécurisée des conversations de chatbot.

Commencer par un modèle de données clair

Avant que les équipes ne conçoivent des boutons, elles doivent inventorier les objets stockés. Une conversation ne se résume souvent pas à de simples messages. S'y ajoutent des identifiants de session, des horodatages, des références de fichiers, des événements de sécurité, des tickets de support, des retours d'expérience et des journaux techniques. Chaque objet nécessite une finalité documentée, un responsable, une règle de conservation et un parcours de suppression.

Le Règlement général sur la protection des données mentionne à l'article 5 la minimisation des données et la limitation de la conservation. L'article 15 concerne le droit d'accès, l'article 17 le droit à l'effacement avec ses conditions et exceptions, et l'article 20 la portabilité des données selon leurs champs d'application respectifs. Il ne s'en suit pas que chaque interface de chatbot doive proposer des fonctionnalités identiques. Les équipes produit doivent cependant construire les flux de données de manière à ce que les demandes légitimes puissent être traitées de manière fiable.

Vérifier l'identité de manière adéquate avant l'exportation et la suppression

Rendre un historique accessible uniquement via un lien devinable ou un identifiant de session réutilisé expose à des fuites de données. Dans le même temps, la vérification d'identité ne doit pas exiger systématiquement plus de données à caractère personnel que nécessaire pour l'action demandée. Les lignes directrices définitives 01/2022 du EDPB sur le droit d'accès traitent notamment de l'identification, du périmètre et de la fourniture sécurisée de copies. L'article 12, paragraphe 6, du RGPD autorise la demande de informations complémentaires pour confirmer l'identité en cas de doutes raisonnables.

En pratique, une approche graduée basée sur le risque a fait ses preuves. L'affichage d'un court historique pseudonyme sur le même appareil peut reposer sur une session valide et de courte durée. Un export complet, une suppression irréversible ou la révocation de tous les appareils justifient davantage une réauthentification. La recommandation NIST sur la gestion des sessions décrit la réauthentification, les limites de temps et la terminaison de session comme des contrôles distincts. La rigueur appliquée doit correspondre au niveau de risque ; les exigences du NIST pour les agences fédérales américaines ne constituent pas une norme juridique automatique pour toutes les entreprises.

Pour les widgets publics et les espaces clients connectés, la frontière doit rester visible. Notre article sur l'identité et l'accès aux données dans le portail client explique pourquoi un chat public ne doit pas devenir discrètement un canal de données de compte.

Un export doit être compréhensible et pleinement explicable

Un bon export n'est pas une extraction brute de la base de données. Il commence par un récapitulatif : période de création, conversations incluses, pièces jointes, fuseau horaire utilisé et version du format. Viennent ensuite les contenus dans un ordre clair. Le format JSON peut être utile pour un traitement automatisé structuré ; l'HTML ou le PDF est souvent plus facile à lire pour les personnes. La nécessité légale d'un format portable et son périmètre doivent être évalués au cas par cas.

Si le système génère l'export de manière asynchrone, l'interface doit afficher un statut clair : « en cours de préparation », « disponible jusqu'au … », « expiré » ou « échec ». Le lien de téléchargement doit être temporaire, impossible à deviner et révocable après utilisation. Les éléments confidentiels tels que les prompts internes, les clés d'accès ou les données de tiers ne doivent pas figurer dans le fichier. Avant la mise à disposition, un filtre côté serveur doit vérifier si des liens avec des tickets de support, des conversations partagées ou des contenus tiers nécessitent un traitement particulier.

La suppression conçue comme une machine à états et non une promesse immédiate

Un bouton affichant « Tout est supprimé » pose problème si l'index de recherche, le stockage d'analyse, le système de support ou les sauvegardes contiennent encore des copies. Il est préférable d'utiliser une machine à états représentant le processus réel.

États de suppression pertinents

1. Demandé : L'identité et le périmètre souhaité sont confirmés.
2. Verrouillé : L'historique n'est plus accessible pour une utilisation normale ; les jetons de reprise et de partage sont invalidés.
3. En cours : Le stockage principal, l'index de recherche, le stockage de fichiers, ainsi que les destinations d'analyse et d'intégration sont traités.
4. Terminé : Les systèmes actifs prévus sont nettoyés ; les copies de sauvegarde restantes sont soumises à la rotation des sauvegardes documentée ou à une exception justifiée.
5. Partiellement bloqué : Un système n'a pas pu être nettoyé ou des données doivent être conservées provisoirement. La situation fait l'objet d'une escalade traçable.

Ne pas oublier les données dépendantes

Les messages peuvent renvoyer à des fichiers, des embeddings, des index de recherche, des évaluations de qualité, des enregistrements CRM ou des tickets de support. La demande de suppression requiert donc un identifiant de requête stable et des étapes de travail idempotentes : une nouvelle exécution ne doit pas créer de nouvelles copies ni annuler des étapes déjà effectuées. Pour les données de mesure, le choix de conserver ou non des indicateurs agrégés non attribuables doit être tranché dès la conception. En savoir plus dans l'article sur l'analytics de chatbot sobre en données.

La révocation protège particulièrement sur les appareils partagés

Dans les hôtels, les points de vente, les ateliers ou les foyers familiaux, les utilisateurs changent fréquemment sur un même appareil. C'est pourquoi « Révoquer l'accès » doit pouvoir faire plus que supprimer un cookie localement. Côté serveur, les jetons de session connus, les liens de partage et, le cas échéant, les liaisons d'appareils doivent devenir invalides. L'interface doit distinguer « cet appareil », « tous les appareils » et « tous les liens partagés ».

Après la révocation, le bouton Retour du navigateur ne doit pas afficher un historique sensible issu du cache. Les aperçus dans les notifications, la saisie automatique du navigateur et les données locales hors ligne doivent faire partie des vérifications. Dans le même temps, l'utilisateur doit recevoir une confirmation claire indiquant quels accès ont été fermés et si les données de conversation restent stockées. Ainsi, la révocation n'est pas confondue avec la suppression.

Concevoir une confirmation de suppression accessible et tolérante aux erreurs

Une action irréversible exige une confirmation sereine et compréhensible. La compréhension du critère de succès 3.3.4 des WCAG 2.2 s'applique expressément à la modification ou la suppression de données contrôlables par l'utilisateur. Au moins une possibilité d'annulation, de vérification ou de confirmation doit être prévue. La variante adaptée dépend du produit.

Les bons dialogues précisent concrètement « 3 conversations et 2 pièces jointes » plutôt qu'un terme générique comme « données ». L'action principale et l'action destructive sont visuellement distinctes, accessibles au clavier et ne reposent pas uniquement sur la couleur. Après l'envoi, une zone de statut accessible indique que la demande a été prise en compte. Une corbeille avec un délai de récupération limité peut corriger les erreurs de manipulation, mais ne doit pas contredire secrètement une promesse de suppression immédiate.

Transfert au support sans copie fantôme

Lorsqu'une conversation est transférée à des agents humains, un ticket de support distinct est souvent créé. Cet objet peut avoir une autre finalité, d'autres rôles d'accès et une autre règle de conservation. Le paramètre d'historique du chatbot ne doit ni supprimer ce ticket de manière invisible ni l'ignorer silencieusement. Avant le transfert, l'interface doit expliquer quels contenus seront transmis. Lors d'une demande ultérieure, le système doit retrouver la liaison et traiter le cas selon les règles applicables.

Si une suppression automatique échoue ou si l'identité et le périmètre ne sont pas clairs, le processus nécessite un canal humain sécurisé. L'article sur le Human Handoff dans le support web décrit les paquets de contexte et les règles d'escalade adaptés. Seul ce dont le collaborateur concerné a réellement besoin doit être transmis.

Check-list d'implémentation pour les équipes produit et support

1. Inventorier tous les objets de données et emplacements de stockage d'une conversation.
2. Modéliser la consultation, l'exportation, la suppression et la révocation comme des autorisations distinctes.
3. Exiger une réauthentification basée sur le risque pour les actions sensibles.
4. Structurer clairement les paquets d'exportation et définir des délais d'expiration sécurisés.
5. Rendre les étapes de suppression idempotentes et les suivre avec un identifiant de requête.
6. Inclure l'index de recherche, les fichiers, l'analytics, les intégrations, les caches et les tickets de support.
7. Tester les dialogues de confirmation et les messages de statut au clavier et avec un lecteur d'écran.
8. Simuler l'utilisation d'appareils partagés, les liens expirés et les appareils perdus.
9. Faire remonter visiblement les erreurs partielles sans copier de contenus sensibles dans les journaux.
10. Revoir régulièrement les règles de conservation et de suppression avec l'équipe donnée et les métiers.

Les tests essentiels avant le lancement

Les scénarios de test ne doivent pas couvrir uniquement le parcours idéal. Vérifiez les demandes de suppression simultanées, une session expirant pendant un export, des liens déjà révoqués, de nouveaux messages arrivant pendant une suppression en cours et la défaillance d'un système connecté. Contrôlez également si un export contient des messages tiers issus de comptes partagés et si un fichier supprimé reste accessible via une ancienne URL.

Chaque action doit avoir un résultat attendu dans l'interface, l'API et le stockage. Un bon test de recette ne s'arrête donc pas à un message de succès vert. Il vérifie ensuite les stockages de données concernés, les jetons et les URL publiques. Les journaux d'événements doivent prouver qu'une étape a été exécutée, sans enregistrer à nouveau le contenu de la conversation supprimée.

Conclusion : le contrôle utilisateur est une propriété de bout en bout

Un chatbot digne de confiance ne se contente pas de rendre l'historique accessible. Il sépare la consultation, l'exportation, la suppression et la révocation, vérifie correctement les actions sensibles et affiche l'état réel du traitement. L'élément déterminant est la combinaison d'une UX claire avec un modèle de données qui connaît l'ensemble des systèmes dépendants.

Intégrer rapidement ces fonctionnalités dans l'architecture, les processus de support et les tests permet de réduire les cas particuliers manuels et d'éviter les fausses promesses. Lors de la planification, vérifiez également quelles fonctionnalités ChatReact s'adaptent à votre site web et à votre processus de support. Commencez par un inventaire des données et un test unique de bout en bout : exporter l'historique, révoquer les accès, déclencher la suppression et vérifier le résultat dans tous les systèmes impliqués.

Sources et références complémentaires

• EUR-Lex : Règlement (UE) 2016/679, notamment les articles 5, 12, 15, 17 et 20.
• EDPB : Guidelines 01/2022 on data subject rights – Right of access, Version 2.1.
• NIST SP 800-63B : Session Management.
• W3C : Understanding WCAG 2.2 Success Criterion 3.3.4.