Audio callbot : AEC, denoise, AGC — la stack qui sauve vos appels

Pourquoi l’audio est le vrai “modèle” de votre callbot

En callbot, tout commence par un fait simple :

l’IA raisonne sur ce qu’elle entend.

Si elle entend mal :

• elle transcrit mal,
• elle comprend mal,
• elle demande de répéter,
• elle rallonge l’appel,
• elle escalade.

Et vous découvrez que votre “callbot IA” est en réalité un “callbot pardon ?”.

Si vous n’avez pas encore cadré latence et barge-in, lisez : Latence, barge-in, VAD. L’audio et la latence sont le duo le plus sous-estimé du callbot.

Téléphonie : 8 kHz, codecs, et pourquoi “ça marchait sur mon micro”

Le téléphone n’est pas un podcast.

Selon votre chaîne télécom, votre callbot peut se retrouver avec :

• du narrowband (typique 8 kHz),
• des codecs historiques,
• des transcodages invisibles,
• et parfois un “HD Voice” (wideband) — mais pas de manière uniforme.

L’ITU documente par exemple G.711 (PCM 64 kbps), très répandu dans les systèmes télécom/VoIP, et G.722 (wideband), souvent associé à une meilleure intelligibilité quand la chaîne le supporte.⁵⁶

Et côté Internet/temps réel, l’IETF standardise des codecs comme Opus (RFC 6716), largement utilisé en WebRTC, justement parce qu’il se comporte bien sur des réseaux imparfaits.⁷

Pourquoi ça compte pour votre callbot ?

• Le STT n’entend pas “la voix”. Il entend un signal compressé.
• Les consonnes (et les chiffres) sont fragiles.
• Le bruit et l’écho prennent plus de place dans un canal étroit.

Pour comprendre la plomberie télécom (SIP/RTP/WebRTC), l’article compagnon est ici : SIP/RTP/WebRTC pour callbot.

AEC (Echo Cancellation) : l’ennemi n°1 du barge-in

Le cas d’école :

• le callbot parle,
• l’appelant écoute sur haut-parleur,
• la voix du callbot revient dans le micro,
• le STT “entend” le callbot,
• et l’IA se met à répondre à… elle-même.

Ce n’est pas de la science-fiction. C’est une journée normale.

SpeexDSP : un exemple d’AEC documenté

Le projet SpeexDSP documente explicitement l’annulation d’écho (AEC) et explique le modèle (signal de référence, adaptation) et les paramètres pratiques.¹

Même si vous n’utilisez pas SpeexDSP, l’idée est universelle :

• fournir un signal de référence (ce que le bot émet),
• estimer l’écho,
• le retirer de l’entrée.

G.168 : la “réalité industrielle” de l’annulation d’écho

Si vous voulez un repère “télécom classique”, l’ITU maintient une recommandation dédiée aux annuleurs d’écho : ITU‑T G.168.⁸

Même sans entrer dans les détails, elle rappelle un point important : l’écho, ce n’est pas juste un filtre. C’est une dynamique :

• chemins acoustiques (haut-parleur),
• chemins électriques (hybrides),
• et surtout double-talk (quand les deux parlent).

Le callbot doit donc être robuste quand :

• vous parlez,
• l’utilisateur parle,
• et votre audio “revient” dans votre micro.

WebRTC APM : la boîte à outils “audio réel”

WebRTC expose un Audio Processing Module (APM) comprenant typiquement :

• echo cancellation,
• noise suppression,
• gain control,
• et autres traitements temps réel.

La doc “audio processing module” (APM) est une référence utile pour comprendre ce que WebRTC fait (et comment il le fait).²

Denoise : bruit, voiture, open space, métro (et 8 kHz)

La téléphonie n’est pas un studio.

Et même si votre LLM est un monstre, il ne peut pas deviner ce que l’appelant a dit quand le micro capte :

• un bus,
• un bébé,
• un chantier,
• ou un open space avec trois conversations.

RNNoise : denoise neuronal (open source)

RNNoise est un exemple d’approche open source de suppression de bruit par réseaux neuronaux (repo officiel).³

L’intérêt produit :

• moins d’erreurs STT,
• moins de répétitions,
• donc AHT plus bas et meilleure satisfaction.

Le piège :

• trop de denoise peut “manger” des consonnes,
• et donc dégrader les chiffres / noms propres.

Conclusion : testez sur vos conditions, pas sur un sample propre.

