Livrer un site bilingue qu'une équipe québécoise peut s'approprier

Les acheteurs de toitures au Québec se comportent autrement que ce que dit le stéréotype des blogs marketing. Ils scannent la page pour : est-ce que vous comprenez mon bâtiment, est-ce que vous desservez ma ville, est-ce que je peux obtenir une étude de faisabilité, et est-ce que votre français est vraiment du français ou du Google Traduction.

Pourquoi je l'ai construit

Le site existant était un thème WordPress avec un bouton de bascule français qui restait à 80 % en anglais sous le capot. Le formulaire de contact se trouvait à trois clics du hero. L'outil d'audit que l'équipe payait notait le site 61/100 et listait des données structurées manquantes, des balises meta manquantes et du contenu mince sur des pages qui en avaient visiblement. J'ai pris le projet pour refaire le front en SPA bilingue avec un prérendu correct, puis rebrancher WordPress uniquement pour le blogue.

Ce que ça fait

Le site est un front marketing bilingue pour un entrepreneur de toiture et de solaire desservant le Grand Montréal. Il présente les services par type de bâtiment, liste les projets passés par ville et achemine chaque CTA vers un seul formulaire d'étude de faisabilité qui capture le type de toit, la superficie et la fenêtre d'installation visée.

• Routes bilingues EN/FR avec métadonnées par locale et hreflang.
• Pages de services par ville, chacune avec son propre schéma areaServed.
• Galerie de projets filtrée par type de bâtiment (résidentiel, commercial, industriel).
• Formulaire de prospects qui poste au CRM de l'équipe avec la locale du formulaire jointe.
• Flux WordPress headless pour les billets de blogue, interrogé au moment du build.

Décisions d'architecture

Une SPA React construite sur Vite a donné à la marque les animations et la finition des formulaires souhaitées, tandis qu'une intégration WordPress en parallèle offre à l'équipe un flux de contenu convivial pour les billets et les mises à jour. La séparation (SPA pour le hero/services/projets, WordPress pour le contenu évolutif) garde le site marketing rapide sans obliger l'équipe à apprendre React.

J'ai choisi Vite plutôt que Next parce que l'équipe ne voulait pas d'hébergement serveur et était à l'aise sur un CDN statique. Le prérendu via vite-plugin-prerender écrit un fichier HTML par route, y compris les variantes françaises, pour qu'un crawler qui n'exécute pas le JavaScript voie quand même la page complète. WordPress tourne sur son propre sous-domaine et est tiré au moment du build via l'API REST, donc le site de production n'a aucune dépendance d'exécution sur le CMS.

L'audit SEO qui a recentré la construction

Un auditeur externe a noté le site 61/100, la plupart des points perdus portant sur des éléments réellement présents mais invisibles pour un crawler sans JS. Le correctif n'était pas de contester l'audit, c'était de s'assurer qu'un nouvel audit puisse trouver le contenu sans exécuter JavaScript. J'ai ajouté un prérendu par route, une couche noscript avec du contenu réel, du JSON-LD FAQPage et BlogPosting, un OfferCatalog de services avec areaServed au niveau ville, et un sitemap qui se régénère depuis les données de blog au moment du build.

Score estimé après refonte : 92 à 96. La plus grande leçon : les outils d'audit pilotés par IA lisent le HTML rendu, pas la coquille React. Si vous voulez qu'ils vous notent sur ce qui est vraiment sur votre site, il faut livrer le contenu dans le HTML.

Ce qui a été difficile

Le routage bilingue est la partie que j'ai sous-estimée. Chaque page devait exister deux fois avec des URL stables (/services/toiture et /en/services/roofing), et le sélecteur de langue devait atterrir sur la page équivalente, pas sur l'accueil. J'ai fini par garder une petite carte de routes indexée par un slug stable pour que la bascule sache que /projets/montreal correspond à /en/projects/montreal même quand les slugs traduits divergent.

L'autre partie difficile était d'aligner le flux WordPress et l'étape de prérendu sur le timing. Le prérendu tourne pendant le build, donc un billet publié cinq minutes après un déploiement n'apparaissait pas avant le build suivant. J'ai ajouté un webhook côté WordPress qui déclenche un redéploiement à la publication d'un billet, ce qui garde le site statique à quelques minutes près du CMS.

Ce que j'ai appris

Les auditeurs et les moteurs de recherche ne récompensent pas l'intention, ils récompensent les octets. Le même contenu qui notait 61 dans une coquille React notait dans les bas 90 une fois assis dans le HTML prérendu. La deuxième leçon, c'est que la copie française écrite par un locuteur natif du Québec se lit complètement autrement que de l'anglais marketing traduit, et le taux de complétion du formulaire côté français suit visiblement cette qualité.

La suite

• Pages d'atterrissage par ville prérendues à partir d'un seul gabarit, une par zone desservie.
• Un calculateur d'économies solaires qui pousse le résultat dans le formulaire d'étude de faisabilité.
• Un webhook CRM qui qualifie les prospects par ville et type de toit avant qu'ils n'arrivent à la boîte de réception.
• Une nouvelle passe d'audit pour confirmer le score estimé de 92 à 96 dans l'outil réel.