Site multilingue en Israël : hébreu, français, anglais, RTL

Un site multilingue en Israël n’a pas besoin de trois langues par défaut : l’hébreu sert le consommateur local, l’anglais les affaires et l’export, le français les niches francophones qui achètent dans leur langue. Choisis une ou deux langues selon ta cible réelle, donne à chacune ses propres URL reliées aux autres par des balises hreflang réciproques, et déclare dir="rtl" sur la version hébraïque dès la conception. La suite détaille chaque décision et ce qui casse quand on la saute.

Le réflexe « tout couvrir » qui plombe ton site

Quand on lance un projet web en Israël en venant de France, la première phrase qui tombe en réunion, c’est presque toujours la même : « On fait le site en français, en hébreu et en anglais, comme ça on est tranquilles. » Logique en apparence. Sauf que ce réflexe « tout couvrir » est précisément ce qui transforme un site potentiellement performant en usine à gaz qui ne classe nulle part.

Trois langues, c’est trois fois le contenu à écrire, trois fois la maintenance éditoriale, trois fois les chances de casser quelque chose techniquement. Et surtout : trois versions qui peuvent se gêner au lieu de s’additionner. Un site trilingue mal géré performe moins bien qu’un bilingue solide, parce que ton effort (contenu, liens, mises à jour) se répartit sur des pages dont deux ne reçoivent peut-être aucun trafic réel.

La vraie question n’est donc pas « combien de langues ? » mais « quelles langues servent vraiment ma cible, et lesquelles je ne maintiens que pour me rassurer ? ». On va y répondre cas par cas, puis voir comment éviter les pièges techniques (structure d’URL, hreflang, RTL) qui font dérailler les projets multilingues.

Qui parle quoi, vraiment, sur le marché israélien

Avant de décider d’une architecture, il faut regarder le terrain. En Israël, les trois langues ne jouent pas du tout le même rôle.

L’hébreu est la langue du consommateur final. E-commerce grand public, services locaux, prise de rendez-vous, administration : si tu vends à des Israéliens, l’hébreu n’est pas optionnel, c’est le socle.

L’anglais est la langue de travail dès que ta cible dépasse les frontières : tech, finance, tourisme d’affaires, B2B international. Une startup israélienne qui vise des clients ou des investisseurs hors d’Israël démarre souvent en anglais, parfois avant même l’hébreu.

Le français, lui, ne se justifie que pour des niches précises. La communauté francophone d’Israël est réelle et active en ligne, mais elle reste une minorité : les recherches Google en français depuis Israël pèsent peu face à l’hébreu et à l’anglais. Vérifie-le pour ton secteur dans le Planificateur de mots-clés avant de décider. Le français est pertinent pour les services aux Olim hadashim (nouveaux immigrants), le tourisme francophone entrant, l’immobilier et le juridique communautaires, certains commerces de quartier à forte clientèle française. Pour capter cette demande locale, la fiche Google et le contenu géolocalisé comptent autant que la langue : voir SEO local en Israël pour un site francophone.

Autrement dit : le français en Israël, c’est une langue de relation et de conversion, rarement une langue d’acquisition organique massive. Si tu attends de ta version française qu’elle te ramène du trafic Google par camions, tu vas être déçu.

Décider selon ta cible : 4 cas concrets

Prenons quatre cas types (fictifs) pour rendre la décision concrète.

Cas 1 : E-commerce grand public en Israël

Tu vends des produits à des Israéliens, livraison locale, paiement local. Ta langue prioritaire est l’hébreu, point. L’anglais peut venir en second pour les anglophones résidents et les touristes. Le français ? Seulement si ta clientèle est spécifiquement francophone (épicerie casher avec produits français, par exemple). Sinon, tu le gardes pour plus tard.

Architecture recommandée : HE principal + EN secondaire. C’est le modèle « langue principale + langue secondaire » qui bat souvent un trilingue dilué.

Cas 2 : Startup tech qui lève des fonds

