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

Le support RTL (right-to-left, de droite à gauche) signifie qu'une interface se lit correctement dans des langues comme l'arabe et l'hébreu, où le texte s'écoule de droite à gauche plutôt que de gauche à droite. L'erreur que commettent presque toutes les équipes est de le traiter comme un réglage d'alignement de texte. Ce n'en est pas un. Le RTL inverse toute la mise en page : la navigation, les icônes, les champs de formulaire et la direction dans laquelle l'œil de l'utilisateur parcourt l'écran. Ratez-le et le logiciel n'a pas l'air étranger. Il a l'air cassé, et les utilisateurs de langues RTL le remarquent dans les premières secondes.

Pour une entreprise française ou belge, l'arabe n'est d'ailleurs pas une langue lointaine : c'est celle du Maghreb, un terrain d'export naturel pour beaucoup de PME francophones. Nous l'avons signalé comme l'une des deux familles d'écritures qui exposent le plus vite une internationalisation (i18n) fragile, aux côtés des écritures CJC, dans le développement de logiciels multilingues. Voici ce que le RTL exige réellement : la mise en miroir de la mise en page, le mécanisme CSS qui la rend maintenable, la gestion du texte bidirectionnel, et une approche de test qui attrape les bugs avant qu'un vrai utilisateur ne le fasse.

Ce que le RTL inverse réellement

Poser dir="rtl" sur une page retourne plus de choses que la plupart des équipes ne l'imaginent, et chacune doit être juste, pas seulement le texte des paragraphes :

• Navigation et menus. Une navigation à gauche devient une navigation à droite. Fils d'Ariane, onglets et flèches de menus déroulants s'inversent tous.
• Icônes qui impliquent une direction. Les flèches « retour » et « suivant », les chevrons et les indicateurs de progression pointent dans l'autre sens, parce que « avancer » dans une interface RTL pointe visuellement vers la gauche.
• Mise en page des formulaires. Les libellés, l'alignement des champs et l'ordre de tabulation d'un formulaire multi-champs se mettent tous en miroir, sinon un formulaire se lit correctement en isolation mais se tabule dans le mauvais ordre.
• Indicateurs de progression et d'étapes. Un parcours d'inscription en cinq étapes qui se remplit de gauche à droite en français doit se remplir de droite à gauche en arabe, sinon la métaphore visuelle cesse d'avoir un sens.

Sautez un seul de ces points et vous obtenez une interface hybride : du texte arabe posé dans une mise en page dessinée pour le français. Elle se lit comme inachevée, parce qu'elle l'est.

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

L'ancienne approche du RTL, c'était une feuille de style séparée où chaque left était remplacé par right, entretenue à la main, en dérive perpétuelle par rapport à la mise en page principale. Le CSS moderne règle cela proprement avec les propriétés logiques, qui décrivent la position par rapport à la direction du texte plutôt que par rapport à un côté physique.

margin-inline-start et margin-inline-end remplacent margin-left et margin-right. padding-inline-start remplace un padding-left codé en dur. Écrit ainsi, le navigateur retourne la mise en page automatiquement selon l'attribut dir de la page, et une seule feuille de style sert correctement les deux directions. Écrit à l'ancienne, avec des valeurs physiques gauche et droite, rien ne se retourne, et le texte arabe finit aligné à gauche dans une interface alignée à 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 construite dès le départ sur les propriétés logiques prend en charge le RTL comme une simple configuration. Une base de code construite sur des valeurs gauche et droite codées en dur exige un audit manuel de chaque composant avant d'y arriver.

Quand un texte arabe rencontre un code produit latin

Le contenu réel reste rarement dans une seule direction. Une phrase arabe contenant une référence produit, un numéro de téléphone ou un nom de marque anglais doit afficher le texte RTL de droite à gauche pendant que les caractères latins et les chiffres imbriqués continuent de se lire de gauche à droite, à leur place, sans brouiller la phrase autour.

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 sous-jacents. La plupart du temps, cela fonctionne tout seul. Cela casse à 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 tiré d'une base de données et interpolé dans une phrase traduite, où le balisage environnant ne déclare pas sa direction. Le correctif est explicite dans les deux cas : les caractères d'isolation Unicode (U+2066 à U+2069) ou les éléments HTML dir et bdi marquent l'endroit où le texte d'une direction est imbriqué dans l'autre, au lieu de laisser l'algorithme deviner.

