Nous concevons actuellement un site Web dans les deux langues. Il est destiné à une petite entreprise de services Web et de conseil que nous prévoyons ouvrir ici, dans la Petite-Nation, plus tard cette année, et il doit fonctionner en français et en anglais dès le premier jour.
Nous nous sommes fixé une règle avant de commencer : ne pas consacrer à notre propre site ce que nous demanderions à un client de consacrer au sien. Cette règle se révèle déjà utile. Elle oriente constamment vers des choix que nous recommandons depuis des années, sans toujours les avoir appliqués nous-mêmes.
Quelle langue doit passer en premier?
Le français, avec l'anglais comme deuxième version complète. La Petite-Nation est majoritairement francophone. On y trouve aussi des résidents anglophones, des propriétaires de chalets qui viennent d'Ottawa et des touristes l'été. Le français est donc la langue par défaut, et l'anglais constitue une deuxième version complète du site, et non un ajout de dernière minute.
Nous avons vu de nombreux sites « bilingues » au Québec dont la version anglaise se limite à trois pages et un formulaire de contact, ou à une traduction automatique que personne n'a révisée. Les visiteurs le remarquent. Un anglophone qui cherche un plombier à Saint-André-Avellin appellera celui dont il peut lire le site. Un francophone quittera le site dès que le français semble traduit de l'anglais, et avec raison.
Chaque page est donc rédigée pour chaque lecteur : la même information, formulée comme le ferait une personne de chaque langue. C'est un travail exigeant. La rédaction devrait d'ailleurs prendre plus de temps que l'ensemble du travail technique.
Pourquoi chaque langue doit-elle avoir sa propre adresse?
Parce que, autrement, Google ne voit généralement qu'une seule version. Ce point technique compte plus qu'on ne le pense.
Chaque langue a sa propre adresse : les pages françaises sous /fr/, les pages anglaises sous /en/. Bien des sites procèdent autrement, avec un bouton qui remplace le texte sur la même URL au moyen d'un témoin ou d'un script. Le résultat semble soigné, mais il pose problème pour Google, qui explore généralement une version sans jamais voir l'autre.
La page de Google sur la gestion des sites multilingues et multirégionaux est sans équivoque : une URL distincte pour chaque version linguistique, sans recourir aux témoins ou aux réglages du navigateur pour déterminer la langue affichée. C'est une lecture technique, mais nous la recommandons à quiconque conçoit un site bilingue au Québec, avant même d'écrire une ligne de code.
Comment Google sait-il quelles pages sont des traductions?
Grâce aux balises hreflang. Une fois les deux URL en place, il faut indiquer à Google qu'il s'agit de la même page en deux langues. Chaque page française pointe vers son équivalent anglais et vers elle-même, et la page anglaise fait de même en sens inverse. Nous marquons les pages françaises fr-CA et les pages anglaises en-CA, le français étant la version par défaut pour les visiteurs dont Google ne peut déterminer la langue.
Si cette configuration est erronée, Google peut présenter la page anglaise à une personne qui cherche en français, ou traiter les deux versions comme du contenu en double. Si elle est correcte, rien n'est perceptible, ce qui est précisément l'objectif.
Une autre étape est souvent négligée : traduire aussi les adresses et les titres de pages. La page sur le référencement se trouvera à /fr/services/referencement-seo, et la page anglaise à /en/services/seo. Le détail semble mineur, mais il s'affiche dans les résultats de recherche et indique au francophone que la page a été rédigée pour lui, plutôt que passée dans un traducteur.
Quand des pages statiques sont-elles préférables à un CMS?
Lorsque personne n'a à modifier le site chaque semaine. Nous avons conçu des sites Drupal et WordPress pendant la majeure partie de notre parcours professionnel, et nous recommandons toujours WordPress aux clients qui doivent modifier leur site eux-mêmes chaque semaine. Pour ce projet, nous avons choisi un site statique, et les résultats sont jusqu'ici satisfaisants.
Concrètement, le texte de chaque page est conservé dans quelques fichiers simples. Un petit script les convertit en pages HTML ordinaires dans les deux langues et génère les menus, les balises hreflang et le plan du site. Le dossier est ensuite téléversé. Il n'y a ni base de données, ni extension en attente de mise à jour, ni page de connexion exposée aux attaques de robots pendant la nuit.
Les pages se chargent rapidement parce que le serveur n'a rien à calculer; il se contente de transmettre des fichiers. La surface d'attaque est aussi très réduite. Ces deux avantages suffisent à justifier ce choix.
L'inconvénient est tout aussi réel. Corriger une coquille exige de modifier un fichier et de régénérer le site. Cela nous convient, mais un restaurateur qui change son menu tous les jeudis trouverait la formule peu pratique, et nous ne la recommanderions pas dans ce cas. La personne qui mettra le site à jour après le lancement devrait déterminer la formule, et cette question devrait être réglée avant toute discussion technologique.
Quel hébergement faut-il pour un site rapide?
Un hébergement ordinaire suffit. Un site statique ne requiert aucun hébergement particulier; un hébergement standard et peu coûteux convient, puisque le serveur ne fait que transmettre des fichiers.
Nous hébergeons les polices de caractères sur le même serveur plutôt que de les charger depuis Google Fonts. Cela retire une requête externe de chaque page, et une entreprise de plus qui pourrait voir qui visite le site. Les photos sont compressées avant d'être mises en ligne. Sur les sites de petites entreprises de la région, la cause de lenteur la plus fréquente est la présence de photos prises au téléphone et téléversées telles quelles, de plusieurs mégaoctets chacune, sur une page qui les affiche à la taille d'un timbre. Corriger ce point règle une bonne partie du problème de vitesse.
Un site de petite entreprise a-t-il besoin de témoins et de traceurs?
Souvent, non. C'est la décision que nous avons soupesée le plus attentivement.
Le plan prévoit aucun outil d'analyse, aucun pixel publicitaire et aucun témoin, et la page de confidentialité l'indiquera en une phrase. Nous ne saurons donc pas exactement combien de personnes lisent chaque page, ce qui constitue un compromis acceptable. La Search Console de Google indique quelles recherches mènent les gens vers un site sans rien ajouter à la page, et l'indicateur le plus important demeure le nombre d'appels et de messages reçus.
Il existe aussi une dimension québécoise. La Loi 25 est entrée en vigueur par étapes entre 2022 et 2024, et l'une de ses règles exige que toute technologie de suivi permettant d'identifier ou de profiler un visiteur soit désactivée par défaut. Un site qui ne recueille rien n'a rien à expliquer, et n'affiche aucun bandeau de témoins couvrant la moitié de l'écran d'un téléphone.
Pour une entreprise qui fait de la publicité, la situation est différente. Le suivi fait partie du travail et doit prendre la forme d'un véritable suivi des conversions, avec consentement. Pour le site d'une petite entreprise dont le rôle est d'être trouvée et de générer des appels, c'est souvent plus que nécessaire. Nous recommandons de commencer sans suivi et de l'ajouter lorsqu'une raison précise le justifie.
Que recommandons-nous aux entreprises de la région?
Le site n'est pas encore en ligne, et quelques détails pourraient encore changer d'ici le lancement. Les choix principaux, toutefois, sont solides.
Pour un site Web de petite entreprise en français et en anglais, la technologie est la partie la plus simple : des URL distinctes, des balises hreflang et un site léger. Un développeur compétent peut mettre cela en place en quelques jours. C'est la rédaction qui demande du temps, et c'est là que la plupart des sites bilingues présentent des lacunes. Nous recommandons de prévoir un budget pour les textes.