Il y a un peu plus d’un an, un client du secteur de la mode avait un besoin particulier : quatre marchés (France, Royaume-Uni, Allemagne, Italie), chacun avec sa propre équipe marketing locale, ses propres promotions saisonnières décalées dans le temps, et parfois des choix de mise en page radicalement différents d’un marché à l’autre. Une architecture Polylang ou WPML classique, où toutes les langues partagent le même thème et les mêmes plugins sur une seule installation, ne correspondait pas à ce besoin d’autonomie forte entre marchés. Le choix s’est porté sur MultilingualPress, une extension qui relie entre eux plusieurs sites d’un réseau WordPress multisite, chacun restant une installation à part entière.
Cet article ne revient pas sur la présentation générale de l’extension, déjà couverte lors de son évaluation initiale il y a un an ; il dresse le bilan concret après une année d’exploitation réelle avec ce client.
Ce qui a bien fonctionné
L’autonomie totale entre marchés a effectivement tenu ses promesses. L’équipe allemande a pu installer un plugin de gestion de tailles vestimentaires spécifique à son marché sans que cela n’affecte en rien les trois autres sites du réseau. Le site italien a changé de thème enfant pour sa collection été, un chantier réalisé en trois jours sans aucune coordination technique nécessaire avec les autres équipes, puisque chaque site du réseau reste indépendant au niveau du thème actif.
La liaison entre contenus équivalents, gérée par MultilingualPress via un système de relation entre articles de sites différents, a également bien fonctionné pour le cas d’usage principal : un visiteur naviguant sur le site français peut basculer vers l’article équivalent en anglais, en allemand ou en italien, quand cette relation a été explicitement créée par l’équipe éditoriale au moment de la publication.
Ce qui a demandé plus d’attention que prévu
La contrepartie de cette autonomie s’est révélée être l’absence totale de synchronisation automatique du contenu entre les sites. Contrairement à WPML ou Polylang, qui proposent un mécanisme de traduction intégré directement dans l’éditeur, MultilingualPress se contente de relier deux contenus existants créés indépendamment sur chaque site. Concrètement, cela signifie qu’un article français n’est jamais « en attente de traduction » quelque part : soit l’équipe anglaise a créé et publié son propre article équivalent et l’a relié manuellement, soit rien n’existe côté anglais, sans aucun indicateur de statut de traduction dans le tableau de bord.
Le suivi éditorial a dû être reconstruit à la main
L’agence a dû mettre en place un tableau de suivi externe, dans un outil de gestion de projet partagé, pour savoir quels articles français avaient effectivement leur équivalent publié dans chaque autre langue. Ce suivi, qui aurait été automatique avec un tableau de statut de traduction natif de WPML, a demandé un effort de discipline éditoriale supplémentaire de la part des quatre équipes locales.
Le coût d’infrastructure réel après un an
Quatre sites WordPress indépendants, même reliés en multisite, signifient quatre bases de données de contenu à sauvegarder, quatre configurations de cache à surveiller, et quatre suivis de mise à jour de plugins séparés puisque chaque site peut avoir des extensions différentes activées. Ce coût de maintenance, plus élevé qu’une architecture Polylang classique à installation unique, doit être anticipé dès le devis initial du projet plutôt que découvert après la mise en production.
| Critère | Constat après un an |
|---|---|
| Autonomie par marché | Totale, aucun conflit rencontré entre équipes |
| Suivi de traduction | Aucun natif, tableau externe nécessaire |
| Charge de maintenance | Supérieure à une installation Polylang unique |
| Satisfaction du client | Élevée, l’autonomie était le besoin prioritaire |
Pour quel type de projet ce choix reste pertinent
Ce retour d’expérience confirme que MultilingualPress convient particulièrement bien aux projets où chaque marché fonctionne réellement comme une entité éditoriale et technique distincte, avec des équipes locales autonomes et des besoins de personnalisation qui divergent fortement d’un marché à l’autre. Pour un site où le contenu reste globalement identique d’une langue à l’autre, avec une simple traduction fidèle attendue, un plugin de traduction classique comme Polylang ou WPML reste probablement un choix plus économique à maintenir sur la durée.
Avant de recommander MultilingualPress à un nouveau client, je pose systématiquement une question simple : vos équipes par marché ont-elles réellement besoin d’installer des plugins différents et de publier du contenu indépendant, ou cherchez-vous surtout une traduction fidèle d’un même contenu source ? La réponse oriente presque toujours le choix.
En résumé
Un an après sa mise en production, l’architecture MultilingualPress de ce client a tenu sa promesse principale d’autonomie totale entre marchés, sans conflit technique entre équipes locales. Le prix de cette autonomie s’est payé en absence de suivi de traduction natif et en charge de maintenance multipliée par le nombre de sites du réseau, deux points à intégrer explicitement dans tout futur devis avant de proposer cette architecture à un nouveau client.
