Authentification callbot : KBA, OTP et biométrie vocale

L’auth en callbot : vous n’êtes pas en train de sécuriser “une voix”, vous sécurisez une action

Le piège numéro 1, c’est de concevoir “une authentification callbot”.

Vous n’avez pas une auth.

Vous avez des actions, avec des risques différents :

• donner des horaires → faible risque,
• déplacer un rendez-vous → risque moyen,
• changer une adresse postale → risque moyen/élevé,
• faire une opposition carte → critique,
• déclencher un virement → ultra critique.

Donc l’auth doit être contextuelle.

Et surtout, le succès d’un callbot n’est pas “j’ai une auth très solide”. C’est :

• “je résous vite”,
• “je sécurise quand il faut”,
• “j’escalade quand je doute”.

Cadre de référence : NIST AAL (Digital Identity Guidelines)

Pour parler sérieusement d’auth, il faut un cadre.

NIST SP 800‑63B (Digital Identity Guidelines — Authentication and Lifecycle Management) définit des niveaux d’assurance d’authentification (AAL) et des exigences associées (facteurs, résistances, etc.).¹

Traduction callbot :

• ce n’est pas “OTP ou pas OTP”,
• c’est “quel niveau d’assurance est nécessaire pour cette action”.

Et si votre callbot sert plusieurs produits (banque + assurance + support), cette grille vous évite de faire des règles au feeling.

SCA (PSD2) : l’idée clé (deux facteurs, pas deux souffrances)

Si vous êtes dans un contexte paiement/banque en Europe, vous allez entendre “SCA”.

L’Autorité bancaire européenne (EBA) a publié des clarifications sur les éléments d’authentification forte (SCA), autour des catégories “connaissance / possession / inhérence”.²

On peut retenir une idée simple :

• connaissance : quelque chose que l’utilisateur sait,
• possession : quelque chose qu’il a,
• inhérence : quelque chose qu’il est.

Et un point très callbot :

vous devez pouvoir expliquer à un humain (audit, conformité) pourquoi vous avez appliqué telle étape.

Les méthodes d’auth les plus courantes en callbot (et leurs pièges)

1) Caller ID / ANI : un signal, pas une identité

Oui, vous pouvez voir un numéro appelant.

Non, ce n’est pas une authentification.

Le numéro est un signal utile (routing, pré‑identification, détection de fraude), mais il ne doit pas suffire pour une action sensible.

Conseil : traitez-le comme un “indice”, jamais comme une preuve.

2) KBA (Knowledge-Based Authentication) : le classique qui fatigue

KBA = questions dont la réponse est censée être connue du client :

• date de naissance,
• dernier montant,
• code postal,
• etc.

Avantages :

• facile à implémenter,
• ne dépend pas d’un device.

Inconvénients :

• ça rallonge l’appel,
• ça se trompe (STT, confusion, bruit),
• et ça ne résiste pas toujours aux attaques de type social engineering.

Le pattern le plus sain : KBA comme step‑up occasionnel, pas comme rituel systématique.

Et côté UX : confirmations obligatoires sur chiffres/dates. Voir : Design conversationnel callbot.

3) OTP (SMS / email) : la possession qui marche (souvent) en prod

L’OTP a un avantage : il sort la preuve de l’audio.

Le callbot peut dire :

“Je vous envoie un code par SMS. Dites-moi les 6 chiffres.”

Puis :

• capture (chiffres),
• read-back,
• confirmation.

Et si l’audio est mauvais : DTMF.

Important : l’OTP n’est pas “gratuit” :

• il a une latence (réception),
• il peut échouer (pas de réseau),
• et il peut créer de l’abandon si vous le demandez trop tôt.

Donc le bon pattern est souvent :

• faire 80% du parcours,
• puis OTP juste avant l’action sensible.

4) App push (possession “forte”) : efficace, mais dépendant

Quand vous avez une application mobile, le push (approbation dans l’app) est souvent une excellente UX :

• rapide,
• clair,
• et moins sujet aux erreurs STT.

Mais il dépend de :

• l’adoption de l’app,
• la connectivité,
• et l’intégration.

Donc c’est une arme utile… mais pas universelle.

5) Biométrie vocale : puissant, mais juridiquement lourd

La biométrie vocale (voiceprint) promet une authentification basée sur “quelque chose que vous êtes”.

En pratique, il y a deux réalités :

1. technique (performance, spoofing, liveness),
2. juridique (RGPD, biométrie).

