Comment traduire une boutique PrestaShop sans la casser

Ajouter une langue à PrestaShop prend environ deux minutes. Vous ouvrez le back office, installez la langue, et elle apparaît dans le sélecteur en front office. Puis vous visitez la nouvelle version de votre boutique et vous constatez le même problème que tout le monde : l'interface est traduite, mais pas votre boutique en elle-même.

C'est là que la plupart des projets de traduction PrestaShop déraillent. Non pas parce que les outils sont mauvais, mais parce que l'on comprend mal ce que PrestaShop fait déjà pour vous et ce qu'il laisse délibérément vide.

PrestaShop est déjà multilingue. Cela change tout

WordPress a besoin d'un plugin pour avoir simplement la notion d'une seconde langue. PrestaShop, non. Chaque contenu traduisible est stocké dans une table de langue dédiée : produits, catégories, pages CMS, méta-titres, réécriture d'URLs. La boutique a été conçue multilingue dès le départ.

La question n'est donc jamais « comment rendre ma boutique multilingue ». Elle l'est déjà. La vraie question est : « comment remplir des milliers de lignes vides sans faire appel à une agence et sans détruire mes URLs ? »

Cette distinction est essentielle, car elle élimine toute une catégorie d'outils avant même que vous ne commenciez à les comparer.

Ce que le pack de langue officiel vous apporte réellement

Lorsque vous installez une langue, PrestaShop télécharge le pack de langue communautaire. Il est gratuit et véritablement utile, mais son périmètre est limité, et il vaut mieux le connaître précisément.

Le pack remplit les chaînes de l'interface ainsi qu'une courte liste de lignes en base de données : les pages statiques par défaut et leurs réécritures d'URLs, les attributs de couleur et de taille standard, les statuts de commande, les délais de livraison des transporteurs et les catégories par défaut. Sur une boutique vierge, cela représente quelques dizaines de lignes.

Ce qu'il ne touche jamais : votre catalogue produits et vos pages CMS. Pas un seul nom de produit, pas une seule description, pas une seule page personnalisée. Ce sont vos contenus, et le pack les laisse intacts.

C'est la frontière exacte du travail. Tout ce que le pack couvre, vous ne devriez jamais payer une IA pour le traduire. Tout ce qui va au-delà constitue le vrai chantier.

Le piège de l'overlay

Beaucoup d'outils de traduction, en particulier ceux importés du monde WordPress, fonctionnent en réécrivant la page au moment où elle est envoyée au navigateur. La boutique reste monolingue en dessous, et une couche substitue le texte à la volée.

Sur PrestaShop, c'est un mauvais choix, pour des raisons qui n'apparaissent qu'après quelques semaines plutôt que dès le premier jour.

Votre boutique ignore l'existence des pages traduites. Le sitemap, les balises hreflang, les URLs canoniques et les données structurées décrivent tous une boutique en une seule langue. Les moteurs de recherche indexent ce que PrestaShop déclare, pas ce qu'un overlay affiche par-dessus.

Les contenus transactionnels restent en retrait. Les emails de confirmation de commande, les factures et les bons de livraison PDF sont générés côté serveur, en dehors de la page que l'overlay intercepte. Les clients reçoivent une boutique traduite et un email dans la mauvaise langue.

Vous payez aussi deux fois pour la partie gratuite. Un overlay traduit tout ce qui est visible à l'écran, y compris les chaînes d'interface et les statuts de commande que le pack de langue a déjà livrés gratuitement.

Et si vous gérez déjà une boutique multilingue, un overlay est tout simplement incompatible avec elle. Vous vous retrouvez avec deux sources contradictoires pour le même contenu.

Le dernier problème est celui qui coûte le plus cher par la suite : désactivez l'outil et toutes les pages traduites disparaissent d'un seul coup.

Remplir les tables natives à la place

L'alternative est moins spectaculaire, mais bien plus solide : écrire les traductions directement dans les tables de langue qu'utilise déjà PrestaShop.

Une fois ces lignes renseignées, PrestaShop prend en charge le reste du travail, parce que c'est précisément pour cela qu'il a été conçu. Le routage, les balises hreflang, le sitemap, le sélecteur de langue déjà présent dans votre thème, les emails, les factures PDF. Rien de tout cela ne nécessite un plugin. Cela nécessite des données.

Cela signifie aussi que les traductions vous appartiennent au sens propre du terme. Elles se trouvent dans votre propre base de données, dans vos propres sauvegardes, dans vos propres exports. Désactivez le module qui les a écrites, et les pages traduites continuent de fonctionner.

C'est l'approche qu'adopte le module PrestaShop TrueLang : catalogue, déclinaisons, caractéristiques, catégories, pages CMS, filtres de recherche à facettes, réécriture d'URLs et champs meta, écrits nativement, sur PrestaShop 1.7.6 à 8.x.

