Configuration multilingue de votre boutique : préparer PrestaShop aux ventes internationales

Révisé en juin 2026, ces étapes s’appliquent à PrestaShop 1.7, 8 et 9 ; l’outil Traductions et les champs _lang par langue fonctionnent de la même manière dans ces versions.

Ajouter une deuxième langue à PrestaShop ressemble à une opération de deux minutes : installer un pack de langue, cocher une case, terminé. Puis les fissures apparaissent, des e-mails à moitié traduits, un bouton de commande encore en anglais sur la boutique allemande, des descriptions produit jamais renseignées, un back-office où votre équipe d’entrepôt se retrouve soudain face à du français. Le moteur multilingue de la plateforme est réellement solide (chaque champ traduisible est stocké par langue au niveau de la base de données, pas ajouté après coup), mais « prend en charge plusieurs langues » et « est correctement configuré pour vendre à l’international » sont deux états très différents. Ce guide sert à combler cet écart : les étapes exactes dans le back-office pour ajouter et configurer une langue, l’endroit où se trouve réellement chaque catégorie de texte traduisible, et l’ordre à suivre pour ne pas lancer une boutique traduite à 80 % et confuse à 100 %.

C’est la partie « configuration des langues » d’un déploiement international. Les devises, les taxes et l’approche pays par pays ont chacun leur propre traitement, le guide sur la configuration multidevise et le guide plus large sur la vente en Europe les couvrent en détail. Ici, nous restons concentrés sur les langues.

Comment PrestaShop stocke les langues (et pourquoi c’est important)

Avant de toucher à un réglage, il est utile de savoir ce que vous configurez réellement. Dans PrestaShop, une langue est une ligne dans la table lang, et presque chaque contenu possède une table _lang associée, product_lang, category_lang, cms_lang, meta_lang, qui contient un enregistrement par langue et par élément. Quand vous ajoutez une langue, vous ne changez pas un mode d’affichage ; vous créez un ensemble parallèle de champs de contenu vides que quelqu’un doit maintenant remplir.

Et alors ? Deux conséquences en découlent, et elles expliquent la plupart des erreurs multilingues :

• Une langue fraîchement ajoutée démarre vide, elle n’est pas traduite automatiquement. PrestaShop peut afficher le texte de la langue par défaut dans les champs non traduits sur certaines surfaces, et c’est exactement comme cela que vous vous retrouvez avec des noms de produits en anglais sous un menu allemand.
• Les textes d’interface (boutons, messages d’erreur, contenu des e-mails) ne sont pas stockés dans ces tables _lang, ils proviennent des fichiers de traduction et de l’outil Traductions, dans un flux de travail complètement distinct. Traduire vos produits ne change rien au bouton de commande. Vous devez faire les deux.

Ajouter une langue correctement : Localisation → Langues

Le chemin le plus rapide et le plus fiable consiste à installer un pack de localisation complet plutôt qu’une simple langue nue. Allez dans International → Localisation (dans les anciennes boutiques 1.6, c’est Localisation → Localisation). Choisissez le pays et, surtout, vérifiez les cases correspondant à ce que vous voulez importer : États, Taxes, Devises, Langues, Unités et Modifier le comportement des taxes. Importer la langue de cette façon récupère aussi les formats de nombres/dates correspondants et un pack de traductions du cœur de PrestaShop ; vous partez donc avec une interface PrestaShop déjà traduite, plutôt qu’une page blanche.

[SCREENSHOT: panneau d’import International → Localisation avec un pays sélectionné et les cases États / Taxes / Devises / Langues / Unités visibles avant l’import du pack]

Après l’import, allez dans International → Localisation → Langues et ouvrez la nouvelle langue pour vérifier les champs qui cassent discrètement les boutiques :

