Pourquoi les nombres sont le cas difficile
La reconnaissance vocale s’appuie lourdement sur le contexte. Quand un son est ambigu, les mots voisins réduisent les possibilités, et c’est pourquoi une phrase entière ressort juste alors qu’un mot isolé ne ressort pas.
Un nombre n’a pas de contexte. N’importe quel chiffre peut suivre n’importe quel autre, donc rien dans « sept » ne rend « trois » plus ou moins probable ensuite. Le système travaille au son seul, privé de toute l’aide sur laquelle il compte d’habitude.
Les adresses et les codes sont pires encore, parce qu’ils mélangent les catégories. Un code postal est fait de chiffres sans logique linguistique. Une adresse e-mail contient un mot, un symbole, un autre mot et un suffixe, livrés d’un seul souffle. Un numéro de dossier est une suite que quelqu’un a inventée.
Voilà toute l’explication, et une meilleure app n’y changera rien.
Ce qui se passe mal en général
Les chiffres fusionnent ou se séparent. « Deux mille vingt-quatre » ressort en 2024, ou en 2000 24, ou en toutes lettres, selon le système et le rythme.
Les nombres composés du français. « Soixante-dix-huit », « quatre-vingt-un » et « quatre-vingt-dix-sept » sont de longues chaînes où une syllabe perdue change le nombre entier. Et si tu dis « septante » ou « nonante », un modèle entraîné surtout sur le français de France peut buter, alors que ces formes sont parfaitement correctes en Belgique et en Suisse.
Le format est inventé. Les numéros de téléphone se regroupent tout seuls, les dates se réordonnent, et le séparateur décimal tombe autrement selon la langue que le modèle a cru entendre.
Les symboles deviennent des mots. L’arobase, le point, le tiret, la barre oblique. On les dit avec des mots, et aucun système ne peut savoir de façon fiable si tu voulais le symbole ou le mot.
Les lettres deviennent leurs sosies. Dans un code ou une référence, les lettres dites à voix haute sont un cauchemar. B, C, D, G, P, T et V riment toutes en français, M et N se ressemblent, et un modèle sans contexte en choisit une.
La règle pratique
Dicte la phrase, tape la suite de caractères.
Ça a l’air d’une défaite et c’est simplement la bonne répartition du travail. Un message qui dit « la référence est » prend deux secondes à dicter. La référence elle-même prend trois secondes à taper et ne produit aucune erreur.
Essayer de tout dicter puis de corriger prend plus longtemps que de taper la suite d’emblée, à chaque fois. La plupart des gens qui dictent depuis un moment convergent vers cette règle en une semaine.
Quand tu veux quand même les dire
Parfois taper n’est pas possible : mains prises, marche en cours, ou une suite assez courte pour ne pas valoir un changement. Quelques techniques aident.
Dis les chiffres un par un, avec un temps entre eux. « Zéro, six, un, deux » plutôt que « zéro six douze ». C’est du groupement que viennent les fusions.
Prends de l’élan. Deux mots ordinaires avant le nombre donnent au système de quoi se caler. « Le numéro est », puis les chiffres, plutôt qu’un démarrage à froid sur un chiffre.
Dis de petits groupes et fais une pause. Un numéro de téléphone en trois morceaux séparés par des pauses est bien plus fiable qu’un flot continu.
Emploie l’alphabet phonétique pour les lettres. Alpha, Bravo, Charlie ne produiront pas des lettres seules, mais ils produisent des mots que tu convertis ensuite de façon sûre à la main, ce qui vaut mieux qu’une lettre fausse que tu n’as pas vue.
Dis les petits nombres en toutes lettres et les grands en chiffres. « Trois » est sans ambiguïté. « Trois mille sept cent douze » est une loterie.
Dates, heures et montants
Chacun a son piège.
Les dates se réordonnent selon les conventions de la langue que le système a cru entendre. C’est un risque réel dans tout contexte bilingue, où les mêmes trois nombres désignent deux jours différents selon la convention. Dis le mois en toutes lettres plutôt qu’en chiffre et l’ambiguïté disparaît entièrement.
Les heures passent d’ordinaire très bien dites naturellement, mais les formes sur douze et sur vingt-quatre heures se mélangent, et « huit heures et demie » ne lève pas le doute entre le matin et le soir.
Les montants souffrent du séparateur décimal. Certaines langues mettent une virgule là où d’autres mettent un point, et le modèle applique la convention de la langue qu’il a entendue. Pour tout ce où le montant compte, tape-le.
Les adresses e-mail, tape-les
C’est la recommandation la plus ferme de toutes.
Une adresse e-mail contient au moins un symbole à déduire d’un mot parlé, en général un nom propre que le système n’a jamais rencontré, et un suffixe qui sonne comme un mot ordinaire. Chaque partie est un mode de panne, et contrairement à une phrase il n’y a aucune redondance : un caractère faux et le message ne part nulle part.
La même chose vaut pour les identifiants, les adresses de sites, les IBAN, les plaques d’immatriculation et tout ce où un seul caractère erroné invalide la suite entière.
Ce qu’on peut quand même ajouter au dictionnaire
Une partie se règle d’avance.
Les noms propres qui reviennent dans les adresses, ta rue, ta commune, le nom du lotissement, sont des mots que le modèle peut apprendre. Les ajouter fait que les mots autour des nombres arrivent corrects, même quand les nombres eux-mêmes demandent de l’attention. LocalType garde ces ajouts sur le téléphone et les transmet au système comme connaissance de fond pendant qu’il travaille.
Les nombres eux-mêmes ne s’apprennent pas ainsi, parce que le problème n’est pas le vocabulaire. Le système connaît parfaitement chaque chiffre ; il n’a simplement aucun moyen de choisir entre eux.
Vérifie avant d’envoyer
Cette seule habitude empêche les erreurs vraiment coûteuses.
Un mot mal entendu dans une phrase saute d’ordinaire aux yeux du lecteur. Un chiffre mal entendu, non, parce qu’un mauvais nombre a l’air exactement aussi plausible qu’un bon. Personne ne relit un numéro de téléphone en le lisant, donc lis-le exprès, ou relis-le à voix haute, ce qui attrape des erreurs qu’un survol laisse passer.
Pour tout ce qui touche à l’argent, au droit ou à la santé, traite un nombre dicté comme non vérifié tant que tu ne l’as pas confronté à la source. Ce n’est pas une critique de la dictée. C’est la règle que tu appliquerais à des nombres tapés en étant fatigué.
La taille du modèle est le levier
Les mêmes limites valent pour LocalType que pour n’importe quoi d’autre, parce qu’elles viennent de la nature du problème et non de la réalisation. Les nombres n’ont pas de contexte, et aucun modèle sur aucun matériel n’invente un contexte qui n’existait pas.
Ce qui aide, c’est la taille du modèle. Les trois options, à 60, 190 et 539 Mo, diffèrent par leur tenue face à un audio ambigu, et les chiffres sont la définition même d’un audio ambigu. Si les nombres comptent dans ton travail, la plus grande mérite la place qu’elle prend. Comme point de repère, l’option intermédiaire de 190 Mo a écrit 6,9 secondes de parole en 4,1 secondes sur le téléphone à 4 Go qui sert aux tests.
Tout le reste ne change pas : reconnaissance sur l’appareil à partir d’un fichier qu’aucune autre app ne peut ouvrir, réseau sollicité une fois pour récupérer le modèle, aucun compte, aucune publicité, rien qui note ton usage, aucun audio conservé, sauvegardes volontairement sautées, et aucune touche micro proposée au-dessus d’un champ de mot de passe. Ce dernier point est pertinent ici, puisque les codes et les numéros sont précisément ce que les gens dictent dans des champs où ils ne devraient pas.
Si tu ne retiens qu’une chose, retiens la répartition du travail. Dis les mots, tape les suites de caractères, et vérifie les chiffres avant d’envoyer. La dictée n’est pas moins bonne que la frappe sur tout, et c’est la seule catégorie où elle l’est manifestement.