Les URLs : là où les boutiques en ligne se font vraiment du mal

Si vous traduisez quoi que ce soit sur une boutique qui génère déjà du trafic, lisez cette section deux fois.

Les routes par défaut de PrestaShop contiennent l'identifiant de l'objet, comme /3-clothes ou /content/1-delivery. Comme l'identifiant est présent dans l'URL, modifier la réécriture ne casse pas l'ancienne adresse : le contrôleur frontal reconnaît l'identifiant et redirige vers la nouvelle. Cela vous protège pour les produits et les catégories.

Les pages statiques font exception. Leurs réécritures ne contiennent pas d'identifiant, donc dès que vous en traduisez une, l'ancienne adresse devient une véritable erreur 404. Si ces pages ont des backlinks ou sont indexées, vous avez besoin de redirections depuis les anciennes adresses, pas de bonnes intentions.

Les URLs traduites restent malgré tout pertinentes. Un /femmes/robes-ete est plus efficace qu'un /3-summer-dresses dans un SERP francophone. Faites-le simplement avec un plan de redirection en place, plutôt qu'après la chute du trafic. Cette même rigueur s'applique à toute migration multilingue : les positions que vous avez déjà acquises sont le capital à protéger.

Le tunnel de commande, les emails et les factures font partie de la boutique

Il est tentant de crier victoire une fois que les pages produits semblent correctes. Mais les clients ne s'arrêtent pas aux pages produits.

Les libellés du tunnel de commande, les textes des étapes de paiement, les emails de confirmation de commande, les factures et les bons de livraison font tous partie de l'expérience d'achat. Ce sont précisément les endroits où une boutique à moitié traduite perd la confiance du client au moment exact où elle s'apprêtait à gagner de l'argent. Une approche native les couvre, car PrestaShop les génère à partir des mêmes tables de langue.

Protégez ce que vous avez déjà rédigé

Deux règles permettent d'éviter une quantité énorme de corrections par la suite.

Ne jamais écraser le travail humain. Si quelqu'un dans votre équipe a réécrit une description de produit en allemand, aucun traitement automatisé ne devrait y toucher de nouveau. Un champ modifié à la main doit être reconnu comme tel et laissé tel quel, définitivement.

Maintenez un glossaire. Les noms de marque, les gammes de produits, les termes métier, les mots que vous ne voulez jamais voir traduits. La traduction par IA est aujourd'hui suffisamment bonne pour que les erreurs soient rarement grammaticales. Ce sont des erreurs de terminologie : votre nom de modèle transformé en nom commun, votre marque déposée aimablement localisée. Un glossaire prend dix minutes à constituer et prévient tout cela.

Ce que cela devrait coûter

La tarification de la traduction est ce qui transforme un projet normal en dépense opérationnelle imprévisible. Les outils par abonnement vous facturent chaque mois pour des pages que vous avez traduites une fois et publiées il y a longtemps, et la facture grossit avec votre catalogue.

Pour une boutique, ce modèle est à l'envers. Un catalogue n'est pas un flux, c'est un stock. Vous traduisez un produit une fois et il se vend pendant deux ans.

La tarification à la consommation est bien plus adaptée : vous payez pour le travail de traduction que vous effectuez réellement, et rien pendant que votre catalogue est en ligne et génère des ventes. Les licences TrueLang sont livrées avec 5 EUR de crédit inclus, soit environ une centaine de pages traduites dans deux langues, sans abonnement derrière. Si vous souhaitez le détail du calcul, nous l'avons expliqué dans combien coûte la traduction d'un site web.

Un ordre des opérations raisonnable

1. Installez d'abord le pack de langue officiel pour chaque langue cible. Il est gratuit et couvre l'interface.
2. Vérifiez votre langue source. Sur PrestaShop, la source est la langue dans laquelle votre contenu a réellement été rédigé, ce qui n'est pas toujours la langue par défaut de la boutique.
3. Traduisez le catalogue et les pages CMS. C'est la partie que rien d'autre ne couvre.
4. Relisez les pages qui vendent : meilleures ventes, pages d'atterrissage, politiques de livraison et de retour.
5. Mettez en place des redirections pour toute page statique dont l'URL a changé.
6. Vérifiez une fois les balises hreflang et le sitemap, en front office. Si les traductions sont dans les tables natives, PrestaShop les génère tous les deux correctement de lui-même.

En résumé

PrestaShop sait déjà être multilingue. Il est simplement livré avec les rayons vides.

Remplissez ces rayons correctement, dans les tables propres à la plateforme, et tout ce qui en découle fonctionne comme prévu : URLs, SEO, emails, factures, et des traductions qui restent les vôtres quelle que soit la décision que vous prendrez plus tard concernant l'outil qui les a produites.