• Code ISO et Code langue, le code ISO (par ex. de) pilote le nom du fichier du pack de langue et le drapeau ; le code langue (par ex. de-DE) pilote l’attribut lang et le formatage des dates. Une incohérence ici est une cause fréquente du fameux « le fichier de traduction ne se charge pas ».
• Format de date, il se définit par langue, afin qu’une même boutique affiche DD/MM/YYYY aux visiteurs français et le bon format ailleurs, sans code personnalisé.
• Langue RTL, activez cette option pour l’arabe, l’hébreu ou le farsi, et PrestaShop chargera la feuille de style de droite à gauche. L’oublier laisse une boutique RTL affichée de gauche à droite, ce qui paraît cassé côté client.
• Statut. Les langues désactivées restent installées (vous pouvez donc préparer les traductions en privé), mais n’apparaissent pas dans le sélecteur du front-office tant que vous ne les activez pas.

Langue de la boutique et langue des employés : gardez-les séparées

Un détail évite beaucoup de mauvaises surprises : les langues vues par vos clients ne sont pas forcément celles dans lesquelles votre équipe travaille. Activer l’allemand pour la boutique ne force pas votre back-office à passer en allemand. Chaque employé définit sa propre langue d’administration dans son profil (Paramètres avancés → Équipe → Employés, ou dans ses propres préférences). Vous pouvez donc vendre en six langues pendant que votre équipe d’entrepôt conserve l’admin en anglais. Les nouveaux marchands craignent souvent qu’ajouter une langue client bouleverse leur propre administration, ce n’est pas le cas.

Les cinq couches de contenu que vous devez vraiment traduire

« Traduire la boutique », ce sont en réalité cinq tâches séparées, situées à des endroits différents. En oublier une, c’est cette couche que les clients remarqueront. Voici la carte, dans l’ordre qui compte :

Couche	Où elle se trouve	Comment la traduire	Si vous l’oubliez…
Catalogue (produits, catégories, caractéristiques, attributs)	Tables _lang	Drapeau/menu déroulant de langue sur chaque page d’édition	Des noms de produits en anglais sous un menu traduit, l’échec le plus visible
Pages CMS (conditions, livraison, retours, confidentialité)	cms_lang	Onglets par langue dans l’éditeur CMS	Des pages légales dans la mauvaise langue, un problème de conformité et de confiance
Chaînes d’interface (boutons, libellés, erreurs)	Fichiers de traduction	International → Traductions	« Ajouter au panier » reste en anglais au milieu du parcours de commande
Modèles d’e-mails	Traductions des e-mails + .tpl/.html	Outil Traductions, type « Traductions des e-mails »	Les confirmations de commande arrivent dans la mauvaise langue, la première impression après le paiement
Chaînes des modules	Fichiers de traduction propres à chaque module	Outil Traductions, module par module	Un bloc tiers en anglais sur une page pourtant traduite

Contenu du catalogue : le sélecteur de langue champ par champ

Chaque champ traduisible d’un produit, d’une catégorie ou d’une page CMS possède un petit sélecteur de langue (un menu avec drapeau en 1.6, un onglet/menu de langue en 1.7+). Changez de langue, saisissez la traduction, enregistrez. Le champ que vous ne remplissez pas reste vide pour cette langue. Il n’y a pas de remplissage automatique discret, et c’est précisément le but. Pour un gros catalogue, c’est l’essentiel du travail, et c’est là que vous décidez de votre stratégie de traduction : traduction professionnelle pour les meilleures ventes et les textes juridiquement sensibles ; traduction par IA avec relecture native pour la longue traîne ; sortie brute de traduction automatique seulement lorsque l’alternative est réellement l’absence totale de contenu. Quel que soit votre choix, ne collez pas le texte anglais dans tous les champs de langue pour « éviter les blancs », c’est pire qu’un champ vide, car cela fabrique du contenu dupliqué sur vos URL linguistiques.

Interface, e-mails et chaînes de modules : l’outil Traductions

[SCREENSHOT: International → Traductions, panneau « Modifier les traductions » avec le menu déroulant du type de traduction ouvert, affichant les options Front-office / E-mail / Modules installés / Back-office]

C’est la couche que les marchands oublient, parce que le catalogue semble terminé et que la boutique a l’air traduite jusqu’au moment où un client clique sur un bouton. Allez dans International → Traductions. Choisissez le type de traduction. Les plus importants sont :

