Le client, un cabinet de conseil avec un site de 120 pages construit entièrement sous Elementor depuis 2019, a demandé une migration complète vers l’éditeur de blocs natif de WordPress, motivée par deux constats : une dépendance jugée trop lourde à un plugin tiers pour un site qui n’utilisait en réalité qu’une poignée de mises en page récurrentes, et des temps de chargement qui s’étaient dégradés au fil des ajouts de widgets et d’extensions.
Ce projet a duré six semaines à temps partiel, réparties entre inventaire, conception des équivalents en blocs, conversion effective et vérifications. Voici le déroulé complet, avec ce qui a pris plus de temps que prévu et ce qui s’est révélé plus simple qu’anticipé.
L’inventaire, étape la plus longue et la plus sous-estimée
Avant de convertir la moindre page, il a fallu établir la liste exhaustive des widgets Elementor réellement utilisés sur les 120 pages, en excluant ceux posés une fois puis jamais réutilisés. Cet inventaire a révélé que sur plus de 60 widgets disponibles avec les extensions installées, seuls 14 étaient effectivement utilisés dans le contenu réel du site, la majorité des pages reposant sur des combinaisons de sections, colonnes, titres, textes, images et boutons.
Ce travail a pris près de deux semaines, principalement parce qu’il a fallu ouvrir chaque page dans l’éditeur Elementor pour repérer les widgets moins courants, l’export JSON des templates ne donnant pas une vue suffisamment lisible pour ce type d’audit à grande échelle.
Concevoir les équivalents en patterns de blocs
Une fois l’inventaire établi, l’équipe a construit une bibliothèque de patterns de blocs correspondant aux mises en page récurrentes identifiées : un pattern « section héro avec image et bouton », un pattern « grille de trois avantages avec icône », un pattern « citation client avec photo ». Ces patterns ont été enregistrés comme patterns synchronisés (les anciens blocs réutilisables) pour les éléments répétés sur de nombreuses pages, comme le bandeau d’appel à l’action en pied de page.
Douze patterns ont suffi à couvrir plus de 90 % des mises en page rencontrées sur le site. Les cas restants, plus spécifiques, ont été reconstruits page par page directement avec les blocs natifs, sans passer par un pattern dédié.
La conversion effective, page par page
La conversion elle-même s’est faite manuellement, page par page, plutôt que via un outil d’export automatique : les convertisseurs automatiques de contenu Elementor vers blocs testés en amont produisaient un résultat truffé de blocs HTML personnalisé bruts, reproduisant visuellement la page mais sans utiliser les vrais blocs natifs, ce qui n’aurait rien réglé du problème de dépendance visé par le client.
Le cas des formulaires
Les formulaires construits avec le widget Formulaire d’Elementor Pro n’ont pas d’équivalent direct dans l’éditeur de blocs natif, qui ne propose pas de bloc Formulaire complet nativement. La solution retenue a été de conserver un plugin de formulaires indépendant, avec son propre bloc dédié, découplé de tout page builder pour éviter de recréer la même dépendance sous une autre forme.
Redirections et vérification du référencement
La structure des URL n’a pas changé pendant la migration, ce qui a évité d’avoir à mettre en place des redirections spécifiques à ce chantier. En revanche, chaque page migrée a fait l’objet d’une vérification manuelle du balisage de titres (H1 à H3) et des données structurées, certains widgets Elementor générant un balisage légèrement différent de celui produit par les blocs natifs équivalents, avec un risque de doublon ou d’absence de H1 sur quelques pages mal converties en première passe.
Les gains mesurés après migration
| Indicateur | Avant migration | Après migration |
|---|---|---|
| Poids JS moyen par page | 310 Ko | 118 Ko |
| Temps de chargement complet (moyenne) | 3,1 s | 1,7 s |
| Score PageSpeed mobile (moyenne) | 58 | 84 |
Ce qu’on referait différemment
Avec le recul, l’inventaire initial aurait mérité d’être mené dès la deuxième semaine avec un tableur partagé alimenté au fur et à mesure, plutôt que consigné en fin d’audit : plusieurs allers-retours ont été nécessaires pour retrouver des pages oubliées lors de la phase de conception des patterns, ce qui a rallongé le projet d’environ une semaine par rapport à l’estimation initiale.
Notre verdict
Cette migration n’était pas justifiée par une insatisfaction envers Elementor en tant qu’outil, mais par un usage du site qui ne nécessitait plus sa flexibilité : peu de mises en page réellement variées, un besoin de performance accru, et une volonté de réduire les dépendances à long terme. Pour un site avec un usage éditorial plus riche et varié, la même démarche aurait probablement montré que le jeu n’en valait pas la chandelle. La leçon principale reste méthodologique : un inventaire rigoureux avant toute migration évite de découvrir les cas particuliers en cours de route, au moment le plus coûteux à corriger.
