Ressources numériques en sciences humaines et sociales OpenEdition Nos plateformes OpenEdition Books OpenEdition Journals Hypothèses Calenda Bibliothèques OpenEdition Freemium Suivez-nous

TransliTAL #2 : la translittération des alphabets consonantiques

Le projet TransliTAL, qui a pour objectif de produire des outils de translittération pour différents systèmes d’écriture, a choisi de focaliser ses efforts sur le script arabe pendant sa deuxième phase. La langue arabe seule compte 25 000 documents à la BULAC, et son script est également utilisé par plusieurs autres langues majeures comme le farsi et l’ourdou. Au total, les documents écrits en script arabe représentent 50 000 documents. 


Dans le billet précédent, nous avons examiné les enjeux de la translittération des textes écrits en alphabet cyrillique vers notre alphabet latin. Nous avons vu que ces deux systèmes d’écriture fonctionnent de façon similaire, et que la plupart des translittérations peuvent donc s’effectuer en remplaçant chaque caractère par son homologue de l’alphabet cible. Ironiquement, un des challenges principaux venait justement de la proximité visuelle entre les deux scripts, qui fait que certaines lettres sont identiques en apparence même si les sons qu’elles représentent ne sont pas les mêmes. En conséquence, certains chiffres romains comme XX pouvaient être translittérés comme HH si le catalogueur n’avait pas utilisé le bon encodage des caractères.

Si la translittération de l’alphabet cyrillique peut se faire par des moyens relativement simples, c’est parce que ces deux systèmes d’écriture ont une similarité fondamentale : ils représentent les voyelles avec des lettres dédiées. Mais ces systèmes alphabétiques sont une évolution d’une forme encore plus ancienne d’écriture phonétique dans laquelle  les consonnes seules sont représentées de manière systématique. Cette conception de l’écriture, connue sous le nom d’alphabet consonantique ou abjad, occupe toujours une place importante dans trois langues du Proche-Orient : l’arabe, l’hébreu et l’araméen, peut-être mieux connu sous le nom de sa variété syriaque. Ces trois langues sont toutes issues de la famille sémitique, et sont écrites avec des alphabets consonantiques visuellement distincts mais fonctionnellement similaires.

Notice bibliographique d’un livre en persan contenant la particule -i

D’un point de vue informatique, la romanisation des alphabets consonantiques est particulièrement complexe. À la différence de la translittération du cyrillique, pour laquelle il suffit de faire une table de correspondance entre chaque lettre cyrillique et son homologue latin pour arriver à une translittération parfaite, les alphabets consonantiques ne révèlent qu’une partie des informations nécessaires pour arriver à la bonne romanisation. Pour bien translittérer un mot arabe, il faut non seulement transformer chaque consonne écrite en lettre latine correspondante, mais également identifier les bonnes voyelles et les situer correctement parmi les consonnes. Malgré les régularités évoquées précédemment qui facilitent la lecture, une certaine connaissance de la langue et du contexte du mot est nécessaire pour réussir la vocalisation. Et même là, un certain niveau d’ambiguïté demeure. 

Prenons l’exemple des trois lettres ملك . Pendant la romanisation, on peut théoriquement translittérer ce mot comme malaka ‘il a régné’, malik ‘roi’, malak ‘ange’, mulk ‘règne’, ou mallaka ‘il a cédé’ (comme pour les voyelles, les consonnes géminées ne sont pas forcément spécifiées en script arabe). Pour le catalogueur humain, il y a plusieurs indices grammaticaux, contextuels, ou même culturels qui permettent d’arriver à la bonne translittération. Par exemple, est-ce que le mot semble être utilisé comme un verbe, et quelles sont les combinaisons de voyelles qui sont permises dans un verbe arabe ? Si le mot se trouve dans un contexte qui indique un substantif, s’agit-il d’un objet inanimé (un règne) ou d’un être animé (un roi ou un ange). Et si c’est un être animé, est-ce que le texte traite d’un sujet historique ou religieux ? Attention cependant : malik et malak sont aussi utilisés comme prénoms, respectivement masculin et féminin. Si le mot est utilisé ainsi, connaître le genre de la personne en question peut également aider. Dans ce cas, on peut exploiter des indices grammaticaux comme les adjectifs, qui s’accordent comme en français avec les noms féminins. Et si tout cela ne suffit pas, il reste les connaissances culturelles. Par exemple, un lecteur français peut probablement exploiter ses connaissances du monde pour bien vocaliser les noms de certaines personnes célèbres comme jn djrdn, jnn drc et jn brkn1.

