Nehos Groupe
Export B2B agroalimentaire — huile d'olive tunisienne en vrac

Zitouna Export — un site B2B d'export en cinq langues, arabe RTL compris

Produit du groupe, exploité par STE AKFER TUNISIA depuis Sfax. 2 760 URL au sitemap, 406 pages éditoriales par langue, l'arabe servi en droite à gauche. Ce que le multilingue coûte vraiment quand une langue se lit à l'envers.

Durée

Socle éditorial français et specs à partir de juillet 2026 ; traduction des quatre langues et audit interne d'internationalisation achevés le 27 juillet 2026 ; arbitrage concurrentiel et retrait des outils de prix trop périssables le 12 août 2026 ; site en ligne et sitemap relevé à 2 760 URL le 8 septembre 2026. Produit interne en itération continue.

Équipe

2 experts

Technologies clés

Next.js 14 App Router next-intl CSS en propriétés logiques (inset-inline, padding-inline, text-align: start) Cairo

2 760

URL déclarées dans le sitemap.xml de zitouna-export.com, toutes langues confondues

5 langues

Versions linguistiques servies — français, anglais, espagnol, arabe (RTL) et italien

551

URL par langue préfixée dans le sitemap — anglais, espagnol, arabe et italien à parité

406

Fichiers Markdown éditoriaux par langue, soit plus de 2 000 fichiers de contenu au total

#Un site export B2B en quatre langues, arabe compris

Zitouna Export est un site B2B d'export d'huile d'olive tunisienne en vrac que nous avons construit pour nous-mêmes, comme produit du groupe. Il sert aujourd'hui 2 760 URL en cinq langues, dont l'arabe en droite-à-gauche. Ce qui coûte cher dans un site multilingue, ce n'est pas la traduction : c'est tout ce qu'une langue RTL casse en silence.

#Le problème : l'acheteur d'huile d'olive en vrac ne cherche pas en français

Le vendeur est à Sfax. L'acheteur est un embouteilleur à Bari, une centrale d'achat à Madrid, un importateur à Dubaï, un créateur de marque à Montréal. Entre les deux, une asymétrie que la plupart des sites d'export ignorent : la langue dans laquelle on vend n'est presque jamais celle dans laquelle on est cherché.

La verticale de l'huile d'olive en vrac illustre le problème à l'état pur. En relevant manuellement la SERP en août 2026, nous avons constaté que les exportateurs qui font du SEO le font dans une seule langue — l'anglais, souvent sur des pages statiques. Résultat : l'intention d'achat hispanophone, qui est loin d'être marginale sur un produit méditerranéen, est occupée par des annuaires B2B généralistes et par de la presse spécialisée. Sur une requête comme « aceite de oliva a granel Túnez », aucun exportateur tunisien dédié ne se présentait. Le créneau n'était pas disputé : il était vide.

L'arabe posait une question différente. Ce n'est pas un créneau vide, c'est la langue de travail d'une partie des acheteurs du Golfe et du Maghreb, et celle des candidats exportateurs que le site adresse aussi. L'ignorer, c'était renoncer à la moitié d'un marché. La traiter, c'était accepter une contrainte de conception, pas une ligne de budget traduction.

Nous avions donc trois décisions à prendre en même temps : combien de langues, avec quelle architecture d'URL, et ce qu'on accepte de payer pour que l'arabe ne soit pas une version dégradée du site.

#Ce que nous avons construit

Le site est en ligne. Au 8 septembre 2026, son sitemap.xml déclare 2 760 URL. Le français vit à la racine ; l'anglais, l'espagnol, l'arabe et l'italien sont préfixés (/en, /es, /ar, /it) et comptent 551 URL chacun. Le corpus éditorial sous-jacent, c'est 406 fichiers Markdown par langue — pages produit, marchés par pays, comparatifs d'origines, guides d'import, certifications, blog — soit un peu plus de 2 000 fichiers au total.

L'italien est arrivé après coup, une fois le socle à quatre langues stabilisé : l'Italie est la première destination du vrac tunisien, et les embouteilleurs qui achètent de l'olio sfuso pour le revendre sous leur marque forment exactement le profil d'acheteur visé. Ce n'est pas anecdotique pour un client qui hésite : une architecture multilingue bien posée absorbe la cinquième langue en une fraction du coût de la deuxième.

