Traduction WordPress : agence pour site multilingue

Traduction WordPress : le plugin ne remplace pas le travail linguistique

Votre site WordPress est prêt à s’ouvrir à un nouveau marché. Vous avez choisi une langue cible, installé une solution multilingue et identifié les pages prioritaires. Pourtant, une traduction WordPress ne se résume pas à dupliquer des pages puis à remplacer leur texte.

Le contenu visible n’est qu’une partie du projet. Menus, formulaires, messages d’erreur, champs personnalisés, métadonnées, boutons, chaînes du thème, extensions et éléments WooCommerce peuvent suivre des circuits différents. Une traduction correcte dans un fichier peut donc rester invisible ou être réintégrée au mauvais endroit.

L’enjeu est de faire travailler ensemble le CMS, le dispositif multilingue et le processus de traduction. Pour le cadrage général d’un projet web international, notre guide consacré à la traduction d’un site internet détaille les décisions à prendre avant le lancement.

Cette page se concentre sur WordPress : ce qu’il faut extraire, traduire, réviser, réintégrer et contrôler pour obtenir des versions linguistiques réellement exploitables.

Que faut-il vraiment traduire dans WordPress ?

Une page WordPress n’est pas un document figé. Ce que voit l’internaute peut provenir de l’éditeur principal, de blocs Gutenberg, de champs personnalisés, du thème, d’un constructeur de pages, d’une extension ou d’un service tiers.

Le premier travail consiste donc à identifier les contenus réellement porteurs de sens avant de lancer la traduction. Une extraction incomplète produit mécaniquement une version linguistique incomplète.

Les pages et publications ne sont que le premier niveau

Les contenus éditoriaux classiques restent les éléments les plus visibles : pages de service, fiches produit, articles, catégories, descriptions, pages institutionnelles ou ressources téléchargeables.

La traduction d’une page ne doit pourtant pas s’arrêter à son corps principal. Titre SEO, meta description, slug lorsque l’architecture le prévoit, légendes, textes alternatifs utiles, appels à l’action et blocs réutilisables font partie du périmètre linguistique.

Un site peut ainsi sembler traduit au premier regard tout en conservant des fragments français dans les endroits les plus importants du parcours.

Menus, en-têtes, pieds de page et widgets

Le menu principal, le pied de page, les coordonnées, les bandeaux, les blocs de réassurance ou les widgets ne sont pas toujours stockés avec la page qui les affiche.

Selon le thème et l’extension multilingue, ces textes peuvent être gérés dans des options globales, des modèles, des zones de widgets ou une interface dédiée aux chaînes de caractères.

Ils doivent donc être recensés séparément. Un bouton oublié dans la langue source suffit à donner l’impression d’une version secondaire mal finalisée.

Formulaires et messages système

Un formulaire traduit doit conserver une logique complète. Les libellés visibles comptent, mais aussi les textes d’aide, les consentements, les validations, les erreurs, la page de confirmation et, si nécessaire, les emails générés après l’envoi.

Un cas type illustre bien le problème. Une entreprise traduit ses principales pages commerciales en allemand. Le formulaire est visuellement en allemand, mais le message d’erreur et l’email de confirmation restent en français. Linguistiquement, la page est traduite. Commercialement, le parcours utilisateur ne l’est pas.

Champs personnalisés et constructeurs de pages

Elementor, Divi, Gutenberg, Advanced Custom Fields et les développements spécifiques peuvent stocker des contenus hors du champ éditorial standard.

Le traducteur ne doit pas avoir à deviner où se trouve chaque chaîne. Le responsable du projet doit identifier les contenus traduisibles, leur contexte et leur format d’échange.

Le contexte compte autant que le texte lui-même. Un mot identique peut demander une traduction différente selon qu’il s’agit d’un bouton, d’une validation technique ou d’une instruction administrative.

Thèmes et extensions : distinguer contenu et localisation logicielle

WordPress distingue l’internationalisation d’un thème ou d’une extension et sa localisation. L’internationalisation prépare le code afin que ses chaînes puissent être traduites. La localisation fournit ensuite les traductions adaptées à une langue ou une locale.

La documentation officielle WordPress confirme l’utilisation du système gettext et des domaines de texte pour rendre les chaînes des extensions traduisibles.

