Trois présupposés, trois milliards de personnes
L’alphabet latin présuppose une lecture horizontale, de gauche à droite, avec des espaces entre les mots.
Trois présupposés. Trois milliards de personnes pour qui aucun d’entre eux ne tient.
Le premier présupposé : la direction
L’arabe se lit de droite à gauche. L’hébreu se lit de droite à gauche. L’ourdou se lit de droite à gauche. Le persan se lit de droite à gauche. Ce ne sont pas des scripts minoritaires. L’arabe seul est le système d’écriture de plus de 370 millions de locuteurs natifs et le script liturgique de 1,8 milliard de musulmans. L’hébreu sert 9 millions de locuteurs natifs. L’ourdou sert 230 millions.
Droite-à-gauche n’est pas un cas particulier. Gauche-à-droite n’est pas le défaut. Les deux sont des conventions — des accidents historiques d’angle de pinceau, de position de roseau et d’ergonomie scribale qui se sont solidifiés en normes au fil des millénaires. Ni l’un ni l’autre n’est plus naturel. L’un domine l’industrie technologique. Cette dominance n’est pas méritée. Elle est héritée.
Chaque interface IA construite sur le présupposé de la lecture gauche-à-droite — chaque fenêtre de chat, chaque champ de saisie, chaque panneau de réponse — est construite sur le premier présupposé. Le présupposé est encodé au niveau CSS, au niveau du moteur de mise en page, au niveau du mode d’interaction. « direction: ltr » est une seule ligne de code. C’est aussi une déclaration culturelle : cette interface a été construite par des personnes qui lisent de gauche à droite, pour des personnes qui lisent de gauche à droite.
Le coût d’ingénierie du support bidirectionnel n’est pas nul. Mais le coût d’ingénierie de l’exclusion de plus de 600 millions de locuteurs natifs de scripts droite-à-gauche est plus élevé — si on les prend en compte. La plupart des interfaces ne le font pas.
Le deuxième présupposé : la continuité
Les caractères latins sont discrets. Chaque lettre occupe son propre espace. La forme d’un « a » ne change pas en fonction de la lettre à côté. Cette discrétion est le fondement architectural de la typographie numérique : tables de glyphes fixes, paires de crénage prévisibles, positionnement du curseur direct.
Le script arabe ne fonctionne pas ainsi. Les caractères arabes sont connectés — chaque lettre se joint à ses voisines dans un flux continu, comme une écriture cursive qui ne lève jamais le stylo. La forme d’un caractère change en fonction de sa position dans le mot : initiale, médiane, finale ou isolée. La lettre « ba » (ب) a quatre formes distinctes selon l’endroit où elle apparaît dans le mot. Ce n’est pas une exception. C’est la règle. Chaque lettre de l’alphabet arabe a des formes multiples.
Le devanagari — le script utilisé pour le hindi, le sanskrit, le marathi, le népalais et des dizaines d’autres langues servant plus de 600 millions de personnes — a une logique structurelle entièrement différente. Les caractères pendent d’une ligne horizontale supérieure appelée shirorekha. La ligne relie les caractères au sein d’un mot, créant une continuité visuelle qui n’est ni la discrétion du latin ni la connexion cursive de l’arabe. C’est un troisième modèle.
L’implication pour les interfaces IA : le rendu du texte, le positionnement du curseur, la sélection de texte, le retour à la ligne et la césure se comportent tous différemment dans chaque système de script. Un chatbot IA qui rend le texte arabe en utilisant la logique de rendu de texte latin produit un texte techniquement lisible mais visuellement faux — des formes de lettres qui ne se connectent pas correctement, des limites de mots qui coupent aux mauvaises positions, un comportement de curseur qui déroute l’utilisateur.
L’utilisateur ne voit pas « un bug de rendu ». L’utilisateur voit une interface qui ne comprend pas sa langue. La confiance se perd non au niveau sémantique mais au niveau typographique — avant qu’un seul mot de la réponse de l’IA n’ait été lu.
Le troisième présupposé : la séparation
L’anglais sépare les mots par des espaces. L’allemand sépare les mots par des espaces (sauf quand il crée des mots composés, qui ne sont alors pas séparés — « Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz » est un seul mot). Le chinois n’utilise pas d’espaces entre les mots. Le japonais n’utilise pas d’espaces entre les mots. Le thaï n’utilise pas d’espaces entre les mots.
En chinois, japonais et coréen (CJC), chaque caractère occupe une cellule à largeur fixe. Les caractères sont espacés régulièrement non par les limites de mots mais par les limites de caractères. La segmentation des mots — savoir où un mot finit et un autre commence — est une tâche accomplie par le lecteur, pas par la typographie. Le texte ne fournit aucun signal explicite.
Pour les systèmes d’IA qui traitent du texte CJC, la segmentation des mots est une tâche computationnelle non triviale. La même séquence de caractères chinois peut être segmentée en différents mots selon le contexte. La phrase « 下雨天留客天留我不留 » peut être lue soit comme une invitation à rester soit comme une demande de partir, selon l’endroit où les limites de mots sont placées. L’ambiguïté est résolue par le contexte, pas par la typographie.
Quand un chatbot IA répond en chinois, la réponse doit être rendue en cellules de caractères à largeur fixe avec un espacement CJC approprié. Quand la même interface gère aussi du texte latin — dans un déploiement multilingue, par exemple — les deux systèmes d’espacement doivent coexister. Les caractères CJC en pleine largeur. Les caractères latins en largeur proportionnelle. Des règles de ponctuation qui diffèrent entre les deux systèmes (le chinois utilise des signes de ponctuation pleine largeur ; le latin utilise la demi-largeur). Des règles de retour à la ligne qui interdisent à certains caractères d’apparaître en début ou en fin de ligne (kinsoku shori en typographie japonaise).
Ce n’est pas une demande de fonctionnalité. C’est un prérequis. Une interface qui échoue à gérer correctement la typographie mixte CJC-latin est une interface qui ne fonctionne pas pour la majorité des utilisateurs est-asiatiques qui lisent les deux scripts quotidiennement.
L’ampleur de l’exclusion
Les chiffres ne sont pas ambigus.
Script arabe : 420 millions de locuteurs natifs. Devanagari : 600+ millions d’utilisateurs à travers plusieurs langues. Caractères chinois : 1,4 milliard de lecteurs natifs. Japonais (mixte kanji, hiragana, katakana) : 125 millions de lecteurs natifs. Coréen (Hangeul) : 80 millions de lecteurs natifs. Script thaï : 38 millions de lecteurs natifs.
Combinés, ces scripts servent plus de personnes que l’alphabet latin. Et ce décompte exclut le cyrillique (250 millions), le bengali (230 millions), le tamoul (80 millions), le télougou (83 millions), et des dizaines d’autres scripts qui servent chacun des dizaines de millions de personnes.
L’alphabet latin n’est pas le système d’écriture du monde. C’est l’un des systèmes d’écriture du monde — et c’est celui qui contrôle les présupposés de chaque interface IA majeure.
Ce que « multilingue » signifie réellement
Chaque modèle d’IA majeur revendique une capacité multilingue. L’affirmation est vraie au niveau linguistique. GPT-4, Claude, Gemini — tous traitent du texte dans des dizaines de langues avec des degrés variables de compétence. Le modèle de langage comprend le chinois, l’arabe, le hindi, le japonais, le coréen, le thaï.
L’interface ne le fait pas.
La capacité multilingue du modèle de langage est rendue à travers une interface construite sur des présupposés latins : mise en page de gauche à droite, rendu de caractères discrets, affichage de mots séparés par des espaces. Le modèle peut penser en arabe. L’interface ne peut pas afficher l’arabe correctement. Le modèle peut générer du chinois. L’interface ne peut pas rendre correctement du texte mixte CJC-latin.
L’écart entre la capacité linguistique du modèle et la capacité typographique de l’interface est l’écart entre « multilingue » et « multiculturel ». Le modèle parle la langue. L’interface parle la typographie latine déguisée en langue.
C’est l’argument de Bluewaves, réduit à sa forme la plus simple : la langue n’est pas la culture. La traduction n’est pas l’adaptation. Un modèle qui génère de l’arabe fluide à travers une interface qui rend l’arabe incorrectement a atteint la compétence linguistique et l’incompétence typographique simultanément.
Les exigences d’ingénierie
Que faudrait-il pour construire une interface IA qui respecte les trois milliards ? Les exigences sont spécifiques, connues et bien documentées dans les spécifications du Consortium Unicode, les directives d’internationalisation du W3C, et des décennies de recherche en ingénierie typographique.
Support de texte bidirectionnel (Bidi). L’algorithme bidirectionnel Unicode (UBA) définit comment le texte avec une directionnalité mixte doit être rendu. L’algorithme gère le cas courant : une phrase arabe contenant un nom de produit anglais, ou un paragraphe hébreu avec une URL. L’UBA est un problème résolu — implémenté dans chaque moteur de navigateur et système d’exploitation majeur. L’exigence n’est pas d’inventer le support bidirectionnel. C’est d’utiliser correctement le standard existant. La plupart des interfaces IA ne le font pas.
Mise en forme contextuelle. L’arabe, le syriaque, le mongol et d’autres scripts connectés nécessitent une mise en forme contextuelle — le rendu de variantes de glyphes différentes selon la position d’un caractère dans le mot. Les fonctionnalités de mise en page OpenType (spécifiquement, les fonctionnalités « init », « medi », « fina » et « isol ») gèrent cela au niveau de la police. L’exigence est d’utiliser des polices qui incluent ces fonctionnalités et des moteurs de rendu qui les appliquent. L’exigence n’est pas exotique. C’est de la typographie standard. Elle est fréquemment ignorée.
Espacement et retour à la ligne CJC. Les « Requirements for Japanese Text Layout » (JLReq) et « Requirements for Chinese Text Layout » (CLReq) du W3C définissent les règles d’espacement, de ponctuation et de retour à la ligne pour le texte CJC. Ce ne sont pas des lignes directrices optionnelles. Ce sont les conventions typographiques que les lecteurs CJC attendent — l’équivalent du texte aligné à gauche en typographie latine. Les violer produit un texte lisible mais faux, de la même manière qu’un livre avec du texte anglais aligné à droite est lisible mais faux.
Rendu de scripts complexes. Le devanagari, le bengali, le tamoul, le télougou, le kannada, le malayalam, le thaï, le lao, le khmer, le tibétain et les scripts du Myanmar nécessitent tous une mise en forme complexe — réordonnancement des caractères, combinaison de caractères de base avec des marques de voyelles, et règles de positionnement dépendant de la combinaison spécifique de caractères. HarfBuzz, le moteur de mise en forme de texte open source, gère tout cela. L’exigence est l’intégration, pas l’invention.
Support du texte vertical. Le chinois, le japonais et le mongol traditionnels peuvent être écrits verticalement (de haut en bas, en colonnes de droite à gauche). Bien que l’écriture horizontale soit devenue dominante pour le texte numérique en chinois et japonais, le texte vertical reste important pour les contextes formels, l’édition littéraire et certains éléments d’interface. Le mongol s’écrit verticalement par défaut. Une interface IA qui revendique le support CJC mais ne peut pas rendre du texte vertical fait un présupposé culturel déguisé en limitation technique.
La dimension accessibilité
Les trois présupposés n’affectent pas seulement la compétence culturelle. Ils affectent l’accessibilité.
L’Organisation Mondiale de la Santé estime que 2,2 milliards de personnes dans le monde ont une forme de déficience visuelle. Les lecteurs d’écran — la technologie d’assistance qui convertit le texte en parole pour les utilisateurs malvoyants — dépendent d’une directionnalité de texte correcte, d’un encodage de caractères correct et d’une structure sémantique correcte. Un lecteur d’écran traitant du texte arabe dans un contexte gauche-à-droite lira les caractères dans le mauvais ordre. L’utilisateur entend du charabia.
Ce n’est pas une préoccupation de niche. Les internautes arabophones sont environ 237 millions. L’intersection des utilisateurs arabophones et des utilisateurs malvoyants se mesure en millions. Une interface IA qui rend le texte arabe dans un contexte gauche-à-droite a exclu ces utilisateurs de l’interaction — non par une décision délibérée, mais par le présupposé hérité que tout texte coule de gauche à droite.
La Directive européenne sur l’accessibilité du web (Directive 2016/2102) exige que les sites et applications du secteur public respectent les standards WCAG 2.1 AA. L’Acte européen d’accessibilité (Directive 2019/882), qui s’applique aux produits et services du secteur privé depuis juin 2025, étend des exigences similaires aux produits commerciaux. Les deux directives exigent un traitement correct du texte bidirectionnel, un balisage sémantique correct pour les lecteurs d’écran, et une identification correcte de la langue dans l’attribut HTML lang.
Un outil d’IA qui échoue à gérer correctement l’arabe, l’hébreu ou d’autres scripts RTL n’est pas simplement culturellement insensible. Il est potentiellement non conforme à la législation européenne sur l’accessibilité.
Le coût d’ingénierie de la conformité est le même que le coût d’ingénierie de la compétence culturelle : implémenter correctement l’algorithme bidirectionnel Unicode, utiliser du HTML sémantique avec des attributs lang corrects, et tester avec des lecteurs d’écran en mode RTL. Le coût est engagé une fois. L’exclusion, si le coût n’est pas engagé, est permanente.
L’écart de test
Voici une observation pratique issue d’années de travail en design interculturel : le présupposé que le texte est latin persiste parce que les tests sont en latin.
Les équipes QA testent les interfaces IA avec du texte latin. Des requêtes en anglais, des réponses en anglais, un rendu en anglais. Les tests passent. Le produit est livré. L’utilisateur arabe, l’utilisateur hindi, l’utilisateur chinois, l’utilisateur thaï découvre les échecs de rendu après le déploiement — en production, avec des requêtes réelles, avec des conséquences réelles sur la confiance.
L’écart de test n’est pas accidentel. Il est structurel. Les équipes QA sont composées de personnes qui lisent la langue de développement. Les cas de test sont écrits dans la langue de développement. Les tests automatisés vérifient des fonctionnalités décrites dans les documents d’exigences en langue de développement. Les tests multilingues nécessitent des testeurs multilingues — des personnes capables d’évaluer si le texte arabe semble correct, si l’espacement CJC est bon, si les connexions du shirorekha devanagari se rendent correctement. Ces testeurs existent. Ils sont rarement embauchés. Ils viennent après coup, si on les considère.
La correction est architecturale : inclure les scripts non latins dans la suite de tests principale, pas en annexe. Chaque test automatisé qui vérifie le rendu de texte devrait s’exécuter sur du texte arabe, chinois, devanagari et thaï en plus de l’anglais. Chaque passe QA manuelle devrait inclure une évaluation en script natif par un lecteur natif. Chaque audit d’accessibilité devrait inclure des scénarios RTL et de scripts complexes.
Ce n’est pas un régime de test premium. C’est un régime de test de base pour un produit qui revendique servir une base d’utilisateurs mondiale. Un produit qui ne teste qu’en latin et revendique un support mondial n’est pas un produit mondial. C’est un produit latin avec une page marketing mondiale.
L’échec de design
L’échec n’est pas que ces exigences soient inconnues. Elles sont abondamment documentées. L’Activité d’Internationalisation du W3C a publié des spécifications complètes pour chaque système de script majeur. Les spécifications du Consortium Unicode sont la référence canonique pour le traitement de texte dans le monde entier. HarfBuzz, ICU et d’autres bibliothèques open source implémentent la logique de rendu.
L’échec est que ces exigences sont traitées comme des cas particuliers plutôt que comme des exigences fondamentales. L’interface IA est conçue pour le texte latin. Puis le support arabe est « ajouté ». Puis le support CJC est « ajouté ». Chaque ajout est une adaptation rétrospective — un patch appliqué à une architecture conçue pour un système de script et étendue, imparfaitement, pour en accommoder d’autres.
L’alternative est de concevoir pour les trois milliards dès le départ. Traiter la mise en page bidirectionnelle, la mise en forme contextuelle, le rendu de scripts complexes et l’espacement CJC comme des exigences architecturales — pas des fonctionnalités à ajouter plus tard, mais des fondations à poser en premier.
C’est plus coûteux en amont. C’est moins coûteux au total. Chaque adaptation rétrospective coûte plus cher que la décision de design originale l’aurait coûté. Et chaque adaptation rétrospective produit des imperfections — bugs de rendu, bugs d’interaction, échecs d’accessibilité — qui érodent la confiance des utilisateurs qui étaient une réflexion après coup.
Le principe
L’alphabet latin n’est pas le défaut. C’est une convention — l’une parmi beaucoup, adoptée par une minorité des lecteurs du monde, élevée à la dominance architecturale par l’accident de la culture qui a industrialisé l’informatique en premier.
Chaque interface IA construite sur des présupposés latins exclut plus de personnes qu’elle n’en inclut. Pas par malveillance. Par héritage. Les présupposés n’ont jamais été examinés parce qu’ils n’ont jamais été visibles — pour les personnes qui les partagent.
Les trois présupposés — direction, continuité, séparation — ne sont pas universels. Ils sont provinciaux. Et construire une technologie mondiale sur des présupposés provinciaux n’est pas de l’ingénierie. C’est de la négligence à grande échelle.
Trois présupposés. Trois milliards de personnes. Les présupposés sont optionnels. Les personnes ne le sont pas.
L’interface IA construite pour les trois milliards est différente de l’interface IA construite pour l’alphabet latin. Elle commence avec la mise en page bidirectionnelle comme défaut, pas comme réflexion après coup. Elle traite la mise en forme contextuelle comme une capacité fondamentale, pas une fonctionnalité avancée. Elle gère l’espacement CJC comme une exigence de rendu centrale, pas un ajout de localisation. Elle teste avec du texte arabe, devanagari, chinois et thaï dans la suite de tests standard, pas comme un cas particulier.
Cette interface n’existe pas. Les spécifications pour la construire existent. Les bibliothèques pour l’implémenter existent. La demande pour elle — trois milliards de personnes — existe.
Ce qui n’existe pas, c’est la décision de la construire. Cette décision n’est pas technique. Elle est attentionnelle. C’est la décision de remarquer les trois présupposés et de les traiter comme les conventions provinciales qu’ils sont, plutôt que comme les vérités universelles qu’ils ne sont pas.
Trois présupposés. Trois milliards de personnes. La décision est une.