Cible : investisseurs, partenaires et talents internationaux. Langue prioritaire : l’anglais. L’hébreu peut suivre pour le recrutement local et la presse israélienne. Le français n’a aucune justification ici, sauf marché francophone explicite.

Cas 3 : Cabinet de services aux Olim francophones

Avocat spécialisé en alyah, expert-comptable, agence immobilière qui accompagne les arrivants de France. Là, le français devient une vraie langue de conversion : ta cible cherche, lit et décide en français. Mais tes prospects vivront en Israël et auront besoin d’interagir avec l’administration : l’hébreu reste utile, et l’anglais sert de pont. C’est le seul cas où un trilingue se défend pleinement, à condition que chaque version ait du contenu réel et soutenu. On en parle plus en détail dans notre guide pour lancer son business en Israël après l’alyah.

Cas 4 : Marque DTC premium qui exporte

Une marque israélienne qui vend du vin, des cosmétiques ou de l’art en direct-to-consumer vers l’Europe et les États-Unis. Anglais d’abord (marché export), hébreu ensuite (marché local), français seulement si la France est un marché cible identifié avec du volume. Les principes de confiance restent les mêmes que ceux décrits dans nos 7 ingrédients d’une boutique DTC premium.

La règle qui ressort : commence avec une ou deux langues qui collent au buyer persona réel, mesure dans Google Search Console, puis étends si la demande est prouvée. Pas l’inverse.

Le piège du trilingue qui dilue ton SEO

Voici ce qui se passe concrètement quand on ajoute trois langues sans stratégie.

Des versions qui se marchent dessus

Contrairement à une idée répandue, une page traduite n’est pas du contenu dupliqué aux yeux de Google : ses versions localisées ne sont considérées comme des doublons que si le contenu principal reste non traduit (Google Search Central, versions localisées). Le piège classique est donc la fausse traduction : menu et pied de page en hébreu, contenu principal resté en français. Google recommande au contraire une seule langue pour le contenu et la navigation de chaque page, sans traductions côte à côte (Google Search Central, sites multirégionaux et multilingues).

Le vrai risque d’un hreflang absent ou cassé est ailleurs : Google peut montrer ta page anglaise à quelqu’un qui cherche en hébreu, et tes efforts se répartissent sur trois versions au lieu d’en renforcer une.

Le thin content auto-traduit

La tentation est immense : passer le contenu hébreu dans un traducteur automatique pour générer la version française en dix minutes. Mauvaise idée. La localisation désigne l’adaptation d’un contenu à un marché (vocabulaire, exemples, prix, références culturelles), là où la traduction se contente de convertir les mots. C’est la localisation qui convainc un lecteur ; une traduction approximative en hébreu décrédibilise immédiatement auprès d’un public local.

Google a aussi durci le cadre. Le 5 mars 2024, il a annoncé de nouvelles règles anti-spam, dont l’abus de contenu à grande échelle, scaled content abuse en anglais (annonce Google du 5 mars 2024). Parmi les exemples cités : des pages produites en masse par transformation automatique de contenus existants, traduction comprise, quand elles apportent peu de valeur aux utilisateurs (règles anti-spam de Google). Une version auto-traduite sans relecture n’aide donc pas ton site : elle l’expose.

Le coût caché d’une langue sans trafic

Le budget d’exploration n’est pas le problème d’un site de quelques centaines de pages. Google réserve principalement son guide sur le sujet aux sites de plus d’un million de pages uniques modifiées environ une fois par semaine, ou de plus de 10 000 pages modifiées chaque jour, et précise que ces seuils sont des estimations (Google, gérer le budget d’exploration). Le vrai coût est éditorial : chaque version doit être mise à jour, relue, enrichie. Trois langues dont une seule travaille, c’est deux tiers de ton effort éditorial qui pèsent sans rapporter.

Le calcul est simple : maintenir trois langues à qualité égale, c’est un budget éditorial multiplié par trois. Si tu n’as pas ce budget, le bilingue solide bat le trilingue bâclé à tous les coups.

