technologie

La technologie sous le capot

La reconnaissance vocale, la compréhension et la synthèse tournent sur nos propres serveurs, et vos données d'appel restent dans votre région. L'agent répond en 0,3 seconde environ, si bien que votre client n'attend jamais — et quand il lui coupe la parole, la plateforme enregistre quelle part de la réponse il a réellement entendue.

vitesse de réponse

La latence est ce qui trahit, et c'est un budget, pas une fonctionnalité

Personne ne remarque une bonne voix. On remarque un blanc. Une pause avant la réponse est le moyen le plus rapide pour un appelant de comprendre qu'il n'y a personne.

0.3 s

du moment où l'appelant se tait à celui où l'agent commence

Où passe le temps

Chaque réponse suit trois étapes : entendre la fin du tour de parole de l'appelant, décider quoi dire, puis commencer à le dire. Chacune consomme des millisecondes, et l'appelant ne perçoit que le total. C'est parce que nous exploitons toute la chaîne nous-mêmes que ce total reste maîtrisable — il n'y a pas de file d'attente sur l'API d'un tiers au milieu de la phrase.

L'agent commence aussi à parler avant d'avoir fini de composer, comme le fait une personne, si bien que le premier mot arrive pendant que le reste se produit encore.

interruptions

Tous les fournisseurs disent gérer les interruptions. Demandez ce qu'ils mesurent

S'arrêter quand l'appelant parle est la partie facile. La partie difficile consiste à savoir quel morceau de votre phrase il n'a jamais entendu, et à en faire quelque chose.

Trois questions à la fois

  • L'appelant a-t-il commencé à parler ? Détecté sur l'audio, pas à l'expiration d'un minuteur de silence.
  • Quelle part de ma réponse a-t-il entendue ? La plateforme enregistre le point de l'énoncé où l'appelant a coupé.
  • Que faire de la partie qu'il a manquée ? Si la proposition importante se trouvait dans la moitié non entendue, elle est reformulée avant que la conversation avance.

À quoi cela ressemble dans un journal

Lors d'un test de résistance enregistré sur l'un de nos propres agents de démonstration, un testeur lui a coupé la parole quatre fois. À la première interruption, la plateforme a consigné que l'appelant avait entendu 76 des 159 caractères que l'agent était en train de prononcer — 47 % de la réponse. Comme l'information clé se trouvait dans la moitié non entendue, le système a annulé son propre passage à l'étape suivante, a redit la substance, et n'est revenu qu'ensuite à sa question.

Les trois autres interruptions sont tombées à 0 % entendu. L'agent a accusé réception, a répété la question restée en suspens et a poursuivi, sans parler par-dessus l'appelant et sans perdre sa place.

Le test de résistance complet, y compris le point que nous avons perdu →
garder le fil

Garder sa place, et ne pas inventer de réponse

Deux modes de défaillance expliquent la plupart des appels qui tournent visiblement mal. Les deux méritent d'être testés avant d'acheter.

01

Le contexte après l'interruption

Un robot piloté par script recommence l'étape. L'agent revient à la question qu'il avait réellement posée, les réponses déjà recueillies restant en place, si bien que l'appelant n'est jamais ramené au début.

02

Dire “je ne sais pas”

Invité à confirmer quelque chose qui n'est pas dans la base de connaissances, un modèle sous pression sociale acceptera souvent, par serviabilité. Le nôtre est conçu pour garder deux propositions distinctes plutôt que de les fondre en une réponse commode, et pour transférer là où un fait manque.

Comment nous bridons l'invention →
03

Une sortie vers un humain

“Je suis un assistant numérique” est honnête et, en soi, une impasse. Le scénario porte une sortie explicite — une proposition de rappel ou un transfert — parce qu'un appelant qui demande un humain et à qui on ne donne rien raccroche, tout simplement.

sur nos propres serveurs

Les données ne quittent jamais notre infrastructure

La reconnaissance, la compréhension et la synthèse sont les nôtres, dans une seule chaîne. C'est à la fois une décision de latence et une décision sur les données.

TTSSTTLLM

Synthèse vocale, reconnaissance vocale et modèle de langage — les trois composants dont tout agent vocal a besoin, qui fonctionnent ensemble au lieu d'être assemblés entre plusieurs fournisseurs.

Une chaîne autonome

Les trois tournent sur nos propres serveurs : l'audio de vos appels, les transcriptions et les données de vos clients restent dans votre région et ne passent par aucun service tiers. Si vous avez une raison de préférer un fournisseur précis pour un composant, nous pouvons l'intégrer — et nous vous indiquons par écrit quels composants sont les nôtres et lesquels ne le sont pas avant que l'agent prenne un appel réel.

Où vos données sont traitées, et ce que nous ne prétendons pas →
également à l'œuvre dans chaque conversation

