Site web multilingue au Maroc : français, arabe et anglais

Un site web multilingue est un site où chaque langue possède ses propres adresses, ses propres balises et son propre contenu indexable par Google. Ce n’est pas un site sur lequel on a posé un widget de traduction automatique : ce widget traduit ce que voit le visiteur, mais ne crée aucune page que Google puisse indexer, donc aucune visibilité supplémentaire.

Ce guide couvre les décisions structurantes, celles qu’on ne peut plus changer facilement une fois le site en ligne : la structure des adresses, les balises hreflang, le traitement de l’arabe, et la façon de traduire sans dégrader le référencement acquis.

Faut-il vraiment traduire ton site ?

Commence par cette question, parce que la réponse est souvent non, et qu’un site multilingue mal entretenu fait plus de mal qu’un site monolingue soigné.

Chaque langue ajoutée est un contenu à maintenir à vie. Chaque changement de tarif, de service, d’horaire ou de coordonnées doit être répercuté partout. Le scénario que je vois le plus souvent : un site créé en trois langues, mis à jour en français pendant deux ans, et dont les versions arabe et anglaise affichent encore l’ancienne adresse et l’ancien numéro de téléphone.

La bonne raison de traduire est commerciale et vérifiable : tu as des clients ou des prospects qui ne lisent pas la langue actuelle du site, et tu peux les nommer. Le tourisme, l’immobilier haut de gamme, l’export, les services aux entreprises internationales sont dans ce cas.

La mauvaise raison est esthétique : « ça fait plus sérieux d’avoir un drapeau anglais ». Ça fait surtout deux fois plus de travail.

Un test simple avant de décider : regarde dans ton outil d’analyse d’audience la langue du navigateur de tes visiteurs actuels, et dans Search Console les requêtes qui t’amènent du trafic. Si personne n’arrive avec des requêtes en arabe ou en anglais aujourd’hui, la traduction ne créera pas la demande toute seule. Elle sert à capter une demande existante.

Quelles langues pour un site marocain

Le Maroc a une situation linguistique particulière, et les réflexes importés d’Europe n’y fonctionnent pas.

L’arabe et l’amazigh sont les langues officielles depuis la Constitution de 2011. Le français reste très présent dans le monde des affaires, l’enseignement supérieur et l’administration. L’anglais progresse rapidement chez les jeunes générations et dans les secteurs tournés vers l’international.

Concrètement, voici comment je vois les choses se répartir chez mes clients.

Français seul convient à une majorité de sites B2B, de professions libérales et de services aux entreprises au Maroc. C’est encore la langue par défaut du commerce.

Français et arabe devient nécessaire dès que tu t’adresses au grand public sur tout le territoire, en particulier hors des grandes villes, et pour tout ce qui touche à l’administration, la santé ou l’éducation.

Français et anglais est la combinaison du tourisme, de l’immobilier destiné aux acheteurs étrangers, et de l’export. C’est le cas d’un site d’agent immobilier haut de gamme à Marrakech que j’ai réalisé : les acheteurs viennent d’Europe et du Golfe, l’anglais est passé devant l’arabe en priorité.

Les trois ne se justifient que si tu as réellement les trois publics et les moyens de tenir les trois versions à jour.

Les trois structures d’adresses possibles

C’est la décision la plus lourde de conséquences, parce qu’elle est très coûteuse à changer après coup.

Structure	Exemple	Autorité SEO	Complexité	Quand la choisir
Sous-dossier	tonsite.ma/ar/	Concentrée sur un domaine	Faible	Presque toujours
Sous-domaine	ar.tonsite.ma	Partiellement séparée	Moyenne	Contraintes techniques fortes
Domaine séparé	tonsite.com	Repart de zéro	Élevée	Marché et entité distincts

Le sous-dossier est le choix par défaut, et il l’est pour une raison simple : toute l’autorité que tu accumules, tous les liens que tu reçois, profitent à un seul domaine. Un lien obtenu sur la version française renforce aussi la version arabe. La gestion technique est également la plus simple : un seul certificat, un seul hébergement, une seule propriété dans Search Console.

Le sous-domaine est traité par Google comme un site partiellement distinct. Tu divises ton autorité sans gagner grand-chose, sauf si une contrainte technique t’y oblige, par exemple deux systèmes de gestion de contenu différents.

