Concevoir des flux d'authentification sécurisés pour l'identité des appelants pour les agents vocaux

Voice agents are rapidly evolving from simple FAQ responders to action-taking systems that modify accounts, process transactions, and access sensitive customer data. This shift introduces a critical challenge: How do you verify caller identity in a conversational AI system where traditional visual authentication methods don't exist?

Quand un agent vocal peut mettre à jour des abonnements, consulter des soldes ou lancer des remboursements, il doit authentifier les appelants avec la même rigueur qu’un centre d’appels humain, mais uniquement via la voix. Contrairement aux agents humains qui suivent des procédures internes, les agents IA nécessitent une authentification déterministe, basée sur des outils, sans dépendre du jugement d’un LLM.

Cet article présente des méthodes d’authentification éprouvées issues de notre expérience en tant qu’ingénieurs déployés sur le terrain auprès de grandes entreprises. Nous allons détailler cinq approches principales, de l’authentification basée sur la session pour les widgets intégrés aux méthodes spécifiques à la téléphonie et à la vérification par OTP, et expliquer comment les mettre en place grâce au contrôle déterministe des workflows sur la plateforme ElevenLabs.

Surtout, nous allons montrer pourquoi l’authentification ne peut pas reposer sur l’inférence conversationnelle. Elle doit être conçue avec des sous-agents isolés, une vérification par outils et un routage conditionnel du workflow pour garantir que seuls les utilisateurs authentifiés accèdent aux opérations sensibles.

Les bases architecturales de l’authentification déterministe

Pour garantir que seuls les utilisateurs authentifiés accèdent aux informations liées à leur compte, nous recommandons une séparation stricte des environnements et des accès via les workflows ElevenLabs. L’authentification doit toujours passer par un appel d’outil avec un résultat booléen (succès ou échec), configuré comme outil de dispatch dans le workflow builder ElevenLabs.

En liant directement la condition de transfert au résultat de l’appel d’outil, le sous-agent ayant accès aux données du compte n’est accessible qu’après une authentification réussie et reste totalement isolé des utilisateurs non authentifiés. Cela garantit une authentification déterministe, sans décision laissée à un LLM, et empêche toute progression vers les étapes suivantes sans identité vérifiée.

En alternative, les expressions de transfert peuvent servir de méthode fiable : elles utilisent des variables dynamiques mises à jour par les résultats des appels d’outils.

Exemple de mise en œuvre

Vérifiez l’utilisateur dans Salesforce (appel d’outil). Si c’est réussi, récupérez les données de transaction client dans Salesforce (autre appel d’outil), puis transférez l’utilisateur vers un sous-agent chargé d’utiliser ces données pour communiquer avec le client et effectuer d’autres actions si besoin.

Méthodes d’authentification de l’identité utilisateur

Ces méthodes d’authentification ne sont pas prises en charge nativement sur la plateforme ElevenLabs. Elles peuvent être mises en place via des outils côté serveur intégrés à votre CRM ou backend/base de données, où sont stockées les données d’authentification.

Authentification par l’application hôte

Pour les agents vocaux intégrés à un site web, l’application hôte peut transmettre les données de session utilisateur (comme l’état de connexion, l’ID de compte ou les tokens de session) via des variables dynamiques lors de l’initialisation de l’agent/widget. Ces variables sont automatiquement injectées dans les appels d’outils, ce qui permet à l’agent de récupérer des données personnalisées sans authentification supplémentaire.

Cela permet un parcours de support fluide, car l’utilisateur a déjà été vérifié par l’application hôte. Vous pouvez configurer cela via une configuration personnalisée ou utiliser le widget ElevenLabs, en passant les variables au moment de l’exécution via la configuration du widget (ex. : <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Documentation on Dynamic Variables:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

Authentification basée sur la connaissance (KBA)

L’agent vocal demande à l’appelant de fournir des informations d’authentification comme le numéro de compte, le code postal, la date de naissance ou des réponses à des questions de sécurité. Un outil côté serveur (webhook ou côté client) vérifie ces valeurs dans votre base de données (CRM ou référentiel d’identité). L’outil retourne un résultat succès/échec avec un statut booléen (is_error) et un texte descriptif. Vous pouvez mettre cela en place via un contrôle déterministe du workflow : après avoir demandé les informations, configurez un dispatch d’outil et utilisez des transferts conditionnels dans le workflow selon le statut succès/échec, pour diriger les utilisateurs authentifiés vers des nœuds “privilégiés”.

Cette approche prend en charge les questions de sécurité statiques et la vérification dynamique de type "hors portefeuille", selon vos besoins en matière de risque de fraude.

Documentation sur les outils :

• https://www.11labs.ru/docs/agents-platform/customization/tools/server-tools 
• https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#dispatch-tool-node 

Variables dynamiques système (téléphonie uniquement)

Pour les conversations téléphoniques (via Twilio ou SIP trunk), votre agent a automatiquement accès à des variables système spécifiques à la téléphonie, comme system__caller_id (numéro de l’appelant). Cette variable se renseigne automatiquement au début de la conversation et peut être utilisée de deux façons : 1) Dans les messages/prompts : utilisez les doubles accolades, ex. {{system__caller_id}}, elles seront remplacées par la valeur réelle ; 2) Dans les paramètres d’outil : configurez les paramètres pour utiliser ces variables, ce qui permet une authentification silencieuse sans mention dans le prompt.

