Un site bilingue efficace, c’est pas un site avec un simple bouton EN ajouté à la fin du projet. Au Québec, la question touche à la fois l’architecture, le SEO, l’expérience utilisateur et la conformité. La Charte de la langue française exige que les documents de même nature disponibles au public soient rédigés en français, et une autre langue n’est permise que si la version française est accessible dans des conditions au moins aussi favorables. L’OQLF rappelle que cette règle vise également les publications de nature commerciale diffusées sur un site Web.
En parallèle, la Loi 25 ajoute une couche technique bien réelle : depuis le 22 septembre 2023, une entreprise qui recueille des renseignements personnels par un moyen technologique, comme un site Web ou une application, doit publier une politique de confidentialité rédigée en termes clairs et simples. Autrement dit, le multilingue n’est plus juste une question de contenu; c’est aussi une question de gouvernance numérique.
Le multilingue, ça se modélise avant de se traduire
La première erreur, c’est de choisir un plugin, un module ou une librairie avant d’avoir décidé ce qui doit vraiment varier par langue. WordPress ne gère pas le bilingue nativement et renvoie vers différentes approches communautaires, du plugin par langue au multisite. Craft CMS, lui, traite le sujet avec une architecture multi-site intégrée. Laravel sépare explicitement les chaînes traduisibles dans lang/ ou dans des fichiers JSON. Ça veut dire qu’avant de traduire un mot, il faut cartographier les articles, les pages, les menus, les taxonomies, les formulaires, les courriels, les messages système, les métadonnées SEO et les textes légaux.
Craft montre bien la bonne logique : un champ peut être non traduisible, traduit par site, par groupe de sites ou par langue. Cette distinction est précieuse, parce qu’elle évite de dupliquer inutilement des données qui devraient rester communes, tout en permettant de localiser ce qui doit réellement l’être. C’est souvent là que les projets multilingues deviennent propres... ou commencent à s’emmêler.
Une URL distincte par langue, sinon ça se gâte vite
Le piège technique le plus fréquent, c’est la page qui change de langue selon le navigateur, le cookie ou l’adresse IP, tout en gardant la même URL. Google est assez clair : les pages locale-adaptive peuvent empêcher l’exploration, l’indexation ou le classement de tout le contenu localisé, et la recommandation officielle reste d’utiliser des URL distinctes par langue avec des annotations hreflang.
Dans Nuxt i18n, la stratégie no_prefix fonctionne justement sans préfixe d’URL et repose sur la détection de langue côté navigateur ou cookie. À l’inverse, prefix, prefix_except_default et prefix_and_default génèrent de vraies routes localisées. La doc recommande aussi de limiter la détection automatique à la racine avec redirectOn: 'root', pour laisser les robots accéder aux pages demandées sans redirection forcée.
Pour un site destiné d’abord au Québec, le choix le plus simple techniquement, éditorialement et politiquement, est souvent de mettre le français à la racine et l’anglais sous /en/ ou sur un domaine distinct. Ça donne des URLs stables, ça simplifie les liens internes, et ça cadre mieux avec l’idée que le français doit être offert dans des conditions au moins aussi favorables, au lieu d’être traité comme une version secondaire cachée derrière un détecteur de langue.
Une locale cohérente d’un bout à l’autre
Un site bilingue solide garde la même logique de locale partout : dans les routes, dans le HTML, dans le CMS, dans l’application et dans le SEO. Le W3C rappelle que les étiquettes de langue suivent la BCP 47 (Best Current Practice 47) et donne fr-CA comme exemple valide; Google attend aussi des codes langue-région corrects dans hreflang. Donc, pas de mélange improvisé entre fr, fr_CA, fr_FR et en. Si le site vise le Québec et le Canada, on choisit une convention claire comme fr-CA et en-CA, puis on la tient partout.
Même chose dans le rendu. Le W3C recommande de déclarer la langue par défaut sur la balise <html> et déconseille d’utiliser un meta Content-Language pour ça. Dans Craft, la langue du site pilote les formats de date, d’heure et de nombres, ainsi que les traductions statiques utilisées en front-end. Dans Nuxt i18n, useLocaleHead() peut générer l’attribut lang, les liens hreflang, les canonicals et les métadonnées Open Graph liées à la locale.
Séparer le contenu éditorial, les chaînes d’interface et les gabarits
Un autre piège classique, c’est de traiter un article de blogue, un bouton "Envoyer", un message d’erreur, un libellé de formulaire et un titre SEO comme si c’était la même chose. Ce n’est pas la même couche. WordPress insiste depuis longtemps sur l’internationalisation des thèmes et plugins : les chaînes ne devraient pas être codées en dur, mais passées par les fonctions de localisation. Sinon, le site devient vite un patchwork de zones traduites et de zones oubliées.
Dans Craft, les messages statiques des gabarits passent par |t ou Craft::t(), tandis que le contenu géré par les éditeurs vit dans les champs et suit les méthodes de traduction configurées. Dans Laravel, les chaînes d’interface se gèrent dans lang/ ou en JSON, la locale par défaut et la locale de repli se configurent dans config/app.php, et la locale peut être changée à la requête avec App::setLocale(). Ça permet de distinguer proprement le contenu éditorial du texte applicatif, ce qui est essentiel quand un site grossit.
C’est aussi pour ça que la traduction automatique brute ne devrait jamais devenir l’architecture principale. La documentation WordPress note que les approches qui traduisent à la volée sur la page générée peuvent produire de mauvaises traductions et créer un couplage fragile avec le contenu source. Comme solution de dépannage, ça peut dépanner; comme fondation de marque, c’est faible.
Le SEO multilingue doit être explicite
Sur le plan SEO, chaque version d’une page doit déclarer toutes ses autres versions, y compris elle-même. Google précise aussi que les URLs alternatives doivent être absolues, que les liens doivent être bidirectionnels, et qu’une valeur x-default est recommandée pour une page de sélection de langue ou une page d’accueil servant de fallback. Le même guide rappelle qu’il n’y a pas d’avantage à maintenir en parallèle le HTML, les en-têtes HTTP et le sitemap pour hreflang : une seule méthode bien tenue suffit.
Concrètement, ça veut dire que les titres, les metas, les canonicals, les sitemaps, les breadcrumbs, les données structurées et les liens internes doivent exister par locale. Si on publie aussi des PDF ou d’autres fichiers non HTML en plusieurs langues, Google permet d’indiquer les variantes via l’en-tête HTTP Link. Et si on veut localiser les segments d’URL eux-mêmes, Google l’autorise aussi, tant que l’encodage UTF-8 est propre.
Penser à l’exploitation avant le lancement
Le multilingue casse rarement au jour 1. Il casse six mois plus tard, quand un nouveau bloc n’a pas été rendu traduisible, qu’un plugin injecte du texte non localisé, ou qu’une page anglaise a été publiée sans sa jumelle française. WordPress le dit sans détour : installer un plugin multilingue est un gros changement, il faut le tester sur un site de test et faire une sauvegarde avant d’expérimenter. La même doc note aussi que certaines approches peuvent faire grossir fortement la base de données, surtout sur les gros catalogues.
La bonne pratique, c’est donc d’ajouter une vraie checklist de régression par langue : gabarits, recherche interne, formulaires, pages 404, redirections, courriels, analytics, SEO, consentement, médias et alt text. Dans Laravel, les groupes de routes avec préfixes et middleware donnent une structure propre pour ça; dans Nuxt, les stratégies de routage évitent de bricoler les versions localisées page par page.
Au Québec, la conformité doit faire partie de la stack
Côté vie privée, la conformité ne devrait jamais être reléguée au footer. Si le site recueille des renseignements personnels par un moyen technologique, la politique de confidentialité devient obligatoire et doit être rédigée en termes clairs et simples. La personne ayant la plus haute autorité dans l’entreprise est, par défaut, responsable de la protection des renseignements personnels, et le titre ainsi que les coordonnées de cette personne doivent être publiés sur le site.
La Loi sur le privé va plus loin : l’entreprise doit établir et mettre en œuvre des politiques et pratiques de gouvernance, et tout projet d’acquisition, de développement ou de refonte d’un système d’information ou d’une prestation électronique de services impliquant des renseignements personnels doit faire l’objet d’une évaluation des facteurs relatifs à la vie privée. En clair, une refonte bilingue avec formulaires, CRM, pixels marketing, analytique, espace client ou personnalisation n’est pas juste un mandat UX; c’est aussi un mandat de gouvernance.
Le consentement, lui, doit être manifeste, libre, éclairé et donné à des fins spécifiques. La CAI donne même comme exemple une fenêtre servant à paramétrer les témoins de connexion. Donc, une bannière de consentement ou une CMP mal traduite, ambiguë ou incomplète, c’est pas un détail cosmétique : c’est un risque juridique et opérationnel.
Et si un incident de confidentialité survient, l’entreprise doit prendre des mesures raisonnables pour réduire le risque de préjudice et éviter que de nouveaux incidents du même type se reproduisent. Ça justifie, dès la conception, un inventaire clair des formulaires, des intégrations, des flux de données et des points de collecte par langue.
Enfin, si ton site est en réalité aussi un produit logiciel ou un espace applicatif livré sur le Web, la Charte ajoute un autre rappel utile : un logiciel doit être disponible en français, sauf s’il n’en existe aucune version française, et la version française doit être accessible dans des conditions au moins aussi favorables avec des caractéristiques techniques au moins équivalentes.
Conclusion
Un site bilingue efficace, au Québec, ce n’est pas un site "traduit". C’est un site architecturé par locale : des URLs distinctes, un français traité comme version de première classe, des codes de langue cohérents, une séparation nette entre contenu et interface, un SEO explicite et une gouvernance vie privée intégrée dès le départ. C’est ça qui évite les vrais pièges techniques du multilingue.