• Traductions du front-office, les chaînes du thème que le client lit pendant ses achats.
• Traductions des e-mails, le texte des e-mails de commande, de livraison et de compte. Traduisez et envoyez-vous un test, car l’allemand et le finnois peuvent être 30 à 40 % plus longs que l’anglais et casser une mise en page d’e-mail à largeur fixe.
• Traductions des modules installés, choisissez la langue et le module précis ; chacun possède ses propres chaînes. Un module tiers fraîchement installé est une source fréquente de fragments restés en anglais.
• Traductions du back-office, seulement si votre équipe travaille dans cette langue.

Les modifications faites ici sont stockées comme surcharges de traduction pour le thème, le module et la langue sélectionnés, sauvegardez-les ou exportez-les donc avant de changer de thème, mettre à jour un module ou lancer une mise à niveau majeure, car ces opérations peuvent les affecter. Si une chaîne n’apparaît pas dans l’outil, c’est presque toujours parce que le développeur ne l’a pas enveloppée dans la fonction de traduction de PrestaShop, une vraie limite qu’il vaut mieux connaître avant de vous en vouloir.

L’ordre de configuration qui évite un lancement à moitié traduit

L’ordre compte, parce que certaines étapes en débloquent d’autres. Une séquence qui fonctionne :

• 1. Importer le pack de localisation du pays (écran Localisation), vous obtenez la langue, la traduction de l’interface de base, les formats de dates/nombres et les unités en une seule opération.
• 2. Vérifier les réglages de langue (écran Langues), codes ISO/langue, format de date, RTL si nécessaire. Laissez la langue désactivée pour l’instant, afin que les clients ne voient pas une version en cours de construction.
• 3. Traduire ensuite les pages CMS et légales. Elles sont limitées, critiques et doivent être traduites professionnellement ; faites-les tant que la langue est encore masquée.
• 4. Traduire le catalogue, le gros chantier ; au minimum vos meilleures ventes et vos catégories principales avant le lancement.
• 5. Utiliser l’outil Traductions pour le front-office, les e-mails et chaque module actif, puis passez une vraie commande de test dans cette langue pour repérer les problèmes de mise en page et les restes d’anglais.
• 6. Activer la langue seulement lorsque tout ce qui précède est réellement terminé. Le but de l’état désactivé est de ne jamais exposer une boutique traduite à 70 %.

Où se trouvent le sélecteur de langue et les drapeaux (et où ils ne se trouvent pas)

Une fois une langue activée, le thème par défaut de PrestaShop affiche automatiquement un sélecteur de langue dans l’en-tête, via le module ps_languageselector. Vous pouvez le déplacer ou le restyler via le thème, et le débat ancien entre drapeaux et noms de langues relève d’une vraie question d’ergonomie, un drapeau suggère un pays, pas une langue, ce qui peut agacer, par exemple, un Autrichien à qui l’on montre un drapeau allemand. Nous avons déjà détaillé ce point et les petites attentions front-end qui évitent aux visiteurs internationaux de repartir dans sélecteur de devise et drapeaux de langue, nous n’allons donc pas rouvrir le sujet ici.

SEO : ne laissez pas vos traductions se cannibaliser

Dès que vous avez la même page en plusieurs langues, vous devez dire à Google qu’il s’agit de versions alternatives les unes des autres, et non de doublons, c’est le rôle des annotations hreflang, un sujet assez dense pour mériter son propre guide : les balises hreflang. Les décisions de configuration linguistique qui les alimentent, en revanche, ont leur place ici :