Pour une entreprise utilisant un thème ou une extension déjà internationalisés, la question n’est donc pas de traduire leur code. Il faut identifier les chaînes standard déjà localisées et celles qui sont propres au site, à la marque ou au paramétrage spécifique.

Pourquoi WordPress change-t-il le workflow de traduction ?

Dans un fichier Word, le périmètre est visible. Sur WordPress, le texte est réparti entre plusieurs couches techniques. Le workflow doit donc préserver les relations entre contenu source, traduction, identifiant de page, langue et emplacement d’affichage.

WordPress justifie des workflows dédiés par son poids sur le web. D’après W3Techs (Usage statistics of WordPress for websites, septembre 2026), WordPress est utilisé par 40,7 % de l’ensemble des sites web et représente 58,9 % des sites dont le CMS est identifié. Pour un projet multilingue, l’enjeu n’est donc plus seulement de traduire du texte, mais de sécuriser son cycle de vie dans le CMS.

W3Techs, statistiques d’usage de WordPress

La documentation officielle WordPress indique que le cœur du CMS ne fournit pas actuellement une gestion complète d’un site bilingue ou multilingue prête à l’emploi. Des extensions ou des architectures distinctes par langue assurent cette fonction.

Cette couche multilingue influence directement la manière dont une agence récupère et restitue les textes. Il faut donc connaître l’architecture avant de chiffrer le traitement.

Le plugin multilingue organise les versions, il ne garantit pas leur qualité

WPML, Polylang, TranslatePress ou Weglot n’ont pas exactement la même logique. Certains relient des publications traduites. D’autres mettent davantage l’accent sur la gestion des chaînes, l’édition en contexte ou une couche de service externe.

Ces solutions peuvent faciliter la diffusion, l’extraction ou la synchronisation. Elles ne remplacent cependant ni le choix terminologique, ni l’adaptation culturelle, ni la révision linguistique.

La bonne question n’est donc pas seulement « quel plugin choisir ? ». Il faut déterminer quel workflow permettra de faire circuler le contenu entre WordPress, les linguistes et la validation finale sans perdre d’information.

WPML : un workflow adapté aux échanges structurés

La documentation WPML permet d’exporter des travaux de traduction en XLIFF, de transmettre ces fichiers à des traducteurs externes puis de les réimporter dans WordPress.

Ce format est utile lorsqu’une agence doit conserver une structure exploitable pour les segments et leur rattachement au contenu. WPML permet également d’inclure des notes destinées aux traducteurs dans les fichiers XLIFF.

Le contenu ne circule donc pas nécessairement sous forme de copier-coller répartis dans plusieurs documents. La traçabilité du flux peut être mieux maîtrisée.

Polylang : bien distinguer publications et chaînes

Polylang Pro propose un module d’import et d’export des traductions de chaînes. Sa documentation officielle prévoit les formats PO et XLIFF, avec possibilité d’exporter des groupes de chaînes puis de réimporter les fichiers traduits.

Dans un projet professionnel, il faut déterminer avant le lancement quels contenus sont gérés comme publications et lesquels apparaissent dans les options du thème, des widgets ou des extensions.

TranslatePress : contrôler le contenu dans son contexte visuel

TranslatePress propose un éditeur de traduction accessible depuis WordPress. Sa documentation décrit une traduction page par page et chaîne par chaîne, directement depuis un aperçu du site.

Ce fonctionnement facilite l’identification d’un bouton, d’un élément d’interface ou d’une chaîne visible. L’outil permet aussi de rechercher certaines chaînes qui ne sont pas directement visibles, comme des titres SEO ou des meta descriptions selon la configuration.

Le contexte visuel facilite la compréhension, mais il ne remplace pas un glossaire partagé ni une révision globale de la terminologie.

Weglot : intégrer une couche multilingue dans WordPress

La documentation Weglot décrit une intégration WordPress via son extension, avec configuration d’une langue source et d’une ou plusieurs langues cibles.

Cette approche peut simplifier le déploiement technique. Pour un acheteur B2B, la question reste toutefois la même : quels contenus nécessitent un niveau de traduction humaine et de contrôle supérieur en raison de leur visibilité, de leur sensibilité ou de leur rôle commercial ?

