Normalisation du texte et prononciation en IA vocale : guide de production

Périmètre. Un même texte écrit peut avoir plusieurs formes orales valides. Le responsable de l’application doit définir le sens visé pour son marché, son domaine et son parcours utilisateur avant d’évaluer un système vocal.

À retenir

• La normalisation directe convertit les formes écrites en mots pour la synthèse vocale. La normalisation inverse convertit une transcription de reconnaissance vocale en texte affichable. Elles résolvent des problèmes différents et ne sont pas des inverses exactes.
• Lorsque l’application sait déjà qu’une valeur est une date, un montant, un numéro de téléphone ou un identifiant, conservez ce type au lieu de demander à un normalisateur de le deviner.
• Les données de localisation peuvent formater une valeur, mais elles ne peuvent pas décider si 1.250 est un entier groupé à l’allemande, un décimal à l’anglaise ou un code.
• Utilisez des règles structurelles pour les valeurs variables et des contrôles de prononciation pour le vocabulaire stable : noms, marques et abréviations.
• Livrez les règles applicatives, les données de localisation, le jeu de dictionnaires, le modèle et la voix comme une seule configuration testée, avec une cible de retour arrière documentée.

Dernière mise à jour : août 2026. Ce guide définit une méthode de mise en œuvre et de test, pas une prononciation universelle pour toutes les langues, tous les dialectes ou toutes les entrées structurées.

Qu’est-ce que la normalisation du texte en IA vocale ?

En synthèse vocale, la normalisation du texte désigne généralement la normalisation directe : la conversion d’une forme écrite en une forme prononçable. La recommandation SSML 1.1 du W3C retient le même sens et rappelle que des chaînes comme 1/2 sont intrinsèquement ambiguës. La normalisation inverse du texte (ITN) va dans l’autre sens : elle transforme la sortie orale de la reconnaissance vocale en formes écrites comme des dates, des montants et des heures. La présentation des travaux d’Apple sur l’ITN retient cette définition.

Dans un agent vocal, la distinction est décisive :

1. Un appelant dit « cinquante euros ».
2. La reconnaissance vocale et l’ITN peuvent afficher 50 €.
3. La logique métier valide le montant et demande une confirmation si nécessaire.
4. Une réponse vocale ultérieure applique la normalisation directe pour énoncer la valeur enregistrée.

Ne testez pas cette chaîne en attendant un aller-retour exact. Plusieurs formes écrites peuvent produire la même parole, et une même forme orale peut correspondre à plusieurs formes écrites. La sortie de l’ITN reste une entrée analysée, non un montant, une date ou un numéro de compte de confiance.

Utilité principale : les entrées typées. N’aplatissez pas un objet date ou un montant décimal en une chaîne d’affichage ambiguë pour tenter ensuite d’en récupérer le sens avec une seule grande expression régulière.

Quelle couche doit porter chaque décision d’énonciation ?

Retenez trois frontières de responsabilité :

1. Sémantique applicative : le système source détient la valeur et son sens. C’est lui qui décide, par exemple, si les centimes sont significatifs ou si un code de compte doit être confirmé caractère par caractère.
2. Normalisation : des règles sensibles à la locale rendent les valeurs typées et traitent le texte écrit ordinaire. Les convertisseurs de valeurs critiques doivent être déterministes et testables isolément.
3. Prononciation : un dictionnaire au périmètre étroit, une forme phonétique ou une balise prise en charge contrôle le vocabulaire récurrent une fois les mots visés connus.

Cette répartition empêche qu’un remplacement propre à un client ne devienne une règle linguistique globale. Elle rend aussi les défaillances diagnosticables : conservez la valeur source, l’entrée envoyée à la synthèse et le manifeste de version, dans les limites de la politique de conservation des données du produit.

Chez KugelAudio, positionnez normalize: true et transmettez language lorsque la langue est connue ; la détection automatique peut se tromper sur des textes courts. La documentation de traitement du texte fait référence et documente également <spell> pour l’épellation. Les dictionnaires de prononciation de projet acceptent un texte de remplacement ou de l’IPA et se sélectionnent via project_id et, en option, dictionary_ids ; voir la documentation des dictionnaires de prononciation.

Ne transposez pas directement des exemples SSML génériques dans des requêtes de production. SSML définit des éléments comme say-as, phoneme et les lexiques externes, mais leur prise en charge dépend du moteur. KugelAudio documente <break>, <spell> et <prosody rate> comme balises interprétées, auxquelles s’ajoutent l’IPA en ligne et les dictionnaires. Sa référence de prompting fait foi pour les contrôles actuellement pris en charge.

Comment traiter les nombres, dates et identifiants allemands ?

Partez d’une valeur typée, puis rendez-la pour la tâche d’écoute. Les exemples ci-dessous sont des cas de test, non des prononciations prescrites :

