Support RTL : construire un logiciel qui fonctionne en arabe et en hébreu

Le support RTL (right-to-left, soit « de droite à gauche ») signifie qu’une interface s’affiche correctement dans des langues comme l’arabe ou l’hébreu, où le texte s’écoule de droite à gauche plutôt que de gauche à droite. En HTML, la direction principale d’un document ou d’un composant se déclare généralement avec l’attribut dir="rtl" pour les langues écrites de droite à gauche, comme l’arabe et l’hébreu (MDN). L’erreur que commettent presque toutes les équipes consiste à réduire le RTL à un simple réglage d’alignement. Le RTL inverse toute la mise en page : navigation, icônes, champs de formulaire et parcours visuel de l’utilisateur. Si vous le négligez, le logiciel ne paraîtra pas simplement étranger, mais cassé. Les utilisateurs de langues RTL le remarquent en quelques secondes.

Pour une entreprise française ou belge, l’arabe n’est d’ailleurs pas une langue lointaine : c’est celle du Maghreb, un marché naturel pour de nombreuses PME francophones. Nous l’avons identifié comme l’une des deux familles d’écritures qui révèlent le plus rapidement une internationalisation (i18n) fragile, aux côtés des écritures CJC, dans le développement de logiciels multilingues.

Ce que le RTL inverse vraiment

Appliquer dir="rtl" à une page modifie bien plus d’éléments que la plupart des équipes ne l’imaginent. Chaque détail doit être correct, pas seulement le texte des paragraphes :

• Navigation et menus. Une barre de navigation placée à gauche bascule à droite. Les fils d’Ariane, les onglets et les flèches des menus déroulants s’inversent également.
• Icônes directionnelles. Les flèches « retour » et « suivant », les chevrons et les indicateurs de progression pointent dans l’autre sens, car « avancer » dans une interface RTL se fait visuellement vers la gauche.
• Mise en page des formulaires. Les libellés, l’alignement des champs et l’ordre de tabulation d’un formulaire à plusieurs champs doivent être vérifiés séparément : la direction visuelle, l’ordre de lecture et l’ordre de tabulation ne s’alignent pas automatiquement. Sinon, un formulaire peut sembler correct en isolation, mais se parcourir dans le mauvais ordre.
• Indicateurs de progression et d’étapes. Pour un parcours d’inscription dont la progression est représentée spatialement, comme cinq étapes qui se remplissent de gauche à droite en français, il peut être pertinent d’adapter le sens visuel à la direction de lecture en arabe. Cette décision doit cependant respecter la convention et la sémantique du composant.

Oubliez un seul de ces points, et vous obtenez une interface hybride : du texte arabe dans une mise en page conçue pour le français. Elle paraît inachevée, car elle l’est.

Les propriétés CSS logiques : le mécanisme qui rend le RTL maintenable

Autrefois, le RTL reposait sur une feuille de style séparée où chaque left était remplacé par right, maintenue manuellement et en décalage constant avec la mise en page principale. Le CSS moderne résout ce problème avec les propriétés logiques, qui décrivent la position par rapport à la direction du texte plutôt qu’à un côté physique.

margin-inline-start et margin-inline-end remplacent margin-left et margin-right. Les propriétés logiques CSS expriment la mise en page en fonction du flux, notamment avec les notions de début et de fin, plutôt qu’en référence à des côtés physiques comme left et right. Cela facilite l’adaptation aux différents modes d’écriture (MDN). padding-inline-start remplace un padding-left codé en dur. Ainsi, le navigateur inverse automatiquement la mise en page selon l’attribut dir de la page, et une seule feuille de style suffit pour les deux directions. À l’inverse, avec des valeurs physiques gauche et droite, rien ne s’inverse : le texte arabe finit aligné à gauche dans une interface prévue pour la droite, avec le padding du mauvais côté.

C’est la décision qui pèse le plus dans le support RTL. Une base de code conçue dès le départ avec les propriétés logiques gère le RTL comme une simple configuration. Une base construite sur des valeurs gauche et droite codées en dur exige un audit manuel de chaque composant pour y parvenir.

Quand un texte arabe rencontre un code produit en caractères latins

Le contenu réel mélange rarement les directions. Une phrase en arabe contenant une référence produit, un numéro de téléphone ou un nom de marque en anglais doit afficher le texte RTL de droite à gauche, tandis que les caractères latins et les chiffres imbriqués continuent de se lire de gauche à droite, à leur place, sans perturber la phrase environnante.