Il n’existe donc pas de « meilleur plugin » valable pour tous les projets. Le choix dépend de l’existant, du volume, du contrôle attendu et de la façon dont vos équipes maintiendront les traductions après la première mise en ligne.

Quel workflow choisir pour faire traduire un site WordPress ?

Le bon workflow est celui qui limite les manipulations manuelles tout en donnant suffisamment de contexte aux linguistes.

Une règle simple évite une grande partie des problèmes : effectuer un test complet sur une page représentative avant d’exporter tout le site.

Le test doit couvrir la sortie de WordPress, la traduction, la révision, la réimportation et l’affichage final. Il révèle les chaînes manquantes et les limitations techniques avant qu’elles affectent l’ensemble du projet.

Si votre projet combine un volume important et un premier jet automatique, notre service de post-édition de traduction automatique permet de cadrer séparément la reprise humaine.

Notre méthode pour une traduction WordPress contrôlée

Chez Traducteo, un projet WordPress doit être cadré comme un projet linguistique intégré au CMS. L’objectif n’est pas de modifier votre architecture, mais de faire circuler les contenus sans perdre leur contexte.

1. Cartographier WordPress avant l’extraction

Nous identifions les types de contenus, les langues cibles, l’extension multilingue, les constructeurs de pages et les zones susceptibles de porter du texte.

Cette phase évite une erreur fréquente : chiffrer uniquement les pages accessibles depuis le menu principal alors que le site contient aussi des modèles, formulaires, catégories, fiches, taxonomies ou contenus dynamiques.

Un cas réaliste revient souvent sur les sites construits au fil des années. Le responsable marketing connaît les pages principales. L’examen du site révèle en parallèle des modèles, blocs réutilisés et formulaires. Le problème n’est alors pas le prix au mot, mais le périmètre initial.

2. Définir ce qui doit être traduit et ce qui doit rester inchangé

Tout texte visible ne doit pas forcément être traduit. Noms de marque, références produit, termes déposés, identifiants techniques et certaines chaînes peuvent devoir rester identiques.

Un glossaire de départ permet de fixer ces décisions. Il évite les variations d’une page à l’autre lorsque plusieurs linguistes interviennent ou lorsque le projet se poursuit dans le temps.

La différence entre logiciel de traduction, TAO et traduction automatique est également importante ici. Une mémoire de traduction aide un professionnel à conserver les segments validés. Elle ne doit pas être confondue avec un moteur de traduction automatique.

3. Valider un format d’échange

Le format dépend de votre configuration. Il peut s’agir de XLIFF, PO, fichiers structurés, exports de contenus ou d’un accès limité à une interface de traduction.

Le format choisi doit préserver le contexte et permettre une réintégration fiable. Un fichier contenant des milliers de phrases sans indication de page ou de fonction augmente le risque d’erreur.

4. Traduire avec un linguiste adapté au secteur

La maîtrise de la langue ne suffit pas lorsqu’un site comporte de la terminologie juridique, médicale, scientifique, industrielle ou financière.

Un WordPress d’entreprise peut mélanger plusieurs registres. Les pages institutionnelles portent la marque. Les fiches techniques exigent une terminologie stable. Les conditions contractuelles engagent d’autres enjeux.

Traducteo organise ses prestations selon la nature du contenu et le domaine concerné. La page consacrée à la traduction par secteur d’activité présente cette logique de spécialisation.

5. Faire intervenir un second linguiste pour la révision

Traducteo est certifiée ISO 17100. La norme encadre les processus, ressources et compétences nécessaires à la prestation de traduction. Dans le processus de traduction humaine décrit par l’agence, la traduction est suivie d’une révision par un second linguiste.

Une personne relisant son propre travail peut corriger des fautes. Une révision comparative menée par une autre personne constitue un contrôle distinct.

Sur WordPress, la révision doit aussi surveiller la cohérence entre les pages. Un même service ne doit pas changer de nom entre le menu, la landing page et le formulaire.

6. Réimporter puis contrôler en contexte

Une traduction peut être correcte dans l’outil linguistique et imparfaite une fois publiée. Les langues n’occupent pas le même espace. Un bouton peut devenir trop long. Un menu peut passer sur deux lignes. Une variable peut casser une phrase.

La dernière vérification doit donc se faire dans son environnement réel.

Ce contrôle permet aussi de repérer une chaîne de panier, un message injecté par une extension ou une option du thème qui n’avait pas été incluse dans l’extraction initiale.

