Migration Elementor vers FSE avec Claude Code : retour d’expérience

Et si on virait Elementor en laissant une IA faire le gros du travail en l’automatisant ? C’est la question que je me suis posée fin mai, après avoir découvert la puissance de Claude Code (voir l’article Migrer 700 articles de SiteOrigin vers Gutenberg avec l’IA).

J’ai pris un site réel, je l’ai cloné en local, et j’ai tenté une migration Elementor vers FSE avec Claude Code comme partenaire. Trois jours plus tard, le site tournait entièrement en Full Site Editing natif.

Je vous raconte comment : la méthode, les garde-fous, les pièges techniques qui font transpirer, et les limites. C’est un POC (preuve de concept), pas un benchmark. Donc je montre l’envers du décor sans rien survendre. Si vous envisagez de sortir d’un page builder, c’est exactement le genre de refonte que j’ai l’intention d’appliquer au site de plusieurs de mes clients.

Le point de départ : un site Elementor à reconstruire

Le site cobaye, c’est Philotude (philotude.fr) : littérature et philosophie, avec un blog d’articles, une présentation de l’auteur, ses publications (livres et articles parus) et une page contact.

La stack d’origine était classique :

• Elementor + Elementor Pro (v4.1.1), thème Hello Elementor, hébergé chez o2switch.
• Un type de contenu personnalisé (CPT) métier via l’extension Mooberry Book Manager (mbdb_book) pour les 10 ouvrages.
• Un formulaire de contact Elementor Pro couplé à l’anti-spam Mosparo.

Côté volumétrie : 42 articles, 5 pages, 10 ouvrages, et une série de modèles Elementor (en-tête, pied de page, article, page, archives, plus le Default Kit).

Premier réflexe méthodologique, et il est décisif : tout s’est passé sur un clone local complet monté avec DevKinsta (philotude.local). Surtout, les données brutes d’Elementor (le JSON stocké dans _elementor_data) étaient intactes en base. C’est cette matière brute qui a servi de source, jamais le HTML rendu. J’y reviens plus bas, parce que c’est tout l’enjeu de la fiabilité.

La cible : Twenty Twenty-Five, le thème par défaut de WordPress, en block-theme FSE standard, explicitement sans thème enfant, complété par Spectra (version gratuite) là où le FSE natif ne suffisait pas.

Pourquoi quitter le constructeur de pages pour le FSE

Quatre raisons, que tout intégrateur connaît bien :

• Sortir de la dépendance. Elementor alourdit (le CSS combiné du site source pesait à lui seul environ 295 ko), verrouille le contenu dans un format propriétaire et impose sa logique par-dessus WordPress. Et côté édition, c’est lourd au quotidien : l’éditeur met un temps fou à charger à chaque ouverture de page, et le moindre changement d’onglet relance une attente. Sur une session de travail, ces secondes s’accumulent.
• Revenir au standard. Le FSE (Full Site Editing, l’édition de site native arrivée avec les block-themes) permet de tout piloter depuis l’éditeur : styles, templates, en-tête, pied de page, avec un design system centralisé dans theme.json et wp_global_styles.
• La question qui m’intéressait vraiment. Est-ce qu’un agent IA peut prendre en charge le travail mécanique de conversion, de façon fiable et supervisable, au point de rendre ce type de mission rentable pour un freelance ? C’est ça que je voulais vérifier.
• Un seul mode d’édition. Dernier point, mais pas des moindres : se débarrasser d’Elementor (ou d’un autre constructeur), c’est ne présenter qu’une seule interface pour éditer pages et articles. L’éditeur de blocs natif, et rien d’autre. Une prise en main simplifiée pour toutes les personnes qui interviennent sur la partie éditoriale du site.

La méthode : des garde-fous avant tout

Le POC s’appuie sur deux compétences (skills) Claude Code : wp-refonte-fse, le skill chapeau qui orchestre la refonte d’un site source vers du FSE, et tt5-spectra, qui génère les pages sur la stack Twenty Twenty-Five + Spectra. Et là, une mention s’impose en toute honnêteté : tt5-spectra est un fork du skill open source claude-skill-astra-spectra de Fabrice Ducarme (WPFormation). C’est son article sur le sujet qui m’a donné l’idée de tenter l’expérience. J’ai adapté son travail (sous licence MIT, fork explicitement autorisé) à ma cible Twenty Twenty-Five + Spectra free. Merci à lui pour le défrichage et pour avoir ouvert son code : c’est exactement l’esprit de l’écosystème WordPress.

