Design conversationnel callbot : scripts et confirmations

Le design conversationnel, c’est de l’ops déguisée en conversation

Je vais être désagréable deux secondes : la “conversation naturelle” est une promesse marketing.

En production, le job d’un callbot n’est pas de faire oublier qu’il est une machine.

Le job, c’est :

• résoudre (ou escalader proprement),
• résoudre vite (AHT),
• résoudre du premier coup (FCR),
• et répéter ça… sur des milliers puis des millions d’appels.

Si ça vous rappelle un centre d’appels, c’est normal : un callbot est une brique de centre d’appels. Un agent logiciel avec des contraintes très humaines.

Le reste (la voix, la personnalité, les intonations), c’est du polish. Sympa, parfois important pour l’image, mais jamais prioritaire sur : compréhension, confirmation, sortie, transfert.

Pour cadrer l’échelle et les KPI, commencez par : Callbot en production.

La voix a des lois physiques (et votre script doit vivre avec)

Un bon script chat peut être mauvais en voix.

Pourquoi ? Parce qu’au téléphone :

• la mémoire est courte (on ne “relit” pas une phrase),
• les mains sont occupées (conduite, enfants, caisse du supermarché),
• l’attention est instable (interruptions),
• le canal est imparfait (8 kHz, bruit, écho),
• et la latence se ressent comme un malaise social.

Deux articles qui font gagner du temps :

• pour la latence, le tour de parole et le barge-in : Latence, barge-in, VAD
• pour le bruit, l’écho, les niveaux et la stack audio : Audio callbot : AEC, denoise, AGC

Et si vous voulez le panorama modèles 2026 (LLM/STT/TTS/S2S, open source vs cloud) : Stack callbot 2026.

Écrire pour l’oreille : “une idée par phrase”, sinon c’est trop tard

Le design conversationnel voice, c’est de la micro-ergonomie.

Une règle simple :

Si votre phrase a besoin d’une virgule, elle a probablement besoin d’être coupée.

Avant / après (exemple réaliste)

Trop long (la phrase “PowerPoint”)

“Très bien, afin de sécuriser votre demande et de vous orienter correctement, pouvez-vous me communiquer votre numéro de contrat, votre date de naissance et le code postal de votre adresse de résidence s’il vous plaît ?”

Plus robuste (la phrase “prod”)

“Ok. D’abord, votre numéro de contrat. Je vous écoute.”
“Merci. Maintenant, votre date de naissance.”
“Parfait. Et votre code postal ?”

Même objectif, mais :

• moins de charge cognitive,
• moins d’erreurs STT,
• plus facile à interrompre (barge-in),
• et plus facile à corriger.

Barge-in : écrivez comme si on allait vous couper (parce qu’on va)

Un callbot qui ne supporte pas l’interruption, c’est comme un répondeur qui ferait une conférence TED.

En réel, les gens coupent :

• pour corriger,
• pour répondre vite,
• parce qu’ils ont compris avant la fin,
• ou parce qu’ils sont pressés.

Le design conversationnel doit donc produire des phrases “interrompables” :

• courtes,
• modulaires,
• sans clause finale qui change le sens.

Le barge-in est autant une affaire de texte que de temps réel (VAD/endpointing, latence). Pour la partie “plomberie”, voir : Latence, barge-in, VAD.

Collecter des infos critiques : chiffres, dates, identifiants (la zone rouge)

Sur un callbot, il y a deux types d’informations :

1. celles qu’on peut reformuler sans risque (“vous voulez suivre votre colis”),
2. celles qu’on ne peut pas se permettre de rater (montants, dates, numéros, identités).

Pour le type 2, votre script doit être procédural.

Le pattern “capture → read-back → confirmation”

Ce pattern est vieux comme la téléphonie, et c’est très bien.

1. capture (“Quel est votre numéro de dossier ?”)
2. read-back (“J’ai noté : 4 8 1 2 7. C’est bien ça ?”)
3. confirmation (oui/non + correction)

Et si ça échoue :

• proposer DTMF,
• ou escalader.

SRGS : quand vous voulez réduire la variance

La spécification SRGS (Speech Recognition Grammar Specification) du W3C définit des grammaires de reconnaissance pour cadrer ce que vous attendez d’un utilisateur (par exemple : des chiffres, un code postal, des formats spécifiques).¹

Dans un callbot moderne “LLM + STT”, SRGS n’est pas toujours exposé tel quel… mais l’idée reste utile :

• sur les champs structurés, réduire l’espace des possibles,
• augmenter la robustesse (moins de “transcriptions poétiques”).

VoiceXML : le rappel que la voix est souvent un state machine