Par exemple, vous pouvez configurer un outil pour transmettre automatiquement le caller ID à votre endpoint CRM, permettant à l’agent de vérifier discrètement si le numéro entrant correspond à celui enregistré pour l’utilisateur. Au lieu d’un appel d’outil, l’authentification peut aussi être configurée comme un webhook d’initiation de conversation, exécuté avant le début de l’échange.

Note de sécurité : Comme les appelants peuvent utiliser un numéro différent ou que des numéros enregistrés peuvent être accessibles à des personnes non autorisées, l’authentification par caller ID doit être soumise à l’accord préalable du client ou combinée à d’autres méthodes (ex. : questions de sécurité).

Documentation sur les variables dynamiques système et le webhook d’initiation :

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://www.11labs.ru/docs/agents-platform/customization/personalization/twilio-personalization 

Authentification avancée par questions de sécurité

L’agent peut authentifier un utilisateur en posant une série de questions de sécurité et n’accorder l’accès que si l’appelant répond correctement à un nombre prédéfini. L’agent peut choisir des questions aléatoires dans une liste (ex. : date de naissance, code postal, nom de l’animal) et valider les réponses via un appel d’outil à votre base de données.

L’outil d’authentification retourne une réponse JSON incluant le nombre de succès actuel. Grâce aux affectations d’outil, ce nombre est automatiquement extrait et stocké/mis à jour dans une variable dynamique (ex. : auth_success_count). Après chaque vérification réussie, la variable s’incrémente.

Une fois le nombre requis de vérifications atteint (ex. : 3), une condition d’expression du workflow vérifie la valeur de la variable dynamique et passe à un sous-agent privilégié. L’expression utilise des opérateurs de comparaison (ex. : auth_success_count >= 3) pour contrôler l’accès de façon déterministe selon le statut d’authentification.

Documentation ici : https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#edges-and-flow-control 

Code à usage unique

C’est une méthode universelle où un code à usage unique est envoyé à l’appareil de l’utilisateur par SMS ou email. L’utilisateur doit ensuite communiquer ce code à l’agent pour être vérifié et accéder au service.

Déroulement de la mise en œuvre :

1. Génération du code : l’agent lance le processus via un appel d’outil serveur vers un endpoint dédié. Cela génère un code sécurisé à usage unique et l’envoie à l’utilisateur par le canal choisi (SMS ou email).
2. Demande à l’utilisateur : l’agent demande ensuite à l’utilisateur de fournir le code reçu. En mode vocal, l’utilisateur énonce le code à voix haute, qui est capté via la reconnaissance vocale.
3. Vérification du code : l’agent envoie le code fourni à un service de vérification backend via un second appel d’outil. Le backend vérifie que le code correspond, n’a pas expiré et n’a pas déjà été utilisé.
4. Routage du workflow : l’agent gère la suite selon la réponse de vérification : Succès : si le code est correct, l’utilisateur accède à la suite du workflow via une condition de succès. Échec : si le code est incorrect, l’agent peut demander à l’utilisateur de réessayer ou lancer une procédure de secours (ex. : renvoi d’un nouveau code).

Considérations de sécurité : il faut limiter le nombre de tentatives pour éviter les attaques par force brute, prévoir une expiration courte des codes (3-5 minutes) et suivre le nombre de tentatives. Pour les interactions vocales, prévoyez des confirmations pour garantir la fiabilité de la reconnaissance vocale lors de la saisie des codes.

Conclusion

Ces méthodes d’authentification sont des briques modulables, pas des solutions toutes faites. Votre choix doit refléter votre niveau de risque, vos obligations réglementaires et l’expérience utilisateur souhaitée. Un bot de service client n’a pas les mêmes besoins de sécurité qu’un assistant bancaire. La flexibilité de la plateforme vous permet de faire évoluer votre stratégie de sécurité selon les menaces et les besoins, en gardant toujours l’équilibre entre protection et expérience utilisateur.