Le 8 octobre 2026, ydca.fr a basculé. Exit le thème du commerce et Elementor : le site tourne désormais sur un thème bloc WordPress (Full Site Editing, ou FSE) écrit sur mesure.
Le résultat se mesure. La page d’accueil pèse 70 Ko de HTML, contre 438 Ko auparavant. Chaque page charge 14,7 Ko de CSS et 4,8 Ko de JavaScript une fois compressés. Et sur mobile, Lighthouse affiche entre 97 et 100 en performance.
Mais le chantier avait un second objet : éprouver notre façon de travailler avec l’IA. Le thème a été développé avec un assistant IA, et nous en avons profité pour remettre à plat nos règles de travail. Ce que l’on mesure, ce que l’on vérifie, ce que l’on écrit. Ce bilan raconte les deux.
Ce bilan laisse de côté le trafic. Moins d’un mois après une bascule, aucun chiffre de référencement n’est lisible, et nous n’allons pas faire semblant. Nous y reviendrons quand les données auront quelque chose à dire.
Pourquoi nous avons quitté Elementor
L’ancien site, c’était un thème préfait, la surcouche Elementor et une quinzaine d’extensions en tout. Sur 22 pages, 21 avaient été montées avec le constructeur.
Combien pesait la page d’accueil, à votre avis ? 438 Ko de HTML. Rien que le HTML, avant la moindre feuille de style ou le moindre script.
Le premier motif de la refonte est là. Une page rapide ne charge que ce qu’elle affiche, et notre montage Elementor en était incapable.
Le second relève davantage du pari. Nous pensons qu’un HTML léger et sémantique se lit plus facilement, par Google comme par les moteurs de réponse qui s’appuient sur des modèles de langage. Rien ne le garantit encore. Rien ne plaide pour l’inverse non plus.
Restait une crainte : perdre la main sur le contenu. Elle s’est dissipée assez vite. Dans l’éditeur de site de WordPress, l’équipe modifie un texte, une image ou l’ordre des sections sans ouvrir le code, avec des garde-fous qui protègent la charte.
Bonne surprise au passage (chose qu’on peut oublier assez facilement, surtout que la structure technique de ce site tourne sous wordpress depuis plus de 10 ans), nos articles ne dépendaient pas d’Elementor. Seules les pages en dépendaient, et nous les redessinions de toute façon.
Un budget de performance fixé avant la première ligne de code
Nous avons fixé un budget par page, et nous l’avons traité comme une date de livraison. Non négociable, ou presque.
| Indicateur | Limite fixée |
|---|---|
| Lighthouse sur mobile | 95 ou plus sur les quatre axes |
| CSS par page | 40 Ko compressés |
| JavaScript par page | 5 Ko compressés |
| Requêtes vers des tiers au premier affichage | aucune, hors mesure d’audience du réseau de diffusion |
Concrètement ? Deux familles de polices hébergées sur notre serveur. Pas de bibliothèque JavaScript. Et des outils de mesure qui attendent l’accord du visiteur avant de se charger.
La seule exception est assumée, c’est le script de mesure d’audience que notre réseau de diffusion ajoute à chaque page.
Côté JavaScript, la marge est mince : 4,8 Ko mesurés pour 5 Ko autorisés. Le moindre ajout devra se justifier.
Avant, après : ce que nous avons mesuré
| Mesure | Avant | Après |
|---|---|---|
| HTML de la page d’accueil | 438 Ko | 70 Ko |
| CSS par page, compressé | non mesuré | 14,7 Ko |
| JavaScript par page, compressé | non mesuré | 4,8 Ko |
| Styles et scripts écrits dans la page | non mesuré | aucun |
| Lighthouse, performance sur mobile | non mesuré | 97 à 100 |
| Lighthouse, accessibilité, bonnes pratiques, SEO | non mesuré | 100 sur les trois axes |
| Affichage du plus grand élément (LCP) | non mesuré | 1,7 à 2,6 secondes |
| Décalage de mise en page (CLS) | non mesuré | 0 |
Les scores Lighthouse datent du 9 octobre 2026. Ils ont été relevés sur neuf pages d’ydca.fr qui couvrent quatre modèles : l’accueil, six pages d’expertise, un article et une rubrique. Deux précautions de lecture, quand même. Ce sont des mesures de laboratoire, pas des mesures prises chez nos visiteurs : la Search Console n’a pas encore assez de données de terrain pour notre site post refonte. Et d’une passe à l’autre, le score de performance bouge d’un ou deux points. Objectif cependant, finir à 100 partout, même en performance.
Un mot sur la colonne « Avant ». Nous avions relevé le poids de l’ancien site, pas ses scores Lighthouse, et ils ne se mesurent plus une fois le site débranché. La mesure complète de l’existant est désormais le deuxième point de notre checklist de refonte.
54 adresses changées sans casser le référencement
Pourquoi toucher aux adresses, alors que c’est précisément ce qui fait peur dans une refonte ? Parce que nous voulions un journal rangé en six rubriques, chacune adossée à une page d’expertise. Or la rubrique fait partie de l’adresse des articles. Résultat : 40 articles et 14 archives de catégories ont changé d’adresse.
Nous avons commencé par l’inventaire, avant de toucher au site. Toutes les adresses connues de Google, relevées dans les plans de site et la Search Console : 171 au total. Ensuite, une règle de redirection permanente pour chaque adresse qui change. Et la chasse aux liens internes, puisque 22 articles pointaient encore vers d’anciennes adresses. Après la bascule, nous avons rejoué l’inventaire complet. Les 171 adresses aboutissent toutes à une page, 110 directement et 61 par une redirection : 49 posées par la refonte, 12 héritées d’adresses plus anciennes.
L’exercice ressemble à celui que nous avions mené pour Le China, dont le site a changé sans perdre son référencement. Pour le nôtre, verdict dans les semaines qui viennent.
Ce que l’IA a changé dans notre méthode
Travailler avec un assistant IA va vite. Trop vite pour se contenter de vérifier à l’œil. Nous avons donc changé quelques habitudes :
- Des règles écrites avant le code. Le budget de performance, la liste des adresses à préserver, et une consigne simple : ne rien affirmer sans l’avoir vérifié. L’assistant les relit à chaque reprise du travail.
- Des contrôles que l’on rejoue. L’inventaire des adresses, le poids des pages et le fonctionnement du thème se vérifient par des scripts, environ 180 contrôles automatiques en tout. Ils sont relancés à chaque étape, pas seulement à la fin.
- Chaque correction devient une règle. Quand une erreur est repérée, elle est consignée par écrit pour ne pas revenir. Le projet en compte près de 70 à ce jour.
Une chose n’a pas changé : les décisions restent humaines. Aucune mise en ligne ne part sans une demande explicite.
Ce que ces contrôles ont attrapé
Trois anomalies montrent ce que cette méthode rapporte. Aucune ne venait du thème lui-même. Deux ont été vues avant la mise en ligne, la troisième le jour même.
Pendant la recette, sur la préproduction, une page affichait 55 en performance là où nous attendions 99. La cause n’était ni dans le thème ni dans WordPress. Une passerelle de balises active sur notre réseau de diffusion ajoutait à la volée des scripts de mesure et de publicité, avant tout accord du visiteur. Nous ne l’avons vue qu’en chargeant la page comme un vrai navigateur. Depuis, toutes nos mesures se font de cette façon, et les outils de mesure sont chargés par le thème, après accord seulement.
L’extension SEO qui défaisait notre travail, et on ne va pas se mentir, c’était assez pénible. Un article plafonnait à 90, avec un affichage principal en 3,4 secondes. Notre extension de référencement refaisait le rendu du contenu dans l’en-tête de la page, et remettait en file deux feuilles de style que nous avions pourtant retirées. File vidée, images du texte chargées en différé : les articles sont repassés au-dessus de notre seuil de 95, à 97 pour celui que nous avons mesuré en production le 9 octobre.
Enfin, le plan de site qui se souvenait de l’ancien. Après la bascule, il listait encore le type de contenu de l’ancien thème, à la place de nos réalisations. Sans contrôle systématique, il serait passé inaperçu.
Le point commun ? À chaque fois, notre code était propre, et c’est ce que le navigateur recevait qui posait problème. Un contrôle systématique l’a montré là où une relecture du code n’aurait rien vu. Assurez-vous que cloudflare reçoive les bonnes informations, si vous l’avez en tampon.
Et pour votre refonte ?
Si vous préparez une refonte, avec ou sans IA, deux décisions pèsent plus lourd que le choix de l’outil. La première, fixer un budget de performance avant la maquette. Alléger un site terminé coûte bien plus cher que refuser un ajout en cours de route. La seconde, dresser l’inventaire de vos adresses avant de toucher à quoi que ce soit. C’est lui qui vous dira, le lendemain de la mise en ligne, si rien ne s’est perdu. Et tant que vous y êtes, mesurez l’existant.
Un thème bloc sur mesure n’a rien d’une solution universelle. Il demande plus de travail au départ qu’un thème du commerce, et un développeur pour le faire évoluer. Il se justifie quand la vitesse et la maîtrise du contenu comptent sur la durée.
Pour une boutique en ligne, d’autres critères entrent en jeu. Nous les détaillons dans notre comparatif des solutions e-commerce.
Vous avez une refonte en vue ? Découvrez notre approche du développement web sur mesure, ou parlons de votre refonte : nous répondons sous 24 heures.