VoiceXML est une recommandation W3C historique qui formalise des applications vocales (prompts, champs, grammaires, événements). C’est une bonne piqûre de rappel : en voix, on gère des états, des erreurs et des transitions, pas des paragraphes.²

DTMF : quand le clavier sauve la conversation (et votre conformité)

DTMF n’est pas “vieux”. DTMF est fiable.

Quand vous collectez un identifiant critique (numéro de carte, code client, code postal, référence dossier), il y a un moment où la voix peut devenir le mauvais outil :

• environnement bruyant,
• accent + STT instable,
• ou champ trop sensible pour être répété à haute voix.

Dans ces cas, proposer un plan B (“Vous pouvez le taper au clavier si vous préférez”) n’est pas un retour en arrière : c’est une issue propre.

Techniquement, en VoIP, le transport des “telephone events” (DTMF et tonalités) est standardisé, notamment via un format de payload RTP décrit par l’IETF (RFC 4733).⁹

Traduction produit : ne sacrifiez pas la résolution sur l’autel du “tout vocal”.

Oui/Non au téléphone : “silence” est une troisième réponse

On croit que oui/non est simple.

En voice, oui/non se mélange avec :

• le bruit,
• la réflexion,
• l’hésitation,
• et le fameux “je vous entends pas… allo ?”.

Amazon Lex propose par exemple un type de slot “AMAZON.Confirmation” qui reconnaît des variantes (“Yes”, “No”, “Maybe”, “Don’t know”) et permet de construire des chemins de dialogue selon la valeur résolue.³

Traduction produit : même les plateformes ont appris que la réalité n’est pas binaire.

Le pattern robuste : “micro-résumé + choix”

Au lieu de :

“Vous confirmez ?”

Faites :

“Je récapitule : vous voulez déplacer votre rendez-vous de mardi 14h à jeudi 10h.
Dites ‘oui’ pour confirmer, ou ‘non’ pour changer.”

Vous :

• réduisez les erreurs,
• donnez un chemin de correction,
• et évitez le “oui… à quoi ?”.

No-input / no-match : l’art de ne pas punir l’utilisateur

Une conversation vocale comporte des “trous” :

• l’utilisateur ne répond pas (no-input),
• l’utilisateur répond, mais le système ne comprend pas (no-match),
• l’utilisateur répond à côté (hors-sujet).

Les bonnes pratiques des agents vocaux (par exemple dans Dialogflow CX) insistent sur le fait de concevoir des parcours voix qui anticipent ces cas, avec des reprompts utiles et des sorties de secours.⁴

Les 3 niveaux de reprompt

Niveau 1 (léger) :

“Je n’ai pas entendu. Vous pouvez répéter ?”

Niveau 2 (aide) :

“Vous pouvez me donner votre numéro de contrat, par exemple : ‘4 8 1 2 7’.”

Niveau 3 (sortie) :

“Je vous propose deux options : taper le numéro au clavier, ou parler à un conseiller.”

Prononciation et TTS : SSML, xml:lang, et les noms propres qui ruinent la confiance

La TTS n’est pas “juste une voix”.

C’est :

• la manière dont vous lisez les chiffres,
• les pauses,
• les unités,
• et la prononciation de noms propres (ou de “Rue du Général de Gaulle”, la vraie boss final).

SSML : le contrôle

SSML (W3C) est la spécification de markup pour piloter la synthèse (pauses, prosodie, prononciation, etc.). Elle prévoit notamment xml:lang pour indiquer la langue du contenu, et renvoie à BCP 47 pour l’usage des tags de langue.⁵⁶

En pratique, SSML est votre boîte à outils pour :

• faire respirer une phrase,
• épeler,
• lire un montant proprement,
• ou changer de langue ponctuellement.

PLS : quand vous avez vraiment des mots qui cassent tout

La Pronunciation Lexicon Specification (PLS) est une recommandation W3C qui définit un format de lexique de prononciation, utilisable pour améliorer la synthèse et/ou la reconnaissance sur des termes spécifiques (noms propres, acronymes, marques).⁷

Ce n’est pas toujours supporté par toutes les stacks modernes. Mais conceptuellement, ça vous donne une option : arrêter d’espérer que le modèle prononce “Schiltz” correctement et lui dire comment le prononcer.

Multilingue : le script n’est pas traduit, il est “reconçu”

Un piège classique :

“On va traduire le script en anglais et en espagnol.”

Non. Vous allez le reconstruire.

Parce que :

• les confirmations ne sont pas les mêmes,
• les noms d’unités changent,
• les adresses changent,
• le rythme change.

Et parce que vous devrez gérer :

• xml:lang,
• les tags de langue (BCP 47),
• et le routage.

Pour le détail (accents, code-switching, SSML), voir : Callbot multilingue.

“Ce n’est pas juste un prompt” : le callbot est un système d’états