Quant à wp-refonte-fse, il est né d’un premier projet qui a servi de banc d’essai : la reproduction d’un site dont je n’avais pas l’accès admin, bâti sur un thème sur mesure. Le but n’était pas le site lui-même, jetable, mais de roder l’outillage sur un cas propre avant d’attaquer un vrai chantier.

Ce banc d’essai a produit la vraie matière : une bibliothèque de scripts de migration, des mémoires de pièges WordPress, Spectra et Gutenberg réinjectées dans les skills, et une trame de cahier des charges réutilisable (objectifs, périmètre, design system, accessibilité WCAG AA). C’est précisément pour ça que j’ai lancé ce POC seulement une fois l’outil maîtrisé : mesurer un gain de temps sur un site où j’apprends encore l’outil n’aurait rien voulu dire. Ce premier projet fera peut-être l’objet d’un article à part.

Le setup technique

Rien d’exotique, et c’est volontaire. Tout repose sur des outils que j’utilise déjà au quotidien :

• L’environnement local : DevKinsta (Docker + Nginx + PHP + MySQL). Le site source a été cloné intégralement en local (philotude.local), base de données comprise. C’est là que tout s’est joué, jamais sur la production en ligne.
• Le pilote : Claude Code (opus 4.7). L’agent IA tourne en ligne de commande directement dans le dossier du projet WordPress. Il lit les skills, exécute des scripts PHP, interroge la base, et rend la main à chaque point de validation.
• Le canal d’écriture : API REST + Application Password. L’agent lit les contenus et poste les pages via l’API REST de WordPress, authentifié par un Application Password dédié, créé à la main. Il agit donc sur le site sans jamais détenir mes identifiants principaux, et je peux révoquer cet accès d’un clic.
• Les yeux de l’agent : le MCP firefox-devtools. Pour appliquer la règle « capture d’écran obligatoire », l’agent doit pouvoir voir ce qu’il produit. Le MCP firefox-devtools (Model Context Protocol) pilote Firefox et ses outils de développement : il ouvre la page générée, prend une capture du rendu réel, inspecte le DOM et le CSS, lit la console. C’est ce qui a permis de diagnostiquer le piège kebab-case des titres invisibles, de vérifier qu’une section s’affichait bien avant de passer à la suivante, et de ne jamais déclarer un succès « à l’aveugle ».
• Les skills : la connaissance métier. Les deux skills encapsulent les règles, les patterns Spectra, les pièges documentés et les garde-fous. Sans eux, l’agent hallucine des attributs de blocs ou invente une structure ; avec eux, il suit une méthode.

Parser la base, pas le HTML

Deux stratégies étaient possibles :

1. repartir du HTML rendu en récupérant les URLs publiques.
2. analyser directement le JSON _elementor_data en base.

Le POC a confirmé que la 2 est nettement plus fiable. On récupère la structure d’intention (sections, widgets, réglages) au lieu de devoir rétro-concevoir du HTML déjà mis en forme.

Les règles anti-désastre

Quand on parle de lâcher un agent IA sur un site, c’est toujours là que ça se crispe. D’où des règles non négociables :

• Le site en ligne reste en lecture seule. Aucune écriture vers la production, tout se fait sur le clone.
• Toute mise en page générée est validée au fur et à mesure, jamais actée en automatique.
• Trois sections maximum par itération, puis pause.
• Capture d’écran obligatoire avant tout « c’est bon ». L’agent ne déclare jamais un succès visuel sans validation humaine de la capture.
• CSS personnalisé en dernier recours, et jamais en douce : on épuise d’abord les réglages natifs Gutenberg et theme.json.

Un déroulé strictement séquentiel : les 7 phases

Pas de passage à la phase suivante sans validation humaine explicite. Le skill chapeau impose un déroulé en sept phases, dans cet ordre :

1. Configuration du clone. Montage de l’environnement local DevKinsta, création de l’Application Password, branchement MCP, vérification que l’agent lit bien le site.
2. Audit de la source. Analyse du JSON _elementor_data en base, inventaire des pages, articles, CPT, templates et widgets utilisés. C’est la cartographie avant les travaux.
3. Design system (Global Styles). Configuration de la palette, des typographies, de l’échelle de titres, des espacements et des largeurs de contenu. Point important : rien n’est écrit dans le fichier theme.json du thème. Tout passe par les Global Styles stockés en base (wp_global_styles, ce que pilote nativement l’éditeur de site) et par des filtres PHP dans le mu-plugin compagnon. Tout est centralisé avant de poser la moindre page.
4. En-tête et pied de page. Les template parts FSE, communs à tout le site, plus la sidebar dynamique.
5. Templates dynamiques. Les gabarits qui pilotent l’affichage des articles, des pages et du CPT ouvrages (single, archive, etc.).
6. Pages statiques. Les pages éditoriales une à une, validées visuellement par lot de 3 sections.
7. Articles en masse. La conversion des 43 articles en contenu Gutenberg natif, dont les 15 anciens articles Classic Editor à basculer par script.