La spécification LDML des nombres et la spécification LDML des dates d’Unicode définissent les structures de données de localisation pour le formatage des nombres, des devises, des dates, des heures et des fuseaux horaires. Utilisez une bibliothèque de localisation maintenue fondée sur ces données plutôt que d’entretenir à la main des séparateurs de milliers et des noms de mois. Le formatage localisé ne fournit toujours ni le sens métier, ni le découpage d’un identifiant d’entreprise, ni une politique de confirmation.

Pour une valeur variable, définissez un convertisseur par type sémantique, par exemple render_money(amount, currency, locale) ou render_reference(value, grouping_policy). Validez la valeur complète avant le rendu. Une expression régulière peut aider à faire respecter une grammaire de champ courte et ancrée, mais elle ne doit pas servir d’analyseur pour toute sous-chaîne ressemblant à un nombre dans un texte libre.

Comment traiter Unicode et les textes non fiables ?

Choisissez et documentez une forme de normalisation Unicode avant toute correspondance de dictionnaire. NFC est un choix courant, car un texte canoniquement équivalent y reçoit une représentation unique ; la spécification de normalisation Unicode définit les formes et leurs garanties. Ne substituez pas NFKC à NFC à la légère : la normalisation de compatibilité peut effacer des distinctions qu’une politique d’identifiants doit parfois préserver.

La normalisation canonique n’est pas un contrôle de sécurité. Des caractères visuellement proches peuvent provenir d’écritures différentes, et des caractères de contrôle invisibles peuvent altérer la correspondance ou l’affichage. Pour les identifiants sensibles, validez l’écriture autorisée, les classes de caractères, la longueur et les séparateurs par rapport au contrat du champ. L’UTS #39 d’Unicode fournit des mécanismes de détection des caractères confusables, mais indique explicitement que son squelette de confusables ne convient pas comme valeur de remplacement ou d’affichage.

Traitez le texte contrôlé par l’utilisateur comme une donnée, pas comme du balisage vocal. Ne concaténez pas le texte libre d’un appelant à l’intérieur d’une syntaxe de confiance <spell> ou <break> sans échappement adapté au contexte ou rejet des délimiteurs de balises. Appliquez des limites de longueur et de structure côté serveur avant la normalisation et bornez le travail des expressions régulières ; les recommandations de l’OWASP sur la validation des entrées expliquent pourquoi les listes d’autorisation conviennent aux champs structurés, et pourquoi interdire quelques chaînes dangereuses ne suffit pas. Incluez dans les tests négatifs des chevrons littéraux, des balises mal formées, des caractères de contrôle bidirectionnels, des signes diacritiques combinants, des écritures mélangées et des entrées surdimensionnées.

Comment maîtriser les noms, les marques et les abréviations ?

Utilisez un dictionnaire pour les termes stables, non pour des valeurs qui changent à chaque requête. Chaque entrée exige la forme écrite, la forme orale visée, l’étiquette de langue, le périmètre de correspondance, un responsable, des preuves et une version de livraison. La spécification des étiquettes de langue BCP 47 normalise les étiquettes de langue et de région, mais une étiquette correcte ne prouve pas qu’une prononciation sonne juste.

Pour une abréviation, notez si chaque acception doit être développée, prononcée comme un mot ou épelée. Testez l’entrée dans des phrases, y compris avec des mots courants qui ne doivent pas déclencher de correspondance. Évitez un remplacement trop large qui corrige une marque dans un contexte mais altère un patronyme ou une sous-chaîne ailleurs.

N’utilisez l’IPA que lorsque le système cible documente l’alphabet accepté et que des relecteurs natifs peuvent approuver le résultat. L’élément phoneme de SSML permet d’indiquer l’IPA, mais les moteurs peuvent différer par leur inventaire de phonèmes et leur rendu. Chez KugelAudio, l’IPA d’un dictionnaire prime sur le texte de remplacement : testez donc à la fois le terme visé et les quasi-correspondances voisines avec le modèle et la voix exacts.

Comment livrer et annuler une normalisation en toute sécurité ?

Traitez les ressources de normalisation comme une unité de livraison. Conservez un manifeste immuable contenant :

• la version des convertisseurs applicatifs et celle des données de localisation ;
• le réglage du normalisateur et la langue explicite ;
• les identifiants de dictionnaires ou une empreinte de leur contenu ;
• le modèle, la voix et la configuration de synthèse pertinente ;
• la version du jeu de non-régression et le compte rendu d’approbation.