Comment éviter les chaînes non traduites dans WordPress ?

Les chaînes oubliées constituent l’un des défauts les plus visibles d’un site WordPress multilingue. Elles donnent immédiatement l’impression d’une version secondaire inachevée.

La documentation WordPress distingue notamment les contenus du site et les ressources de localisation des thèmes ou extensions. Les solutions multilingues ajoutent leurs propres mécanismes pour gérer d’autres chaînes.

Commencer par les éléments partagés sur tout le site

Le header et le footer doivent être contrôlés en priorité. Une chaîne oubliée à cet endroit peut apparaître sur un grand nombre de pages.

Viennent ensuite les modèles de pages, menus secondaires, widgets, formulaires, pop-ups et blocs réutilisables.

La vérification par modèle est souvent plus efficace qu’une vérification page par page. Corriger une chaîne globale à sa source évite de traiter plusieurs symptômes identiques.

Tester les parcours, pas seulement les pages

Un site doit être testé comme le ferait un visiteur réel.

Il faut ouvrir un formulaire, provoquer une erreur, valider une demande, naviguer vers une page de confirmation et, sur un site marchand, parcourir les étapes du panier et du paiement.

Ce parcours fait apparaître des textes qui ne se voient jamais pendant une simple lecture de la page d’accueil.

Prévoir WooCommerce comme un sous-projet

Sur WooCommerce, le périmètre peut comprendre les fiches produit, catégories, attributs, filtres, panier, tunnel de commande, emails, coupons, messages de stock et extensions de paiement.

Un site peut traduire parfaitement ses fiches produit tout en laissant des filtres ou messages du panier dans la langue source. L’utilisateur comprend ce qui est vendu, puis rencontre une interface incohérente au moment d’acheter.

Pour éviter cette rupture, le périmètre linguistique doit suivre le parcours d’achat complet.

Comment préserver la confidentialité d’un projet WordPress ?

Un projet WordPress peut donner accès à des pages non publiées, catalogues produits, documents internes, zones de préproduction ou paramètres de l’administration. La confidentialité ne doit donc pas être traitée après coup.

Traducteo présente la confidentialité des documents confiés comme un élément de son processus. Pour un projet WordPress, cette exigence doit aussi se traduire dans la manière dont les contenus et les accès sont transmis.

Privilégier l’échange le moins exposant

Lorsque des fichiers XLIFF, PO ou des exports structurés apportent suffisamment de contexte, ils peuvent éviter d’ouvrir un accès plus large au CMS.

Lorsque le contrôle dans WordPress est nécessaire, un compte limité ou un environnement de préproduction peut être plus adapté qu’un accès administrateur complet.

Ne pas transmettre des données inutiles à la traduction

Les réponses historiques de formulaires, comptes clients ou données utilisateurs n’ont généralement aucune utilité pour traduire une page ou une interface.

Le périmètre transmis doit donc être limité aux contenus nécessaires à la mission.

Cadrer les accès avant le lancement

Avant le premier échange, identifiez qui intervient, quels fichiers seront transmis, quels espaces doivent être accessibles et quels droits sont réellement utiles.

Cette discipline réduit les ambiguïtés et facilite la fermeture des accès temporaires à la fin du projet.

Traduction WordPress et référencement : quels contrôles sont indispensables ?

Cette page n’a pas vocation à transformer un projet de traduction en audit SEO international. Quelques contrôles sont néanmoins indispensables pour que les versions traduites soient accessibles et compréhensibles par les moteurs.

Une URL identifiable pour chaque version

Google recommande des URL distinctes pour chaque version linguistique d’une page plutôt qu’une adaptation fondée uniquement sur des cookies ou les réglages du navigateur.

Google recommande également d’utiliser les annotations hreflang lorsque plusieurs URL correspondent à différentes langues, afin d’aider le moteur à associer la bonne version au bon utilisateur.

WordPress et l’extension multilingue doivent donc produire une structure stable. Le traducteur n’a pas à choisir seul entre sous-répertoire, sous-domaine ou domaine distinct, mais ce choix conditionne la livraison des slugs, balises et liens internes.

Ne pas traduire littéralement les mots-clés