Quand votre callbot fait des actions (CRM, paiement, planning), vous avez besoin de :

• validations,
• permissions,
• logs,
• et garde-fous.

Le modèle peut varier (open source, cloud, S2S). Le design conversationnel doit, lui, rester stable :

• quelles questions poser,
• dans quel ordre,
• comment confirmer,
• quand escalader.

Si vous avez besoin d’une vue globale des briques 2026 (LLM/STT/TTS/S2S, open source vs commercial), c’est ici : Stack callbot 2026.

Méthode “zéro à héros” : écrire un callbot voice en 7 étapes

1

Choisir une intention qui se mesure

Un seul parcours, mais mesurable : “suivi de dossier”, “prise de rendez-vous”, “changement d’adresse”. Si vous démarrez par “tout le service client”, vous démarrez par “rien”.

2

Cartographier les informations critiques

Listez les champs structurés (numéros, dates, montants) et appliquez le pattern capture → read-back → confirmation. Préparez le fallback DTMF.

3

Écrire des tours courts (et interrompables)

Une question à la fois. Une réponse à la fois. Le téléphone n’aime pas les paragraphes.

4

Prévoir no-input/no-match et une sortie

Trois niveaux de reprompt, puis une option : transfert, rappel, ou canal alternatif. Évitez les boucles.

5

Instrumenter (logs + raisons)

Loggez les événements utiles : “demande”, “champ collecté”, “confirmation”, “action”, “escalade”. Sans traces, vous ne saurez pas corriger le design.

6

Tester sur audio réel

8 kHz téléphonie, bruit, chevauchement, accents. Mesurez (AHT, FCR, transferts) et écoutez des échantillons. Pour la méthode d’évals : Benchmark callbot.

7

Itérer en prod (sans casser)

Faites des itérations petites et traçables (scripts, confirmations, reprompts). La prod aime les changements contrôlés, pas les réécritures.

Checklist “script callbot” (copiable/citable)

• Accueil : qui je suis + pourquoi j’appelle + option.
• Tours courts : une question, une réponse.
• Barge-in : phrases interrompables.
• Champs structurés : capture → read-back → confirmation.
• Oui/non : micro-résumé + choix de correction.
• No-input/no-match : 3 niveaux, puis sortie.
• Fallback : DTMF ou escalade sur champs critiques.
• TTS : pauses, chiffres, SSML sur cas sensibles.
• Multilingue : script reconçu, pas “traduit”.
• Escalade : transfert avec résumé et contexte.
• Mesures : AHT/FCR/transfer quality (pas “vibes”).
• Monitoring : boucles, répétitions, “pardon ?”.

FAQ

Questions frequentes

Je dois choisir un framework (Lex / Dialogflow / maison). Le design change ?+

Les patterns de design restent les mêmes (tours courts, confirmations, no-input/no-match, sorties). Les outils changent la manière d’implémenter (slots, pages, routes), pas la psychologie de la voix. Les guides voice de plateformes (par ex. Dialogflow CX) sont utiles pour cadrer les erreurs et reprompts.⁴

Faut-il une voix ultra réaliste ?+

Non. Une voix agréable aide, mais un callbot gagne surtout sur la structure : clarté, concision, confirmations, et escalade. La “meilleure voix” ne compense pas un callbot qui boucle ou qui rate un numéro.

SRGS/VoiceXML, c’est encore utile en 2026 ?+

Oui comme boîte à outils mentale : états, grammaires pour champs structurés, événements (no-input/no-match). Même si votre stack moderne ne s’appelle pas “VoiceXML”, vos problèmes, eux, n’ont pas changé.¹²

Quel est le meilleur 'hack' pour baisser l’AHT ?+

Réduire les répétitions. Chaque “pardon ?” ajoute des secondes, et à l’échelle, ça devient des heures (et des euros). Le duo gagnant : audio propre + confirmations intelligentes.

Sources et references

1. [1]W3C, “Speech Recognition Grammar Specification (SRGS) Version 1.0”.
2. [2]W3C, “Voice Extensible Markup Language (VoiceXML) 2.1”.
3. [3]AWS, “AMAZON.Confirmation (built-in slot type) — Amazon Lex”.
4. [4]Google Cloud, “Voice agent design best practices — Dialogflow CX”.
5. [5]W3C, “Speech Synthesis Markup Language (SSML) Version 1.1”.
6. [6]IETF, “BCP 47: Tags for Identifying Languages”.
7. [7]W3C, “Pronunciation Lexicon Specification (PLS) Version 1.0”.
8. [8]AWS, “Add an Amazon Lex bot to Amazon Connect” (langue du bot vs contact flow).
9. [9]IETF, “RFC 4733 — RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals”.