Le domaine séparé ne se justifie que dans un cas : tu cibles un autre pays, avec une entité locale, une équipe locale et un budget marketing dédié. Un .fr pour le marché français a du sens si tu ouvres une structure en France. Il n’en a aucun si tu veux juste une version française depuis Casablanca. Google détaille les critères dans sa documentation sur les sites multirégionaux.

Le choix de l’extension elle-même est un sujet en soi, traité dans l’article sur le choix entre .ma et .com.

hreflang : la balise qui évite que tes pages se concurrencent

Sans indication, Google voit trois pages différentes et doit deviner leur relation. Avec les balises hreflang, tu lui dis explicitement : ces adresses sont trois versions du même contenu, sers la bonne selon la langue de l’utilisateur.

Concrètement, chaque page porte dans son <head> la liste complète des versions, y compris elle-même :

<link rel="alternate" hreflang="fr" href="https://tonsite.ma/services/" />
<link rel="alternate" hreflang="ar" href="https://tonsite.ma/ar/services/" />
<link rel="alternate" hreflang="en" href="https://tonsite.ma/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://tonsite.ma/services/" />

Trois règles décident si ça fonctionne.

La réciprocité. Si la page française pointe vers la page arabe, la page arabe doit pointer vers la française. Une déclaration non réciproque est ignorée. C’est l’erreur la plus fréquente, et elle est invisible tant qu’on ne va pas la chercher.

L’auto-référence. Chaque page doit se déclarer elle-même dans la liste. Beaucoup d’implémentations l’oublient.

Le x-default. Il indique la version à servir quand aucune langue ne correspond. Sur un site marocain, c’est en général la version française.

Google documente la syntaxe complète et les erreurs courantes dans sa page sur les versions localisées. C’est la seule référence à suivre.

Une précision qui évite une confusion courante : hreflang n’est pas un signal de classement. Il ne fait pas monter tes pages. Il évite que tes propres versions se cannibalisent et que Google affiche la mauvaise à la mauvaise personne.

L’arabe : bien plus qu’une traduction du texte

C’est le point sur lequel les sites marocains multilingues échouent le plus souvent, et c’est immédiatement visible pour un lecteur arabophone.

L’arabe s’écrit et se lit de droite à gauche. La page doit le déclarer :

<html lang="ar" dir="rtl">

L’attribut dir change le sens de lecture de l’ensemble du document : alignement des textes, ordre des colonnes, position des puces de liste, sens des marges. Son fonctionnement exact est documenté sur la référence MDN de l’attribut dir.

Mais déclarer dir="rtl" ne suffit pas. Voici ce qu’il faut reprendre à la main, et que j’ai appris en le faisant.

Les icônes directionnelles. Une flèche « suivant » qui pointe vers la droite doit pointer vers la gauche en arabe. Les chevrons de carrousel s’inversent. Les icônes de retour aussi.

Les marges et espacements asymétriques. Une marge à gauche codée en dur reste à gauche. Il faut utiliser les propriétés logiques du CSS, qui s’adaptent au sens de lecture, plutôt que margin-left et margin-right.

Les nombres et les dates. Les chiffres restent lus de gauche à droite même dans un texte arabe. Les numéros de téléphone et les prix demandent une attention particulière pour ne pas s’afficher à l’envers.

La typographie. Une police latine ne contient pas les caractères arabes. Il faut charger une police arabe de qualité, et vérifier que les hauteurs de ligne restent lisibles : l’arabe a besoin de plus d’interligne que le latin pour respirer.

Les formulaires. Les libellés, les champs, les messages d’erreur, le sens de saisie : tout doit être vérifié champ par champ.

Le test qui ne trompe pas : fais relire la version arabe par quelqu’un dont c’est la langue maternelle, sur un téléphone. Il repérera en trente secondes ce qu’aucun outil ne détecte.

Ce que la traduction automatique fait vraiment à ton référencement

Il faut distinguer deux choses qu’on confond en permanence.

Le widget de traduction posé sur le site traduit l’affichage dans le navigateur du visiteur. Il ne crée aucune adresse, aucune page, aucun contenu indexable. Pour Google, ton site reste monolingue. Tu n’auras jamais une seule visite de recherche supplémentaire grâce à lui. Ce n’est pas une solution multilingue, c’est une aide à la lecture.

La traduction automatique publiée comme contenu crée bien des pages, mais Google classe le texte traduit automatiquement et publié sans relecture parmi les contenus générés sans valeur ajoutée. Le problème n’est pas l’outil : c’est l’absence de relecture humaine.