Perte de paquets, jitter, “blancs” : l’audio qui saute est un bug conversationnel

Un callbot en prod voit des réseaux imparfaits :

• Wi‑Fi,
• 4G/5G,
• VPN,
• et parfois un SBC qui fait des choses créatives.

Résultat côté audio :

• micro-coupures,
• syllabes mangées,
• “robotisation”,
• et latence instable.

La conséquence produit n’est pas “la qualité est moins bonne”.

La conséquence, c’est :

• STT plus instable,
• plus de reprompts,
• donc AHT qui monte.

Ça rejoint le point central : ce que vous optimisez n’est pas “la beauté du signal”, c’est le temps de résolution.

AGC : niveaux et dynamique (quand “allo ?” devient un bug)

La dynamique de volume est un sujet callbot :

• certains parlent très bas,
• d’autres très fort,
• d’autres alternent.

Si votre entrée clip :

• le STT perd des mots,
• vous perdez des chiffres,
• et vous perdez la confiance.

Si votre entrée est trop faible :

• le STT invente,
• et l’utilisateur répète.

L’AGC (automatic gain control) est donc une brique utile, mais à calibrer (sinon vous amplifiez aussi le bruit).

VAD et endpointing : l’audio au service du tour de parole

La VAD (voice activity detection) et l’endpointing servent à décider :

• “est-ce que l’utilisateur parle ?”
• “a-t-il fini ?”

Sans ça, vous avez :

• des silences trop longs,
• des coupures impolies,
• et du temps d’appel perdu.

Ces sujets sont détaillés dans Latence, barge-in, VAD, mais retenez ceci :

• AEC rend la VAD plus fiable,
• denoise rend le STT plus stable,
• et un bon endpointing réduit le coût.

Où mettre les traitements audio (et comment ne pas ajouter de latence)

C’est la question la plus importante.

Vous avez 3 options :

1) Côté client (WebRTC / app)

Avantages :

• vous nettoyez la source,
• moins de transport de bruit,
• parfois meilleure AEC (proche du device).

Risques :

• hétérogénéité device,
• complexité multi-plateforme.

2) Côté passerelle média (media server / gateway)

Avantages :

• contrôle central,
• monitoring homogène,
• mêmes paramètres pour tout le monde.

Risques :

• coût de compute,
• latence si mal implémenté.

3) Côté STT (feature intégrée fournisseur)

Avantages :

• simplicité,
• parfois optimisé par le vendor.

Risques :

• moins de contrôle,
• moins de transparence,
• et dépendance fournisseur.

Mesure objective : PESQ/POLQA… et les proxies qui suffisent souvent

Le MOS (écoute humaine) est une référence, mais ce n’est pas toujours industrialisable.

Il existe aussi des méthodes “objectives” d’évaluation de la qualité vocale. PESQ (ITU‑T P.862) est une recommandation connue pour estimer une qualité perçue à partir d’un signal de référence et d’un signal dégradé.⁹

En pratique callbot, vous n’avez pas toujours un “signal de référence”.

Donc vous finissez avec des proxies :

• taux de clipping,
• niveau RMS,
• taux de “repeat” (pardon/je répète),
• erreurs sur chiffres,
• et drop rate.

Ce n’est pas parfait. Mais c’est actionnable, et la prod aime l’actionnable.

Mesurer la qualité : MOS, clipping, et signaux de santé

La qualité audio n’est pas seulement une impression.

Dans le monde télécom, l’évaluation subjective de la qualité de la parole (MOS, tests d’écoute) a des cadres standardisés. ITU-T P.800 est la recommandation de référence pour les méthodes d’évaluation subjective de la qualité de la parole.⁴

Sans reproduire un labo ITU, vous pouvez suivre des signaux simples :

• taux de clipping,
• niveaux RMS,
• taux de “repeat” (pardon/allo),
• erreurs sur chiffres,
• et latence tour complet.

Et, surtout : écoutez des échantillons. Les dashboards ne remplacent pas l’oreille.

Table de diagnostic (symptôme → cause probable → fix)

Ce tableau n’est pas une vérité universelle.

Mais c’est un bon point de départ pour éviter le “c’est sûrement le LLM”.

Test terrain : 30 minutes d’audio qui évitent 3 mois de “mystère”

Quand une équipe dit : “notre callbot comprend mal”, il y a une question que je pose toujours :

“Vous avez testé sur quel téléphone, dans quel bruit, avec quel codec, et sur haut‑parleur ?”

