Une IA vocale qui fonctionne vraiment en Amérique latine : le guide du CTO

Votre démo d’IA vocale est parfaite dans une salle silencieuse. Puis vous la mettez devant de vrais clients à São Paulo et tout s’effondre. L’appelant est sur une 3G instable, un chien aboie, il passe du portugais à l’espagnol en plein milieu d’une phrase, et il lit son CPF comme « zero oito dois… não, dois… oito. » Votre agent panique, votre CSAT se fracasse, et votre équipe ops revient en catastrophe à des files 100% humaines.

Des reportages récents sur l’IA vocale en Inde décrivent la même réalité : la diversité des accents et des réseaux punit les conceptions fragiles. L’Amérique latine n’est pas plus simple. Mais c’est solvable — si vous respectez les contraintes et concevez pour la rue, pas pour le stand de démo. Ce post propose un cadre de décision pour CTO afin de livrer une IA vocale qui fonctionne vraiment au Brazil et dans toute la LatAm.

Pourquoi la voix en LatAm est difficile (et où les démos vous induisent en erreur)

• Le code‑switching est la norme : Portugais ↔ Espagnol dans les régions frontalières et les grandes villes, plus des termes de marque en US English. Beaucoup de modèles ASR se dégradent de 20–40% de WER sous code‑switching si vous n’avez pas fait le bon choix ou le bon tuning.
• Les nombres et entités dominent : CPF (11 chiffres), CNPJ (14), CEP (8), dates en D/M ou formes parlées, clés PIX (alphanumériques ou emails), et montants (« mil trezentos e cinquenta e dois e oitenta »). Une NLU généraliste les rate constamment.
• Les conditions acoustiques sont rudes : Motos, vendeurs de rue, surfaces dures. Attendez‑vous à 2–5% de perte de paquets et 60–150 ms de gigue sur des liaisons mobiles PSTN/WebRTC ; le Wi‑Fi calling n’est pas une panacée.
• WhatsApp n’est pas optionnel : Les notes vocales sont le canal de support préféré de nombreux segments clients. C’est du 16 kHz OPUS en OGG, une sonie variable, souvent enregistré loin du micro.
• Les tours de parole comptent : Les gens se parlent dessus. Sans barge‑in fiable et backchannels, votre agent sonne robotique et lent.

Planifiez cette réalité dès le premier jour. Si vous traitez la LatAm comme de « l’US English mais plus lent », vous brûlerez votre marque en une semaine.

Un cadre de décision : quoi centraliser, quoi spécialiser

1) ASR : modèles à poids ouverts vs API managée

• ASR temps réel managé (ex. clouds majeurs, éditeurs spécialisés) : Bon défaut. Comptez $0.006–$0.02 par minute, des endpoints de streaming matures, ponctuation, options de diarisation. Évaluez sur portugais brésilien (pt‑BR) et espagnol rioplatense (es‑AR/UY) spécifiquement, pas un es‑ES générique.
• ASR à poids ouverts (ex. variantes de la famille Whisper, modèles distillés plus rapides) sur votre GPU : Plus de contrôle et potentiellement moins cher à l’échelle. Une seule L4/A10 peut traiter 30–60 flux simultanés 16 kHz avec des partiels < 300 ms si vous gardez des fenêtres de contexte serrées. Le coût effectif peut descendre sous ~$0.005/minute à forte utilisation.

Comment choisir : Faites un bake‑off hors ligne sur 500–2 000 extraits in‑domain avec des accents de SP, RJ, MG, RS, BA, PE, plus espagnol rioplatense et andin. Suivez le WER global et le taux d’erreur caractère (CER) pour les entités (CPF/CEP/montants). Vous visez un WER ≤ 12% in‑domain et un CER entités ≤ 3%. En essais live, exigez une latence partielle T50 ≤ 300 ms, T95 ≤ 700 ms.

2) TTS : naturalité vs interruptibilité

• Ne courez pas après une qualité studio si vous ne pouvez pas gérer le barge‑in : Votre TTS doit démarrer vite (<150 ms), offrir des points de pause fins, et une interruption propre. Les auditeurs pardonnent une voix un peu synthétique ; ils ne pardonnent pas un robot qui parle par‑dessus.
• Des voix locales battent le « neutre » : Une voix pt‑BR avec une prosodie São Paulo ou Sudeste neutre inspire davantage confiance. Idem pour es‑AR/es‑MX si applicable.

3) NLU/LLM : noyau déterministe, bord génératif

