Pourquoi on a quitté WordPress pour un site à 2700 pages

Le site comptait 2700 pages et articles, en 7 langues. Sur les douze derniers mois, il avait reçu 1,4 million de visites, dont 800 000 venues du SEO. Avant de décider de le reconstruire, il fallait regarder ce que le changement allait résoudre, et ce qu'il risquait de casser.

Je suis Jim, lead acquisition chez Eurofiscalis. Cette année, j'ai piloté deux refontes : celle du site d'Eva, une entrepreneuse seule, et celle du site Eurofiscalis, avec une équipe répartie dans plusieurs pays. Certaines bases techniques se ressemblent. Les besoins d'édition et la migration, eux, changent avec l'échelle. Cette série raconte les choix du second projet.

Ce qui fonctionnait, et ce qui demandait trop de travail

WordPress et Elementor avaient fait fonctionner le site pendant des années. Les 2700 pages étaient réparties entre le français, l'anglais, l'allemand, l'italien, le polonais, le tchèque et le norvégien.

On avait plusieurs problèmes de maintenance et d'organisation, et je voulais les traiter ensemble. C'est ce qui a orienté la refonte.

Cadrer les accès par langue

L'équipe devait pouvoir travailler sans intervenir par erreur sur les contenus d'un autre pays. Un rédacteur polonais avait besoin d'éditer le polonais, un traducteur allemand l'allemand.

Dans notre installation, les droits ne correspondaient pas assez précisément à cette répartition. Les ajuster impliquait de gérer des règles et des extensions supplémentaires. La question était donc assez concrète : comment donner à chacun les accès nécessaires, tout en limitant les modifications hors de son périmètre ?

Cette exigence a pesé dans le choix du CMS. Je détaille les options et le changement de décision dans Sanity, puis Payload.

Maintenir les mises à jour

Il y avait aussi le core WordPress, le thème et les plugins à suivre. Une mise à jour pouvait modifier la mise en page ou entrer en conflit avec une autre extension. Il fallait vérifier l'ensemble avant de considérer le travail terminé.

Avec 2700 pages, plusieurs langues et un trafic dont dépend l'acquisition, ces vérifications prennent de la place dans le travail de l'équipe.

Changer de stack ne supprime pas ce travail. On voulait réduire les dépendances liées à l'affichage et mieux distinguer le contenu, le CMS et le site rendu aux visiteurs.

Alléger les pages

Les performances de notre installation WordPress avec Elementor étaient un autre sujet. Le site avait accumulé des scripts et des extensions, et les Core Web Vitals étaient à améliorer.

Ces indicateurs portent sur le chargement, la stabilité visuelle et la réactivité. Google les utilise dans ses systèmes de classement, sans garantir une bonne position aux pages qui obtiennent de bons scores.

Pour moi, c'était d'abord une question de visite : afficher le contenu correctement et éviter de faire attendre un prospect. J'ai développé ce raisonnement dans l'article sur la performance comme choix de conception. Je ne peux pas convertir un gain de vitesse en un montant de trafic ou de chiffre d'affaires.

Pouvoir reprendre le design

Kévin, le fondateur d'Eurofiscalis, avait une direction précise pour le nouveau design. Notre usage d'Elementor ne nous permettait pas de la réaliser comme on le souhaitait, sans multiplier les adaptations.

Repartir sur une nouvelle structure nous donnait davantage de marge sur les composants et le CSS. L'IA pouvait accélérer la conception et le code une fois cette direction posée.

Mettre les données variables à un seul endroit

Le contenu comportait des données qui changent : taux de TVA, seuils Intrastat, délais de déclaration. Une même valeur pouvait apparaître dans de nombreuses pages.

On utilisait déjà des shortcodes sur WordPress. L'idée de centraliser ces valeurs existait donc avant la refonte. Ce qui nous manquait, c'était un modèle plus facile à suivre : où se trouve la donnée, quelles pages la reprennent et comment vérifier qu'une mise à jour est bien répercutée ?

On voulait que le rédacteur insère une référence à une valeur, plutôt que la recopier. La génération du site devait ensuite résoudre cette référence. Il fallait donc prévoir ensemble le modèle de données, son utilisation dans l'éditeur et les contrôles du rendu.

Le choix de reconstruire

On a retenu une reconstruction à trois : Kévin sur la direction du design, Max au développement, moi sur l'architecture SEO, les contenus et le pilotage.

Pour le site, on est partis sur Astro. Dans notre configuration, les pages sont générées en HTML au build et les outils interactifs chargent le JavaScript dont ils ont besoin. C'est le fonctionnement décrit par l'architecture en îlots d'Astro.

Cette organisation correspondait à un site principalement éditorial. Les routes devaient aussi reprendre les sept langues, avec le français à la racine. Le choix du framework ne réglait toutefois ni les droits d'édition, ni le transfert des contenus, ni les redirections.

La suite porte sur l'outil utilisé chaque jour par les rédacteurs et les traducteurs : Sanity, puis Payload, le CMS qu'on a choisi deux fois.