La méthode qui fonctionne aujourd’hui est hybride, et c’est celle que je recommande : traduction par un outil, puis relecture et adaptation par une personne qui parle la langue et connaît le vocabulaire du métier. Le coût est très inférieur à une traduction entièrement humaine, et le résultat est publiable.

Un exemple concret de ce que la relecture rattrape : en immobilier, un outil traduira « bien immobilier » par un terme générique, là où le marché anglophone attend « property ». Le texte sera correct grammaticalement et invisible dans les recherches, parce que personne ne tape le mot choisi par la machine.

Ce qu’il ne faut pas traduire

Certains éléments doivent rester identiques dans toutes les versions, et les traduire crée des problèmes.

Le nom de ton entreprise. Il reste tel quel, dans toutes les langues. C’est une entité, pas une expression.

Les noms de tes produits ou offres, sauf s’ils sont purement descriptifs.

Les coordonnées. Adresse, téléphone, email : identiques partout. Une incohérence entre les versions dégrade la cohérence de tes informations d’entreprise sur le web, ce qui compte pour ton référencement local. Le sujet est développé dans l’article sur le référencement d’un site marocain sur Google.

Les URL des versions traduites, en revanche, gagnent à être traduites. Une adresse tonsite.ma/en/services/ est meilleure que tonsite.ma/en/nos-services/, parce que le mot dans l’adresse participe à la compréhension de la page.

Le sélecteur de langue : les règles qui comptent

Il paraît anodin, et il est responsable d’une bonne partie des échecs.

Ne redirige jamais automatiquement selon le pays du visiteur. Le robot de Google explore depuis les États-Unis : une redirection automatique le renverrait systématiquement vers la version anglaise, et les autres versions ne seraient jamais explorées ni indexées. C’est le meilleur moyen de rendre invisibles deux tiers de ton travail. Ça agace aussi les visiteurs, un Marocain francophone en déplacement n’ayant aucune envie d’une version imposée.

Affiche les noms de langue dans leur propre langue. « العربية » et non « Arabe ». « English » et non « Anglais ». C’est ce que cherche du regard quelqu’un qui ne lit pas la langue actuelle.

Évite les drapeaux. Un drapeau représente un pays, pas une langue. Quel drapeau pour l’arabe, parlé dans plus de vingt pays ? Quel drapeau pour l’anglais, britannique ou américain ? Le texte est plus clair et plus respectueux.

Renvoie vers la page équivalente, jamais vers l’accueil. Un visiteur sur une fiche produit qui change de langue doit arriver sur la même fiche, pas sur la page d’accueil. Sinon il abandonne.

Rends le sélecteur visible sans le mettre au premier plan. En haut à droite ou dans le pied de page, il est trouvé par ceux qui le cherchent sans encombrer les autres.

Les erreurs que je corrige le plus souvent

Des versions qui divergent avec le temps. Le français est mis à jour, les autres non. Au bout d’un an, la version arabe annonce des services que tu ne proposes plus. Le remède est organisationnel, pas technique : décider qui met à jour quoi, et vérifier tous les trimestres.

Le menu traduit mais pas les pages. Le visiteur clique sur un lien du menu arabe et atterrit sur une page en français. C’est le pire des mondes : il a compris que la version arabe est un décor.

Le hreflang posé seulement sur la page d’accueil. Il doit être présent sur chaque page qui a des équivalents. Sur l’accueil seul, il ne sert quasiment à rien.

Les balises title et description non traduites. C’est ce qui s’affiche dans les résultats de recherche. Une page arabe avec un titre en français ne sera pas cliquée, quelle que soit sa position.

Les images contenant du texte. Une bannière avec un slogan incrusté dans l’image ne se traduit pas. Il faut soit une image par langue, soit du texte HTML par-dessus une image neutre. La seconde option est meilleure, y compris pour la performance.

Le formulaire de contact en français sur la version anglaise. Détail apparent, effet réel : c’est exactement là que le visiteur allait convertir.

Le cas particulier d’une boutique en ligne

Traduire un site vitrine et traduire une boutique n’ont rien à voir en termes de charge.

Une boutique multiplie tout : chaque fiche produit, chaque catégorie, chaque attribut, chaque message du tunnel de commande. Un catalogue de trois cents références en trois langues, ce sont neuf cents fiches à écrire et à tenir à jour.

Il y a aussi des éléments propres au commerce que la traduction ne suffit pas à régler.