• Utilisez une grammaire déterministe pour les entités : Des transducteurs à états finis pour la normalisation CPF/CNPJ/CEP/montant/date surpasseront un LLM en précision et en coût.
• Contraignez les appels de fonction : Faites correspondre les intentions à un ensemble restreint d’opérations (vérifier l’identité, récupérer une facture, initier un remboursement PIX) avec des clés d’idempotence par tour. Le LLM peut résumer et choisir des actions ; il ne doit pas écrire du SQL brut ni effectuer des appels irréversibles sans confirmation.

L’architecture de production (qui survit aux ascenseurs et au bruit de la rue)

Chemin de streaming à faible latence

• Capture et prétraitement : 16 kHz mono, OPUS. Appliquez un VAD et un léger débruiteur (classe RNNoise) côté client ou en edge. Maintenez un tampon de gigue de 60–120 ms et adaptez‑le selon les stats RTCP.
• ASR en streaming avec partiels incrémentaux : Utilisez gRPC/WebSocket avec des partiels horodatés. Ne faites pas trop confiance à la ponctuation dans les partiels ; traitez la finalisation comme un événement séparé.
• Détection de tour : Terminez quand le VAD détecte un silence ≥ 250–400 ms ou que la chute de prosodie dépasse un seuil réglé. Un endpointing agressif réduit la latence ; trop agressif coupe la précision sur les longues séquences de chiffres — ajustez selon le domaine.
• Passe NLU : D’abord, le normaliseur d’entités extrait/valide CPF, montants, dates. Ensuite, la classification d’intention ou le routage via LLM choisit un flux. Enfin, des appels de fonction s’exécutent avec des jetons d’idempotence construits à partir de (call_id, turn_id, intent, entity_hash).
• TTS avec backchannels : Insérez de brefs « uhum », « certo » en <150 ms pour signaler votre présence pendant qu’une réponse plus lourde se prépare.
• Barge‑in : Toujours à l’écoute. Si le VAD s’active pendant le TTS, abaissez et arrêtez en 150–250 ms, appliquez un court fondu, et priorisez l’audio de l’appelant.

Parcours notes vocales WhatsApp

• Transcodez et diarisez si nécessaire : OGG/OPUS → PCM 16 kHz. Pour des notes multi‑locuteurs, une diarisation légère (type pyannote) aide, mais ne bloquez pas l’UX : livrez un premier passage vite, puis affinez en asynchrone.
• Détection de langue avec soin du code‑switching : Utilisez un modèle bilingue pt‑BR/es ou exécutez deux décodeurs et fusionnez les meilleurs segments. Pénalisez les lexiques improbables pour réduire les hallucinations inter‑langues.
• Renvoyez en texte avec des actions cliquables : Sur WhatsApp, de courts résumés avec entités extraites et 1–2 actions proposées (ex. « Confirmer le remboursement PIX de R$ 135,80 vers la chave email@example.com ? ») surperforment les dissertations génératives.

Réalités de la téléphonie

• Choisissez des opérateurs avec terminaison locale : Twilio, Infobip, et des fournisseurs régionaux varient selon l’État. Testez séparément les routes SP/RJ/NE ; la latence aller‑retour peut osciller de plus de 100 ms.
• Collectez RTCP et estimations MOS : Conservez par appel la gigue, la perte de paquets, le temps aller‑retour. Corrélez avec les erreurs ASR — ne blâmez pas le modèle pour le réseau.
• Secours DTMF : Proposez toujours « Appuyez sur 1 pour confirmer » pour les parcours à haut risque. La voix est excellente ; les mouvements d’argent exigent de la redondance.

Critères d’acceptation : à quoi ressemble le « bon »

• Latence : Mic‑to‑first‑token T50 ≤ 300 ms, T95 ≤ 700 ms. Réponse de bout en bout (arrêt utilisateur → prise de parole agent) T50 ≤ 700 ms, T95 ≤ 1,2 s en 4G.
• Reconnaissance : WER in‑domain ≤ 12% (pt‑BR, es‑AR/MX) ; CER entités (CPF/montant/date) ≤ 3%.
• Barge‑in : Arrêt de l’agent sous 250 ms en cas de chevauchement dans ≥ 98% des cas.
• Containment : ≥ 60% des intentions de niveau 1 résolues sans humain (cible variable selon le domaine), avec SLA d’escalade ≤ 3 s si nécessaire.
• Conformité : 100% de masquage des PII dans les transcriptions stockées ; résidence des données LGPD appliquée (région São Paulo) pour l’audio que vous devez conserver.