Le tout se clôt par une phase de bilan et nettoyage : audit qualitatif, puis désinstallation complète d’Elementor une fois le clone validé.

Le récit, jour après jour

Jour 1. Audit de la source et arbitrages de cadrage, dont la question « faut-il Spectra Pro ? ». Décision documentée, livrables d’audit validés.

Jour 2. Le design system, l’en-tête, le pied de page, et déjà la sidebar dynamique.

Jour 3. La grosse journée : templates dynamiques, pages statiques, contact avec Mosparo, conversion des articles et le fameux bug de chargement Spectra. Puis audit qualitatif des articles, finitions du template article, et enfin bilan et grand nettoyage avec la désinstallation complète d’Elementor.

Les surprises techniques (le sel de l’histoire)

Ce sont les moments qui valent vraiment le détour, parce que ce sont de vrais pièges.

Le piège kebab-case de WordPress core. Subtil et très instructif : WordPress « kebab-case » les slugs de tailles de police côté CSS (h1 devient --h-1) mais pas côté résolveur de variables (var:preset|font-size|h1). Résultat : des titres invisibles dans le sélecteur de l’éditeur de site. La correction : déclarer le slug déjà kebabé (h-1) et le référencer via le preset, jamais via la variable CSS brute. Le genre de « gotcha » (Je t’ai eu) qu’on n’oublie plus une fois rencontré.

Mosparo sans porte d’entrée. Les formulaires Spectra n’exposent pas d’API publique pour brancher un anti-spam tiers comme Mosparo. Solution : un correctif qui détourne window.fetch côté client, plus un gestionnaire AJAX prioritaire côté serveur. Ça marche, mais ça raconte une vraie limite de l’écosystème.

Deux autres points méritent une mention rapide : 15 vieux articles en Classic Editor ont dû être basculés en blocs par un script PHP dédié (le coût caché classique du contenu ancien).

Les résultats concrets

À la clôture, sur le clone, sans aucun constructeur de pages :

• 6 pages publiées (les 5 d’origine plus une Politique de confidentialité).
• 43 articles repassés en contenu Gutenberg natif, dont 15 anciens articles convertis depuis Classic Editor par script.
• 10 fiches ouvrages (CPT Mooberry) avec un carrousel de livres Spectra (bonus).
• 6 templates FSE et 3 template parts (en-tête, pied de page, sidebar), plus 3 compositions synchronisées réutilisables.
• Un design system complet dans wp_global_styles : palette de 8 couleurs, trois typographies (Roboto Condensed, Open Sans, Condiment), échelle de titres et de corps, espacements base 8, largeurs de contenu 720 et 1140.

Le point dont je suis le plus content, c’est l’empreinte du code : zéro fichier de thème modifié, un seul mu-plugin compagnon (environ 30 lignes utiles pour 3 contournements documentés), et 6 snippets métier. Et là, un détail qui compte : le fichier theme.json du thème n’a pas été touché non plus. Toute la personnalisation « type theme.json » (palette, typo, espacements) passe par la base via wp_global_styles et par des filtres PHP dans le mu-plugin. C’est exactement le contournement que je voulais : obtenir un design system complet sans jamais patcher le thème, donc sans rien casser lors d’une future mise à jour de Twenty Twenty-Five. La personnalisation vit dans la base et l’éditeur de site, pas dans des fichiers modifiés à la main. Au nettoyage final, la désinstallation d’Elementor, d’Elementor Pro et de Hello Elementor a libéré environ 140 Mo de disque et nettoyé près de 315 lignes en base, sauvegarde préalable conservée et vérifications HTTP 200 à l’appui.

Ce que l’IA fait seule, ce qui reste à l’humain

C’est sans doute le partage des rôles le plus parlant du POC.