• Des métadonnées par langue, rédigées plutôt que traduites. Les titres et descriptions meta sont stockés par langue, dans la table meta_lang pour les pages statiques et CMS, et dans product_lang / category_lang pour les pages catalogue. Le mot-clé le plus performant en anglais est rarement sa traduction littérale ; les metas doivent donc être rédigées dans la langue cible par quelqu’un qui recherche dans cette langue, ne traduisez pas automatiquement vos balises meta.
• Des URL simplifiées par langue. Avec les URL simplifiées activées (Paramètres de la boutique → Trafic & SEO), chaque langue reçoit un slug localisé, /en/shower-drain, /de/duschrinne, /fr/caniveau-de-douche, bien plus solide que de conserver des slugs anglais dans toutes les langues. Notre module Smart SEO Friendly URL Manager garde ces slugs propres et adaptés à la langue, pour vous éviter de les reprendre produit par produit.
• Des sitemaps par langue avec hreflang. Un sitemap qui liste chaque version linguistique et les référence entre elles aide Google à indexer l’ensemble au lieu d’une seule version. Notre module Advanced SEO Sitemap Builder génère des sitemaps par langue avec les bonnes annotations.
• Des liens internes dans la même langue. Un article de blog allemand doit pointer vers des pages produit allemandes, pas vers leurs équivalents anglais, les liens internes mélangés entre langues gaspillent l’autorité et brouillent les robots d’exploration. Le module Automatic Internal SEO Linker respecte la langue courante lorsqu’il crée des liens, ce qui maintient la cohérence à mesure que votre catalogue grandit.

Traduction ou localisation : la partie que les équipes sous-estiment

Traduire les mots est nécessaire ; adapter au marché, c’est ce qui convertit réellement. PrestaShop en gère une partie pour vous une fois les langues et le pack de localisation en place, mais seulement une partie :

• Formats de dates et de nombres. Ils sont gérés par langue grâce aux réglages ci-dessus (1.234,56 pour l’Allemagne, 1,234.56 pour le Royaume-Uni), à condition de définir correctement le champ de format.
• Unités de mesure, le pack de localisation définit les valeurs métriques/impériales par défaut, mais vos descriptions produit doivent encore employer les bonnes unités.
• Adéquation culturelle, une bannière de Saint-Valentin ou une référence centrée sur les États-Unis tombe à plat sur le mauvais marché ; c’est une décision éditoriale, pas un réglage.
• Attentes de paiement, les acheteurs néerlandais s’attendent à iDEAL, les acheteurs polonais à BLIK. C’est une décision liée aux moyens de paiement, mais c’est précisément pour cela qu’une boutique « entièrement traduite » peut encore sembler étrangère au moment de payer.

La devise appartient aussi à cette zone, un Autrichien germanophone s’attend à l’EUR, un Suisse germanophone au CHF, et la langue seule ne suffit pas à le déterminer. Comme la devise est un axe réellement distinct de la langue, nous gardons le traitement complet dans le guide multidevise plutôt que de l’aborder à moitié ici.

Une seule administration ou plusieurs ? Quand les langues ne suffisent plus

Tout ce qui précède fait fonctionner plusieurs langues dans une seule boutique, avec un catalogue partagé. C’est le bon modèle pour la plupart des vendeurs internationaux. Mais si vos marchés exigent des catalogues, des structures tarifaires ou une identité de marque réellement différents, pas seulement des traductions de la même boutique, vous êtes entré dans le domaine du multiboutique, une architecture différente avec ses propres compromis. Nous comparons les deux approches et les cas où chacune vaut la peine dans PrestaShop multiboutique. Pour la grande majorité des boutiques, le multilingue sur une seule boutique est plus simple, moins cher à maintenir et largement suffisant.

Les erreurs qui vous coûtent discrètement cher

• Activer une langue avant qu’elle soit traduite. Utilisez l’état désactivé. Une boutique en ligne à moitié en anglais érode la confiance plus vite qu’une absence totale de traduction.
• Traduire le catalogue mais ignorer l’outil Traductions. Produits en allemand, boutons et e-mails en anglais. Ce sont les couches le plus souvent oubliées, parce que la boutique semble terminée.
• Copier l’anglais dans chaque champ de langue. Fait pour éviter les blancs, cela fabrique du contenu dupliqué. Un champ vide se rattrape ; un doublon est une blessure SEO que vous vous infligez.
• Traduire automatiquement les metas et les slugs. Vos URL et extraits de recherche méritent des choix de mots-clés natifs, pas des traductions littérales.
• Oublier les chaînes de modules après chaque nouvelle installation. Chaque module tiers apporte ses propres traductions ; relancez l’outil chaque fois que vous en ajoutez un.

