8 min de lecture
Migrer un site Elementor ou Divi vers Gutenberg : ce qu'on garde, ce qu'on refait
Depuis que j'ai publié l'article sur pourquoi j'ai arrêté les page builders, plusieurs personnes m'ont posé la même question : d'accord, mais concrètement, ça coûte quoi de migrer ? C'est une bonne question. Décider de sortir d'Elementor sur le principe ne change pas grand-chose si la migration représente six mois de travail et un budget qu'on n'a pas.
La réponse courte : ça dépend. Et pas de façon vague. Il y a des variables précises qui font qu'une migration peut prendre une semaine ou deux mois.
L'inventaire d'abord, avant tout devis
La première chose que je fais quand un client arrive avec un site à migrer, c'est compter. Pas estimer, pas supposer : compter. Nombre de pages, types de pages (home, page de service, blog, contact, landing événementielle), nombre d'articles, templates utilisés, plugins tiers qui injectent des blocs dans le page builder.
Ce décompte prend une demi-journée et il change radicalement le devis. Un site de 12 pages avec 3 templates différents, c'est une semaine de travail. Un site de 80 pages avec des templates custom pour chaque pôle métier et 400 articles de blog, c'est un vrai projet de refonte à plusieurs mois. J'ai vu des clients surpris dans les deux sens.
Ce qu'on récupère sans trop de douleur
Les textes et les images d'abord. Tout le contenu éditorial (titres, paragraphes, metas SEO, images avec leurs attributs alt) est dans la base de données WordPress. On peut tout extraire automatiquement. C'est souvent la majorité de ce qui a de la valeur sur un site de cinq ans.
La structure d'URL aussi. Si le site était bien configuré et que les URL étaient propres (/services/refonte-site/ plutôt que /?page_id=42), on garde exactement les mêmes. Pas de redirection à mettre en place, pas de risque de casser le référencement existant. Ou alors on établit un plan de redirection, ça prends une demie-journée et ça sauve des mois de référencement naturel.
Les intégrations tierces (Search Console, pixels de tracking, formulaires dans des plugins dédiés) sont généralement indépendantes du page builder. Elles migrent sans travail particulier.
Ce qu'il faut reconstruire
La mise en page, entièrement. Elementor stocke ses mises en page dans des meta champs propriétaires. On peut lire ce JSON en PHP, extraire la structure des colonnes et des widgets. Dans la pratique, le traduire automatiquement en blocs Gutenberg propres n'est pas vraiment faisable. Il existe des plugins de migration (Convert to Blocks, Elementor to Blocks), j'en ai essayé plusieurs. Ils récupèrent parfois 70 % d'une page standard, mais les cas complexes sortent systématiquement cassés, et les retouches prennent souvent plus de temps que de repartir du contenu brut.
Divi, c'est encore plus fermé. Le format de stockage est particulier, et les migrations automatiques que j'ai testées donnaient du markup dégénéré qu'il fallait corriger balise par balise. Autant reconstruire directement depuis le contenu.
WPBakery (l'ancien Visual Composer) stocke des shortcodes dans le contenu des pages : [vc_row][vc_column][vc_column_text]. Des extensions dédiées peuvent les convertir, avec un résultat correct sur les sites simples. Pour les sites avec des shortcodes custom de plugins tiers greffés sur WPBakery, c'est une autre histoire.
Les cas qui rallongent le devis
Les mega-menus construits avec Elementor Header Builder sont de la configuration propriétaire. Pas de migration possible. On repart d'un header natif ou d'un bloc custom. Sur des sites avec des menus à plusieurs niveaux et des contenus visuels dans les dropdowns, c'est parfois deux jours de travail rien que pour le header.
Les formulaires avancés avec champs conditionnels, notifications complexes ou intégrations CRM. Le formulaire lui-même sera remis en place dans le nouveau site (Gravity Forms fonctionne très bien avec Gutenberg natif), mais sa configuration ne migre pas. Il faut tout reconfigurer.
Les sliders et carrousels. Swiper, Revolution Slider, chacun avec ses configurations propres. C'est souvent l'occasion de se débarrasser de quelque chose d'inutile, ou de décider si on garde vraiment la fonctionnalité et avec quel outil sous Gutenberg.
Comment je chiffre
Ma base de calcul : compter le nombre de templates uniques, pas de pages. Une home avec ses sections est un template. Une page de service type, un autre. Un article de blog avec sa sidebar, un autre encore.
Pour chaque template, j'estime la complexité. Simple (1 à 3 blocs, mise en page standard) : 2 à 4 heures. Moyen (multi-colonnes, éléments interactifs) : 4 à 8 heures. Complexe (sections animées, intégrations, logique conditionnelle) : 8 heures minimum, souvent plus.
Il faut aussi compter le temps de mise en place du design system dans theme.json (couleurs, typographie, espacements) et les tests sur navigateurs et mobiles avant de lancer.
Sur cette base, un site de 12 pages avec 5 templates dont un complexe, j'arrive en général à 30-40 heures. Entre 3 000 et 4 500 € selon les conditions. Ce n'est pas donné, mais c'est prévisible, et ça s'amortit rapidement sur la performance récupérée et la licence économisée.
Le SEO pendant la migration : ce qu'il faut surveiller
Le risque principal, c'est de migrer le contenu mais de perdre les metas et la structure sémantique. J'ai vu des migrations faites par des gens qui maîtrisaient Gutenberg mais n'avaient pas vérifié les balises title et les descriptions sur chaque page. Résultat : des pages qui sortaient avec les titres par défaut du thème pendant trois semaines, le temps que Google re-crawle.
Les données structurées Schema.org, si le site en avait, sont à vérifier aussi. Quand elles viennent d'un plugin SEO (SEOPress, RankMath) indépendant du builder, elles migrent sans travail. Quand elles sont injectées via des fonctionnalités dynamiques d'Elementor, il faut les recoder.
Ce que le client gagne après
Sur toutes les migrations que j'ai faites, le score PageSpeed mobile passe de la fourchette 40-60 à quelque chose entre 70 et 90. C'est mécanique. Le site envoie moins de JavaScript, moins de CSS inutile, le rendu initial est plus rapide parce qu'il n'y a plus le runtime du builder à charger.
L'autre gain, plus discret, c'est l'éditeur. Les clients qui passaient cinq minutes à charger le frontend d'Elementor pour changer un titre retrouvent Gutenberg et ses quelques secondes. Pour certains, c'est la première fois qu'ils modifient leur propre site sans appeler quelqu'un.
Et le jour du lancement, le client peut désinstaller Elementor Pro. Définitivement. Sur cinq ans à 60 € par an minimum, c'est 300 € récupérés, sans compter les hausses de tarif qui arrivent régulièrement.
Ce que je déconseille
Garder Elementor en parallèle pendant la transition, c'est une mauvaise idée. Ça semble raisonnable en théorie (garder le site en production, travailler sur une copie en parallèle), mais dans la pratique les deux versions coexistent pendant des mois, les clients ne savent plus laquelle éditer, et on se retrouve avec des contenus dupliqués et des redirections à nettoyer. Mon approche : nouveau site sur un sous-domaine, validation, bascule DNS, désinstallation du builder le jour J. Rien en parallèle.
L'autre chose à ne pas rater : si le site a cinq ans, son design a cinq ans. Ce serait dommage de reconstruire à l'identique sans retravailler les couleurs, les typos, les espacements. Remettre le theme.json à plat pendant qu'on y est ne coûte pas grand-chose et ça fait souvent une vraie différence visuelle.
Si vous avez un site sous Elementor ou Divi et que ça commence à peser (performance, facture, ou juste la flemme de se battre avec le builder), j'en fais régulièrement. Le plus simple c'est de me décrire le site en quelques lignes et d'estimer ensemble ce que représente le projet.