Ne riez pas. Les bugs les plus coûteux sont souvent des bugs de contexte.

Voici un protocole simple, que vous pouvez faire en une demi-heure, et qui fait apparaître 80% des problèmes :

1. Appel “propre” : bureau calme, casque, diction normale. (C’est votre baseline.)
2. Appel “haut‑parleur” : téléphone en mode speaker, proche du micro. (AEC en sueur.)
3. Appel “terrain” : rue, voiture à l’arrêt, open space. (Denoise + AGC en stress test.)
4. Appel “chiffres” : dictez des numéros et dates, puis corrigez volontairement. (Confirmation + clipping.)
5. Appel “interruption” : coupez le bot volontairement. (Barge‑in réel, pas théorique.)

Pour chaque appel, notez :

• nombre de “pardon ?”,
• temps avant première réponse,
• nombre de reprompts,
• et si le bot vous coupe.

Ensuite, écoutez 3 extraits. Juste trois. Vous allez entendre des choses que vos métriques ne montrent pas.

Et si vous voulez industrialiser ça, reliez l’audio à vos KPI. Un callbot est jugé sur la vitesse de résolution (AHT/FCR), pas sur la beauté d’un waveform. Pour la méthode d’évals “callbot”, voyez : Benchmark callbot. Pour la prod et la supervision : Callbot en production.

Open source vs “audio magique” : ce que vous achetez vraiment

Sur l’audio, vous avez deux chemins classiques :

1. Assembler vous-même (WebRTC APM, RNNoise, SpeexDSP…)
2. Déléguer (audio processing intégré à une passerelle média, ou parfois au fournisseur STT/TTS)

Le premier chemin vous donne du contrôle : vous pouvez mesurer, régler, changer. WebRTC APM est une base très solide pour AEC/NS/AGC en temps réel.² RNNoise est un bon exemple d’approche denoise open source.³

Le second chemin vous donne du time-to-market : moins de glue code, moins de tuning au début.

Mais il a un coût caché : si vous ne savez pas où le signal est nettoyé, vous ne savez pas pourquoi il casse.

Checklist “audio robuste” (copiable/citable)

1. AEC activée et testée (haut-parleur).
2. Denoise calibré (ne pas tuer les consonnes).
3. AGC calibré (éviter clipping + bruit amplifié).
4. VAD + endpointing validés sur audio réel.
5. Mesures audio (clipping, niveaux) monitorées.
6. Tests sur 8 kHz téléphonie + bruit.
7. Barge-in testé (interruption fiable).
8. Fallback prévu (DTMF / transfert) si audio trop mauvais.
9. Enregistrements “brut” et “traité” disponibles pour debug.
10. Seuils d’alerte sur répétitions et silences initiaux.

FAQ

Questions frequentes

AEC ou denoise : je commence par quoi ?+

AEC si vous avez du barge-in et des retours audio (haut-parleur). Denoise si vous avez du bruit terrain. Dans la pratique, les deux finissent presque toujours dans la stack.

Est-ce que WebRTC APM suffit ?+

Souvent, c’est une excellente base (AEC/NS/AGC). Mais la calibration et le placement dans l’architecture (client vs gateway) restent votre responsabilité.²

Pourquoi mon STT est mauvais seulement en prod ?+

Parce que la prod a : 8 kHz téléphonie, bruit, échos, chevauchement. Le dataset de démo ne représente pas la réalité.

Ça impacte vraiment le ROI ?+

Oui. Chaque répétition (“pardon ?”) ajoute du temps d’appel. À volume, c’est un coût direct. Audio = économie.

Sources et references

1. [1]SpeexDSP manual, “Echo Cancellation”.
2. [2]WebRTC docs, “Audio Processing Module”.
3. [3]RNNoise (Xiph), repository GitHub.
4. [4]ITU, “Recommendation ITU-T P.800” (Methods for subjective determination of transmission quality).
5. [5]ITU, “Recommendation ITU‑T G.711” (Pulse code modulation of voice frequencies).
6. [6]ITU, “Recommendation ITU‑T G.722” (7 kHz audio-coding within 64 kbit/s).
7. [7]IETF, “RFC 6716 — Definition of the Opus Audio Codec”.
8. [8]ITU, “Recommendation ITU‑T G.168” (Digital network echo cancellers).
9. [9]ITU, “Recommendation ITU‑T P.862” (Perceptual Evaluation of Speech Quality — PESQ).