La mécanique ingrate qui décide si cela fonctionne

Rien de tout cela n'apparaît dans une démo. Tout cela apparaît dans vos journaux d'appels.

Détecte les répondeurs

Un message d'accueil de répondeur ressemble à une personne qui décroche, et un argumentaire délivré à un répondeur est du pur gaspillage. L'agent fait la différence et traite une machine comme une machine.

Comment fonctionne la détection →

Vérifie ce qu'il a noté

Adresses, orthographes, dates et numéros sont relus et confirmés pendant l'appel, parce qu'une livraison à la mauvaise adresse coûte plus cher que l'appel.

Note chaque appel ensuite

Locator examine 100 % des conversations selon une grille convenue avec vous. Un service qualité humain en atteint 3–5 %, chiffre qui vient de notre propre exploitation d'opérations d'appels réelles.

Ce que produit la notation des appels →
questions que nous posent les ingénieurs

Questions fréquentes

Quelle latence un agent vocal doit-il réellement atteindre ?
Le chiffre qui compte est l'écart que perçoit l'appelant entre la fin de sa phrase et le premier mot de la réponse. Le nôtre est d'environ 0,3 seconde. Au-delà d'une seconde environ, les appelants comblent eux-mêmes le silence — ils répètent la question, disent « allô ? », ou raccrochent — et aucune qualité de voix ne rattrape cela. Demandez à un fournisseur le chiffre mesuré de bout en bout sur une vraie ligne téléphonique, pas le temps d'inférence du modèle.
Qu'est-ce que le barge-in, et pourquoi est-ce important ?
Le barge-in, c'est l'appelant qui parle par-dessus l'agent. Bien le gérer suppose trois choses : détecter l'interruption sur l'audio plutôt qu'attendre l'expiration d'un minuteur de silence, s'arrêter proprement, et savoir quelle part de la réponse l'appelant a entendue avant de couper. La troisième est celle que la plupart des systèmes sautent, et c'est elle qui décide si l'agent répète le passage manqué ou continue comme si la phrase était passée.
Quels modèles de parole et de langage utilisez-vous ?
La reconnaissance vocale, le modèle de langage et la synthèse vocale tournent tous sur une infrastructure que nous exploitons, ce qui nous permet de maîtriser le budget de latence et de garder les données d'appel dans la région. Si vous avez une raison précise de préférer un fournisseur nommé pour un composant, nous pouvons l'intégrer, et nous confirmons par écrit quels composants sont les nôtres avant la mise en service. Nous ne publions pas de schéma d'architecture, parce que la réponse honnête change à mesure que nous en remplaçons des parties.
Où nos données d'appel sont-elles traitées et combien de temps les conservez-vous ?
L'audio des appels, les transcriptions et les champs recueillis par l'agent sont traités sur nos propres serveurs et restent dans la région. Les durées de conservation, les rôles de responsable de traitement et de sous-traitant, et notre représentant désigné dans l'Union européenne au titre de l'article 27 du RGPD sont exposés sur la page sécurité et conformité. Cette page indique aussi clairement quelles certifications nous ne détenons pas, car un fournisseur qui affiche des normes sans avoir été audité pose un problème plus grave que de ne pas les avoir.
Comment empêchez-vous l'agent d'inventer une réponse ?
L'agent répond à partir du matériel que vous nous fournissez, et là où un fait manque, le bon comportement est de le dire et de transférer, pas de combler le vide. Le mode de défaillance qu'il faut tester n'est pas l'invention spontanée mais l'appelant qui avance une fausse prémisse avec une pression sociale derrière — « on m'a dit que vous avez un spécialiste en X ». Demandez à un fournisseur de jouer cette sonde devant vous, et regardez si l'agent garde les deux affirmations séparées ou s'aligne sur la plus commode.
Pouvons-nous tester l'agent avant qu'il prenne de vrais appels ?
Oui, et nous préférons que vous le fassiez. Nous jouons des provocations scriptées contre nos propres agents — interruptions, fausses prémisses, demandes d'un humain — nous les notons selon une grille fixe, puis nous publions ce qui échoue. Nous mettrons le même test en place pour votre scénario pendant la construction. Une démo de fournisseur vous montre l'agent dans son meilleur jour, ce qui n'est pas ce que vous avez besoin de savoir.
S'intègre-t-il à notre téléphonie et à notre CRM ?
L'agent se place sur votre ligne téléphonique et écrit dans les systèmes que votre équipe utilise déjà, et les deux connexions font partie de la construction, pas d'un projet supplémentaire. Ce que nous confirmons par écrit avant le premier appel réel, c'est exactement quels systèmes sont raccordés et ce qui est écrit où. Là où un système ne peut être lu et écrit par programmation, nous vous le disons au cadrage plutôt qu'après.