Normalisation des entités : arrêtez de perdre sur les évidences

La plupart des échecs de la voix en LatAm ne relèvent pas de « l’IA difficile ». Ce sont des erreurs de normalisation.

• CPF/CNPJ : Acceptez les lectures groupées et chiffre par chiffre. Construisez un validateur de checksum ; demandez une re‑dictée immédiate en cas d’incohérence. Cachez les partiels à travers les interruptions.
• Montants en monnaie : Normalisez « mil trezentos e cinquenta e dois e oitenta » → R$ 1.352,80. Résolvez « quinze e noventa » quand le contexte implique de la monnaie.
• Dates et heures : Comprenez « depois de amanhã », « próxima terça », et l’ordre D/M. Confirmez avec une reformulation naturelle : « Terça, 12 de maio, às 14h ? »
• Noms et emails : Utilisez un repli d’orthographiation de type OTAN pour les captures à risque : « F de Fábio, R de Ricardo… »

Mettez d’abord en œuvre ces éléments avec des grammaires déterministes, puis laissez le LLM gérer la récupération hors grammaire avec des confirmations explicites.

Garde‑fous et idempotence : les tours de parole ne sont pas des retries HTTP

La voix est désordonnée : les appelants se répètent, les agents comprennent mal et posent des questions de clarification, les réseaux perdent des paquets, et les utilisateurs raccrochent et rappellent. Sans ingénierie pour cela, vous doublerez des débits, des envois, ou créerez de la dérive de données.

• Idempotence par tour : Pour chaque fonction qui modifie l’état (remboursement, changement d’adresse, résiliation d’abonnement), calculez une clé d’idempotence à partir de call_id, turn_index, intent, et d’un entity_hash stable. Conservez les réponses au moins 24 heures.
• Machine à états, pas texte libre : Contraignez chaque étape à un état fini avec transitions explicites. Si l’appelant dit « espera » en plein flux, mettez en pause sans perdre le scope d’idempotence.
• Humain dans la boucle avec traçabilité : En cas d’escalade, transmettez la transcription, les entités normalisées, et le journal d’actions avec clés d’idempotence. Rendez les replays impossibles par conception.

Sécurité, confidentialité et LGPD

• Masquage des PII à l’ingestion : Exécutez un léger redacteur sur les transcriptions avant écriture. Remplacez CPF/emails/téléphones par des jetons ; stockez les originaux uniquement dans un coffre scellé et à durée limitée si requis.
• Résidence des données : Si vous servez des clients brésiliens, gardez l’audio et les PII dans les régions Brazil (AWS sa‑east‑1, GCP southamerica‑east1). Le transfert transfrontalier requiert un processus et un consentement.
• Consentement et rétention : Annoncez l’enregistrement ; offrez un opt‑out. Rétention par défaut de 30–90 jours pour l’audio, plus longue pour des transcriptions expurgées lorsque nécessaire opérationnellement.
• Gouvernance des modèles : Suivez précisément quelles versions ASR/TTS/LLM ont traité chaque appel. Si vous faites tourner les modèles, vous avez besoin de reproductibilité pour les investigations.

Un modèle de coûts que vous pouvez défendre auprès de la finance

Les coûts varient selon les fournisseurs et le prix GPU, mais l’ordre de grandeur est stable pour la planification 2025–2026 :

• Téléphonie : $0.01–$0.03/min entrant selon la route et le volume.
• ASR : Temps réel managé typiquement $0.006–$0.02/min. Poids ouverts sur une L4/A10 mutualisée peuvent atterrir < $0.005/min à ≥ 70% d’utilisation.
• TTS : $0.002–$0.01/min selon la qualité et le fournisseur.
• LLM/NLU : Très variable. Avec appels de fonction et grammaires déterministes, vous devriez rester à $0.002–$0.02/minute de conversation sur des modèles milieu de gamme ; des flux génératifs complexes peuvent monter plus haut.

Règle de base : Une pile vocale LatAm bien conçue devrait se situer entre $0.02 et $0.07 par minute gérée en coûts variables à échelle modérée, hors escalades humaines. Si vous êtes au‑delà de $0.10/min avec un containment médiocre, votre architecture ou votre mix fournisseur demande à être revu.

30–60–90 : un plan pilote réaliste

Jours 0–30 : prouvez‑le hors ligne

