🤔 Faut-il vraiment un site bilingue ?
Avant de choisir une architecture technique, mieux vaut se poser une question plus simple : le bilinguisme répond-il à un besoin commercial identifiable, ou s’agit-il d’un réflexe qui semble incontournable sans que ce besoin soit clairement établi ? Un artisan qui reçoit occasionnellement trois demandes en anglais par an n’a probablement pas intérêt à doubler l’intégralité de son site, avec la charge de traduction et de maintenance que cela implique dans la durée. Une entreprise qui réalise ou vise une part significative de son chiffre d’affaires à l’étranger, en revanche, a tout intérêt à construire une vraie stratégie multilingue dès la conception du site.
Chez Something in the Web, nous posons systématiquement cette question avant de recommander un site bilingue à un client. Dans certains cas, une page de contact traduite ou un formulaire bilingue suffit à couvrir le besoin réel, sans justifier la complexité d’une architecture multilingue complète. Le bilinguisme n’est un bon calcul que lorsqu’il répond à une demande commerciale déjà identifiable, pas à une envie de paraître plus international.
🌍 Pourquoi le bilinguisme change la donne dès la conception
Pour les projets où le besoin est réel, un point reste vrai : un site bilingue n’est pas un site auquel on ajoute une langue après coup. C’est un projet qui doit être pensé comme tel dès l’architecture initiale, car chaque choix structurel a des répercussions sur la façon dont Google indexera les deux versions, sur la manière dont l’utilisateur naviguera entre elles, et sur la charge de maintenance à long terme. Un client qui découvre après la mise en ligne qu’il souhaite ajouter l’anglais à son site français devra souvent revoir des pans entiers de sa structure d’URLs, de son maillage interne et de sa stratégie de mots-clés. Anticiper le bilinguisme, même si la seconde langue n’est publiée que plus tard, évite ces reprises coûteuses.
Cette anticipation passe aussi par une question de fond : le bilinguisme sert-il à toucher deux publics distincts avec des besoins différents, ou s’agit-il simplement de rendre accessible le même contenu à un public plus large ? La réponse oriente tout le reste, de l’arborescence du site jusqu’au ton adopté dans chaque langue.
🔧 Les trois approches techniques possibles sous WordPress
WordPress propose plusieurs façons de gérer le multilinguisme, et le choix de l’approche conditionne tout le reste du projet. La première consiste à installer WordPress Multisite, une fonctionnalité native qui permet de gérer plusieurs installations WordPress reliées entre elles, chacune correspondant à une langue. Cette solution offre une isolation forte entre les langues mais complexifie l’administration quotidienne, notamment pour un client qui n’a pas de compétences techniques poussées.
La deuxième approche repose sur des plugins de traduction dédiés, qui s’installent sur une instance unique de WordPress et gèrent les versions linguistiques au sein d’une même base de données. C’est la solution la plus répandue pour les sites de TPE et d’artisans, car elle reste accessible en administration tout en offrant une structure SEO solide.
La troisième option, plus artisanale, consiste à créer manuellement des pages dupliquées dans chaque langue, reliées entre elles par de simples liens. Cette méthode peut convenir à un site vitrine très simple de trois ou quatre pages, mais elle montre vite ses limites dès que le site grandit, car elle ne gère ni les balises techniques d’indexation multilingue ni la cohérence de la navigation.
Pour un site vitrine de cinq à vingt pages, nous privilégions presque systématiquement une installation WordPress unique avec une gestion multilingue par plugin plutôt que WordPress Multisite, dont la complexité d’administration dépasse rarement les bénéfices pour ce type de projet.
🧩 WPML et Polylang : deux philosophies, deux publics
Pour la grande majorité des projets que nous accompagnons, le choix se resserre entre deux plugins qui dominent l’écosystème WordPress francophone : WPML et Polylang. Leur logique de fonctionnement diffère sur plusieurs terrains concrets.
Côté tarif, Polylang reste accessible dès sa version gratuite, quand WPML implique un abonnement annuel dès le premier site. Côté e-commerce, WPML conserve une longueur d’avance nette pour les boutiques WooCommerce ambitieuses, grâce à une intégration native pensée pour la gestion de catalogues multilingues complexes, quand Polylang nécessite des extensions complémentaires pour couvrir les mêmes besoins. Côté administration, Polylang reste généralement plus simple à prendre en main pour un client qui gérera lui-même son contenu au quotidien, tandis que WPML, plus complet, demande une courbe d’apprentissage plus longue. Côté maintenance enfin, une installation Polylang bien structurée reste plus légère à faire évoluer dans le temps qu’une installation WPML, dont la richesse fonctionnelle a pour contrepartie une configuration plus lourde.
Pour un site vitrine sans boutique en ligne, nous recommandons presque systématiquement Polylang à nos clients TPE et artisans. Nous réservons WPML aux projets qui intègrent une boutique WooCommerce internationale ou un volume de contenu suffisamment important pour justifier son coût et sa complexité.
Pour accélérer la phase de traduction elle-même, des outils complémentaires basés sur l’IA, comme l’addon AutoPoly pour Polylang, permettent de produire un premier jet de traduction directement dans l’éditeur WordPress. Ils font gagner un temps réel sur le travail initial, mais ne dispensent pas de la relecture humaine, en particulier pour les pages commerciales et les contenus stratégiques du site.
🔗 La structure des URLs, un enjeu SEO à ne pas négliger
Un site bilingue bien référencé repose sur une structure d’URLs claire, qui indique sans ambiguïté à Google et à l’utilisateur dans quelle langue se trouve chaque page. Trois structures principales existent : des sous-répertoires comme monsite.fr/en/, des sous-domaines comme en.monsite.fr, ou des domaines totalement distincts comme monsite.com. Pour un site de TPE, nous recommandons le plus souvent la structure en sous-répertoires, moins pour un avantage SEO qui reste aujourd’hui limité que pour sa simplicité d’administration : elle évite de multiplier les configurations techniques et facilite la maintenance d’un site que le client gère ensuite au quotidien.
À cette structure d’URLs doit s’ajouter une balise technique essentielle : l’attribut hreflang. Cette balise, insérée dans le code de chaque page, indique explicitement à Google quelle version linguistique proposer selon la langue et la localisation de l’internaute qui effectue une recherche. Son absence n’entraîne pas de pénalité au sens strict, mais elle complique la capacité des moteurs de recherche à comprendre la relation entre les différentes versions d’une même page, avec pour conséquence fréquente l’affichage de la mauvaise langue à un utilisateur ou une indexation incohérente entre les versions. Les plugins comme WPML et Polylang génèrent normalement ces balises automatiquement, mais il reste indispensable de vérifier leur bonne implémentation après la mise en ligne, notamment via la Search Console.
✍️ Traduire un site ne se limite pas à traduire des mots
L’erreur la plus fréquente sur les projets bilingues consiste à considérer la traduction comme une opération purement linguistique, confiée à un outil automatique ou traitée à la va-vite. Or un site professionnel engage l’image d’une entreprise, et une traduction approximative ou trop littérale peut nuire à la crédibilité perçue par une audience étrangère, parfois plus sévèrement qu’une simple faute d’orthographe ne le ferait dans la langue maternelle du visiteur.
Au-delà de la justesse linguistique, traduire un site suppose souvent d’adapter certains éléments au contexte culturel du public visé : les références, les exemples concrets, parfois même la structure argumentative d’une page entière. Un texte qui fonctionne parfaitement en français peut sembler trop direct, trop formel ou au contraire pas assez structuré une fois transposé pour un public anglophone. Cette adaptation, que l’on appelle la localisation, dépasse largement ce que peut produire une traduction automatique, aussi performante soit-elle devenue ces dernières années.
Le référencement naturel ajoute une couche supplémentaire de complexité à cette question. Les mots-clés qu’un internaute français tape dans Google ne sont pas la traduction littérale de ceux qu’un internaute anglophone utiliserait pour chercher le même service. Une vraie stratégie bilingue implique donc de mener une recherche de mots-clés spécifique à chaque langue, plutôt que de simplement traduire les mots-clés identifiés pour la version française.
Concrètement, la liste des éléments à traduire dépasse largement le corps du texte visible : l’URL elle-même, la balise title, la meta description, les titres Hn, les textes alternatifs des images, les ancres de liens internes, les formulaires et leurs messages de confirmation, ainsi que les appels à l’action. Oublier l’un de ces éléments laisse des traces visibles d’un site mal traduit, même lorsque le contenu principal a été soigné.
🧭 Penser l’expérience utilisateur autant que la technique
Un sélecteur de langue mal positionné, une bascule d’une langue à l’autre qui renvoie systématiquement vers la page d’accueil au lieu de la page équivalente traduite, ou encore une langue par défaut mal détectée selon la localisation du visiteur : ces détails, souvent négligés, dégradent sensiblement l’expérience utilisateur d’un site pourtant techniquement bien construit. Le sélecteur de langue doit rester visible et accessible en permanence, généralement dans l’en-tête du site, et la bascule d’une langue à l’autre doit toujours conserver l’utilisateur sur l’équivalent exact de la page qu’il consultait.
Nous déconseillons généralement la redirection automatique basée sur la langue du navigateur. Elle peut sembler pratique, mais elle complique l’exploration du site par les moteurs de recherche et crée surtout une expérience frustrante pour les utilisateurs qui souhaitent volontairement consulter une autre version linguistique. Une suggestion de langue, laissant l’utilisateur libre de choisir, reste presque toujours préférable à une redirection forcée.
⚠️ Les pièges qui coûtent cher a posteriori
Certaines erreurs, une fois commises, se corrigent difficilement sans reprendre une partie du travail déjà effectué. Traduire un site avec un plugin automatique sans jamais relire le résultat produit souvent des textes qui sonnent artificiels et qui desservent l’image de l’entreprise. Oublier de traduire les métadonnées SEO, les textes alternatifs des images ou les formulaires de contact laisse des zones du site incohérentes, visibles par n’importe quel visiteur attentif. Dupliquer une structure de site pensée uniquement pour un public français, sans l’adapter aux attentes d’un public étranger, produit un site bilingue dans la forme mais pas dans le fond.
Un dernier piège, plus insidieux, concerne la maintenance dans la durée. Un site bilingue demande une double vigilance à chaque mise à jour de contenu : toute modification apportée dans une langue doit être répercutée dans l’autre. Sans processus clair pour assurer ce suivi, les deux versions du site finissent par diverger, jusqu’à ce que la version secondaire devienne obsolète et desserve l’image qu’elle était censée renforcer.
✈️ L’avis du studio
Un site bilingue réussi ne se mesure pas au nombre de langues qu’il propose, mais à la cohérence avec laquelle chacune d’elles est pensée, structurée et entretenue. Chez Something in the Web, nous considérons que le bilinguisme d’un site doit être une décision stratégique prise en amont du projet, jamais un ajout de dernière minute, et encore moins un réflexe automatique. Cela suppose de vérifier d’abord que le besoin commercial existe réellement, puis de choisir la bonne architecture technique, de confier la traduction à un travail de fond plutôt qu’à un outil automatique livré à lui-même, et de prévoir dès la conception les processus qui garantiront la cohérence du site dans la durée. C’est à ce prix qu’un site bilingue devient un véritable atout commercial, plutôt qu’une charge qui s’alourdit avec le temps.
