Reprendre une conversation chatbot : sessions, changement d'appareil et transfert sécurisé

Un visiteur pose trois questions dans le chatbot du site web, passe à la page produit et revient plus tard. Une cliente commence sur son smartphone et souhaite continuer sur son ordinateur portable. Enfin, un agent humain prend le relais au support. Dans ces trois cas, l'attente est la même : la conversation doit se poursuivre de manière fluide. D'un point de vue technique et organisationnel, il s'agit pourtant de trois tâches bien distinctes. Mélanger ces concepts expose à la perte de contexte, à la divulgation involontaire de données ou à une session qui reste active plus longtemps que nécessaire.

« Poursuivre » n'est pas équivalent à « reconnaître »

Pour la conception, il est utile de distinguer clairement trois niveaux de continuité :

1. Au cours d'une même visite : La conversation est conservée pendant que l'utilisateur navigue entre les pages ou lorsqu'il ferme et rouvre la fenêtre de chat.
2. Lors d'un retour ultérieur : Le même navigateur retrouve une conversation antérieure dans un délai limité.
3. D'un appareil à l'autre : Une personne poursuit la conversation sur un autre navigateur ou appareil. Cela nécessite généralement une association à un compte vérifié ou une procédure de transfert temporaire déclenchée intentionnellement.

L'existence d'un historique de conversation ne prouve pas l'identité de l'utilisateur. Posséder un identifiant de conversation ou un lien ne doit donc pas donner un accès automatique aux commandes, aux données contractuelles ou aux informations personnelles. C'est la même frontière fondamentale qui s'applique lors de la séparation entre chatbot public et portail client authentifié : le contexte apporte du confort, mais il ne remplace ni une connexion ni un contrôle des autorisations.

La base technique : référence dans le navigateur, état sur le serveur