La CNIL rappelle des principes sur la biométrie (finalité, proportionnalité, sécurité, encadrement).³

Et elle mentionne le sujet de la reconnaissance vocale (voice recognition) dans ses contenus grand public (par ex. sur la biométrie des smartphones), ce qui aide à cadrer le fait que la voix peut être utilisée comme donnée biométrique selon le contexte.⁴

Si votre callbot touche à la biométrie, lisez aussi : RGPD & callbots.

Matrice action → niveau d’auth : la table qui calme les débats

Une équipe sans matrice finit par discuter d’auth au cas par cas… et à changer d’avis tous les vendredis.

Voici une matrice simple (à adapter à vos contraintes) :

Le point n’est pas “c’est la vérité”.

Le point est : vous avez une base cohérente, versionnée, discutable.

Et vous pourrez expliquer pourquoi vous avez demandé un OTP à cet instant.

Biométrie vocale : le cycle de vie est plus important que la démo

La biométrie vocale se décompose en réalité en plusieurs moments :

1. enrollment (création du gabarit / voiceprint),
2. vérification (comparaison),
3. gestion des erreurs (faux rejets / faux acceptés),
4. révocation / ré-enrollment (quand la voix change, quand on suspecte un compromis).

La démo se concentre sur “regardez, il reconnaît”.

La prod se concentre sur :

• “que fait-on quand il se trompe ?”
• “comment on prouve que c’est proportionné ?”
• “qui a accès au gabarit, et combien de temps ?”

Et surtout : quelle est la sortie ?

Parce qu’une biométrie sans sortie (OTP/humain) n’est pas “plus sécurisée”. Elle est juste plus fragile.

La CNIL rappelle des principes d’encadrement de la biométrie (proportionnalité, finalité, sécurité).³

Step-up auth : la stratégie qui marche quand on veut à la fois la sécurité et la vitesse

La stratégie “step-up” est simple :

1. on démarre avec une friction minimale,
2. on ajoute de la preuve seulement si l’action l’exige,
3. et on escalade si on doute.

Exemple (fictif, mais réaliste)

• Client : “Je veux changer mon adresse.”
• Callbot : “Ok. Je peux vous aider. Pour sécuriser, je vous envoie un code par SMS. Vous préférez SMS ou email ?”

Et si l’OTP échoue :

• “Je vous passe un conseiller.”

Ce pattern est boring. Et c’est exactement ce que vous voulez en prod.

Lien direct avec la conversation : l’auth est un scénario, pas une question

Au téléphone, on ne peut pas “afficher un écran d’auth”.

Donc l’auth est un micro-scénario :

• annonce (“pour sécuriser…”),
• choix (“SMS ou email”),
• collecte,
• confirmation,
• et issue de secours.

Et ce scénario doit être écrit pour l’oreille (phrases courtes, interrompables). Voir : Design conversationnel callbot.

UX : demander un code sans transformer l’appel en dictée punitive

Le problème n’est pas l’OTP. Le problème, c’est la collecte en voix.

Quelques patterns qui marchent :

• annoncer la forme : “6 chiffres” avant de demander,
• collecter par paquets : “dites-les par deux” (selon vos tests STT),
• read-back : répéter, puis confirmer,
• DTMF en option : “vous pouvez aussi le taper”.

Et surtout : ne faites pas “dites le code” sans contexte.

Dites :

“Pour sécuriser l’opération, je vous envoie un code par SMS. Dites-moi les 6 chiffres, ou tapez-les au clavier.”

La différence est énorme en compréhension et en acceptation.

Sécurité : spoofing, replay, et pourquoi vous devez prévoir l’escalade

En callbot, l’auth est aussi un problème “adversarial” :

• attaques par ingénierie sociale,
• tentatives de contournement,
• et, de plus en plus, audio synthétique.

La conséquence produit est simple :

si vous doutez, vous escaladez.

Ça ne veut pas dire “le bot est nul”.

Ça veut dire : le bot sait rester dans sa zone de confiance.

Pour les menaces et garde-fous (prompt injection, spoofing, etc.), voir : Sécurité callbot.

Auth et handoff : l’agent doit savoir ce qui a été tenté (sinon il recommence)

Quand une authentification échoue, vous avez deux options :

1. vous faites boucler l’utilisateur (“répétez le code”),
2. vous escaladez.

L’escalade est souvent la meilleure option… à condition que l’agent reçoive le contexte.

Sinon vous fabriquez une scène très classique :