Une expression commerciale française n’a aucune raison d’avoir le même comportement de recherche une fois transposée mot pour mot.

Lorsque la visibilité organique est un objectif, les intitulés stratégiques doivent être validés pour la langue cible avant de figer les principaux titres et métadonnées.

Il ne s’agit pas de transformer chaque traducteur en consultant SEO. Il s’agit d’éviter un équivalent linguistique qui ne correspond pas au vocabulaire réellement recherché sur le marché cible.

Contrôler les titres, descriptions et slugs séparément

Un titre SEO impose une contrainte et une intention différentes du texte courant. Une meta description doit rester persuasive. Un slug doit être lisible et compatible avec la structure retenue.

Ces éléments ne doivent pas être traités comme une colonne résiduelle ajoutée à la fin du projet.

Vérifier les liens entre les versions

Une migration multilingue peut laisser des liens internes pointant vers la mauvaise langue. Le contenu est alors traduit, mais l’utilisateur revient vers la version source au premier clic.

Une vérification de navigation permet de détecter ces ruptures avant publication.

Traduction humaine, automatique ou post-édition sur WordPress ?

WordPress permet d’automatiser une partie importante du traitement. Cela ne signifie pas que tous les contenus doivent suivre le même niveau de traduction.

Une page d’accueil, une page de service stratégique ou un contenu juridiquement sensible n’ont pas le même enjeu qu’une archive ou un catalogue standardisé à faible exposition. La décision dépend du risque, du volume et du rôle du contenu.

La norme ISO 17100:2015 ne couvre pas l’utilisation du résultat brut d’une traduction automatique accompagnée de post-édition. Ce périmètre est explicitement indiqué par l’ISO.

Une erreur d’achat fréquente consiste à choisir la traduction automatique pour l’intégralité du site simplement parce qu’elle est disponible dans le plugin. La facilité technique d’activation ne dit rien du niveau de qualité nécessaire à une page donnée.

Pour comprendre le fonctionnement de ces moteurs sans les confondre avec une mémoire de traduction ou un outil de TAO, consultez notre dossier sur la traduction automatique neuronale.

Combien coûte une traduction WordPress ?

Un tarif sérieux ne peut pas être déduit uniquement du nombre de pages affichées dans WordPress.

Le coût dépend du volume réellement traduisible, des langues, du degré de spécialisation, du type de workflow, du niveau de répétition, de la qualité de l’extraction et des contrôles demandés après intégration.

Le volume éditorial

Le nombre de mots source constitue une base de calcul, mais il doit correspondre au périmètre réel. Une page courte utilisant de nombreux blocs globaux peut générer peu de nouveaux mots. À l’inverse, une page simple en apparence peut mobiliser plusieurs champs invisibles depuis l’éditeur principal.

Le format de livraison

Un fichier Word propre n’implique pas le même travail qu’un export WordPress complexe, un XLIFF, un lot de chaînes ou une intégration nécessitant des contrôles particuliers.

Le traitement technique doit donc être distingué du travail linguistique lorsque le workflow le justifie.

Les répétitions et la mémoire de traduction

Un site contient souvent des formulations récurrentes. Une mémoire de traduction permet d’identifier les segments déjà validés et de maintenir leur cohérence.

Elle est particulièrement utile lors des mises à jour. Une nouvelle version d’une page ne signifie pas qu’il faut retraduire tout ce qui n’a pas changé.

La spécialisation

Un catalogue industriel, une plateforme médicale et un site de conseil n’exigent pas le même profil linguistique.

Un tarif bas obtenu en confiant un texte spécialisé à une personne qui ne maîtrise pas son domaine peut entraîner une reprise coûteuse.

L’intégration et le contrôle final

Un devis WordPress doit indiquer clairement si la prestation s’arrête à la livraison des textes ou si elle comprend une phase de contrôle après import.

Comparer deux devis uniquement sur le prix au mot peut donc masquer une différence de périmètre plus importante que l’écart de tarif. Notre page dédiée au prix d’une traduction professionnelle explique les principales variables à comparer.

Comment préparer votre WordPress avant de demander un devis ?

Quelques informations bien préparées permettent d’obtenir un devis beaucoup plus précis et d’éviter les échanges inutiles.

