01
Pourquoi votre agent vocal paraît lent et sourd
Un agent qui met quatre secondes à répondre, et qui continue de parler
quand on le coupe, donne à l'appelant l'impression d'un répondeur
automatique. Deux mesures expliquent l'essentiel du problème.
Le time-to-first-audio est le délai entre la fin de la phrase de
l'appelant et le premier son de l'agent. Au-delà d'environ une seconde,
l'humain relance, se répète ou raccroche. Le barge-in désigne ce
qui se passe quand l'appelant coupe la parole. C'est le geste le plus
courant d'une conversation téléphonique, et presque toutes les
implémentations le gèrent mal.
① La connexion ouverte trop tard
Le schéma naïf : l'appel arrive, le fournisseur de téléphonie appelle
votre webhook, vous ouvrez alors la connexion vers le modèle, handshake,
configuration de session, premier audio. Cela fait cinq à dix secondes de
silence avant que l'agent dise « allô ». Pendant ce temps, l'appelant a
déjà demandé « allô ? » deux fois.
Le correctif tient en une phrase : la connexion au modèle doit être
établie avant que l'appel décroche, et maintenue chaude. Le coût est
une session ouverte quelques secondes pour rien. Le gain est un
time-to-first-audio divisé par cinq, pour une modification qui touche peu
de code.
② L'interruption sans troncature
L'appelant coupe la parole. Vous arrêtez de jouer l'audio côté
téléphonie, ce qui est la bonne réaction. Mais le modèle, lui, croit
avoir prononcé sa phrase entière : elle est déjà inscrite dans
l'historique de la conversation. Il enchaîne donc comme s'il avait été
écouté jusqu'au bout.
Il faut explicitement tronquer l'élément côté modèle et lui
indiquer où la lecture s'est arrêtée. Sans cela, le contexte de l'agent et
ce que l'appelant a réellement entendu divergent un peu plus à chaque
interruption.
③ Ne pas mesurer l'audio réellement entendu
Pour tronquer au bon endroit, il faut savoir combien de millisecondes ont
été entendues, et non combien ont été envoyées. La
téléphonie bufferise : au moment où vous coupez, plusieurs centaines de
millisecondes sont déjà parties sur le réseau et ne seront jamais jouées.
Sans compteur fondé sur les acquittements de lecture, la troncature tombe
au mauvais endroit. Sur un appel de trois minutes avec six interruptions,
l'écart s'accumule et l'agent finit par répondre à la question
précédente. C'est le bug que les utilisateurs signalent en disant « il est
bizarre ».
④ Confondre silence et fin de tour
La détection de fin de parole se règle appel après appel. Trop agressive,
elle coupe l'appelant qui réfléchit. Trop permissive, elle laisse un blanc
gênant qui pousse l'appelant à relancer au moment précis où l'agent
démarre.
Ce seuil dépend du métier. Un patient âgé qui cherche ses dates ne parle
pas au rythme d'un courtier pressé. C'est un paramètre à fixer par
verticale, sur des appels réels plutôt que sur une valeur par défaut.
Ce que je fais concrètement
Instrumenter le time-to-first-audio dès le premier appel de test, tracer
chaque interruption avec sa position de troncature, régler la détection
de tour métier par métier. Ce sont trois chantiers courts dont l'effet
s'entend immédiatement, et c'est souvent par là que je commence sur un
agent existant.
02
Un agent qui écrit dans vos systèmes sans tout casser
Un agent qui se contente de répondre à des questions apporte peu. La
valeur arrive quand il agit dans vos systèmes, et c'est aussi à ce
moment-là que le risque apparaît.
Un modèle qui se trompe en lecture produit une réponse fausse :
désagréable, réversible. Un modèle qui se trompe en écriture détruit une
donnée client. Le problème change de nature, et un meilleur prompt ne le
résout pas.
Séparer lecture et écriture, structurellement
Chaque outil est déclaré en lecture seule ou en écriture. Les lectures
s'exécutent directement. Les écritures passent par un cycle en deux
temps : l'outil renvoie d'abord ce qu'il ferait, sans rien
faire. L'utilisateur voit l'effet exact, l'ancienne valeur, la nouvelle et
l'enregistrement touché, puis confirme.
L'exécution part alors avec un jeton d'action signé qui encode
l'opération validée. Le modèle ne peut plus exécuter autre chose que ce
qui a été montré à l'écran, même s'il se trompe de cible au moment de
l'appel.
Les garde-fous qui vont avec
-
Anti-rejeu : chaque jeton porte un identifiant unique
consommé à l'usage. Un double-clic, une reprise réseau ou un rejeu
malveillant ne déclenche pas deux écritures.
-
Annulation : toute écriture réversible embarque son inverse.
L'utilisateur accepte plus vite quand il sait qu'il peut revenir en
arrière.
-
Masquage des données personnelles : noms, téléphones,
courriels et identifiants sont remplacés par des jetons avant l'envoi au
modèle, puis restaurés après. Le fournisseur du LLM ne voit jamais la
donnée en clair. Le RGPD, la Loi 25 et la LPRPDE l'imposent.
-
Cloisonnement par client : le filtre par organisation vit
dans la requête, pas dans l'affichage. Un identifiant deviné ne doit
rien retourner du tout.
-
Quotas : un budget de jetons par utilisateur et par jour.
Sans quota, un seul utilisateur en boucle coûte plus cher que son
abonnement.
Le piège le moins évident : la mémoire entre les tours
Une conversation utile enchaîne les outils. « Les appels de cette
semaine », puis « rappelle le premier ». Si le contexte ne conserve que
les identifiants des résultats précédents et pas les données, l'agent ne
sait plus qui est « le premier ». Il redemande, ou il invente.
La correction est moins spectaculaire que le prompt
engineering : standardiser le format de retour de tous les
outils. Un même contenant, une même clé d'identité, un même libellé.
Cela répare d'un coup la mémoire entre les tours, le masquage des données
et la qualité des résumés, qui remontent tous à la même cause.
Ce que je fais concrètement
Je conçois la boucle d'outils avant les prompts. Le prompt système est
la dernière chose que j'écris et la première que je réduis. Un prompt de
six mille jetons signale presque toujours des outils mal conçus.
03
Ce qui casse quand les appels IA passent en production
En démo, tout marche : un appel à la fois, un utilisateur, un
scénario nominal. La production apporte la concurrence, les rejeux et les
gens de mauvaise foi.
Les callbacks rejoués
Les fournisseurs de téléphonie rejouent leurs webhooks. C'est documenté et
c'est le comportement attendu d'un système fiable. Si votre traitement
manque d'idempotence, le rejeu produit un double courriel, une double
facturation, un double appel. La clé d'idempotence doit venir de
l'identifiant de l'événement, jamais d'un horodatage.
La réservation de créneau lue puis écrite
Deux appelants confirment le même créneau à deux cents millisecondes
d'intervalle. Le code lit « libre », puis écrit. Les deux passent. La
clinique découvre le double-booking le lendemain matin.
Une condition dans le code ne garantit pas l'unicité. Il faut une écriture
conditionnelle atomique au niveau de la base de données, seul endroit où
la course entre les deux requêtes est réellement arbitrée.
Le coût comme surface d'attaque
Un endpoint public qui déclenche un appel sortant expose directement votre
budget télécom. La fraude classique consiste à faire composer des numéros
surtaxés à l'étranger, dont l'attaquant touche une part des minutes que
vous payez.
Les contrôles, par ordre d'efficacité : liste blanche de pays,
plafond de dépense sur un sous-compte dédié, blocage des préfixes
surtaxés, limite par numéro et par adresse IP, durée maximale d'appel. Le
premier retire déjà l'essentiel du risque.
Les contrôles d'accès qui échouent ouverts
Une vérification d'autorisation qui laisse passer la requête quand elle
rencontre une erreur technique. Les tests ne la détectent pas, puisqu'ils
passent et que le contrôle fonctionne. Le problème apparaît le jour où le
service dont dépend la vérification devient indisponible, et où tout le
monde accède à tout.
L'isolation multi-client, testée à l'envers
La plupart des tests vérifient que le client A voit bien ses propres
données. Le test utile vérifie l'inverse : est-ce que le client A
peut atteindre les données du client B en devinant un
identifiant ? Les deux se ressemblent, et seul le second couvre le
scénario qui compte.
Les jetons qui n'expirent jamais
Un jeton signé dont on vérifie la signature mais jamais la date de
validité reste valable indéfiniment. Un lien de confirmation envoyé par
courriel il y a six mois fonctionne encore aujourd'hui.
Ce que je fais concrètement
Aucun de ces points n'apparaît dans une démo. Ils se manifestent une
fois le système ouvert au public. Je sépare donc deux
livraisons : un prototype qui décroche et répond, puis une phase de
durcissement pour la production, avec sa propre liste de vérifications.