Synthèse vocale française : lire du code et des extraits techniques
getUserById, max_retries, config.json, npm install, v1.2.3 : un blog technique est plein de chaînes que personne ne prononce comme elles s'écrivent. Ce qu'une voix de synthèse en fait, ce qu'il faut lui épargner, et comment marquer le code pour qu'il se lise juste.
Un article de fond en informatique mêle deux langues dans le même paragraphe : le français, fait pour être lu à voix haute, et le code, qui ne l'est pas. « Ouvrez le fichier config.json et passez max_retries à 3 » se lit sans peine par un humain, parce qu'il sait qu'on ne prononce pas « config point j s o n » comme un mot. Une voix de synthèse, elle, n'a pas ce réflexe : elle rencontre une suite de caractères et tente quelque chose. Parfois elle épelle, parfois elle invente une prononciation, parfois elle avale la moitié. Le résultat est un audio qui trébuche à chaque terme technique, et c'est exactement là qu'un lecteur expert décroche.
Le tableau des formes qui piègent
| Forme écrite | Lecture raisonnable | Erreur fréquente |
|---|---|---|
| config.json | config point jason | « config point j s o n », « config jissonne » |
| getUserById | get user by id | « gé-tu-zeur-baï-dé » lu d'un bloc |
| max_retries | max retries | « max souligné retries », « max tiret bas retries » |
| /usr/local/bin | slash u s r slash local slash bin | « eusseur local bine » collé |
| MAX_SIZE | max size | « m a x souligné s i z e » |
| npm install | npm install | « n p m » épelé puis « install » francisé |
| v1.2.3 | version un point deux point trois | « vé un virgule deux virgule trois » |
| .env | point env | « point e n v » épelé |
| a === b | a triple égal b | « a égal égal égal b » |
| () => {} | fonction fléchée | lecture caractère par caractère du symbole |
La colonne du milieu n'est pas une norme officielle : c'est ce qu'un développeur dit spontanément en lisant son code à un collègue. Une voix qui s'en approche reste écoutable ; une voix qui épelle tout transforme un tutoriel en suite de lettres.
Pourquoi une machine s'y perd
Une voix neuronale prédit la prononciation à partir de ce qu'elle a vu à l'entraînement, et elle a surtout vu de la langue naturelle. Face à « getUserById », elle n'a aucun modèle du camelCase : elle voit un mot inconnu et tente une prononciation globale, souvent avec un accent anglais approximatif. Le tiret bas de « max_retries » n'existe pas à l'oral, donc soit elle le nomme (« souligné »), soit elle colle les deux mots. Le point de « config.json » est tantôt une fin de phrase, tantôt un séparateur d'extension : rien dans le caractère ne tranche.
C'est le même problème que pour les adresses web et les courriels, et il relève de la même idée, celle de la page text to speech français : ce qui compte se joue avant le son, dans la reconnaissance et la réécriture du texte pour la voix. Le code est le cas extrême, parce qu'il n'a presque aucun sens à l'oral : le lire caractère par caractère est fidèle et inutilisable à la fois.
Ce que WeDispatch en fait, sans surpromesse
Le parti pris est simple et il s'assume : un lecteur audio d'article est fait pour lire de la prose, pas pour réciter un dépôt de code. Un bloc de code entier n'a pas vocation à être lu à voix haute, et le forcer produirait un audio que personne n'écoute jusqu'au bout. La bonne pratique est donc de traiter le code comme du code, à part de la phrase qui le commente, exactement comme on traite le bruit typographique qui ne se lit pas.
Pour les termes techniques courts qui reviennent dans votre prose (un nom de produit, une commande, une extension que vous citez sans cesse), le lexique de prononciation vous laisse fixer une fois pour toutes la lecture attendue : déclarez que « .env » se dit « point env » et non « point e n v », et le réglage tient sur tous vos articles, sans rien régénérer. C'est le levier honnête : il ne prétend pas deviner le code, il vous laisse décider pour les cas qui comptent chez vous.
Le geste de rédaction qui règle presque tout
Écrivez pour l'oreille dans la phrase, et gardez le littéral pour les blocs. Plutôt que « passez max_retries à 3 » dans une phrase censée être écoutée, préférez « augmentez le nombre de tentatives, le paramètre max_retries, à trois », en donnant le sens avant le jeton. Le lecteur pressé entend l'idée, le lecteur technique retrouve le terme exact à l'écran. Et quand un passage est fait pour être copié, pas écouté (une commande complète, un extrait de configuration), il gagne à vivre dans un vrai bloc de code : l'œil le repère, et l'audio n'essaie pas de le dire. Une relecture à l'oreille avant de publier vous dira en une minute quels termes trébuchent chez vous, et lesquels valent une entrée de lexique.
Sonorisez vos articles avec WeDispatch
Ce blog sera lui-même sonorisé par WeDispatch. Envie de voir ce que ça donne sur vos contenus ?
Demandez une démo