L’arabe n’est pas une traduction, c’est une direction

Ajouter l’arabe à un site ne consiste pas à remplacer des mots. L’arabe se lit de droite à gauche, ce qui inverse la mise en page entière : navigation, icônes directionnelles, marges, colonnes, alignement des formulaires, position des boutons. C’est une décision d’architecture, pas une ligne de devis.

C’est pour cette raison qu’un site conçu en français puis « traduit » en arabe demande presque toujours une reprise de la mise en page. La traduction est la partie facile ; la direction est la partie structurante.

Ce qui casse quand on traduit un site conçu en français

Les défauts sont visibles et vérifiables. Vous pouvez les chercher vous-même sur n’importe quel site prétendument bilingue :

  • Les flèches pointent dans le mauvais sens. Un bouton « suivant » avec une flèche vers la droite devient absurde dans une interface qui progresse vers la gauche.
  • Les marges restent du mauvais côté. Le texte se colle au bord opposé, ou une indentation de liste apparaît à droite du texte au lieu de le précéder.
  • Les colonnes gardent leur ordre latin. Ce qui était la colonne principale à gauche devrait devenir la colonne principale à droite.
  • Les champs de formulaire s’alignent à gauche pendant que leurs libellés s’alignent à droite.
  • Les chiffres et les mots latins insérés dans une phrase arabe cassent l’ordre d’affichage si la direction n’est pas déclarée correctement.
  • La typographie ne suit pas. Une police latine qui n’a pas de jeu arabe produit un rendu de substitution irrégulier et difficile à lire.

Aucun de ces défauts n’apparaît dans un fichier de traduction. Ils apparaissent uniquement quand on regarde l’écran.

Une langue par intention : tout ne doit pas exister en trois versions

Le réflexe habituel est de tout traduire. Ce n’est pas toujours le bon choix.

La question utile n’est pas « ai-je traduit cette page ? » mais « quelqu’un cherche-t-il cela dans cette langue ? ». Une page de services commerciale et une page d’assistance technique n’ont pas nécessairement le même public linguistique.

Une approche raisonnable : traduisez d’abord ce qui porte l’intention commerciale et ce qui construit la confiance, puis étendez selon ce que vos données montrent réellement. Vos propres statistiques de recherche vous diront dans quelle langue on vous trouve ; c’est la seule source qui décrit votre situation plutôt qu’une moyenne.

Les URL et le hreflang : dire à Google quelle version est pour qui

Deux règles techniques décident si vos versions linguistiques fonctionnent ou se nuisent.

Gardez les segments d’URL neutres. Traduisez le contenu, pas le chemin. Si la version française vit sur une adresse et la version arabe sur une adresse construite différemment, plus rien ne relie les deux versions entre elles, et chaque version se retrouve seule.

Déclarez les alternatives avec hreflang. Chaque version doit annoncer les autres, y compris une valeur x-default pour les visiteurs dont la langue ne correspond à aucune version. Sans cela, deux problèmes surviennent : la mauvaise langue peut être servie au mauvais utilisateur, et vos versions risquent d’être interprétées comme du contenu dupliqué plutôt que comme des traductions.

Ces deux points relèvent de la structure du site autant que du contenu ; c’est pourquoi ils font partie de nos services de référencement plutôt que d’une option ajoutée après coup.

Le vrai coût d’une langue supplémentaire

Le coût n’est pas dans la traduction initiale. Il est dans ce qui suit :

  • La production du contenu, si les textes n’existent pas déjà dans la langue cible.
  • La relecture par une personne qui parle réellement la langue. Une traduction automatique non relue se voit immédiatement et coûte en crédibilité.
  • Le travail de mise en page RTL : une fois si l’architecture est prévue pour, bien plus si elle ne l’est pas.
  • La maintenance permanente. Chaque nouvelle page, chaque modification de prix, chaque article devient un travail multiplié par le nombre de langues. C’est le poste que l’on sous-estime le plus.

C’est aussi pourquoi il vaut mieux décider du nombre de langues avant la conception. Un site pensé dès le départ pour le multilingue absorbe l’arabe naturellement ; un site qui le découvre après coup paie deux fois. Nos services de création de sites web partent de cette décision plutôt que de la reporter.

Comment vérifier qu’un prestataire sait faire du RTL

Vous n’avez pas besoin d’être technicien pour contrôler. Demandez à voir une interface arabe qu’ils ont livrée, ouvrez-la, et vérifiez trois choses :

  1. La navigation commence-t-elle à droite ?
  2. Les flèches et icônes directionnelles sont-elles inversées ?
  3. Les formulaires sont-ils alignés du bon côté, libellés compris ?

Si la réponse est non aux trois, ils ont traduit un site latin sans l’adapter. Si l’on vous répond que « le CMS gère ça automatiquement », demandez à voir : la gestion automatique couvre le texte, rarement la mise en page complète.

C’est un test qu’il est juste de nous appliquer aussi. Luxury.co.ma est un site de location de voitures que nous avons construit en sept langues, l’arabe compris, chaque version ayant sa propre adresse. Ouvrez la version arabe et faites les trois vérifications ci-dessus.

Questions fréquentes

Faut-il traduire tout le site ?

Non. Commencez par les pages qui portent l’intention commerciale et la confiance, puis étendez selon ce que montrent vos données de recherche.

Arabe standard ou darija ?

L’arabe standard pour le contenu écrit du site. La darija apparaît surtout dans les requêtes de recherche, souvent écrite en caractères latins ; cela influence le choix des mots-clés, pas la langue de rédaction des pages.

Peut-on ajouter l’arabe plus tard ?

Oui, mais c’est plus coûteux que de l’avoir prévu. Si l’arabe est probable un jour, dites-le au moment de la conception : réserver la possibilité coûte peu, la rétro-adapter coûte cher.

Si vous hésitez sur le nombre de langues à prévoir, décrivez-nous votre projet ; la réponse dépend de votre marché, pas d’une règle générale.