Pourquoi une transcription exportée affiche des caractères bizarres sur iPhone ?

C'est un type de panne précis et déroutant : la transcription a l'air parfaitement normale dans l'app, s'exporte sans la moindre erreur, puis un nom en ukrainien ou un mot en hébreu ressort de l'autre côté sous forme d'une série de points d'interrogation ou de carrés vides dès qu'on ouvre le fichier ailleurs — un PC sous Windows, un vieux programme, l'import dans un tableur. Rien de tout cela ne ressemble à une coquille ou à une erreur de reconnaissance vocale. On dirait que le fichier s'est cassé en cours de route, ce qui est un soupçon raisonnable et presque jamais ce qui s'est réellement passé.

Ce qu'est vraiment un fichier texte, en dessous

Un fichier texte brut ne porte aucune étiquette interne indiquant quel alphabet ses octets sont censés représenter. Ce n'est qu'une suite d'octets, et chaque programme qui l'ouvre doit poser une hypothèse sur la correspondance entre ces octets et les lettres et symboles qu'il vous affiche — un encodage de caractères. Si l'hypothèse est la bonne, le fichier se lit exactement comme il a été écrit. Si elle est fausse, le programme n'invente rien : il affiche fidèlement le mauvais caractère pour chaque octet où son hypothèse et l'encodage réel du fichier ne concordent pas.

Presque tout ce qui est écrit pour iPhone, Mac, Android ou le web moderne pose la même hypothèse : UTF-8, un encodage unique capable de représenter toutes les écritures qu'un iPhone peut transcrire — l'hébreu, le cyrillique de l'ukrainien et du russe, les caractères chinois, les kana et kanji japonais, le hangeul coréen, et chaque lettre accentuée du français, de l'espagnol ou du portugais. C'est ce qui se rapproche le plus, aujourd'hui, d'un standard universel pour le texte, ce qui explique à la fois pourquoi ce problème est devenu bien plus rare qu'avant, et pourquoi il surprend encore les quelques fois où il survient.

Pourquoi seuls certains mots sont touchés

L'indice qui distingue un décalage d'encodage d'une erreur de transcription, c'est de voir quels caractères survivent. Les lettres ordinaires, les chiffres et la ponctuation courante sont représentés de la même façon en UTF-8 et dans presque tous les anciens encodages encore utilisés — cette coïncidence est délibérée, elle remonte à des décennies, et c'est pour ça qu'une phrase en français sans accent traverse presque n'importe quel programme mal réglé sans dommage. Ce sont précisément les caractères sur lesquels ces encodages ne s'accordent pas — un é ou un ñ accentué, et toute écriture non latine — qui ressortent en point d'interrogation, en carré ou en une courte série de symboles sans rapport. Si toute la transcription est illisible d'un bout à l'autre, le problème vient d'ailleurs ; si seuls les accents et les mots en alphabet non latin sont touchés pendant que le reste se lit bien, ce schéma est précisément la signature d'un décalage d'encodage.

C'est aussi ce qui permet de distinguer ce cas d'une simple erreur du logiciel de reconnaissance sur un mot. Un mot mal transcrit reste un vrai mot plausible — le logiciel a entendu quelque chose et écrit sa meilleure supposition, fausse mais cohérente. Un caractère corrompu n'est pas une supposition du tout : il n'a aucun rapport avec ce qui a été dit, il ressort exactement de la même façon abîmée à chaque fois que cette suite d'octets revient, et c'est une propriété de ce qui affiche le fichier, pas de ce que l'app y a réellement écrit.

Où cela arrive encore, maintenant que l'UTF-8 est le standard presque partout