Créez un dictionnaire candidat plutôt que de modifier l’unique copie en service. La sélection dictionary_ids par requête de KugelAudio permet de cibler un dictionnaire candidat pour des tests ou une version canari, sans toucher au trafic par défaut. Promouvez le jeu testé par configuration, surveillez les erreurs par classe d’entrée et gardez le manifeste précédent prêt à l’emploi. Un retour arrière consiste alors à restaurer des identifiants et des versions connus, non à défaire des entrées à la main sous pression.

Comment tester la normalisation sans masquer les erreurs ?

Constituez un tableau de non-régression synthétique avec la valeur source, le type sémantique, la locale, le fuseau horaire, l’entrée de synthèse attendue, les variantes orales admises, la criticité et le repli. Incluez des zéros, des valeurs négatives, des bornes de plage, des jours bissextiles, des passages à l’heure d’été, des précisions inattendues, des valeurs mal formées et des cas limites Unicode.

Testez par couches :

1. Vérifiez le texte normalisé exact pour les convertisseurs applicatifs déterministes.
2. Générez l’audio avec la version candidate et archivez des échantillons pour les cas critiques.
3. Utilisez la reconnaissance vocale ou l’alignement forcé pour signaler omissions et substitutions, non pour certifier l’accentuation, le découpage ou la prononciation.
4. Faites relire les noms, les attentes régionales, le découpage et l’intelligibilité par des auditeurs natifs, sans leur montrer d’abord la réponse attendue.
5. Exercez l’intégralité du parcours de clarification ou de confirmation pour les données qui déclenchent une action.

Publiez les résultats par classe et par gravité. Un score de précision moyen unique peut masquer une virgule décimale ou une clé de contrôle erronée. Notez le taux de repli, les échecs des convertisseurs exacts, les omissions de contenu et les rejets critiques des auditeurs, ainsi que le manifeste qui les a produits. Le guide de benchmark allemand et dialectal explique pourquoi l’intelligibilité et la qualité jugée par des auditeurs natifs demandent des preuves distinctes.

Que faire lorsque la normalisation est incertaine ?

Ne devinez jamais en silence pour une valeur qui déclenche une action. Rejetez une valeur qui viole son type déclaré, ou empruntez un chemin de récupération approuvé : poser une question précise, employer une forme longue non ambiguë, épeler ou grouper la valeur, l’afficher, l’envoyer sur un canal authentifié, ou transférer à une personne.

L’erreur doit nommer le champ et le contrat violé, sans recopier de secrets dans les journaux. Une lecture plausible mais fausse est plus difficile à détecter qu’un échec explicite.

Quelles sont les limites de ce guide ?

Il s’agit de motifs d’ingénierie, non de règles linguistiques universelles. La prononciation varie selon la langue, la région, le locuteur et la politique de l’organisation. Cet article ne prétend pas à une prise en charge complète de SSML, de tous les dialectes, de noms arbitraires ou de tous les formats structurés. Testez la configuration de production exacte et les entrées qui portent un risque métier.

FAQ

La normalisation du texte équivaut-elle au contrôle de la prononciation ?

Non. La normalisation transforme des structures comme les dates et les montants en mots visés. Le contrôle de la prononciation précise comment certains mots ou contenus phonétiques doivent sonner. Un système de production a souvent besoin des deux.

Quelle différence entre normalisation du texte et normalisation inverse du texte ?

La normalisation directe convertit les formes écrites en texte prononçable pour la synthèse. La normalisation inverse convertit la sortie orale de la reconnaissance vocale en formes écrites. Ce ne sont pas des inverses exactes, car les deux directions comportent des ambiguïtés.

Le modèle de synthèse doit-il décider comment lire chaque nombre ?

Non. Si l’application sait qu’une valeur est un prix, un numéro de téléphone ou un identifiant, elle doit conserver ce type et construire l’entrée de synthèse voulue avant la génération.

Un dictionnaire de prononciation peut-il corriger un IBAN ou un identifiant client ?

Pas comme mécanisme principal. Les dictionnaires conviennent au vocabulaire récurrent ; les identifiants variables exigent une validation, des règles de découpage structurel et une politique de confirmation.

La reconnaissance vocale suffit-elle à valider la prononciation ?

Non. Elle peut signaler des omissions ou des substitutions, mais une transcription correcte ne prouve ni une accentuation juste, ni un bon découpage, ni l’acceptabilité régionale, ni l’intelligibilité.

Comment livrer une modification de dictionnaire ?

Testez une version candidate avec des phrases représentatives et des non-correspondances, puis livrez-la avec le manifeste du normalisateur, du modèle et de la voix. Conservez le jeu de dictionnaires précédent comme cible de retour arrière.

Que doit faire un système face à un texte critique ambigu ?

Renvoyer une erreur de validation explicite ou emprunter un parcours approuvé de clarification et de confirmation. Il ne doit pas choisir en silence une lecture plausible lorsque ce choix peut changer le sens.