• le bot a essayé un OTP,
• l’utilisateur n’a pas reçu le SMS,
• l’appel est transféré,
• et l’agent… redemande le SMS.

Résultat : frustration + minutes perdues.

Un bon handoff d’auth doit donc passer :

• méthode tentée (OTP/KBA),
• raison d’échec (non reçu, délai, erreurs chiffres),
• nombre de tentatives,
• et niveau de risque de l’action demandée.

L’objectif n’est pas de “décrire l’attaque”.

L’objectif est d’éviter la répétition, et d’aider l’agent à choisir la bonne suite :

• autre canal (email),
• autre facteur (push),
• ou traitement manuel.

Pour la méthode complète de transfert + agent assist : Handoff & agent assist.

Open source vs commercial : l’auth n’est pas qu’une brique IA

Beaucoup d’équipes abordent l’auth comme “un modèle”.

En réalité, l’auth est un système :

• intégration SMS/email,
• règles d’expiration,
• logs,
• et parfois un composant biométrique.

Le choix open source vs vendor se fait surtout sur :

• conformité,
• audit,
• et capacité d’exploitation.

Et, bien sûr, sur votre stack callbot (STT/TTS/LLM). Pour le panorama modèles 2026 : Stack callbot 2026.

Checklist “auth callbot” (copiable/citable)

• Action classée par risque (faible → critique).
• Politique step‑up écrite (qui/quoi/quand).
• Script voix court : annonce + collecte + confirmation.
• Chiffres : read-back + option DTMF.
• Tentatives limitées + expiration.
• Monitoring : échecs OTP/KBA, abandons, temps ajouté.
• Handoff : méthode tentée + raison d’échec + tentatives.
• RGPD : logs minimisés + rétention définie.
• Escalade : prévue et testée (pas “si ça arrive”).
• Versionning : toute modification doit être traçable.

Et souvenez-vous : à l’échelle, une authentification qui ajoute 20 secondes “en moyenne” finit par ajouter des heures de temps de conversation par jour. La sécurité compte, mais la sécurité opérable compte encore plus.

C’est exactement là qu’un bon callbot bat une belle démo.

Implémenter une auth callbot sans se tirer une balle : méthode en 8 étapes

1

Lister les actions et leur risque

Classez : faible / moyen / élevé / critique. Sans ça, vous allez sur-authentifier.

2

Définir votre politique (step-up)

À quel moment OTP/KBA ? Quand escalader ? Quelles preuves minimales ?

3

Écrire les scripts (voix)

Annonce, collecte, confirmation, fallback DTMF. Court. Clair. Humain.

4

Instrumenter les échecs

Combien d’OTP non reçus ? Combien d’échecs STT sur chiffres ? Où l’utilisateur abandonne ?

5

Prévoir la sortie (humain)

Escalade = feature. Préparez le transfert et le contexte.

6

Tester sur audio réel

8 kHz, bruit, accents. L’auth “marche” en studio, puis casse dans la vraie vie.

7

Cadrer RGPD et rétention

Logs, transcriptions, stockage. Pas de biométrie “par accident”.

8

Itérer en prod (et versionner)

L’auth est un parcours sensible. Changez petit, mesurez, documentez.

FAQ

Questions frequentes

Puis-je faire de l’auth uniquement avec le numéro appelant ?+

Pour des actions à faible risque, c’est un signal utile. Pour des actions sensibles, non : le numéro n’est pas une preuve d’identité. Utilisez du step-up (OTP/KBA) ou escalade.

OTP vocal (dicté) : ça marche ?+

Oui si vous écrivez le scénario correctement : chiffres par chiffres, confirmation, et DTMF en fallback. Le problème n’est pas l’OTP : c’est la collecte en audio.

Biométrie vocale : recommandée ?+

Parfois, mais ce n’est pas une décision “tech”. C’est une décision produit + juridique + sécurité. La CNIL rappelle l’encadrement de la biométrie, et la mise en place doit être proportionnée et sécurisée.³

Comment réduire la friction sans baisser la sécurité ?+

Par le step-up : friction faible tant que l’action est faible risque, puis preuve plus forte juste avant l’action sensible. Et escalade quand vous doutez.

Sources et references

1. [1]NIST, “SP 800‑63B — Digital Identity Guidelines: Authentication and Lifecycle Management”.
2. [2]EBA, “Opinion on the elements of strong customer authentication under PSD2” (SCA).
3. [3]CNIL, “Biométrie : les principes”.
4. [4]CNIL, “Biométrie : les principes (smartphone et reconnaissance vocale)”.