• Assemblez 500–2 000 extraits anonymisés : accents SP/RJ/MG/RS/NE, plus es‑AR/es‑MX. Incluez des notes vocales WhatsApp.
• Faites un bake‑off ASR. Mesurez WER et CER entités. Retenez deux prétendants (un managé, un poids ouvert) pour l’essai live.
• Construisez votre normaliseur d’entités et votre couche d’actions idempotentes. Pas de vernis UI pour l’instant.

Jours 31–60 : mise en production sur une tranche étroite

• Activez 5% des intentions de niveau 1 sur une petite file téléphonique à SP. Instrumentez RTCP, latence, barge‑in. Ajoutez un secours DTMF pour tout parcours de mouvement d’argent.
• Mettez en place une console humain‑dans‑la‑boucle. Quand l’agent hésite ou échoue des contrôles de confiance, escaladez en moins de 3 secondes.
• Suivez : containment, CSAT, taux d’abandon/transfert, latence, et coût par minute. Corrigez chaque semaine les trois principaux modes d’échec d’entités.

Jours 61–90 : scale maîtrisée

• Étendez à 20–30% des intentions de niveau 1 ; ajoutez les notes vocales WhatsApp avec résumés asynchrones et actions cliquables.
• Ajustez barge‑in et backchannels en mesurant le confort d’interruption — les clients ne devraient presque jamais dire « alô ? você está aí ? »
• Décidez de votre mix stable de fournisseurs ASR/TTS. Si vous opérez des poids ouverts, ajoutez un secours managé pour les pointes.

Modes de défaillance courants (et comment les éviter)

• Trop faire confiance à la ponctuation partielle : Le partiel « R$ 1.000,00 ? » devient le final « R$ 100,00 ». Considérez la ponctuation comme indicative jusqu’à la finalisation ; confirmez toujours les entités critiques.
• S’entraîner sur de l’audio de bureau silencieux : Augmentez avec bruit de rue, échos de cuisine, motos. Si votre WER double avec 3% de perte de paquets, votre choix de modèle ou votre prétraitement est mauvais.
• Ignorer le lexique régional : « Crachá », « boleto », « comprovante », « factura » vs « nota ». Constituez un lexique et évaluez avec ces termes présents.
• TTS ininterruptible : Voix magnifique, UX terrible. Priorisez le barge‑in sur le timbre.
• Laisser les LLM modifier l’état librement : Appels de fonction avec clés d’idempotence ou rien. Toute action irréversible doit être relue et confirmée.

Pourquoi des équipes nearshore au Brazil vous donnent un avantage

Vous avez besoin d’ingénieurs et de linguistes qui vivent cette réalité. Une équipe brésilienne vous apporte une couverture native pt‑BR, la proximité de collaborateurs es‑AR/es‑MX, et 6–8 heures de recouvrement avec les fuseaux horaires US pour itérer vite. La différence entre une démo passable et un système de production résilient se joue souvent dans ces cycles d’ajustement hebdomadaires sur de vrais appels.

L’essentiel

L’IA vocale en Amérique latine n’est pas une version plus difficile de l’US English — c’est un autre problème. Si vous concevez pour le code‑switching, les réseaux bruyants, WhatsApp, et les tâches centrées sur les entités, vous pouvez atteindre vos objectifs de containment sans brûler la CSAT. La technologie existe. La différence vient du respect de la physique, de la langue, et des opérations.

Points clés

• Ne livrez pas la pile de démo. Concevez dès le premier jour pour le code‑switching, les nombres, et des réseaux bruyants.
• Choisissez l’ASR par WER in‑domain et CER sur entités, pas par marque. Ciblez WER ≤ 12%, CER entités ≤ 3%.
• Ingénieriez pour la latence : partiels ≤ 300 ms, réponse de bout en bout ≤ 1,2 s au P95.
• Utilisez des grammaires déterministes pour les entités et des clés d’idempotence pour toute action modifiant l’état.
• Priorisez le barge‑in et les backchannels plutôt qu’un timbre TTS parfait.
• Mesurez le réseau (RTCP, MOS) et corrélez avec les erreurs ASR avant d’incriminer les modèles.
• Respectez la LGPD : masquez les PII à l’ingestion et gardez les données dans les régions Brazil quand requis.
• Attendez‑vous à des coûts variables de $0.02–$0.07/min à l’échelle ; si plus élevé, revoyez votre mix fournisseurs et votre architecture.

Auteur : Diogo Hudson Dias