Claude Code a traité sans intervention manuelle, notamment : l’audit complet des données Elementor via scripts PHP, la configuration du design system en base (Global Styles), la migration des 8 templates Elementor en 6 templates et 3 parts FSE, la conversion des pages et des articles, l’audit qualitatif du contenu (719 corrections d’entités et de balises legacy), le diagnostic des bugs et le grand nettoyage final.

J’ai gardé la main, moi, sur le reste : l’installation des polices via la Font Library, la création de l’Application Password (la sécurité, je n’y touche pas en automatique), la validation visuelle après chaque lot de 3 sections, les décisions de design, la réécriture éditoriale de 2 articles vides, et la décision irréversible de hiérarchie WordPress (page statique en accueil).

En une phrase : l’agent est imbattable sur le mécanique et le diagnostic, l’humain reste maître du design, de la sécurité et de tout ce qui se valide à l’œil.

Le gain de temps, et les limites que j’assume

Soyons honnêtes sur le gain de temps : je n’ai pas de chiffre exact, mais j’ai vraiment l’impression que, sans IA, ça aurait pris beaucoup plus de temps. Le POC s’est déroulé sur 3 jours calendaires, en plusieurs sessions, pas en continu. Ce qui allège déjà le travail, c’est que pendant que Claude bosse, je peux vaquer à d’autres tâches ou réfléchir à la suite.

Ce que je peux dire en qualitatif, c’est que tout le travail mécanique (analyse, conversion, audit de contenu, nettoyage) a été pris en charge par l’agent, et que mon temps s’est concentré sur la supervision, la validation et les décisions, pas sur l’intégration manuelle.

Et puis il faut nommer les limites, parce qu’un POC sans limites est suspect :

• C’est un seul site, un blog de taille modeste. Pas un benchmark généralisable.
• Spectra Pro n’a pas été testé : inutile ici, donc les widgets Pro complexes (modal, slideshow avancés) restent hors périmètre.
• Les médias n’ont pas été migrés en masse ; une vraie industrialisation devra trancher ce point.

Ces limites tracent d’ailleurs la feuille de route. La v2 du POC est déjà cadrée, avec une nouveauté que j’attends de pied ferme : brancher le MCP Opquast pour faire auditer la qualité du site directement pendant la refonte. L’idée, c’est que l’agent ne se contente plus de produire des pages correctes techniquement, mais qu’il les confronte aux bonnes pratiques (accessibilité, conformité, qualité web) au fil de l’eau. Vu ma certification Opquast, autant que l’exigence qualité soit dans la boucle dès la génération, pas seulement à la relecture.

100son.net : la refonte WordPress sans dépendance

Sortir d’un constructeur de pages, ce n’est pas un caprice de technicien. C’est un pari sur la durée : un site qui ne dépend plus d’un produit tiers vieillit mieux. Voici ce que je propose autour de ce sujet :

• Migration d’un site Elementor, Divi ou autre vers le Full Site Editing natif.
• Mise en place d’un design system propre dans theme.json, sans thème enfant à maintenir.
• Conversion de contenu ancien (Classic Editor, Page Builder) en blocs Gutenberg natifs.
• Allègement et sécurisation du site : moins de dépendances, moins de surface d’attaque, de meilleures performances.
• Respect des bonnes pratiques d’accessibilité et de RGPD tout au long de la refonte.

Tout ça avec 10 ans de pratique WordPress, une certification Opquast Expert, et l’habitude de travailler sur un site de dev avant de toucher à votre production.

Pour qui cette approche a du sens

Si votre site repose sur un constructeur de pages qui vous coûte cher en performances et en dépendance, et que vous voulez revenir au standard WordPress sans repartir de zéro, cette méthode tient la route. Elle suppose quand même trois choses : un site clonable en local, un périmètre raisonnable, et quelqu’un qui valide à chaque étape. À ces conditions, oui, l’IA prend en charge le gros du travail ingrat. Le reste, le jugement, reste entre vos mains (ou les miennes).

👉 Contactez-moi pour parler de votre projet de migration Elementor vers FSE, je vous dirai franchement si l’approche est adaptée à votre site.

Ce POC présenté au Meetup WordPress Toulouse

J’ai présenté ce retour d’expérience en avant-première lors du Meetup WordPress Toulouse du 3 juin 2026, devant la communauté locale. Merci aux participantes et participants pour leurs questions, qui ont d’ailleurs nourri certaines précisions de cet article.

Le support de la présentation est disponible ici [.pdf, 435ko].

Et si vous êtes dans la région, rejoignez le meetup : on s’y retrouve régulièrement depuis 2014 pour parler WordPress sans langue de bois.