2026-06-03 · Rédaction Baduno · 8 blog.readMin · Blog & Savoir
Conception RTL : Ce qui change quand le sens de lecture s'inverse
L'arabe et l'hébreu se lisent de droite à gauche – et bouleversent ainsi les hypothèses implicites de conception. Un rapport pratique issu de notre système de design.
Plus qu'un simple miroir
L'approche naïve – 'tout inverser simplement' – échoue rapidement : les chiffres et les noms de marque latins restent de gauche à droite, les symboles des lecteurs multimédias conservent leur direction, les numéros de téléphone se cassent. La conception RTL signifie décider pour chaque élément s'il est logique (suivant le sens de lecture) ou physique (fixe en direction).
CSS : propriétés logiques
La logique CSS moderne rend le RTL gérable : margin-inline-start au lieu de margin-left, inset-inline-end au lieu de right, text-align:start au lieu de left. Qui écrit logiquement dès le départ obtient le second sens de lecture presque gratuitement – qui met à jour après coup lutte avec des centaines d'exceptions. Ce site utilise systématiquement des propriétés logiques ; chaque version RTL provient de la même feuille de style que la version allemande.
Typographie et densité
L'écriture arabe n'a pas de majuscules, des hampes et jambages différents, et paraît plus petite et plus dense à la même taille de police. Une bonne typographie RTL nécessite des polices spécialisées, souvent un à deux points de plus et une hauteur de ligne plus généreuse. Les effets d'espacement des lettres, populaires en latin, ne fonctionnent pas avec l'écriture liée.
Tester avec des locuteurs natifs
Aucun automatisme ne remplace le regard d'une personne qui vit dans l'écriture : sauts de ligne dans les composés, chiffres dans le texte courant, directions mixtes dans les formulaires – les classes d'erreurs sont subtiles. Notre processus de validation inclut donc toujours une revue visuelle RTL, pas seulement une correction de texte.
Navigation : Là où la logique bascule
Dans les environnements RTL, les structures de navigation doivent être repensées. Une barre de menu horizontale commence à droite, le premier élément de menu est le plus à gauche – l'ordre reste logique de droite à gauche. Les menus déroulants s'ouvrent par défaut en bas à gauche au lieu de bas à droite, car le point d'ancrage se trouve sur le côté droit. Les barres latérales, positionnées à gauche dans une mise en page LTR, se déplacent vers la droite en RTL. Une attention particulière est requise pour les menus hamburger : l'icône elle-même (trois lignes horizontales) est neutre en direction, mais son emplacement (en haut à gauche vs en haut à droite) doit être inversé. Une erreur fréquente concerne les sous-menus qui affichent encore une direction LTR car ils ne sont pas contrôlés par des propriétés CSS logiques. Dans notre système de conception, nous définissons donc les composants de navigation entièrement avec inset-inline-start/end, afin qu'ils basculent automatiquement entre LTR et RTL. Exemple pratique : Une navigation par fil d'Ariane affiche en mode RTL la page actuelle à gauche et la page d'accueil à droite – les flèches de séparation doivent également changer de direction. Nous utilisons ici CSS-content avec des flèches intégrées qui utilisent une entité différente selon la valeur dir.
Directions mixtes : chiffres et caractères
Les chiffres, numéros de téléphone, adresses e-mail et noms de marque latins conservent leur alignement LTR même si le texte environnant est RTL. Cela conduit à ce qu'on appelle des sections bidirectionnelles, où le sens de lecture change au milieu de la phrase. Par défaut, l'algorithme bidirectionnel Unicode (Bidi) traite ces textes mixtes, mais vous devez vous assurer que la bascule de direction est correcte. Utilisez l'attribut dir au niveau de l'élément mixte ou utilisez des caractères comme LRM (Left-to-Right Mark) et RLM (Right-to-Left Mark). Exemple : dans une phrase en hébreu « Téléphone : 01234 56789 », la séquence de chiffres doit être lue de gauche à droite. Sans balisage correct, le navigateur pourrait couper la chaîne de caractères ou l'afficher de manière incorrecte. Dans les formulaires, il est essentiel que l'étiquette soit à droite et l'entrée à gauche, car l'utilisateur commence à lire à droite. Notre approche : pour chaque élément de texte contenant du matériel latin intégré, nous plaçons dans le modèle RTL un wrapper <span dir="ltr"> avec un LRM final, afin que le caractère RTL suivant se place correctement à la fin.
L'arabe et l'hébreu se lisent de droite à gauche – et bouleversent ainsi les hypothèses implicites de conception. Un rapport pratique issu de notre système de design.
Symboles : fixes en direction ou logiques ?
Les icônes et pictogrammes portent souvent des directions implicites : les flèches avant pointent vers la droite, les flèches arrière vers la gauche. Celles-ci doivent être inversées dans les interfaces RTL, sinon la navigation semble contre-intuitive. Cependant, tous les symboles ne dépendent pas de la direction : un triangle de lecture reste toujours le même (car il représente une action physique), de même pour une icône d'e-mail ou de téléphone. La règle d'or : la direction logique (chronologie, sens de lecture, direction de navigation) doit être inversée ; la signification physique ou symbolique ne l'est pas. En développement, nous utilisons des transformations CSS pour les icônes : scaleX(-1) pour tous les SVG logiques en direction, contrôlés par une classe [dir=rtl] .icon--directional. Ainsi, nous évitons les ressources en double. Attention : les flèches de carrousel qui pointent vers la droite doivent pointer vers la gauche en mode RTL, car la page « suivante » se trouve maintenant à gauche. Il en va de même pour les barres de progression : la progression doit augmenter de droite à gauche. Dans notre système de conception, ces composants sont implémentés avec des propriétés logiques (inline-size au lieu de width), de sorte que le niveau de remplissage se lie automatiquement au début de la barre de progression.
Images : que refléter, que redessiner ?
Les graphiques et illustrations contiennent souvent des symboles culturels ou dépendants de l’orientation : des horloges qui tournent dans le sens des aiguilles d’une montre (dans le contexte RTL, cela semble normal en miroir), des poignées de main, des frises chronologiques. Toutes les images ne doivent pas être entièrement reflétées – un mouvement d’aiguille inversé pourrait être perçu comme erroné car la réalité physique doit être préservée. Mais une frise chronologique de gauche à droite doit, dans le contexte RTL, aller de droite à gauche. Les logos et images de marque restent généralement inchangés car ils sont soumis à une identité visuelle fixe. Le défi consiste à délivrer automatiquement les bonnes images. Nous stockons pour chaque graphique un équivalent RTL en tant qu’actif séparé ou utilisons des transformations CSS pour les cas simples. Dans les scénarios complexes (ex. infographies avec texte), une refonte manuelle est nécessaire. Notre workflow : le graphiste étiquette chaque image comme « sans direction », « miroitable » ou « individuelle » dans le CMS. La diffusion se fait via une condition qui lit l’attribut dir de l’élément parent. Exemple : une illustration d’une bibliothèque avec des livres en écriture latine devrait être reflétée pour que les dos des livres apparaissent à droite – cela peut surprendre au premier abord, mais c’est cohérent.
SEO et hreflang : balisage spécifique au RTL
Pour les moteurs de recherche, le balisage correct de la langue et de la direction est essentiel. Outre l'attribut de langue (lang), l'attribut dir doit être défini sur chaque page afin que le navigateur et le moteur de recherche interprètent correctement le sens de lecture. Sur les pages RTL multilingues, le balisage hreflang est particulièrement critique : une page arabe (ar) doit correctement référencer ses équivalents allemands ou anglais. Des entrées hreflang erronées entraînent des indexations incorrectes, car Google ne déduit pas automatiquement le sens de lecture. De plus, envisagez de créer des sitemaps séparés pour les versions LTR et RTL afin de renforcer les signaux. Une erreur fréquente consiste à utiliser des balises génériques sans tenir compte de la direction d'écriture. Nous misons sur une génération dynamique de hreflang qui dérive à la fois les codes de langue et de région de la base de données linguistique. Pour les dialectes arabes, la différenciation régionale est nécessaire, car les consommateurs et les algorithmes ont des attentes différentes. Nous utilisons également la balise canonical pour éviter les incohérences entre les contenus miroirs et non miroirs. Notre workflow vérifie automatiquement si l'attribut dir dans l'en-tête HTML est cohérent avec les indications hreflang. Car un texte arabe sans dir="rtl" peut être mal affiché par les navigateurs, ce qui augmente le taux de rebond. Les performances SEO sont donc influencées non seulement par les textes, mais aussi par le balisage correct du sens de lecture.
Accessibilité : défis RTL pour les technologies d'assistance
Les besoins des lecteurs d'écran et autres technologies d'assistance changent avec le sens de lecture. Les lecteurs d'écran comme JAWS ou VoiceOver attendent l'attribut dir pour déterminer l'ordre de lecture correct. En l'absence de cette indication, ils risquent de lire les contenus multilingues dans le mauvais ordre. Les repères ARIA restent les mêmes, mais la position dans le DOM devrait idéalement suivre le sens de lecture : le menu principal doit se trouver dans le code source avant le contenu principal – en RTL, cela signifie le côté droit en premier. Un autre point concerne les ordres de focus : les tab-index doivent être logiquement de droite à gauche sur les pages RTL. Utilisez des éléments HTML natifs qui ajustent automatiquement la navigation au clavier. Les textes alternatifs des images doivent être spécifiques à la langue et refléter la perspective de la culture cible. Exemple : un graphique montrant une poignée de main devrait être décrit en arabe comme « deux mains qui se croisent », car la connotation culturelle est différente. Nous recommandons d'effectuer des audits d'accessibilité à la fois en vue LTR et RTL. Cela inclut la vérification des contrastes, qui peuvent différer sous la typographie RTL. Notre équipe utilise des outils automatisés combinés à des tests manuels effectués par des locuteurs natifs pour garantir une expérience utilisateur inclusive.
blog.faqT
Dois-je inverser toutes les images lorsque je crée une version RTL ?
Non. Seules les images avec un sens de lecture clair, comme les frises chronologiques, les flèches ou les diagrammes séquentiels, doivent être inversées. Les logos, portraits, graphiques avec des objets physiques (horloge, globe) restent inchangés, car leur inversion en altérerait le sens. Décidez au cas par cas.
Comment tester efficacement le RTL en développement ?
Utilisez les outils de développement du navigateur pour définir l'attribut dir sur l'élément html à "rtl" et vérifiez l'ordre correct de chaque composant. Étendez votre processus de révision de code avec une vérification RTL dédiée par des locuteurs natifs, couvrant les perturbations visuelles et les flux de texte bidirectionnels incorrects.