Questions fréquentes

Ajouter une langue client change-t-il la langue de mon back-office ?

Non. Les langues vues par vos clients et la langue utilisée par votre équipe sont séparées. Activer l’allemand pour la boutique ne touche pas à votre administration. Chaque employé définit sa propre langue d’administration dans Paramètres avancés → Équipe → Employés (ou dans ses propres préférences), ce qui vous permet de vendre en six langues pendant que votre équipe d’entrepôt conserve l’admin en anglais.

Pourquoi mon produit est-il traduit alors que le bouton « Ajouter au panier » reste en anglais ?

Parce qu’ils ne vivent pas au même endroit. Le contenu du catalogue (noms de produits, descriptions, CMS) se trouve dans les tables _lang par langue et se traduit via le sélecteur de langue sur chaque page d’édition. Les chaînes d’interface, boutons, libellés, messages d’erreur, e-mails, proviennent des fichiers de traduction et de l’outil Traductions (International → Traductions), dans un flux complètement distinct. Vous devez faire les deux, et relancer l’outil pour chaque module après chaque nouvelle installation.

Dois-je copier le texte anglais dans les champs de langue vides pour éviter les blancs ?

Non, c’est pire que de les laisser vides. Coller l’anglais dans chaque champ de langue fabrique du contenu dupliqué sur vos URL linguistiques, ce qui crée un problème SEO que vous vous infligez vous-même. Un champ vide se rattrape ; un contenu dupliqué est une blessure qu’il faudra nettoyer plus tard. Traduisez correctement, ou laissez le champ vide et traduisez-le ensuite.

Puis-je préparer les traductions sans que les clients voient une boutique à moitié construite ?

Oui, gardez la langue désactivée pendant que vous travaillez. Une langue désactivée reste installée et modifiable, mais n’apparaît pas dans le sélecteur du front-office ; vous pouvez donc traduire en privé les pages CMS, le catalogue, les e-mails et les chaînes de modules, puis l’activer seulement lorsqu’elle est réellement terminée. L’état désactivé existe précisément pour ne jamais exposer une boutique traduite à 70 %.

Dois-je traduire automatiquement mes titres meta et mes slugs d’URL ?

Non. Les titres et descriptions meta sont stockés par langue et doivent être rédigés dans la langue cible par quelqu’un qui recherche dans cette langue. Le meilleur mot-clé en anglais est rarement sa traduction littérale. Les URL simplifiées doivent recevoir un slug localisé par langue (/de/duschrinne, pas le slug anglais recopié partout). Notre module Smart SEO Friendly URL Manager garde ces slugs par langue propres, pour vous éviter de les modifier produit par produit.

Lectures associées

• Balises hreflang, dès que vous avez plusieurs URL linguistiques, c’est ce qui les empêche de se cannibaliser dans les résultats de recherche.
• Multidevise et vente internationale. La devise est un axe séparé de la langue (un Suisse germanophone s’attend au CHF, pas à l’EUR).
• Vendre en Europe, la carte d’ensemble au-dessus des langues, des devises et des règles de TVA dans l’UE.

Une boutique PrestaShop multilingue correctement configurée ouvre des marchés que vos concurrents monolingues ne peuvent pas atteindre, et la plateforme vous donne les mécanismes nécessaires pour le faire proprement, champs de contenu par langue, véritable interface de traduction, formats et URL localisés. Le travail ne tient pas à un réglage unique ; il consiste à savoir qu’il existe cinq couches de texte, à les traiter dans un ordre qui n’expose jamais une boutique à moitié construite, et à garder la langue, la devise et le SEO comme les problèmes distincts qu’ils sont vraiment. Respectez la séquence, et la boutique se lit comme si elle avait été conçue nativement dans chaque langue. Ce qui, pour le client qui décide s’il peut vous confier son paiement, change tout.