La problématique se complexifie encore lorsqu’on élargit notre champ d’étude à d’autres langues qui utilisent le script arabe. Le farsi, une variété du persan parlée en Iran, ne partage ni le même inventaire de voyelles que l’arabe, ni le même système de racines consonantiques. Il a également d’autres particularités grammaticales qui doivent être prises en compte dans un système de translittération. Dans cette langue, la particule -i est utilisée pour marquer des relations de possession, d’association, ou de modification dans des constructions comme duẖtar-i maryam ‘la fille de Maryam’. Mais cette particularité n’est pas représentée orthographiquement. Translittérer correctement le texte دختر مریم implique non seulement d’identifier la bonne prononciation des deux mots, mais également de comprendre la relation grammaticale entre eux. Un système de translittération développé pour l’arabe ne peut donc pas être appliqué au farsi de la même manière que nous l’avons fait pour les langues écrites en lettres cyrilliques.

Si le persan et l’arabe posent des problématiques complexes, le turc ottoman est de loin le grand vizir des voyelles ambiguës. Comme l’ouzbek, le kazakh, le tatar, et d’autres langues turciques, le turc était écrit en script arabe jusqu’aux années 1920. Le choix d’adopter l’alphabet latin (et plus tard le cyrillique en URSS) a été partiellement identitaire, ce script étant perçu comme plus représentatif des courants laïques des nouvelles républiques turque et soviétiques. Il y avait également un intérêt pratique, car les variantes du script arabe utilisées pour ces langues étaient perçues comme particulièrement difficiles à apprendre. Les langues turciques sont notamment riches en sons vocaliques, raison pour laquelle le turc moderne utilise des points au dessus des lettres pour distinguer a, e, ı, i, o, ö, u et ü. Mais la variante ottomane de l’alphabet arabe n’a pas été adaptée pour prendre en compte ces distinctions, introduisant ainsi encore plus d’ambiguïté qu’en langue arabe. À titre d’exemple, la lettre و en arabe représente deux sons distincts : soit la voyelle longue /ū/ soit la consonne /w/. En turc ottoman, les fonctions de cette seule lettre ont été élargies pour couvrir l’ensemble des sons v, o, ö, u et ü. Et parfois, ces sons étaient tout simplement exclus de l’écrit.

Communication industrialiste ouzbek (1920) et magazine turc (1921) publiés avant la romanisation (Wikimedia Commons)

 

Vers un système de translittération automatique

L’arabe, le farsi, et le turc ottoman présentent chacun des particularités qui rendent ces trois langues impossibles à traiter à l’aide d’un outil générique. La solution dans un tel cas est de concevoir un outil de translittération différent pour chaque langue. Cependant, les règles qui déterminent la bonne vocalisation sont tellement complexes qu’il serait difficile voire impossible de les définir manuellement dans le cadre de ce projet. 

Heureusement, nous avons accès à une méthode informatique qui est particulièrement adaptée à des situations où les règles ne peuvent pas être définies facilement. L’apprentissage profond, une technique rendue possible par les avancées récentes en puissance de calcul, permet à un informaticien d’extraire automatiquement les règles nécessaires à l’accomplissement d’une tâche donnée. Le rôle de l’ingénieur est de fournir des milliers d’exemples et de bonnes réponses pour une tâche donnée, et de laisser à l’ordinateur la responsabilité de trouver les règles qui permettent d’arriver aux bonnes réponses à partir des exemples. On appelle ces informations les données d’entraînement, car elles permettent au système de s’entraîner en apprenant les règles. Une fois que le système est suffisamment performant, les règles peuvent être sauvegardées sous forme de modèle. Celui-ci peut être appliqué à de futurs exemples, un processus bien moins coûteux sur le plan informatique que la phase d’entraînement initial. 

L’apprentissage profond a eu un impact important sur diverses tâches informatiques complexes comme la reconnaissance faciale, la génération de voix synthétisées, et la traduction automatique. Dans le domaine du traitement du langage, la traduction automatique peut être décrite plus généralement comme une tâche text-to-text : un système informatique prend en entrée un texte, et génère en sortie un autre. Un modèle de traduction français-anglais sera entraîné sur un grand nombre d’exemples de traductions dans les deux langues.

Revenons alors à la translittération d’une langue comme l’arabe. D’un point de vue conceptuel, cette tâche n’est pas si différente de la traduction. Après tout, il s’agit de prendre un texte et d’appliquer une série de règles pour générer un autre texte. Si un bon modèle de traduction est capable de transformer un mot ambigu comme avocat en avocado ou lawyer selon son contexte, alors un bon modèle de translittération devrait être capable de transformer ملك <mlk> en malak ou malik selon son contexte, voyelles manquantes comprises.