• indiquez l’URL du site et les langues source et cible ;
• précisez l’extension multilingue déjà utilisée, si elle existe ;
• signalez WooCommerce, les constructeurs de pages et les champs personnalisés ;
• définissez les contenus prioritaires et l’échéance de mise en ligne ;
• transmettez votre glossaire, guide de style ou terminologie existante.

Ne traduisez pas tout avant d’avoir défini les priorités

Une entreprise peut avoir intérêt à commencer par le parcours commercial le plus important plutôt que par l’intégralité de ses archives.

Les pages qui présentent l’offre, répondent aux objections et conduisent au contact sont souvent prioritaires. Les ressources secondaires peuvent suivre une fois le marché et le workflow validés.

Figez une version pendant le lot de traduction

Modifier en permanence les pages sources alors qu’elles sont en traduction crée des écarts difficiles à suivre.

Pour un projet important, mieux vaut définir un lot, une version de référence et un processus distinct pour les modifications ultérieures.

Un responsable export peut autrement découvrir au moment de la recette que plusieurs pages ont évolué entre l’extraction et la livraison. Le problème ne vient alors ni du traducteur ni du plugin, mais de l’absence de gestion des versions.

Pourquoi confier la traduction WordPress à une agence spécialisée ?

Un plugin sait organiser, afficher ou automatiser des traductions. Une agence intervient sur la qualité linguistique, le processus, la spécialisation et les contrôles. Les deux rôles sont complémentaires.

Pour conserver une terminologie cohérente

Une entreprise utilise souvent les mêmes termes pendant plusieurs années. Le glossaire et la mémoire de traduction permettent de capitaliser sur les décisions déjà validées.

Cette continuité compte particulièrement lorsqu’un WordPress évolue régulièrement avec de nouvelles pages, produits ou contenus.

Pour adapter le niveau de traduction au risque

Un même site peut contenir une page commerciale, une notice technique, un formulaire sensible et des archives de blog.

Appliquer le même workflow à tout le site n’est pas toujours rationnel. Une agence peut séparer les traitements selon la valeur et la sensibilité des contenus.

Pour bénéficier d’un processus encadré

Traducteo est certifiée ISO 17100 pour ses prestations de traduction. La norme encadre les processus et ressources nécessaires à la prestation de traduction.

ISO 17100 doit être comprise comme une norme de processus, pas comme une promesse de perfection. D’après l’ISO, l’édition publiée ISO 17100:2015 définit des exigences relatives aux processus, ressources et autres aspects nécessaires à la prestation. En septembre 2026, cette édition reste publiée, tandis qu’une deuxième édition est en préparation.

ISO, exigences relatives aux services de traduction

Pour disposer d’un interlocuteur responsable du périmètre

Sur un projet WordPress, les difficultés ne viennent pas toutes de la langue. Une chaîne absente, un export incomplet ou une page non synchronisée peuvent bloquer le travail.

Un interlocuteur central permet de distinguer rapidement ce qui relève de la traduction, de l’intégration ou de votre prestataire technique.

Les expériences publiées par les clients permettent également d’évaluer la manière dont l’agence travaille sur des projets professionnels. Consultez les témoignages clients de Traducteo.

Un WordPress multilingue doit rester maintenable après sa mise en ligne

La première traduction n’est que le début du cycle de vie d’un site. WordPress évolue : nouvelles pages, modifications d’offres, mises à jour produits, campagnes, contenus et changements d’interface.

Le véritable bénéfice d’un workflow bien conçu apparaît à ce moment-là.

Vous savez quels contenus sont traduisibles. Vous disposez d’un glossaire. Les segments déjà validés peuvent être réutilisés. Les nouvelles chaînes suivent le même processus de contrôle. Les versions linguistiques restent alignées sans reconstruire le projet à chaque modification.

À l’inverse, un site traduit ponctuellement par copier-coller devient rapidement difficile à maintenir. Certaines pages évoluent, d’autres non. Les termes divergent et personne ne sait quelle version constitue la référence.

Pour approfondir le cadre général d’une prestation web multilingue, découvrez notre agence de traduction de sites internet.

Vos questions fréquentes sur la traduction WordPress

Traducteo, agence de traduction certifiée ISO 17100

Agence de traduction professionnelle basée à Pantin. Chaque traduction est confiée à un traducteur natif spécialisé, puis relue par un second linguiste, conformément à la norme ISO 17100.