Les devises. Afficher un prix en dirhams à un acheteur européen ne l’aide pas à décider. Mais convertir automatiquement crée un autre problème : le montant réellement débité dépend du taux appliqué par sa banque, et l’écart génère des réclamations. La solution honnête est d’afficher la devise de facturation clairement, et de proposer une conversion indicative.

Les frais de livraison et les délais, qui diffèrent par destination et doivent apparaître avant la commande, dans la langue du client.

Les mentions obligatoires du commerce à distance, qui doivent être compréhensibles par l’acheteur. Une condition de rétractation rédigée en français sur une commande passée depuis la version anglaise est difficilement opposable.

Mon conseil sur une boutique : traduis d’abord le tunnel de commande et les vingt produits qui font l’essentiel de ton chiffre. Le reste du catalogue peut attendre de savoir si le marché répond.

Le référencement local reste dans ta langue principale

Une confusion fréquente mérite d’être levée : traduire ton site ne traduit pas ta présence locale.

Ta fiche Google Business Profile, tes coordonnées dans les annuaires, les citations de ton entreprise sur d’autres sites : tout cela reste dans la langue où tu l’as créé, et ce n’est pas un problème. Google associe ces informations à une entité, pas à une langue.

Ce qu’il faut vérifier, en revanche, c’est la cohérence. Le nom exact de l’entreprise, l’adresse et le numéro de téléphone doivent être identiques partout, dans toutes les versions du site et dans toutes les fiches externes. Une adresse écrite « Av. Mohammed V » ici et « Avenue Mohamed V » ailleurs affaiblit l’association.

Enfin, si tu vises une clientèle étrangère qui cherche depuis son pays, sache que le référencement local ne t’y aidera pas : personne ne cherchera ton entreprise sur une carte depuis Paris. C’est la version linguistique de ton site, bien indexée, qui fait ce travail.

Combien de travail cela représente réellement

Soyons concrets, parce que l’écart entre la perception et la réalité est important.

La partie technique, structure d’URL, hreflang, gestion du RTL, se fait une fois. Sur un site de taille moyenne, c’est un chantier de quelques jours, et ensuite le mécanisme tourne.

La partie contenu est celle qui ne s’arrête jamais. Compte, pour chaque langue supplémentaire, un temps de traduction et de relecture proportionnel au volume, puis une charge récurrente à chaque mise à jour. C’est cette charge récurrente que tout le monde sous-estime.

D’où mon conseil systématique : commence par deux langues tenues correctement. Si la deuxième langue produit des demandes au bout de six mois, ajoute la troisième. Si elle n’en produit aucune, tu viens d’économiser des années d’entretien.

Si le site est déjà en ligne avec du trafic et que tu veux ajouter une langue sans casser l’existant, c’est une opération où l’ordre des étapes compte : mise en place de la structure, puis des balises, puis publication des contenus, jamais l’inverse. Ce type de chantier fait partie de ce que je traite en développement web sur-mesure, justement parce qu’une erreur de structure se paie pendant des mois.

Mesurer si ça a servi à quelque chose

Six semaines après la mise en ligne, ouvre Search Console et filtre le rapport Performances par pays et par requête. Tu cherches trois choses.

Des impressions sur des requêtes dans la nouvelle langue : c’est le signe que Google a compris et indexé.

Des clics, et pas seulement des impressions : si tu apparais sans être cliqué, tes titres et descriptions traduits sont à revoir.

Des demandes de contact venant de ces pages : c’est la seule mesure qui compte vraiment.

Vérifie aussi, dans le rapport d’indexation, qu’aucune des nouvelles pages n’est en « Explorée, actuellement non indexée ». Ce statut sur une version traduite signale presque toujours une traduction jugée trop faible.

Par où commencer

Avant toute chose, décide pourquoi tu traduis, et pour quel public précis. Si tu ne peux pas nommer le type de client que tu veux atteindre, la réponse est probablement que tu n’as pas besoin d’un site multilingue.

Si la réponse est claire, alors l’ordre est : choisir la structure en sous-dossier, traduire d’abord les cinq pages qui font vendre, poser les balises hreflang correctement et réciproquement, traiter le RTL si l’arabe est concerné, puis mesurer pendant six semaines avant d’aller plus loin.

Et si tu hésites entre ajouter une langue ou améliorer ce qui existe déjà, c’est une question qui mérite d’être tranchée avec des chiffres plutôt qu’à l’intuition. Envoie-moi l’adresse de ton site : je regarde d’où vient ton trafic actuel et je te dis franchement si une deuxième langue a une chance de rapporter quelque chose dans ton cas.