# Un site multilingue devenu ingérable après quatre ans de traductions ad hoc

> Chaque nouvelle langue ajoutée sans revoir l'architecture initiale a fini par produire un site multilingue que plus personne ne comprenait entièrement.

- Auteur : Clément Hadrot
- Publié le : 2025-09-22
- Mis à jour le : 2025-09-22
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/site-multilingue-ingerable-quatre-ans-traductions-ad-hoc/

## L’essentiel

- Une architecture pensée pour deux langues ne s'étend pas linéairement à six
- Chaque exception ajoutée localement finit par former un système parallèle
- L'audit doit distinguer ce qui est cassé de ce qui est simplement incohérent

Deux langues au départ ; six, quatre ans plus tard. C'est le grand écart de ce site. Sur le papier, l'ajout progressif de langues ressemble à une évolution maîtrisée. Dans les faits, l'audit mené sur ce site a révélé une accumulation de solutions locales, chacune raisonnable prise isolément, qui forment ensemble un système dont plus aucun développeur de l'équipe ne pouvait donner une description complète et fiable.

Ce cas mérite d'être détaillé parce qu'il ne relève d'aucune faute évidente : personne n'a pris de décision manifestement mauvaise à un moment donné. C'est l'absence de révision périodique de l'architecture, à chaque ajout de langue, qui a transformé une base saine en un système ingérable.

## L'architecture d'origine, pensée pour deux langues

Le site a démarré en français et en anglais, avec Polylang configuré en sous-dossiers de langue. Les choix initiaux étaient cohérents pour ce périmètre : une taxonomie de langue par article, un menu par langue géré manuellement (deux menus à synchroniser, une charge raisonnable), et des chaînes de thème traduites directement via des fichiers de traduction du thème.

Rien dans cette architecture n'était conçu pour anticiper une extension à six langues. Ce n'est pas un défaut de conception initiale : concevoir pour un périmètre inconnu et hypothétique aurait probablement introduit une complexité inutile si le site en était resté à deux langues, ce qui reste l'issue la plus probable pour la majorité des projets à ce stade.

## Ce qui s'est accumulé à chaque langue ajoutée

> L'essentiel à retenir : Une architecture pensée pour deux langues ne s'étend pas linéairement à six ; Chaque exception ajoutée localement finit par former un système parallèle ; L'audit doit distinguer ce qui est cassé de ce qui est simplement incohérent

La troisième langue (l'allemand) a été ajoutée sans problème notable : le modèle à deux menus synchronisés manuellement passait à trois, une charge de travail supplémentaire mais gérable. C'est à partir de la quatrième langue que les raccourcis ont commencé à s'accumuler :

- Pour l'espagnol, faute de temps, une partie des chaînes du thème a été traduite directement en dur dans un fichier de surcharge plutôt que via le système de traduction du thème, créant une divergence entre les deux mécanismes de traduction cohabitant sur le même site.
- Pour l'italien, une nouvelle personne a repris la synchronisation des menus et a réactivé, sans le savoir, une option de synchronisation automatique de Polylang que l'équipe précédente avait délibérément désactivée pour une raison non documentée.
- Pour le portugais, une extension tierce de recherche interne a été ajoutée sans filtrage par langue, parce que la personne qui l'a installée ignorait que ce filtrage existait déjà pour les autres langues via un correctif maison ailleurs dans le thème.

Chacune de ces décisions, isolément, était compréhensible dans le contexte où elle a été prise : contrainte de temps, changement de personne, méconnaissance d'un correctif existant. Prises ensemble, elles ont produit un site où deux mécanismes de traduction du thème coexistent sans que personne ne sache lequel prime, où la synchronisation des menus se comporte différemment d'une langue à l'autre, et où la recherche interne ne respecte la langue active que pour certaines langues.

## La méthode d'audit : séparer le cassé de l'incohérent

Face à ce constat, la tentation naturelle est de vouloir « tout refaire proprement ». Cette approche est risquée sur un site en production : elle traite comme équivalents des problèmes de gravité très différente. L'audit mené a distingué deux catégories :

| Catégorie | Définition | Exemple sur ce site |
| --- | --- | --- |
| Cassé | Produit un résultat visiblement faux pour l'utilisateur final | Recherche interne qui mélange des résultats de plusieurs langues |
| Incohérent | Fonctionne, mais différemment d'une langue à l'autre sans raison valable | Deux mécanismes de traduction du thème qui cohabitent |

Cette distinction a permis de prioriser : le problème de recherche interne, cassé et visible, a été corrigé en premier avec un filtrage par langue appliqué uniformément. La coexistence des deux mécanismes de traduction du thème, incohérente mais sans impact direct visible pour l'utilisateur, a été traitée ensuite, avec une migration progressive vers un seul mécanisme plutôt qu'une bascule brutale qui aurait risqué de casser des traductions existantes.

## Ce que l'audit a révélé sur la cause racine

Le point commun entre les trois raccourcis identifiés n'est pas un manque de compétence technique : c'est l'absence d'un moment de révision d'architecture à chaque ajout de langue. Chaque nouvelle langue a été traitée comme un ajout de contenu, jamais comme une occasion de vérifier que les mécanismes existants supportaient bien un périmètre élargi.

> Ajouter une langue à un site multilingue n'est jamais une opération purement additive. Chaque langue supplémentaire change la charge de synchronisation, le risque de divergence entre mécanismes, et la probabilité qu'une nouvelle personne reprenne une partie du système sans connaître les décisions passées.

## Ce qui a été mis en place pour éviter la répétition

La correction technique ne suffisait pas à empêcher qu'un cinquième ou sixième cycle du même problème se reproduise. Une checklist de révision d'architecture a été introduite, à appliquer systématiquement avant l'activation de toute nouvelle langue : vérification du mécanisme de traduction du thème utilisé, vérification de la configuration de synchronisation des menus, vérification que les extensions tierces respectent le filtrage par langue déjà en place ailleurs sur le site. Cette checklist ne prend pas plus d'une heure à appliquer, un coût dérisoire comparé aux semaines qu'a demandées l'audit correctif.

## En résumé

Aucune décision isolée n'a rendu ce site ingérable : c'est l'absence de révision de l'architecture à chaque extension de périmètre qui a laissé s'accumuler des mécanismes divergents. L'audit a distingué ce qui produisait un résultat visiblement faux de ce qui fonctionnait de manière simplement incohérente, pour prioriser la correction sans tout remettre à plat d'un coup. La leçon la plus utile de ce cas n'est pas technique mais organisationnelle : chaque nouvelle langue mérite une révision, pas seulement une activation.