Au-dessus du contenu, une couche d'outils interactifs — lecteur de certificat d'analyse qui classe un lot en extra vierge, vierge ou lampante selon les seuils COI/UE, simulateur de marge, calcul de remplissage de conteneur, décomposition de coût par incoterm — et un tiroir de demande de devis accessible depuis n'importe quelle page, branché sur Brevo. Chaque outil existe dans les cinq langues.

La rédaction du socle français puis les traductions ont été menées par des agents IA orchestrés en parallèle et relus, ce qui explique qu'un corpus de cette taille existe. C'est une méthode que nous appliquons à nos propres actifs avant de la proposer ailleurs.

#Ce que l'arabe coûte vraiment

C'est le cœur du dossier, et la partie que les devis multilingues sous-estiment presque toujours.

Le passage en droite-à-gauche se déclare en une ligne : la locale arabe est marquée dans la configuration de routage, et le gabarit émet <html lang="ar" dir="rtl">. Toutes les pages arabes du site, pas seulement l'accueil, portent cet attribut — nous l'avons revérifié sur des pages profondes du type « importer de l'huile d'olive tunisienne en Allemagne ».

Ce qui se met en place tout seul ensuite, ce sont les propriétés CSS logiques. Dès que la feuille de style parle en inset-inline-end, padding-inline-start ou text-align: start plutôt qu'en right et left, la mise en page se retourne d'elle-même. C'est la bonne nouvelle, et c'est la raison pour laquelle un site conçu dès le départ avec des propriétés logiques absorbe le RTL sans refonte.

La mauvaise nouvelle, c'est tout ce qui n'est pas une propriété logique. Trois familles, dans notre cas :

Les transformations. Une transformation CSS ne connaît pas la direction du texte. Le tiroir de devis est ancré avec inset-inline-end: 0 — il se place correctement à gauche en arabe — mais il entre à l'écran par translateX(100%), une valeur qui le fait sortir du mauvais côté en RTL. Il a fallu écrire explicitement [dir="rtl"] .drawer { transform: translateX(-100%) }. Même correctif pour les fenêtres de capture d'e-mail, qui glissent depuis un bord, et pour l'effet de survol des liens de pied de page.

Les animations directionnelles. Les bandeaux défilants — articles, certifications, services, outils — reposent sur des @keyframes qui déplacent une piste horizontalement. En arabe, un bandeau qui défile dans le sens de lecture latin donne une impression de bug. Chacun de ces composants a donc reçu un jeu d'images-clés miroir, activé par [dir=rtl]. Quatre composants, quatre animations dupliquées.

Les glyphes orientés. Le chevron du fil d'Ariane pointe dans le sens de la lecture. En arabe, il doit pointer dans l'autre. Il est retourné par un transform: scaleX(-1) conditionné à la direction. C'est trois lignes de CSS, et c'est le genre de détail dont l'absence trahit immédiatement une traduction posée sur une maquette latine.

S'ajoute la typographie : la pile de polices latines ne rend pas l'arabe correctement. Une règle dédiée bascule le corps de texte sur Cairo dès que la page est en arabe. Et la calibration SEO ne se transpose pas : un titre de 60 caractères en français ne dit pas la même chose en 60 caractères d'arabe ou d'espagnol, ce qui impose de recalibrer titres et méta-descriptions langue par langue plutôt que de traduire au mot.

Enfin, la partie invisible : la parité de l'interface. L'audit interne du 27 juillet 2026 a mesuré 1 602 clés de messages d'interface par langue, sans écart entre les quatre langues d'alors. Une clé manquante, et c'est un bouton en français au milieu d'une page arabe.

#Les choix techniques, et pourquoi

Le site tourne sous Next.js 14 en App Router, entièrement pré-rendu, avec next-intl pour l'internationalisation. Trois décisions méritent d'être expliquées, parce qu'elles se rejouent sur tout projet multilingue.