Sautez 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. Le rapprochement n'est pas qu'une image, puisque les deux échecs viennent de la même couche : voyez Unicode et encodage des caractères pour le versant octets du problème.

Quelles icônes mettre en miroir, et lesquelles surtout pas

Toutes les icônes ne se retournent pas, et se tromper dans un sens comme dans l'autre se lit comme un bug.

À mettre en miroir : 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 mettre en miroir : 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, parce que ces icônes représentent un objet du monde réel, pas une métaphore directionnelle.

La distinction paraît simple énoncée ainsi. En pratique, elle exige une passe délibérée sur chaque icône de l'interface, en catégorisant chacune, parce qu'une transformation globale « tout retourner » se trompe dans les deux sens.

Tester le RTL avant que de vrais utilisateurs ne trouvent les bugs

Les bugs RTL échappent à une passe de QA menée uniquement en français, parce que rien dans la mise en page visible ne paraît inachevé tant que du vrai contenu RTL ne l'a pas remplie. Trois vérifications attrapent ce qu'un coup d'œil distrait manque :

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 le problème d'expansion du texte : le W3C mesure que les libellés d'interface courts peuvent s'étendre jusqu'à 300 % à la traduction depuis l'anglais, et que même les mots du quotidien sont régulièrement plus longs que leur source (W3C, Text size in translation). Le français part déjà plus long que l'anglais, et un bouton taillé au millimètre pour « Envoyer » ne survit pas davantage à 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 retourner la direction d'une page sans traduction en place, ce qui fait remonter vite 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 soit prêt pour les tests.
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 exactement là que l'algorithme bidirectionnel a besoin d'aide, et là que les bugs de jonction se cachent. Un prix en dirhams marocains rendu à l'envers dans une phrase arabe reste un prix faux.

Nous lançons la pseudo-localisation plus au moins une locale RTL et une locale CJC sur chaque construction multilingue, précisément pour cette raison : les bugs RTL coûtent peu à corriger pendant le développement et cher à corriger après qu'un client signale que l'application « a l'air cassée » en arabe.

Questions fréquentes sur le support RTL

Que signifie RTL en logiciel ?

RTL signifie right-to-left, de droite à gauche, en référence aux langues comme l'arabe et l'hébreu qui se lisent dans ce sens. Le support RTL signifie que toute l'interface, pas seulement le texte, se met correctement en miroir : navigation, icônes, formulaires et direction de mise en page s'inversent ensemble.

Quelles langues ont besoin du support RTL ?

L'arabe et l'hébreu sont les deux grandes écritures RTL du logiciel commercial ; le persan (farsi) et l'ourdou utilisent aussi l'écriture arabe et se lisent de droite à gauche. Toutes les autres grandes langues du monde, y compris le chinois, le japonais et le coréen, se lisent de gauche à droite malgré d'autres particularités de mise en page.

Puis-je simplement retourner mon CSS en permutant gauche et droite ?

Vous le pouvez, mais cela crée une seconde feuille de style qui dérive à chaque mise à jour de la mise en page principale. Les propriétés CSS logiques (margin-inline-start au lieu de margin-left) permettent à une seule feuille de style de servir les deux directions automatiquement, selon la direction déclarée de la page.

Pourquoi un texte arabe affiche-t-il parfois des nombres ou des mots anglais dans le mauvais ordre ?

C'est un bug de texte bidirectionnel : un contenu à directions mixtes (du texte arabe contenant un code produit latin, un numéro de téléphone ou un nom de marque) a besoin de marqueurs de direction explicites pour que l'algorithme bidirectionnel Unicode l'affiche correctement. Sans eux, l'algorithme doit deviner, et il devine parfois mal à la frontière entre les écritures.

Comment tester correctement le support RTL ?

Avec du vrai contenu arabe ou hébreu plutôt que du texte de remplissage, une passe de pseudo-localisation en RTL forcé pour attraper tôt les casses de mise en page, et au moins un cas de test mêlant texte RTL et nombres ou codes produits latins. Nous intégrons ces tests à chaque projet multilingue ; demandez un devis à prix fixe et le support RTL est cadré dès le départ.

Construisez-le bien du premier coup

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

Demander un devis à prix fixe →