Une centaine de fiches produit, trois langues de destination, et pour seule ressource humaine une chargée de communication qui parle correctement l’espagnol mais pas le portugais. C’est la situation de départ d’une coopérative de pêcheurs du Finistère qui vend une partie de sa production à des mareyeurs et des restaurateurs en Espagne et au Portugal. Aucun budget n’avait été prévu pour la traduction du site : elle a été ajoutée après coup, quand les commandes internationales ont commencé à représenter une part significative du chiffre d’affaires.
Ce texte n’est pas une démonstration d’extension miracle. C’est le récit des compromis retenus, de ce qu’ils ont coûté en temps et en qualité, et de ce qu’on referait différemment avec un peu plus de recul.
Le constat : une rédactrice, trois langues, aucun outil
Le site tournait sous WordPress avec Polylang en version gratuite, installé par le prestataire initial pour gérer le français et l’anglais des pages institutionnelles. Les fiches produit, elles, n’avaient jamais été traduites : elles vivaient en français dans un Custom Post Type produit, avec des champs ACF pour le poids, le calibre et le mode de conservation.
Face à la demande de clients espagnols récurrents, la direction a décidé de traduire le catalogue sans recruter de traducteur professionnel ni souscrire à une extension de traduction automatique payante. La chargée de communication, seule disponible, a hérité du dossier en plus de ses missions habituelles.
Le compromis retenu : traduire par lots, pas fiche par fiche
Traduire une fiche à la fois, dans l’éditeur WordPress, se serait révélé beaucoup trop lent : chaque fiche contient une dizaine de champs répartis entre le contenu principal et les champs personnalisés. La solution retenue a consisté à exporter l’ensemble du catalogue au format CSV via WP All Export, à faire traduire les colonnes de texte par la rédactrice en espagnol dans un tableur partagé, puis à réimporter les traductions comme des articles Polylang liés aux originaux avec WP All Import.
Le rôle central d’un glossaire partagé en tableur
Le vrai levier de cohérence n’a pas été un outil de traduction, mais un onglet supplémentaire dans le même tableur : un glossaire de quarante termes récurrents (noms d’espèces, modes de pêche, mentions de fraîcheur) avec leur traduction validée une bonne fois pour toutes. Sans cette liste, chaque fiche aurait pu voir « poisson entier vidé » traduit de trois façons différentes selon l’humeur du moment.
- Une colonne « terme source » et une colonne « traduction validée », triées par ordre alphabétique.
- Un onglet séparé par langue, pour ne pas mélanger l’espagnol et le portugais dans les mêmes recherches.
- Une relecture croisée : la rédactrice traduit, un collègue bilingue relit avant réimport.
Un tableur bien tenu vaut souvent mieux qu’une extension mal comprise : ce qui compte, c’est la discipline de mise à jour, pas l’outil lui-même.
Ce qu’a coûté l’absence de mémoire de traduction
Le vrai manque s’est fait sentir six mois plus tard, quand il a fallu ajouter le portugais après avoir déjà traduit en espagnol. Sans mémoire de traduction, chaque phrase a dû être retraduite depuis le français, alors qu’une partie du vocabulaire commun (les mentions réglementaires, les unités de poids) aurait pu être réutilisée directement depuis l’espagnol vers un pivot commun.
| Étape | Temps estimé | Écueil rencontré |
|---|---|---|
| Export CSV du catalogue | 1 heure | Champs ACF mal mappés à la première tentative |
| Traduction espagnole | 3 semaines à temps partiel | Incohérences avant la mise en place du glossaire |
| Réimport et vérification Polylang | 2 jours | Liaisons de traduction à recontrôler une à une |
| Ajout du portugais | 4 semaines | Aucune réutilisation du travail déjà fait |
Les limites atteintes au bout d’un an
Passé la mise en ligne initiale, la maintenance des traductions est devenue le vrai point de friction. Chaque nouveau produit ajouté au catalogue français nécessitait une relance manuelle : rien ne signalait automatiquement qu’une fiche existait en français sans équivalent espagnol ou portugais. Le contrôle reposait entièrement sur la mémoire de la personne en charge, ce qui a fini par laisser passer plusieurs oublis, découverts par des clients étrangers plutôt que par l’équipe.
Un filtre simple dans l’administration, listant les fiches du Custom Post Type produit sans traduction associée pour une langue donnée, aurait suffi à éviter ces oublis. Il n’a été mis en place que l’année suivante, avec une requête WP_Query croisant les identifiants de traduction Polylang.
En résumé
Traduire un catalogue sans budget dédié, c’est possible à petite échelle, à condition d’accepter deux règles simples : traiter les traductions par lots plutôt que fiche par fiche, et construire un glossaire partagé avant de commencer, pas après. Ce qui manque le plus dans ce genre de configuration n’est pas l’argent, mais l’outillage de suivi : sans lui, la dette de traduction s’accumule silencieusement jusqu’à devenir visible aux yeux des clients eux-mêmes.