Les apps modernes à usage général déclenchent rarement ce problème en se contentant d'ouvrir un fichier texte — Notes, Mail, Messages, un navigateur ou un traitement de texte sur un téléphone ou un ordinateur récent lisent l'UTF-8 correctement sans que vous ayez rien à faire. Là où une mauvaise hypothèse se voit encore, c'est plutôt à l'entrée d'un outil plus spécialisé : la boîte de dialogue « importer un fichier texte » d'un tableur, qui propose un choix d'encodage mais retient par défaut un encodage régional plutôt que l'UTF-8, ou un vieux script ou programme conçu en supposant un encodage à un seul octet, réservé à l'alphabet latin, parce que celui qui l'a écrit ne s'attendait jamais à autre chose en entrée. La transcription elle-même n'y est pour rien dans les deux cas — le décalage se produit précisément à la porte par laquelle elle est passée.

Corriger la seule copie concernée

La transcription d'origine, toujours dans l'app qui l'a produite, n'est touchée par rien de tout cela — seule cette copie exportée, lue par ce programme qui s'est trompé d'hypothèse, s'affiche mal. Cela indique directement la solution : rouvrir le fichier et indiquer explicitement au programme quel encodage utiliser, quand cette option existe. Un éditeur de texte doté d'une commande « rouvrir avec cet encodage », ou l'assistant d'import d'un tableur avec un menu déroulant d'encodage, permettent tous deux de choisir l'UTF-8 directement plutôt que d'accepter ce que le programme a deviné par défaut. Si l'outil ne propose aucune option de ce genre, ré-exporter depuis la source et coller le texte directement dans la destination, plutôt que d'ouvrir le fichier enregistré, contourne entièrement le problème — un copier-coller transporte les caractères réels, sans aucune hypothèse de lecture de fichier entre les deux.

Comment Voice Studio gère cela

L'export TXT comme l'export JSON écrivent du texte brut en UTF-8, le même encodage que presque tous les outils actuels sur iOS, Mac, Android ou le web supposent déjà à l'ouverture d'un fichier — une transcription en hébreu, en ukrainien, en chinois, en japonais, en coréen ou en français ou espagnol accentué s'ouvre correctement dans la grande majorité des endroits où elle est susceptible d'atterrir. Si une destination précise affiche encore les mauvais caractères, c'est un fait qui concerne ce qui lit le fichier à cet endroit, pas ce qui y a été écrit — indiquer à ce programme de lire le fichier en UTF-8, là où il vous laisse le choix, est ce qui règle vraiment le problème. Rien dans ce raté d'affichage à l'ouverture n'affecte la transcription restée dans l'app, qui demeure exactement telle qu'elle a été transcrite.

Questions fréquentes

Est-ce que cela veut dire que la transcription s'est trompée sur le mot ?

Non. Un mot mal transcrit reste un vrai mot, juste le mauvais. Les caractères corrompus — points d'interrogation, carrés ou symboles sans rapport — viennent d'un programme qui lit le fichier avec le mauvais encodage, un problème totalement différent d'une erreur d'écoute du logiciel de reconnaissance.

Pourquoi seules certaines lettres se transforment-elles en symboles et pas toute la transcription ?

Les lettres ordinaires, les chiffres et la ponctuation courante sont représentés de la même façon en UTF-8 et dans presque tous les anciens encodages, donc ils se lisent correctement quelle que soit l'hypothèse d'un programme. Ce sont précisément les lettres accentuées et les écritures non latines — là où les encodages divergent — qui ressortent mal.

Ma transcription est-elle abîmée si je vois cela ?

Non. La transcription dans l'app n'est pas affectée — cela arrive à une copie exportée précise, dans le programme qui l'a ouverte avec la mauvaise hypothèse. La ré-exporter, ou rouvrir cette copie en réglant l'encodage sur UTF-8, corrige le problème.

Comment corriger une transcription qui affiche déjà des caractères corrompus ?

Rouvrez-la dans un programme qui permet de choisir l'encodage explicitement et choisissez UTF-8, si cette option existe. Si elle n'existe pas, ré-exportez la transcription depuis l'app et collez le texte directement dans la destination plutôt que d'ouvrir le fichier enregistré.