Le français à la racine, mais l'anglais en x-default. Ce sont deux questions différentes, et les confondre est une erreur classique. La locale par défaut décide quelle version vit sans préfixe d'URL ; le hreflang x-default dit aux moteurs quelle version servir à un visiteur dont la langue ne correspond à aucune des nôtres. Sur un site d'export dont les acheteurs sont espagnols, italiens, américains et du Golfe, ce visiteur-là comprend l'anglais bien plus souvent que le français. Le site déclare donc cinq alternates et un x-default pointant vers l'anglais, calculés page par page — un premier jet les faisait tous pointer vers les pages d'accueil, ce que l'audit a rattrapé.

La détection automatique de langue désactivée. Symptôme observé : un visiteur passé en arabe ne pouvait plus revenir au français. Le cookie de langue mémorisé redirigeait /budget vers /ar/budget en 307, donc le sélecteur semblait cassé — alors que les autres langues, qui ont un préfixe explicite, fonctionnaient. La détection par cookie a été coupée. Le sélecteur navigue par de vrais liens et recharge la page ; le site est volontairement multi-pages et non une application monopage.

Une table d'alias pour les liens internes. Le corpus a été rédigé avant que les URL canoniques ne soient figées, si bien que des centaines de liens pointaient vers un nom de fichier plutôt que vers l'URL finale. Plutôt que de réécrire à la main dans cinq langues, une table de 119 alias résout le lien vers son URL canonique, puis applique le préfixe de langue. Une suite de 26 fichiers de tests automatisés — parité des locales, hreflang, x-default, liens internes, longueurs de méta — empêche la régression.

Côté hébergement, le site tourne sur Netlify : le contenu est copié dans l'application au pré-build, et les redirections de l'ancien site WordPress sont déclarées dans netlify.toml — un fichier _redirects dans le dossier public n'est pas honoré par le runtime Next. Détail qui compte pour un site multilingue : chaque redirection utile doit être écrite une fois par langue. Pour un projet client soumis à une exigence de souveraineté, la même architecture se déploie sur OVHcloud SecNumCloud ; pour un site d'export public, Netlify suffisait.

#Ce que ça prouve si vous avez le même besoin

Trois enseignements transposables, que nous assumons parce que nous les avons payés sur notre propre produit.

Le premier : dans un budget multilingue, la traduction est la ligne la moins risquée. Ce qui dérape, c'est le nombre de gabarits, de composants animés et de règles de redirection à décliner par langue. Si vous chiffrez un site en quatre langues comme un site en une langue multiplié par quatre, vous vous trompez dans les deux sens — le contenu coûte moins que prévu, l'ingénierie coûte plus.

Le deuxième : le RTL est une décision d'architecture, pas une option de fin de projet. Un site écrit dès l'origine en propriétés logiques bascule presque gratuitement ; un site écrit en left/right demande une reprise de chaque composant. La différence se joue au premier jour de développement, pas au moment où l'on commande la traduction arabe.

Le troisième : les langues sous-desservies sont souvent le meilleur retour sur investissement. L'espagnol n'a rien coûté de plus que l'anglais et adressait un espace concurrentiel nettement moins tenu. C'est un raisonnement qui vaut bien au-delà de l'agroalimentaire — nous le retrouvons sur les dossiers de commerce international cross-border.

La méthode a depuis été reprise pour deux autres corpus export du groupe — les dattes et l'huile de pépins de figue de barbarie — dont les sites ne sont pas encore publiés. Le gabarit, lui, se réutilise : c'est précisément ce qu'on attend d'un investissement d'architecture.

Le socle technique est celui de notre pratique Next.js et React, porté sur ce dossier par l'équipe Next.js de Sfax, à une heure de route des oliveraies qui ont servi de terrain au contenu.

Ce qui est vérifiable aujourd'hui

2 760 URL au sitemap public, relevé du 8 sept. 2026

551 URL pour chacune des quatre langues préfixées — parité stricte entre anglais, espagnol, arabe et italien

`<html lang="ar" dir="rtl">` vérifié sur l'accueil arabe et sur une page profonde de marché par pays

Cinq balises alternates plus un x-default pointant vers l'anglais, calculées page par page

406 fichiers Markdown éditoriaux par langue, rendus par une route unique indexée sur l'URL de frontmatter

119 alias de liens internes et 26 fichiers de tests automatisés protégeant la mécanique multilingue

Aucune métrique de trafic, de position ou de retour sur investissement publiée — elles ne sont pas stabilisées