La structure technique : une URL par langue

Une fois les langues décidées, l’architecture des URL conditionne tout le reste.

Première règle : chaque langue a ses propres URL. Google recommande des URL différentes pour chaque version linguistique, plutôt qu’un contenu qui change selon un cookie ou les réglages du navigateur (Google Search Central). Un simple bouton JavaScript qui traduit la page sans changer l’adresse laisse Google face à une seule URL : il risque de ne pas trouver ni explorer la seconde version.

Google décrit 4 structures possibles, dont une qu’il déconseille :

Pour la majorité des projets, les sous-répertoires sont le choix le plus simple : un seul domaine, un seul hébergement, une seule configuration. Le domaine national envoie un signal géographique fort mais devient lourd à gérer sur plusieurs langues ; le choix entre les deux extensions est détaillé dans .co.il ou .com : quel domaine pour ton business en Israël ?.

Hreflang : relier les versions entre elles

Vient ensuite le hreflang, là où tout le monde se trompe. L’attribut hreflang désigne la déclaration qui indique à Google les versions équivalentes d’une page dans d’autres langues ou pour d’autres régions, afin qu’il serve la bonne version à chaque internaute. Google accepte 3 méthodes pour la déclarer : des balises <link> dans le <head> HTML, des en-têtes HTTP ou le sitemap (Google Search Central, versions localisées). La valeur contient un code de langue au format ISO 639-1 (he, en, fr), éventuellement suivi d’un code pays au format ISO 3166-1 alpha-2 (IL). Un code pays seul n’est pas accepté.

Pour un trilingue ciblant Israël, chaque page a besoin au minimum de :

<link rel="alternate" hreflang="he-IL" href="https://exemple.com/he/page" />
<link rel="alternate" hreflang="en-IL" href="https://exemple.com/en/page" />
<link rel="alternate" hreflang="fr-IL" href="https://exemple.com/fr/page" />
<link rel="alternate" hreflang="x-default" href="https://exemple.com/en/page" />

La valeur réservée x-default sert quand aucune langue ne correspond aux réglages du navigateur du visiteur. Si ta version française vise aussi les francophones de France ou de Belgique, la langue seule suffit : Google traite par exemple de comme du contenu en allemand, quelle que soit la région, donc hreflang="fr" couvre tous les francophones.

Quatre erreurs cassent le système :

