Ajouter l'arabe à un site français ne consiste pas à traduire les textes puis à inverser les marges. Le rendu de droite à gauche touche la mise en page, la typographie, les nombres, les formulaires, les PDF et les e-mails, et chacun de ces sujets casse à sa manière. Ce site existe en trois langues dont l'arabe, et nous avons livré un site institutionnel bilingue arabe/anglais pour un contractant EPC international. Voici ce que ces projets nous ont appris, y compris ce que nous ne referions pas.
Le RTL n'est pas un miroir CSS
L'approche classique consiste à livrer la version LTR, puis à passer quelques jours à écrire des règles [dir="rtl"] qui inversent les paddings à la main. On obtient un site qui ressemble à du RTL en capture d'écran et qui se dégrade à chaque nouvelle fonctionnalité, parce que chaque composant doit désormais exister en deux exemplaires.
Le bon outil existe depuis des années : les propriétés logiques CSS. margin-inline-start remplace margin-left, inset-inline-end remplace right, text-align: start remplace text-align: left. Le navigateur résout le côté physique en fonction de la direction du document, et un composant écrit ainsi fonctionne dans les deux sens sans une seule règle conditionnelle.
/* Avant : chaque règle doit être doublée */
.card { margin-left: 1rem; border-left: 3px solid; }
[dir='rtl'] .card {
margin-left: 0; margin-right: 1rem;
border-left: none; border-right: 3px solid;
}
/* Après : une seule règle, valable dans les deux sens */
.card {
margin-inline-start: 1rem;
border-inline-start: 3px solid;
padding-inline: 1.5rem;
text-align: start;
}Sur le projet EPC, la règle de revue de code était simple : left et right sont interdits, sauf pour ce qui ne dépend pas du sens de lecture, comme une carte géographique ou un lecteur vidéo. Posée au premier commit, cette contrainte ne coûte presque rien. Le rétrofit sur un site existant, lui, oblige à repasser sur chaque composant un par un.
Attention au piège inverse : tout ne doit pas s'inverser. Une flèche « retour » change de sens en arabe, mais un numéro de téléphone, un extrait de code ou une barre de progression de lecture vidéo restent LTR. La question à se poser pour chaque élément n'est pas « est-on en RTL ? » mais « cet élément suit-il le sens de lecture ? ».
Le bidirectionnel : là où l'algorithme vous trahit
Un texte arabe réel n'est jamais purement arabe. Il contient des noms de produits latins, des sigles, des URL, des numéros de version. L'algorithme bidirectionnel Unicode décide seul de l'ordre d'affichage de ces segments, et il se trompe dès que la ponctuation s'en mêle : un nom de technologie en fin de phrase arabe, un numéro précédé d'un « + », une parenthèse qui saute de l'autre côté de l'écran.
dirsur le document et sur les îlots.dir="rtl"sur la page, puisdir="ltr"explicite sur tout bloc dont le contenu est latin : extrait de code, adresse e-mail, référence produit.<bdi>autour des valeurs injectées. Un nom d'utilisateur ou une raison sociale venus d'une base de données peuvent être latins dans une page arabe, ou l'inverse.<bdi>isole le segment et l'empêche de déformer la ponctuation qui l'entoure.- Tester avec du vrai contenu mixte. Un faux texte purement arabe ne révèle rien. Ce qui casse, ce sont les phrases arabes qui contiennent « Node.js 22 » ou « +33 6 ». Constituez un jeu de chaînes piégées et gardez-le dans vos tests visuels.
Dates, nombres et devises : ne bricolez rien
Deuxième source de bugs : le formatage. Selon le pays, l'arabe s'écrit avec des chiffres arabes orientaux (٠١٢٣) ou occidentaux (0123), la position du symbole monétaire change, et les noms de mois ne sont pas les mêmes au Maghreb et au Golfe. Toute concaténation manuelle de chaîne finira par produire un montant illisible chez quelqu'un.
Intl.NumberFormat et Intl.DateTimeFormat traitent ces cas correctement, à condition de passer une locale complète : ar-SA et ar-MA ne font pas les mêmes choix, et un simple ar laisse le moteur décider pour vous. Le choix des chiffres est d'ailleurs une décision éditoriale plus que technique : une partie du public du Golfe, habituée aux interfaces en anglais, préfère les chiffres occidentaux. C'est une question à trancher avec un locuteur du marché visé, pas dans le code.
La typographie arabe : vos habitudes cassent les ligatures
L'arabe est une écriture cursive : les lettres se lient et changent de forme selon leur position dans le mot. Trois conséquences concrètes pour une feuille de style pensée en latin :
letter-spacingest interdit. Un interlettrage élégant sur des capitales latines détache les lettres arabes les unes des autres et rend le mot difficilement lisible. Toute règle globale de ce type doit être neutralisée sur les pages arabes.- Votre police latine ne suffit pas. Ce site utilise une police à axe de largeur variable pour le latin ; elle ne couvre pas l'arabe. Les pages arabes sont servies en Noto Sans Arabic, qui, telle que nous la chargeons, n'a pas d'axe de largeur : la hiérarchie visuelle y repose sur la graisse et le corps uniquement. Il faut accepter que la version arabe n'ait pas exactement la même voix typographique, plutôt que de forcer une police de moindre qualité qui « fait arabe ».
- Les hauteurs de ligne bougent. L'arabe a des ascendantes, des descendantes et des diacritiques plus marqués ; un
line-heightcalé au plus juste pour le latin les coupe. De même, l'italique n'a pas d'équivalent traditionnel en arabe : les emphases passent par la graisse.
Formulaires : le champ le plus simple devient piégeux
Un formulaire bilingue concentre tous les problèmes précédents dans quelques centimètres carrés :
- Un champ e-mail, URL ou téléphone reste LTR même dans une page arabe :
dir="ltr"sur l'input, sinon le curseur saute et le « +33 » se retrouve du mauvais côté. - Un champ texte libre (nom, message) doit accepter les deux directions :
dir="auto"laisse le navigateur détecter le sens à partir des premiers caractères saisis. - Les messages de validation natifs du navigateur s'affichent dans la langue du système de l'utilisateur, pas dans celle de la page. Pour une expérience cohérente, la validation côté client doit porter ses propres messages, traduits et relus comme le reste.
- Le placeholder suit la direction du champ, pas celle de la page : un placeholder arabe dans un champ forcé en LTR se retrouve aligné à gauche, ce qui se voit immédiatement.
PDF et e-mails : tout recommence
Le navigateur fait énormément de travail bidirectionnel pour vous. Dès que vous en sortez, ce travail disparaît. Les bibliothèques de génération PDF gèrent inégalement la liaison des lettres arabes : certaines affichent les caractères détachés, dans le mauvais ordre, ou coupent les lignes du mauvais côté. Les clients e-mail sont pires encore : prise en charge inégale de dir, CSS restreint, propriétés logiques absentes chez plusieurs d'entre eux.
Un e-mail transactionnel arabe à deux colonnes n'est pas un objectif raisonnable. Simplifiez la mise en page de ces canaux plutôt que de vous battre avec eux.
Notre pratique : tester le rendu arabe de chaque sortie, PDF comme e-mail, sur les vrais clients cibles avant la mise en ligne, et considérer ces canaux comme des livrables à part entière, avec leur propre recette.
Le relecteur arabophone n'est pas optionnel
Dernier point, le plus important. Une traduction automatique, ou même une traduction professionnelle non relue, produit un texte grammaticalement correct et pourtant étranger : registre trop littéraire pour une interface, terminologie technique tantôt translittérée tantôt traduite sans cohérence, formules qui sentent le calque du français. L'arabe standard moderne est commun à tous les marchés, mais les choix lexicaux d'un lecteur marocain et d'un lecteur saoudien ne coïncident pas toujours, et il faut trancher pour son public.
Le relecteur natif voit aussi ce qu'aucun œil non arabophone ne détectera : une ligature cassée par une règle CSS oubliée, une ponctuation déplacée par l'algorithme bidirectionnel, un pluriel fautif dans un compteur. Une page arabe cassée « ressemble à de l'arabe » pour qui ne le lit pas. C'est précisément ce qui rend ce défaut dangereux : personne dans une équipe non arabophone ne le remarquera avant vos utilisateurs.
Un produit à livrer en français et en arabe ? Décrivez-le : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Ce que nous ne referions pas
- Ajouter le RTL en fin de projet. C'est faisable, nous l'avons fait, mais chaque composant écrit sans propriétés logiques devient une dette à reprendre. Le surcoût du RTL dès le premier commit est faible ; celui du rétrofit ne l'est pas.
- Valider sur captures d'écran. Un site RTL se teste au clavier et à la souris : sélection de texte, position du curseur, navigation dans les champs, carrousels, défilement. Une capture ne montre rien de tout cela.
- Traduire l'interface sans traduire le reste. Messages d'erreur d'API, e-mails transactionnels, notifications : l'utilisateur arabophone les voit tous, et un seul message resté en français suffit à rompre la confiance dans le sérieux de la version arabe.
L'essentiel
- Propriétés logiques partout, propriétés physiques interdites en revue de code.
direxplicite sur les îlots LTR,<bdi>sur les valeurs injectées.- Formats de dates, nombres et devises via
Intl, avec une locale complète. - Police arabe dédiée, pas de
letter-spacing, hiérarchie par la graisse. - Champs techniques en LTR forcé, champs libres en
dir="auto". - PDF et e-mails testés comme des livrables à part entière.
- Aucune mise en ligne sans relecture par un arabophone natif du marché visé.
Un site bilingue français-arabe est un projet d'ingénierie à part entière, pas une option de traduction cochée en fin de parcours. C'est le périmètre exact de notre offre d'applications bilingues et RTL : des produits qui fonctionnent dans les deux sens de lecture dès le premier commit.