Canaux

Web et application : clients connectés

Comment l’agent IA reconnaît, sans questions d’identité, un client déjà connecté à votre site web ou à votre application, comment l’identité de ce client est transmise de manière sécurisée, et ce que l’agent peut alors voir et faire.

Sur cette page

Ce qui change lorsqu’un client est connecté
Comment l’identité du client parvient à l’agent
Détails techniques
Ce que l’agent peut voir et faire
La session connectée, l’une de vos vérifications d’identité
En pratique
Ce que votre équipe contrôle
Voir aussi

Un client qui s’est connecté à votre application a déjà prouvé son identité. Lui demander une référence de réservation et une date de naissance avant de répondre revient à lui imposer une contrainte inutile. Lorsqu’un client connecté ouvre une conversation, vos systèmes transmettent son identité à l’agent IA : la conversation commence donc avec le compte du client, c’est-à-dire sa réservation, son logement ou son contrat. Les sessions authentifiées sont configurées lors de la mise en œuvre pour les parcours sur le site web et dans l’application que vous choisissez.

Ce qui change lorsqu’un client est connecté

	Non connecté	Connecté
Ce que l’agent sait de son interlocuteur	Un contact non confirmé, jusqu’à ce qu’une vérification d’identité soit réussie	Le client que vos systèmes ont identifié
Première question	« Pourriez-vous confirmer votre référence de réservation et votre date de naissance ? »	« Bon retour parmi nous, Leila. Est-ce au sujet de votre sinistre automobile du 3 octobre ? »
Informations du compte	Communiquées uniquement après une vérification d’identité	Disponibles dès le début, dans le respect de vos règles
Actions	Disponibles une fois l’identité confirmée	Disponibles dès le début, dans le respect de vos règles et du rôle du client

Comment l’identité du client parvient à l’agent

Votre site web ou votre application sait déjà qui est le client, car celui-ci s’est connecté au moyen de votre propre processus de connexion. Lorsqu’il ouvre une conversation, vos systèmes créent un jeton signé : une courte déclaration numérique qui indique qui est le client, que seuls vos systèmes peuvent émettre et que personne ne peut modifier sans que la modification soit détectée. Le jeton accompagne la conversation, et votre déploiement Telonic le vérifie avant que l’agent ne considère le client comme identifié.

Le mot de passe du client ne quitte jamais vos systèmes, et l’agent ne le demande jamais.

Détails techniques

Élément	Fonctionnement
Jeton	Un jeton signé émis par votre back end (la partie serveur de votre site web ou de votre application), par exemple un JSON Web Token (un format standard très répandu pour un ensemble signé de déclarations concernant un utilisateur)
Contenu	L’identifiant que vous attribuez au client, une heure d’expiration, le déploiement auquel le jeton est destiné et, éventuellement, le rôle du client
Signature	Avec une clé que détiennent vos systèmes. Votre déploiement vérifie la signature avec la clé de vérification correspondante, convenue lors de la mise en œuvre
Vérifications	La signature, l’heure d’expiration et le déploiement destinataire. Un jeton qui échoue à l’une de ces vérifications est refusé, et le client est traité comme non connecté
Durée de validité	Courte, de sorte qu’un jeton copié n’a guère d’utilité. Un nouveau jeton est émis à mesure que le client continue d’utiliser votre site ou votre application
En transit	Chaque connexion utilise TLS (Transport Layer Security), version 1.2 ou supérieure
Ce qui n’est pas partagé	Les mots de passe, ainsi que tout secret de connexion qu’utilisent vos systèmes

Ce que l’agent peut voir et faire

Une fois le client identifié, l’agent consulte dans vos systèmes les fiches de ce client, et uniquement les siennes. Un assuré connecté à l’application d’un assureur peut poser des questions sur ses propres contrats et sinistres. Il ne peut pas en poser sur ceux d’une autre personne, car les consultations de l’agent sont effectuées pour le client identifié.

Ce que l’agent peut faire est également limité par le rôle du client, lorsque vos systèmes gèrent des rôles. Vous décidez de ce que chaque rôle autorise :

Secteur	Rôle	Ce que l’agent peut faire pour ce client
Immobilier	Propriétaire d’un logement	Échéancier de paiement, rendez-vous de livraison, réserves concernant ses logements
Immobilier	Locataire	Demandes de maintenance pour le logement qu’il loue. Aucune information sur le plan de paiement
Voyage et hôtellerie	Membre du programme de fidélité	Ses réservations, son solde de points et ses utilisations de points
Assurance	Assuré	Ses propres contrats et sinistres
Assurance	Courtier	État d’avancement et documents des clients pour lesquels le courtier est habilité

Ces limites s’ajoutent aux autorisations dont dispose déjà chaque connexion à vos systèmes, définies avec votre équipe informatique. Voir Autorisations.

La session connectée, l’une de vos vérifications d’identité

Une session connectée est l’une des vérifications d’identité que vous pouvez définir pour votre déploiement, aux côtés des vérifications par informations connues, comme une référence de réservation associée à une date de naissance, et d’un code à usage unique envoyé par SMS ou sur WhatsApp. Vous décidez pour quelles demandes une session connectée suffit.

Pour la plupart des demandes, elle suffit à elle seule. Pour les demandes que vous jugez plus risquées, comme la modification du numéro de téléphone ou de l’adresse e-mail d’un compte, vous pouvez exiger une vérification supplémentaire, comme un code à usage unique envoyé au numéro déjà enregistré. Voir SMS et Rattachement des contacts aux clients.

Important

L’agent ne voit ni ne traite jamais de données de carte, que le client soit connecté ou non. Les paiements s’effectuent via un lien de paiement de votre prestataire de paiement, de sorte que les données de carte restent chez ce prestataire.

En pratique

Wadi Assurance, assureur automobile basé à Dubaï, ajoute l’agent IA à son application destinée aux assurés.

Leila est connectée à l’application. Elle ouvre la conversation, et le back end de l’application émet un jeton signé contenant son identifiant client et le rôle « Policyholder ».
Le déploiement vérifie le jeton. L’agent accueille Leila par son nom et lui demande si elle prend contact au sujet de son sinistre en cours.
Elle demande ce qui manque encore. L’agent consulte son sinistre et répond que la facture du garage n’a pas encore été fournie. Elle l’envoie dans la conversation, et la facture est rattachée au sinistre.
Elle demande à modifier le numéro de mobile associé à son contrat. L’assureur exige un code à usage unique pour les modifications de coordonnées : l’agent envoie donc un code au numéro enregistré, puis effectue la modification une fois que Leila l’a saisi.
La conversation, le document et la modification sont enregistrés dans le dossier client de Leila, avec les vérifications d’identité réussies.

Ce que votre équipe contrôle

Les parcours sur le site web et dans l’application où les clients connectés sont reconnus.
Les demandes pour lesquelles une session connectée suffit, et celles qui nécessitent une vérification supplémentaire.
Les rôles que l’agent reconnaît, et ce que chaque rôle autorise.
La clé utilisée pour signer les jetons, conservée dans vos propres systèmes.

Les noms et logos de produits sont des marques de leurs propriétaires respectifs. Leur mention indique les systèmes auxquels Telonic se connecte et n’implique ni partenariat ni approbation.