Cependant, pour la plupart des systèmes text-to-text, la machine ne voit pas comme nous des séquences de caractères, mais des séquences d’objets qu’on appelle des tokens. Un token peut être défini comme une chaîne de caractères délimitée par des éléments comme des espaces ou des marques de ponctuation. En termes simples, ce sont des mots tels qu’ils sont affichés sur l’écran. Mais contrairement à nous, le système n’est pas conscient des caractères à l’intérieur de chaque token, ni des similitudes entre eux. Les termes tokens Token, token, tokens, et TOKEN seraient donc interprétés non pas comme des variantes du même mot mais comme quatre éléments aussi différents que fève, poisson et sentimentalité. Justement, une tâche importante dans le domaine du traitement automatique des langues est de trouver la meilleure façon de lier ces différentes formes pour mieux traiter un texte. La discrétisation des textes en tokens peut poser des problèmes si, par exemple, on essaie de traduire un texte contenant un mot que le modèle n’a jamais vu dans ses données d’entraînement. Ou bien, si le texte contient une faute de frappe qui entraîne l’interprétation d’un nom commun comme un mot entièrement inconnu. Après tout, il serait bien dommage d’avoir un système de traduction capable de traduire le mot état, mais qui génère un point d’interrogation dès qu’il rencontre une variante comme État

De notre point de vue, une approche basée sur les tokens n’est pas forcément la plus adaptée aux besoins du projet TransliTAL. Premièrement, cette stratégie rend difficile l’entraînement d’un bon modèle dans un contexte où il manque suffisamment de données d’entraînement pour couvrir toutes les formes possibles de chaque mot. Ceci est un vrai problème pour des langues comme le pachto ou le turc ottoman, pour lesquelles nous avons relativement peu de notices dans notre catalogue. Cela signifie que les données d’entraînement qui nous sont accessibles ne contiennent pas forcément tous les mots qu’un système de translittération pourrait rencontrer à l’avenir. Nous ne serions donc pas capables de bien translittérer un nouveau mot dans le titre d’un futur livre acquis par la BULAC. De plus, les sous-composants de chaque mot – les lettres arabes – encodent tout de même des informations utiles pour générer une translittération, même si celles-ci sont incomplètes. Il serait donc dommage de se baser sur une approche qui ne tient pas compte de ces informations précieuses. 

Pour ces raisons, nous avons fait le choix de baser nos travaux sur le modèle ByT5, développé en 2022 par un groupe de recherche chez Google. Comme d’autres modèles de langue, ByT5 encode un réseau complexe de relations statistiques entre des éléments de langage et leurs contextes. Ces modèles peuvent servir de base pour entraîner des modèles spécialisés capables de traduire, reformuler, ou même d’analyser les émotions exprimées dans des textes (en supposant que les données d’entraînement soient suffisamment nombreuses). À la différence des autres modèles, ByT5 ne travaille pas au niveau du token, mais au niveau du caractère (ou, pour être encore plus précis, au niveau des octets, les groupes de 1 et de 0 qui encodent les caractères). Cela signifie que ce modèle est capable d’exploiter les informations fournies par chaque consonne pendant la translittération des textes, et d’exploiter les règles apprises à de nouvelles combinaisons de ces mêmes consonnes. ByT5 peut donc appliquer les règles de translittération qu’il a apprises sur un mot comme ملك <mlk> à un nouveau mot كلم <klm> même s’il ne l’a jamais rencontré dans ses données d’entraînement.

Le dernier ingrédient dont nous avons besoin pour un modèle de translittération fonctionnel est une grande collection d’exemples de textes et de bonnes translittérations pour préparer nos données d’entraînement. Heureusement, le catalogue de la BULAC devrait nous fournir tout ce dont nous avons besoin à cet égard, surtout pour des langues bien représentées comme l’arabe et le farsi. Les langues ayant moins de documents dans notre catalogue sont un plus grand défi, mais nous verrons dans le prochain billet qu’il existe d’autres approches informatiques qui permettent d’atteindre de bons résultats même avec peu de données d’entraînement. Nous verrons également que le modèle ByT5 présente un autre avantage : il est parfaitement compatible avec des systèmes d’écriture encore plus complexes comme ceux du chinois et du japonais. Enfin, nous examinerons de plus près les problématiques autour de l’entraînement de nos modèles de translittération, et leurs résultats sur différents systèmes d’écriture.

Agenda
Emmett Strickland interviendra lors de la conférence CORIA-TALN 2025, organisée par l’université d’Aix-Marseille et les UMR CNRS LIS et LPL, sous l’égide de l’Association francophone de recherche d’information et applications (ARIA) et l’Association pour le Traitement automatique des langues (ATALA), du 30 juin au 4 juillet 2025 à Marseille.

À paraître
Emmett Strickland, Ilaine Wang, Damien Nouvel, Bénédicte Parvaz-Ahmad, 2025, « Systèmes d’écriture et qualité des données : l’affinage de modèles de translittération dans un contexte de faibles ressources », Actes de la 32ème Conférence sur le Traitement Automatique des Langues Naturelles, Marseille, France.
  1. Jean Dujardin, Jeanne d’Arc, Jane Birkin []
Emmett Strickland
Emmett Strickland

OpenEdition vous propose de citer ce billet de la manière suivante :
Emmett Strickland (20 mai 2025). TransliTAL #2 : la translittération des alphabets consonantiques. Le Carreau de la BULAC. Consulté le 21 mai 2026 à l’adresse https://doi.org/10.58079/13yjb


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

This site uses Akismet to reduce spam. Learn how your comment data is processed.