Un client appelle notre agent téléphonique pour créer un contrat dans un de ses établissements de Chibougamau. Le moteur de transcription l'entend parfaitement bien, et écrit « Shibugamo ». L'agent cherche alors Shibugamo dans la base de données, ne trouve rien et dit poliment qu'il n'y a aucun établissement à « Shibugamo ». L'IA aime Shibugamo. Pas nous.
Le moteur ne s'est pas trompé
Le premier réflexe est d'accuser la transcription. Mais prononcez les deux mots à voix haute : Chibougamau, Shibugamo. Au téléphone, ils sonnent exactement pareil. Le moteur a écrit ce qu'il a entendu, comme le ferait quelqu'un qui n'a jamais vu le nom écrit. Demandez à un collègue de Paris de l'écrire après l'avoir entendu une seule fois : vous risquez fort d'obtenir une nouvelle orthographe.
Et demander à l'appelant de répéter n'y change rien. Il redira Chibougamau, de la même façon, et le moteur réécrira Shibugamo, de la même façon. Le problème n'est pas la prononciation de l'appelant, c'est que le son ne porte pas l'orthographe. Épeler un nom de ville lettre par lettre au téléphone ? C'est possible, mais la conversation n'a alors plus rien de naturel, et c'était justement tout l'intérêt d'un agent vocal.
Quelques éléments aggravent les choses en pratique :
- Les noms propres. Villes, rues, noms d'entreprises et de personnes : ce sont précisément les mots qu'un moteur de transcription connaît le moins, et précisément ceux sur lesquels vos outils font leurs recherches.
- Le son du téléphone. Une ligne téléphonique coupe les hautes fréquences qu'un micro capterait, et c'est justement là que « ch » et « sh » se distinguent.
- Les accents et les langues. Un nom québécois, prononcé par un francophone, transcrit par un moteur qui hésite entre le français et l'anglais : chaque hypothèse est plausible.
Nos outils ont été pensés pour le clavier
Dans un clavardage, le client tape « Chibougamau ». S'il fait une faute de frappe, il la voit, et nous aussi. Nos outils de recherche, et la plupart des API sur lesquelles ils reposent, ont été conçus pour ce monde-là : correspondance exacte, « contient », préfixe, recherche plein texte. Tous supposent que les mots recherchés ont été tapés par quelqu'un qui savait les écrire.
À la voix, cette hypothèse ne tient plus. Les mots qui arrivent à l'outil sont la meilleure hypothèse d'orthographe du moteur. Une lettre de travers, et une recherche exacte ne renvoie rien. L'IA fait alors exactement ce qu'on lui a demandé : elle annonce qu'elle n'a rien trouvé. Techniquement correct, et parfaitement inutile pour la personne au bout du fil.
La plupart des API d'affaires, des CRM aux ERP en passant par les systèmes de réservation et d'inventaire, n'offrent pas mieux. On peut chercher par nom, parfois par « commence par ». Chercher par son n'est presque jamais offert, parce que personne n'avait imaginé que la requête viendrait d'une oreille plutôt que d'un clavier.
Changer de stratégie : chercher par le son
La leçon pour quiconque développe des outils pour un agent IA téléphonique : ne cherchez pas ce qui a été écrit, cherchez ce qui a été entendu. En pratique, cela se joue sur trois niveaux.
1. Aider le moteur à bien entendre
Les moteurs de transcription acceptent une liste de termes à prévoir, souvent appelés keyterms ou indices de vocabulaire. Donnez-lui « Chibougamau », et il a beaucoup plus de chances de l'écrire correctement. Le hic, c'est que la liste est courte (quelques dizaines de termes) et payante. On choisit donc avec soin, selon qui appelle : pour un client, les villes et les noms de ses propres établissements ; pour un employé, peut-être rien du tout. Ça aide beaucoup, mais ça ne suffira jamais à lui seul.
2. Chercher par le son, pas par les lettres
Quand la recherche exacte ne trouve rien, on réessaie par le son. Des techniques bien connues décrivent un mot par la façon dont il se prononce plutôt que par la façon dont il s'écrit : « ch » et « sh » comptent pour le même son, les lettres muettes sont ignorées, les voyelles comptent moins. Chibougamau et Shibugamo correspondent alors, tout simplement parce qu'ils sonnent pareil. Une deuxième technique rattrape les noms à peine mal écrits.
Ces techniques n'ont rien de nouveau, et la plupart des bases de données les offrent déjà. Le truc est de s'en servir en repli : d'abord la recherche exacte, et seulement si elle revient vide, les quelques noms les plus proches par le son.
Et quand l'API dont vous dépendez n'en est pas capable ? Alors c'est votre outil qui s'en charge : il récupère la courte liste des candidats qui ont du sens pour cet appelant (ses établissements, ses comptes, ses produits), les compare lui-même par le son, puis appelle l'API avec le bon identifiant.
3. Confirmer plutôt que supposer
Une recherche approximative trouve des candidats, pas des certitudes. L'outil doit le dire à l'agent : « aucune correspondance exacte, voici les résultats les plus proches ». Et l'agent doit alors faire ce que ferait une bonne réceptionniste : « Vous voulez dire Chibougamau ? » Une courte question, et la conversation continue. Surtout, l'agent ne doit jamais agir sur une supposition, encore moins pour créer un contrat ou réserver un rendez-vous.
Ce que nous faisons chez Netcoder
Chez Netcoder, ce n'est pas une leçon apprise à la dure puis oubliée. C'est la façon dont nous construisons chaque outil qu'appellent nos agents vocaux, dès le départ :
- L'oreille est préparée pour chaque appelant. Les termes fournis au moteur de transcription sont choisis selon le type d'agent et la personne qui appelle, dans les limites du moteur.
- Chaque recherche a un plan B. D'abord exacte, puis par le son, puis par similarité, et seulement les quelques résultats les plus proches.
- L'agent confirme avant d'agir. Un résultat approximatif est toujours présenté comme tel, et rien n'est créé ni réservé sur une supposition.
- Chaque outil s'explique. Quand quelque chose est introuvable ou impossible, l'outil dit pourquoi, pour que l'agent puisse corriger le tir au lieu de répéter la même erreur.
- Vos systèmes n'ont pas à changer. Quand votre CRM ou votre ERP ne sait chercher que par nom exact, notre couche d'outils fait le travail phonétique avant de l'appeler avec le bon identifiant.
Et nous testons avec de vrais appels, en français québécois, avec les noms de vrais endroits, comme Chibougamau. C'est là que l'approche générique s'effondre, et que la nôtre tient.
Concevoir pour l'oreille
Un agent téléphonique n'est pas un chatbot avec une voix. Chez Netcoder, c'est la conviction derrière tout ce que nous construisons.
Rien de tout cela n'est magique. Ce qui est difficile, c'est de le savoir, parce que nos réflexes viennent des écrans et des claviers. Chaque outil qu'appelle un agent téléphonique doit s'attendre à des mots approximatifs, mais fidèles à ce qui a été dit, et réagir comme le ferait une personne : en cherchant ce qui sonne pareil, puis en confirmant.
L'IA continuera d'aimer Shibugamo. C'est à nous de faire en sorte que l'appelant arrive quand même à Chibougamau.
Construire les outils des agents vocaux, c'est notre métier : les nôtres sont conçus pour l'oreille d'abord, et nos agents vocaux reposent sur eux. Votre agent téléphonique bute sur les noms de vos clients, ou vous avez un projet qui en demande un qui ne butera pas ? Parlons-en.
— Frédéric Brabant