• Pas de lien retour : si deux pages ne pointent pas l’une vers l’autre, Google ignore leurs balises. Si la version hébraïque ne renvoie pas vers la française, la déclaration ne compte pas.
• Une version qui ne se liste pas elle-même : chaque version doit lister toutes les versions, y compris elle-même.
• Un code hors norme : seuls les codes de langue ISO 639-1 et de pays ISO 3166-1 alpha-2 sont pris en charge.
• Une URL relative : les URL alternatives doivent être complètes, protocole compris (https://).

La réciprocité est non négociable. C’est un travail méticuleux, qu’on automatise dans le modèle de page plutôt qu’à la main, page par page.

Dernier point souvent oublié : ne redirige pas automatiquement le visiteur vers la langue que tu lui supposes. Google déconseille les redirections automatiques entre versions linguistiques et l’adaptation du contenu selon l’adresse IP, et propose plutôt des liens vers les autres versions sur chaque page (Google Search Central). Un visiteur francophone bloqué sur une version hébraïque ferme l’onglet.

L’hébreu et le RTL : ce qui casse en vrai

L’hébreu s’écrit de droite à gauche (Unicode 18.0, chapitre 9). Le RTL désigne un sens d’écriture et de mise en page qui va de la droite vers la gauche (right-to-left). Ce n’est pas un détail cosmétique, c’est une bascule complète du layout : sur la version hébraïque, le menu se lit de droite à gauche, les listes et les puces se réalignent, les flèches et icônes directionnelles s’inversent, et les marges « à gauche » passent à droite. Et c’est là que les projets dérapent.

Les bases obligatoires

Sur la balise <html>, tu déclares à la fois la langue et la direction :

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

Les deux attributs ne font pas la même chose. C’est dir="rtl" qui bascule la page de droite à gauche : tous les blocs en héritent, sauf contre-ordre explicite. L’attribut dir n’accepte que 3 valeurs, ltr, rtl et auto (MDN, attribut dir). Le W3C insiste sur deux points : une déclaration de langue n’indique pas la direction, et la direction de base ne se règle jamais en CSS, toujours dans le balisage (W3C, Structural markup and right-to-left text in HTML). C’est un choix d’architecture : il se prend au début du projet, pas une fois le site fini.

Pour lang, la valeur correcte est he. L’ancien code iw est déprécié depuis le 1er janvier 1989 dans le registre IANA des codes de langue, qui indique he comme valeur à utiliser ; le W3C conseille d’éviter tout code déprécié (W3C, Choosing a language tag).

À quoi sert lang, alors ? Pas au référencement : Google détermine la langue d’une page à partir de son contenu visible et n’utilise pas les attributs lang (Google Search Central). Il sert d’abord aux technologies d’assistance, comme les lecteurs d’écran, pour choisir la bonne prononciation (MDN, attribut lang). Le W3C recommande de toujours le déclarer sur la balise <html> (W3C, Declaring language in HTML).

Les segments mixtes

Dans une ligne en hébreu, les nombres et le texte latin se lisent de gauche à droite (W3C, Hebrew Script Resources). L’affichage se dérègle surtout quand un segment de sens opposé commence ou finit par une ponctuation, commence par un chiffre ou est suivi d’un nombre : le navigateur rattache alors ces caractères au mauvais sens de lecture. La règle du W3C : entoure chaque segment de sens opposé d’une balise qui fixe sa direction (W3C, Inline markup and bidirectional text in HTML) :

<span dir="ltr">Peechy</span>

Quand tu ne connais pas la direction à l’avance (un nom saisi par un utilisateur, un avis client), utilise dir="auto" ou l’élément <bdi>. Pense aux URL, aux numéros de téléphone et aux noms de marque en caractères latins.

Les CSS logiques, la vraie économie

L’erreur classique : dupliquer toute la feuille de style pour gérer LTR et RTL. Une propriété CSS logique désigne une propriété définie par rapport au sens du texte (début et fin de ligne) plutôt que par rapport à la gauche et à la droite de l’écran (MDN, propriétés logiques). margin-inline-start, padding-inline-end ou inset-inline gèrent les deux directions sans duplication (web.dev). Côté compatibilité, margin-inline-start fonctionne dans tous les navigateurs courants depuis janvier 2020 (MDN, margin-inline-start). Pour les alignements, préfère text-align: start à text-align: left. Tu écris ton CSS une fois, il s’adapte à la direction.

Les polices et la typographie

Toutes les polices ne contiennent pas les caractères hébreux, regroupés dans le bloc Unicode U+0590 à U+05FF (Unicode, Blocks.txt). Google Fonts propose Heebo, Frank Ruhl Libre ou Noto Sans Hebrew, qui fournissent toutes un sous-ensemble hébreu dédié. Choisis une police qui couvre réellement les deux alphabets, ou une paire cohérente (une latine et une hébraïque assorties) : un site bilingue où les deux typographies jurent fait amateur.

Deux différences changent ta mise en page :

• l’hébreu n’a pas de distinction entre majuscules et minuscules (W3C, Hebrew Script Resources) : ta hiérarchie de titres repose sur la taille et la graisse, pas sur les capitales ;
• les voyelles (nikoud) s’écrivent sous la lettre, sauf le holam placé au-dessus (Unicode 18.0, chapitre 9) : si tu les affiches, prévois un interlignage plus généreux.

Les pièges d’interface mobile

Ce qui casse le plus souvent : les menus de navigation, les boutons CTA, les barres de progression et les carrousels. Leur inversion en RTL peut briser l’expérience, surtout sur mobile. Teste chaque composant interactif en mode RTL, pas seulement le texte, y compris les formulaires et le paiement. Une flèche « suivant » qui pointe dans le mauvais sens, c’est subtil mais ça désoriente.

Pour un site WordPress avec Elementor, le RTL ajoute une couche de fragilité ; si ton éditeur rame déjà, lis Elementor lent : alléger et stabiliser avant d’empiler les langues. Avec un constructeur no-code, vérifie avant de t’engager qu’il permet une URL par langue, des balises hreflang réciproques et un dir="rtl" par version. Le débat de fond entre WordPress et Astro en 2026 se pose d’ailleurs différemment quand le multilingue RTL entre en jeu.

Les détails UX qui font la différence

Au-delà de la technique, quelques détails séparent un site bilingue crédible d’un site traduit à la va-vite :

• Le sélecteur de langue est visible et explicite, chaque langue écrite dans sa propre langue (« FR / EN / עברית »), sur toutes les pages, pas caché dans un menu.
• Le parcours reste cohérent : si un visiteur passe en hébreu sur une page, le menu et le tunnel de conversion suivent, sans le renvoyer en français au milieu.
• Une page, une langue : contenu et navigation dans la même langue, sans paragraphes traduits côte à côte.
• Une relecture humaine par un locuteur natif avant la mise en ligne de chaque version.

Performance : ne pas doubler le poids du site

Un site bilingue charge potentiellement deux jeux de polices. Sans optimisation, ça pèse sur les Core Web Vitals, dont les seuils jugés bons sont 2,5 secondes pour le LCP, 200 millisecondes pour l’INP et 0,1 pour le CLS, mesurés au 75e centile des chargements (web.dev, Core Web Vitals). Deux réglages évitent de doubler le poids :

• découpe tes polices par alphabet avec unicode-range : le navigateur ne télécharge une police que si la page utilise au moins un caractère de sa plage (MDN, unicode-range). Une page française ne charge donc pas la police hébraïque, sauf si elle affiche du texte hébreu, comme le libellé « עברית » du sélecteur de langue ;
• ajoute font-display: swap : le texte s’affiche presque tout de suite avec une police de secours, puis la police web prend le relais dès qu’elle est chargée (MDN, font-display).

@font-face {
  font-family: "Heebo";
  src: url("/fonts/heebo-hebrew.woff2") format("woff2");
  unicode-range: U+0590-05FF, U+20AA, U+FB1D-FB4F;
  font-display: swap;
}

Ces trois plages, reprises du sous-ensemble hébreu de Google Fonts, couvrent le bloc hébreu, le symbole du shekel (U+20AA) et les formes de présentation hébraïques. Mutualise aussi le CSS grâce aux propriétés logiques plutôt que de charger deux feuilles en miroir. L’enjeu complet est détaillé dans performance web et Core Web Vitals.

En résumé

Le trilingue FR/HE/EN n’est pas un standard à appliquer par défaut : c’est une décision stratégique qui découle de ta cible, pas l’inverse. Hébreu pour le consommateur israélien, anglais pour les affaires et l’export, français pour les niches francophones de conversion. Côté technique, quatre fondations se posent dès le départ : une URL par langue, des hreflang réciproques, un dir="rtl" sur la version hébraïque avec des propriétés CSS logiques, et des polices découpées par alphabet. Un bilingue solide bat systématiquement un trilingue dilué, mal localisé et sans hreflang réciproque.

Action concrète cette semaine : ouvre Google Search Console (ou le Planificateur de mots-clés), regarde dans quelle langue ta cible cherche réellement tes produits ou services, et classe tes langues par volume de demande prouvée. Tu sauras alors lesquelles méritent un vrai budget éditorial, et lesquelles tu n’ajoutais que pour te rassurer. Pour le reste du projet (hébergement, domaine, contenu), le panorama complet est dans créer son site web en Israël quand on est francophone.

FAQ