Une architecture solide ne conserve dans le navigateur qu'une référence aléatoire et non explicite. L'état de conversation correspondant est stocké côté serveur et contrôlé à chaque requête (validité, environnement client, autorisations et date d'expiration). Les recommandations OWASP sur la gestion des sessions préconisent des identifiants de session neutres, difficiles à deviner, associés à des limites de temps contrôlées côté serveur. De plus, les identifiants de session ne doivent pas figurer dans les URL : ils pourraient être partagés via l'historique, les journaux, les en-têtes Referrer ou des liens transmis.

Les technologies de stockage des navigateurs ont des portées différentes. Selon la documentation MDN sur l'API Web Storage, sessionStorage est lié à un onglet et à son origine, et prend fin à la fermeture de l'onglet. localStorage persiste quant à lui d'une session de navigation à l'autre, mais reste strictement limité à un profil de navigateur unique. Aucun des deux ne permet d'établir une identité multi-appareils. Y stocker directement des transcriptions sensibles ou des jetons d'accès permanents augmente considérablement l'impact en cas d'accès non autorisé au script ou à l'appareil.

Quelles données l'état doit-il contenir ?

Pour reprendre utilement un échange, le système a souvent besoin de bien moins de données qu'une transcription complète. Un jeu de données d'état compact et versionné peut suffire :

• la demande actuelle et l'objectif confirmé,
• les faits non sensibles déjà clarifiés,
• les questions en attente et la prochaine étape logique,
• les sources de connaissances utilisées ou leurs versions,
• le statut des consentements, de l'authentification et du transfert (handoff),
• l'horodatage de la dernière activité ainsi que la date d'expiration fixée.

Cela permet de poursuivre l'échange de manière cohérente sans copier indéfiniment chaque ancien message dans le prompt actif. L'historique complet peut être stocké séparément, sous forme résumée ou pas du tout – selon la finalité, l'attente des utilisateurs et les règles établies. Pour les données à caractère personnel, la limitation des finalités, la minimisation des données et la limitation de la conservation énoncées à l'article 5 du RGPD constituent des principes de conception essentiels. Sans remplacer un conseil juridique individuel, cela fixe une exigence produit claire : ne stocker que ce qui est réellement nécessaire pour un objectif défini.

Traiter différemment les conversations anonymes et authentifiées

Retour anonyme sur le même navigateur

Pour les visiteurs anonymes, la fonction « reprendre la conversation » doit rester une simple commodité limitée dans le temps. Il convient de prévoir une durée de conservation courte, une commande de suppression bien visible et une explication précisant que l'historique ne pourra être retrouvé que sur ce navigateur. Le chatbot ne doit pas déduire du retour du navigateur qu'il s'agit de la même personne physique. Après expiration ou perte de la référence locale, une nouvelle session commence.

En pratique, lors d'un retour, le chatbot peut demander : « Souhaitez-vous poursuivre votre échange sur la sélection de produits ou recommencer à zéro ? » Cette approche est préférable au réengagement silencieux de l'ancien contexte. Sur les appareils partagés, cette confirmation évite que la personne suivante ne voie immédiatement des informations qui ne la concernent pas.

Changement d'appareil avec connexion

La continuité entre plusieurs appareils doit être liée à un compte vérifié et à ses autorisations actuelles. Une fois l'utilisateur connecté, le serveur ne charge que les conversations associées à ce compte et au bon environnement. Pour les actions sensibles – telles qu'un changement d'adresse, une demande d'information contractuelle ou une commande –, une ré-authentification est recommandée, même si la discussion générale est toujours active.

Les recommandations NIST SP 800-63B sur la gestion des sessions décrivent une session comme une liaison entre une personne authentifiée et un service via un secret de session. Elles exigent des limites de temps basées sur l'inactivité ainsi qu'une limite absolue, accompagnées d'une fermeture côté serveur. Pour les équipes produit, cela implique qu'un état « connecté » ne doit pas être illimité, et qu'un jeton de session ou de compte expiré ne doit pas être réactivé par un simple historique de chat résiduel.

Un code de transfert comme passerelle strictement délimitée

Certains services souhaitent permettre un passage anonyme d'un appareil à l'autre via un code à usage unique ou un QR code. Dans ce cas, le code doit être éphémère, à usage unique et révocable. Il ne doit contenir ni transcription ni données client, mais seulement une référence aléatoire vers un état de conversation minimal et validé. Une fois le transfert effectué, l'ancienne référence devient invalide. Ce code sert de passerelle pour le contexte, et non de preuve d'identité ni d'autorisation d'accès aux données sensibles du compte.

Les règles d'expiration doivent être claires dans l'interface

Les limites de temps techniques ne résolvent qu'une partie du problème. Les utilisateurs doivent savoir si et combien de temps leur conversation sera conservée. Les recommandations NIST sur l'expérience client soulignent l'importance de fournir des informations claires sur la fin de session afin d'éviter la perte de travail et d'empêcher les utilisateurs de recourir à des contournements risqués.

Un bon concept d'expiration répond donc directement dans le chat aux questions suivantes :

• La conversation est-elle conservée après la fermeture de la fenêtre ?
• Cela s'applique-t-il uniquement à ce navigateur ou également sur d'autres appareils après connexion ?
• Quand la session prend-elle fin pour cause d'inactivité, et quand l'historique enregistré est-il supprimé ?
• Quelles parties l'utilisateur peut-il supprimer lui-même ou exporter ?
• Que devient une demande de support en cours après l'expiration de la session ?

Avant la fin prévue d'une session, un message discret peut proposer d'enregistrer les informations ou de les transmettre au support. Après l'expiration, l'interface doit distinguer clairement « Session terminée » et « Historique supprimé ». L'un concerne l'accès, l'autre la conservation.

Human Handoff : transmettre le contexte, rendre les responsabilités visibles

Lors du passage à un conseiller humain, un résumé court et structuré apporte souvent plus de valeur qu'un long historique brut. Il indique la demande, les éléments confirmés, les étapes déjà suggérées, les questions en suspens et les sources utilisées. Les contenus sensibles ne sont transmis que s'ils sont nécessaires au dossier de support et dûment autorisés.

L'utilisateur doit voir clairement qu'un conseiller humain prend le relais, comprendre quelles informations sont transmises et savoir si un temps d'attente est à prévoir. En parallèle, l'IA doit savoir, après le transfert, si elle doit se taire, fournir un simple soutien organisationnel ou reprendre la main ultérieurement. Pour découvrir les déclencheurs et règles d'escalade précis, consultez notre article sur le Human Handoff dans le chatbot de site web.

Mise en œuvre en six étapes

1. Identifier les cas d'usage : Spécifier séparément la navigation sur le site, le retour ultérieur, le changement d'appareil et le transfert à un conseiller humain.
2. Définir les niveaux de confiance : Déterminer quel contenu est accessible de manière anonyme, après association au compte ou uniquement après ré-authentification.
3. Minimiser l'état : Concevoir un état de reprise structuré incluant l'objectif, les faits confirmés, les points ouverts et l'échéance.
4. Appliquer le cycle de vie : Tester côté serveur la limite d'inactivité, la limite absolue, la suppression, la révocation et la déconnexion.
5. Concevoir les transferts : Rendre visibles la confirmation utilisateur, le résumé pour le support, le statut d'attente et l'attribution de la responsabilité.
6. Mesurer le succès sans texte intégral : Suivre des événements tels que « reprise proposée », « acceptée », « expirée », « changement d'appareil réussi » et « transfert à un humain réussi ». Pour savoir comment y parvenir dans le respect de la sobriété des données, consultez notre guide sur l'analyse des chatbots IA.

Matrice de test pour ordinateur, mobile et cas limites réels

Avant le déploiement, il ne suffit pas de vérifier que le parcours nominal fonctionne. Une matrice de test ciblée permet de couvrir les erreurs classiques :

• Navigation sur un même site web avec la fenêtre de chat ouverte puis fermée,
• Retour sur le même navigateur avant et après la limite d'inactivité,
• Retour en navigation privée ou après suppression des données locales du navigateur,
• Changement d'appareil avant et après connexion, ainsi qu'après une déconnexion,
• Changement de compte sur un appareil partagé,
• Code de transfert expiré, déjà utilisé ou révoqué,
• Conversation supprimée, compte bloqué et modification des autorisations de l'environnement client,
• Reprise d'une conversation après une mise à jour de la base de connaissances,
• Transfert au support avec ou sans résumé expressément validé,
• Titres longs, langues avec des longueurs de texte différentes et affichage mobile sans débordement horizontal.

Pour chaque cas, la vérification doit porter non seulement sur la réponse visible, mais aussi sur les appels réseau, l'invalidation de la session, les journaux d'erreurs et les événements d'analyse. Un chatbot peut expliquer poliment qu'un contexte n'est plus disponible. Il ne doit en aucun cas tenter de le reconstruire à partir de données similaires d'autres utilisateurs ni l'attribuer à une nouvelle personne.

Conclusion : la continuité est un transfert contrôlé

Offrir une bonne expérience de reprise ne consiste pas à tout stocker indéfiniment. Cela consiste à transmettre le juste contexte minimal sur un parcours clairement délimité. Un même navigateur, un second appareil connecté ou un canal de support humain nécessitent des règles de confiance et d'expiration adaptées à chaque situation. En maintenant séparés l'état de la conversation, l'identité et les autorisations, on offre de la fluidité sans compromettre la confidentialité des données.

Intégrer ces règles dès le départ dans l'expérience conversationnelle (UX) permet de réduire les interruptions de session et de rendre les transferts vers le support plus transparents. Les fonctionnalités ChatReact offrent un aperçu des composants disponibles pour les chatbots de site web ; la configuration précise des sessions et de la protection des données doit ensuite être planifiée et testée en fonction de votre cas d'usage spécifique.

Sources

• NIST SP 800-63B : Session Management
• NIST SP 800-63C : Customer Experience
• OWASP Session Management Cheat Sheet
• MDN : Web Storage API
• EUR-Lex : Règlement général sur la protection des données, article 5