L'essentiel sur cette réalisation

Zitouna Export est un produit du groupe : un site B2B d'export d'huile d'olive tunisienne en vrac, exploité par STE AKFER TUNISIA depuis Sfax.

En ligne, il déclare 2 760 URL dans son sitemap au 8 septembre 2026, réparties sur cinq langues : français à la racine, anglais, espagnol, arabe et italien préfixés.

L'arabe impose une mise en page de droite à gauche. Les propriétés CSS logiques la prennent en charge ; les transformations, les animations et les glyphes orientés, non.

L'espagnol a été retenu parce qu'aucun exportateur tunisien dédié n'occupait cette intention d'achat lors d'un relevé manuel de SERP en août 2026.

Stack : Next.js 14 App Router pré-rendu, next-intl, hébergement Netlify, e-mails transactionnels Brevo.

Questions & Réponses

Questions fréquentes sur cette réalisation

Cela dépend presque entièrement de la façon dont la feuille de style a été écrite. Si les règles de mise en page sont exprimées en propriétés logiques — inset-inline, padding-inline, text-align: start —, la bascule droite à gauche est quasi gratuite : le navigateur retourne la mise en page pour vous. Le travail restant porte sur ce que ces propriétés ne couvrent pas : les transformations CSS, qui ignorent la direction du texte et doivent être inversées explicitement ; les animations horizontales, qui demandent un jeu d'images-clés miroir ; les glyphes orientés comme les chevrons ; la pile typographique, qui doit basculer vers une police arabe. Si le site a été écrit en left et right, il faut reprendre chaque composant, et le chiffrage n'a plus rien à voir.

Parce que les deux réglages répondent à des questions différentes, et les confondre est une erreur classique de SEO international. La locale par défaut décide quelle version du site vit à la racine du domaine, sans préfixe d'URL. Le x-default dit aux moteurs quelle version servir à un visiteur dont la langue ne correspond à aucune des versions publiées. Sur un site d'export dont les acheteurs sont espagnols, italiens, nord-américains et du Golfe, ce visiteur-là comprend l'anglais bien plus souvent que le français. Nous avons donc gardé le français à la racine, pour des raisons d'exploitation, et déclaré l'anglais en repli. La valeur est portée par une constante unique et un test empêche qu'un autre fichier la recalcule.

Pour ce dossier, ce sont les préfixes d'URL sur un domaine unique, et nous les recommandons par défaut. Un domaine par pays est justifié quand chaque marché a une entité juridique, un catalogue et une équipe distincts — il fragmente en revanche l'autorité et multiplie les coûts d'exploitation. Les sous-domaines partagent les défauts sans les avantages. Le préfixe concentre tout le signal sur un seul domaine, simplifie l'hébergement, et reste lisible : un acheteur qui voit /es dans la barre d'adresse comprend immédiatement où il est. La nuance, c'est qu'il faut alors décliner par langue tout ce qui est routé : les redirections de reprise, notamment, doivent être écrites une fois par version.

Ce n'est pas obligatoire, et nous ne l'avons pas fait ici : les segments d'URL restent en français derrière le préfixe de langue. C'est un compromis assumé. Traduire les slugs améliore marginalement la lisibilité et la correspondance de mots-clés dans l'URL, mais multiplie par le nombre de langues la table de correspondance à maintenir, complique le maillage interne et fragilise les redirections. Sur un corpus de plusieurs centaines de pages par langue, ce coût de maintenance dépasse le gain. Si votre corpus est plus resserré — quelques dizaines de pages commerciales très concurrentielles — l'arbitrage peut basculer dans l'autre sens.

En arrêtant de compter sur la vérification manuelle. Au-delà de quelques centaines de pages par langue, une relecture humaine ne survit pas à une vague de publication. Nous encodons les invariants dans des tests exécutés au build : parité du nombre de fichiers entre les langues, préfixe d'URL correct pour chaque locale, alternates calculées à partir du chemin réel de la page et non du gabarit, liens internes tous résolvables, longueurs de titres et de méta-descriptions dans les limites utiles. Sur ce dossier, cela représente 26 fichiers de tests. C'est ce qui a permis d'ajouter une cinquième langue sans repartir dans un audit complet.

Réserver un audit