Tout cela est régi par l’algorithme bidirectionnel Unicode (UAX #9), qui détermine l’ordre visuel d’un texte à directions mixtes à partir des propriétés des caractères. La plupart du temps, cela fonctionne automatiquement. Les problèmes surviennent à deux endroits prévisibles : les nombres et la ponctuation en bordure d’un segment de texte, où l’algorithme doit deviner quelle direction « possède » un caractère partagé comme un tiret ou une barre oblique, et le contenu inséré dynamiquement, comme un nom de produit extrait d’une base de données et interpolé dans une phrase traduite, où le balisage environnant ne déclare pas sa direction. La solution est explicite dans les deux cas : les caractères d’isolation Unicode (U+2066 à U+2069) ou l’attribut HTML dir et l’élément bdi marquent l’endroit où un texte d’une direction est imbriqué dans l’autre, évitant ainsi à l’algorithme de deviner.

Ignorez cette étape, et vous obtenez l’équivalent RTL du mojibake : un numéro de téléphone affiché à l’envers, ou une phrase où un code produit apparaît du mauvais côté des mots qui l’entourent. La comparaison n’est pas qu’une image, puisque les deux problèmes viennent de la même couche : consultez Unicode et l’encodage des caractères pour le versant octets du problème.

Quelles icônes inverser, et lesquelles surtout pas

Toutes les icônes ne se retournent pas, et une erreur dans un sens comme dans l’autre se remarque immédiatement.

À inverser : les flèches retour et suivant, les chevrons, les boutons « suivant » et « précédent », les barres de progression, et toute icône qui encode une séquence gauche-droite ou un sens de déplacement.

À ne pas inverser : les horloges, le bouton lecture d’un lecteur multimédia, une coche, les chiffres, les logos et les photographies de personnes ou d’objets. Un cadran d’horloge inversé ou un triangle de lecture à l’envers ressemble à un bug d’affichage, pas à un choix de localisation, car ces icônes représentent un objet réel, pas une métaphore directionnelle.

La distinction semble simple sur le papier. En pratique, elle exige une vérification systématique de chaque icône de l’interface, car une transformation globale « tout retourner » se trompe dans les deux cas.

Tester le RTL avant que les utilisateurs ne trouvent les bugs

Les bugs RTL échappent à une phase de QA menée uniquement en français, car rien dans la mise en page ne semble inachevé tant qu’un vrai contenu RTL ne l’a pas remplie. Trois vérifications repèrent ce qu’un coup d’œil distrait rate :

1. Tester avec du vrai contenu arabe ou hébreu, pas du lorem ipsum ni des blocs de remplissage. Le texte de remplissage est uniforme en longueur et en direction, donc il n’expose jamais les cas limites bidirectionnels ni les problèmes d’expansion du texte. Le W3C cite des écarts pouvant atteindre 200 à 300 % pour certaines chaînes anglaises très courtes, selon des lignes directrices IBM. (W3C, La taille des textes dans les traductions). Les mises en page localisées doivent donc rester flexibles : le W3C recommande d’éviter les conteneurs trop étroits et de laisser le texte se redistribuer, car la longueur des traductions varie fortement. Le français est déjà plus long que l’anglais, et un bouton dimensionné au millimètre pour « Envoyer » ne survivra pas à son équivalent arabe sans un test en contenu réel.
2. Lancer une passe de pseudo-localisation en mode RTL forcé. La plupart des frameworks modernes savent inverser la direction d’une page sans traduction en place, ce qui révèle rapidement les casses de mise en page (icônes pointant du mauvais côté, formulaires désalignés, débordements), avant même que le contenu traduit ne soit prêt.
3. Inclure au moins un cas de test à directions mixtes. Un champ de formulaire, un résultat de recherche ou une notification qui combine du texte RTL avec un code produit, une adresse e-mail ou un montant issu de votre gestion multidevise en caractères latins. C’est précisément là que l’algorithme bidirectionnel a besoin d’aide, et là que les bugs de jonction se cachent. Un affichage incorrect d’un prix en dirhams marocains, d’un numéro ou d’un identifiant dans une phrase arabe peut créer une ambiguïté ou une erreur d’interprétation.

Nous lançons systématiquement la pseudo-localisation ainsi qu’une locale RTL et une locale CJC sur chaque projet multilingue, précisément pour cette raison : les intégrer aux tests en amont réduit le risque de devoir corriger ces bugs plus tard, une fois qu’un client a signalé que l’application « a l’air cassée » en arabe.

Questions fréquentes sur le support RTL

Construisez-le bien dès la première fois

Indiquez-nous quelles écritures et quelles directions votre logiciel doit prendre en charge. Nous intégrons le RTL dès le premier commit, pas en rattrapage, et vous répondons avec un prix fixe et une date de livraison.

Demander un devis à prix fixe →