« Mon nom est Tschanz. »
« Merci, Monsieur Schanz. »
« Non, Tschanz, avec un T. »
« Très bien, Monsieur Schanz. »
À la troisième tentative, l’assistant n’a pas besoin d’être plus patient. Il doit comprendre que sa méthode de réparation ne marche pas.
Les nouveaux modèles vocaux peuvent fluidifier la conversation. OpenAI décrit GPT-Live comme une architecture full-duplex et publie des évaluations qui examinent notamment le turn-taking, les interruptions et le flow. La production conserve cependant ses difficultés : dialectes, bruit, Bluetooth, noms propres, plaques, chiffres et changements de langue.
La bonne question n’est donc pas « l’IA se trompe-t-elle parfois ? ». C’est : que fait-elle juste après l’erreur ?
Un repair loop Voice AI a besoin d’états
Le bot faible possède une phrase de secours : « Je n’ai pas compris, pouvez-vous répéter ? » Trois répétitions identiques ne créent aucune information nouvelle.
La réparation doit évoluer.
Première incertitude : proposer une confirmation, « Est-ce Tschanz ? ». Deuxième : réduire l’ambiguïté, « Pouvez-vous l’épeler ? ». Si le champ critique reste instable, transfert ou rappel.
Recommandation : après deux échecs sur la même donnée critique, changez de stratégie ou passez à un humain. C’est un seuil opérationnel de départ, pas une loi scientifique universelle.
Fait confirmé : le comportement conversationnel — timing, interruptions, turn-taking — est une dimension de la qualité Voice ; de meilleurs modèles ne suppriment pas toutes les limites audio et linguistiques.
Toutes les erreurs n’ont pas le même coût
Confondre un mot de politesse n’a presque aucune conséquence. Confondre mercredi et jeudi pour une intervention en a beaucoup.
Définissez les entités critiques du workflow : nom, téléphone, adresse, date, heure, montant, plaque, service demandé. Une confirmation explicite est utile avant l’action.
« J’ai mardi 25 août à 14 h. C’est bien cela ? »
La contradiction est également un bon trigger. Si la personne dit « non, pas Berne, Thoune » et que l’agent revient ensuite à Berne, la correction humaine non intégrée est un signal fort.
Le comportement peut compléter l’analyse : « non », « c’est faux », « je viens de vous le dire », reformulations répétées. Utilisez ces signes sans prétendre mesurer parfaitement l’émotion de la personne.
Changer la forme de la réparation
Une réparation utile simplifie ou change le canal.
- Proposer deux hypothèses. « Meier ou Meyer ? »
- Découper les données structurées. Numéro de téléphone par petits groupes.
- Offrir une autre entrée. Lien SMS ou clavier pour un code.
- Changer d’identifiant. Numéro client plutôt que nom si le processus le permet.
- Réinitialiser le champ contesté. Ne conservez pas la mauvaise valeur dans le contexte.
- Transférer avec le contexte. Demande, données déjà confirmées, point incertain et tentatives.
Le client ne devrait pas devoir reprendre l’appel depuis zéro après le transfert.
Le suisse allemand et le code-switching faussent les seuils simples
En Suisse, une conversation peut démarrer en allemand standard, passer au dialecte puis contenir un nom français. Un unique score de confiance audio peut transférer trop de bons appels.
Combinez plusieurs signaux : champ critique, correction explicite, répétition du même échec, changement de langue, disponibilité d’un autre canal.
Le type de handover dépend aussi de l’heure. En journée, transfert direct. Le soir, callback priorisé avec contexte.
Expliquez honnêtement : « Je n’arrive pas à saisir votre nom de manière fiable. Je transmets à l’équipe ; votre numéro et votre demande de rendez-vous sont déjà enregistrés. »
Cette phrase respecte davantage la personne qu’une quatrième répétition.
Pilote minimum : utiliser les cas que les démos évitent
Testez des noms suisses, localités, chiffres, plaques, bruit, haut-parleur et code-switching. Demandez aux testeurs de corriger volontairement le système.
Mesurez la réussite au premier passage sur les entités critiques, les cas résolus après une réparation, le nombre moyen de repairs, le taux de transfert pour incompréhension, les appels avec trois répétitions ou plus du même champ et les transferts dont le contexte est complet.
Ne cherchez pas à minimiser le handover à tout prix. Un taux très bas peut simplement signifier que l’agent retient trop longtemps les appels ratés.
Conclusion : l’incompréhension doit être un flow conçu, pas une anomalie gênante. Un repair loop court et varié, puis un transfert propre, vaut mieux qu’une conversation artificiellement longue.
Un bon repair loop change aussi de stratégie, pas seulement de formulation. Si le système n’a pas compris un nom dicté deux fois, une troisième phrase plus polie avec le même canal audio apporte peu. Il peut proposer l’épellation, demander uniquement les lettres incertaines, utiliser un numéro déjà connu avec confirmation, ou envoyer un lien sécurisé pour saisir l’information.
Classez les champs par criticité. Une légère incertitude sur une préférence de créneau peut être confirmée à la fin ; une incertitude sur le nom, l’adresse d’intervention, un numéro de contrat ou une donnée qui déclenche une action ne doit pas être masquée. Le repair loop devient ainsi proportionnel au risque de l’erreur.
Conservez enfin l’historique des réparations comme donnée QA : quel champ échoue, avec quelle langue, quel bruit, quelle stratégie a résolu le problème et après combien d’essais. Cela permet d’améliorer le flow sans utiliser « nombre de transferts » comme unique indicateur. Un transfert volontaire après deux échecs peut être un succès de conception.
Une action sensible demande aussi la vérification de l'appelant. Notre assistant téléphonique IA prévoit des actions limitées et un transfert explicite.
Sources
FAQ
Combien de fois l’agent doit-il demander de répéter ?
Pas de nombre universel. Deux échecs sur une donnée critique sont un bon trigger de pilote pour changer de tactique.
Faut-il confirmer chaque information ?
Non. Surtout celles dont l’erreur change le rendez-vous, la personne, le montant ou l’action.
Un score audio faible suffit-il pour transférer ?
Non. Ajoutez corrections explicites, répétitions et criticité métier.
Que transmettre au collaborateur ?
Motif de l’appel, données confirmées, point incertain, tentatives déjà effectuées et prochaine action souhaitée.
Et la nuit ?
Créez un callback ou ticket attribué, avec tout le contexte et une attente claire pour le client.