Migrer 700 articles de SiteOrigin vers Gutenberg avec l’IA : retour d’expérience

Migrer un site WordPress qui tourne depuis dix ans sur SiteOrigin Page Builder vers les blocs natifs Gutenberg, c’est un chantier que beaucoup repoussent. Plus de sept cents articles à reprendre un par un, c’est plusieurs mois de travail à la main. Sur le projet Ma Maison Magazine (ma-maison-mag.fr), j’ai bouclé l’opération en 30 heures réelles, en pilotant Claude Code (l’agent de programmation d’Anthropic) pour produire un ensemble de scripts PHP exécutés via WP-CLI. Voici comment, et surtout ce que ça change pour ce type de chantier.

Le contexte : le troisième temps d’une rénovation complète

Cette migration s’inscrit dans la suite logique d’une intervention plus large que je raconte dans Modernisation et allègement du site Ma Maison Mag. Pour résumer rapidement les deux premières étapes déjà accomplies :

1. Optimisation des médias : compression des images, suppression des fichiers inutilisés. Un site qui pesait plus de 8 Go a déjà été allégé de plus de 50 %.
2. Modernisation du socle WordPress : passage du vieux thème Origamiez au thème natif Twenty Twenty-Five, adoption de l’extension Spectra Pro, constructeur basée sur Gutenberg, ajout du champ ACF Chapô pour gérer proprement les chapeaux éditoriaux. Nouvelle division par deux du poids du site, formation de l’équipe éditoriale au mode bloc.

À ce stade, le site est moderne, performant, l’équipe est autonome sur les nouveaux articles. Mais plus de sept cents articles publiés depuis 2016 restent en SiteOrigin Page Builder en base de données. Tant que l’extension SiteOrigin tourne, l’affichage public reste correct. Mais c’est une dette technique de dix ans qui pèse sur la maintenabilité, l’éditorial, et la pérennité du site.

L’objectif de cette troisième étape : désinstaller définitivement SiteOrigin en convertissant tout le corpus historique en blocs Gutenberg natifs.

Pourquoi sortir de SiteOrigin Page Builder en 2026 ?

SiteOrigin Page Builder a longtemps été un excellent outil. Mais aujourd’hui, le rester pose plusieurs problèmes concrets :

• Dette technique : le balisage HTML stocké en base est imbriqué dans des structures panels_data propriétaires, illisibles sans l’extension
• Performance : les wrappers <div class="panel-grid"> empilés génèrent du DOM inutile, pénalisant le LCP et le score Core Web Vitals
• Pérennité : Gutenberg est désormais le standard WordPress, soutenu par le core, FSE compatible, et bien plus accessible
• Éditorial : la rédaction qui reprend un ancien article doit comprendre une grille SiteOrigin avant de pouvoir corriger une virgule

Pour un site qui veut durer dix ans de plus, la question n’est pas si on migre, mais quand et comment.

Deux images pour comparer l’interface SiteOrigin vs Gutenberg

L’écueil habituel : la migration manuelle est hors-budget

Le réflexe le plus répandu, c’est de faire la migration article par article, à la main, dans l’éditeur Gutenberg. Faisons le calcul honnêtement sur 728 articles SiteOrigin précisément (le reste du corpus ayant été créé directement en Gutenberg après la modernisation) :

• Article simple (un seul widget Editor) : 5 à 10 minutes pour copier le contenu, recréer les blocs, replacer les images, vérifier le rendu
• Article complexe (plusieurs grilles, colonnes, légendes, liens externes) : 20 à 40 minutes
• Cas particulier (Smart Slider, citations multilignes, mises en page exotiques) : jusqu’à une heure

Le profil du corpus donne une médiane réaliste autour de 15-20 minutes par article, soit 200 à 250 heures de travail pur. Pas d’effet d’échelle, pas de capitalisation : la 700ᵉ migration coûte autant que la 10ᵉ.

À un TJM standard de freelance, on atteint vite les 15 000 à 25 000 € de prestation pour une migration. Pour un magazine régional, c’est tout simplement infinançable.

Faux départ : huit heures perdues avec le mauvais outil

Première confession : avant les 30 heures que je décompte sur ce projet, j’ai laissé filer environ 8 heures non comptées sur un faux départ. À ce moment-là, je travaille avec Claude en mode Chat (l’interface de claude.ai) : je décris le problème, l’IA me produit un script PHP, je copie-colle ce script à la racine du site WordPress et je l’exécute. Boucle. Itération. Re-boucle.

Le résultat semble satisfaisant. Les premiers articles sortent en blocs Gutenberg propres. Je commence à me dire que le chantier va être une formalité.

Jusqu’au moment où, en relisant un article au hasard, je découvre que près de 80 % du contenu a tout simplement été effacé. Pas un, pas deux : plusieurs articles avaient été silencieusement vidés de leur substance par un script qui croyait bien faire. Aucune sauvegarde automatique. Aucun mode DRY_RUN. Aucune validation visuelle systématique. Juste un copier-coller à l’arrache.

Heureusement je travaillais sur un site de dev, copie de la prod et les sauvegardes automatiques que j’avais mis en place m’ont permis de restaurer la base. Mais la leçon était claire : le couple Chat + copier-coller ne tient pas la route sur un chantier de cette ampleur. Il fallait un autre outil.

La bonne configuration : Claude Code, MCP WordPress et skills adaptés

C’est en lisant l’article de WP-Formation « WordPress + MCP : connecter Claude à votre site » que j’ai compris ce qui me manquait. Merci à Fabrice Ducarme (notre étoile du berger⭐️) pour cette mise au point très claire, c’est le déclic qu’il fallait.

La configuration que j’ai mis en place ensuite repose sur trois briques complémentaires :

1 – Claude Code, l’agent de programmation d’Anthropic

Claude Code n’est pas une simple interface de chat. C’est un agent qui :

• Travaille directement dans le système de fichiers du projet (lecture, écriture, exécution)
• Voit les retours d’exécution des commandes qu’il lance et corrige ses erreurs en temps réel
• Garde la trace de ses actions dans un fichier CHANGELOG.md et un CLAUDE.md qui sert de mémoire projet
• Itère sur le code au lieu de redémarrer à zéro à chaque message

Concrètement, je n’ai plus à copier-coller : l’agent écrit le script directement dans le dossier scripts/ du projet, le lance via WP-CLI, lit la sortie, et corrige.

Astuce : penser à lui demander de signaler les scripts que l’on peut lancer manuellement. Ça économise les tokens.😉

2 – Le MCP adapter officiel WordPress

L’extension WordPress/mcp-adapter (maintenue par l’équipe WordPress sur GitHub) expose les capacités du site (lecture de posts, exécution de scripts, requêtes SQL, métadonnées ACF…) via le protocole MCP (Model Context Protocol). Branché sur Claude Code en transport STDIO, ça donne à l’agent un accès direct, structuré et tracé à WordPress, sans passer par un proxy HTTP ni des Application Passwords.

Côté WordPress, l’Abilities API est désormais intégrée au cœur du CMS depuis la version 6.9. Pas besoin d’extension supplémentaire pour la base, juste le mcp-adapter qui sert d’interface.

3 – Des skills personnalisés pour le contexte WordPress

J’ai construit pour Claude Code une bibliothèque de skills (fichiers SKILL.md chargés à la demande selon le contexte) qui encapsulent mes standards de développement WordPress :

• Standards de sécurité : nonces, $wpdb->prepare(), wp_kses selon contexte, OWASP
• Coding Standards WordPress : conventions de nommage, hooks, structure des extensions, internationalisation
• PHP 8.2+ : type hints, syntaxe moderne, attributs
• Schéma réutilisables : POST_ID / DRY_RUN / ROLLBACK, idempotence, sauvegarde en post_meta

Ces skills sont l’équivalent d’un briefing permanent : à chaque nouvelle session, l’agent commence par lire le skill pertinent et applique mes conventions sans que j’aie à les rappeler.

4 – L’abonnement adapté à la charge de travail

Premier réflexe : j’ai démarré le chantier avec l’abonnement Claude Pro à 18 € par mois, qui suffit largement pour un usage de développement courant. Mauvaise pioche. Sur un chantier intensif comme celui-ci, où Claude Code enchaîne lectures de fichiers, exécutions de scripts, analyses de retours et itérations sur le code, j’ai été bloqué toutes les deux heures avec une pause obligatoire de deux heures avant de pouvoir reprendre. La moitié de la journée passée à attendre.

J’ai donc basculé sur l’abonnement Claude Max à 90 € par mois (formule 5× Pro). Plus aucune coupure, le travail s’enchaîne sans rupture de rythme. Sur un mois d’usage intensif, ça reste un investissement très inférieur au coût d’une seule journée perdue à attendre la fin d’une fenêtre de blocage.

Pour un usage occasionnel, Pro suffit. Pour piloter un chantier dense sur plusieurs jours, Max devient indispensable.

Le tout dans un environnement local

DevKinsta sur Linux Mint pour faire tourner WordPress en local, WP-CLI pour exécuter les scripts, Git pour versionner le projet, et le mcp-adapter qui fait le pont entre Claude Code et le site. Une fois cette configuration en place, la productivité change d’échelle.

Le pipeline scripté : un script PHP par groupe d’articles

L’approche que j’ai retenue, c’est l’inverse du « article par article » : profiler le corpus, identifier des groupes de structures similaires, et écrire un script de migration par groupe. L’audit initial a révélé des regroupements clairs :

• 209 articles à structure simple (1 grille × 1 widget Éditeur)
• 343 articles à 2 rangées (chapô + corps)
• 31 articles « shopping listings » avec mise en page uniforme (2 colonnes)
• 67 articles « multirow listings » à structure mixte
• Une longue traîne d’articles à 3 à 32 rangées, traités par modèles dédiés

Pour chaque groupe, un script PHP exécuté via wp eval-file qui :

• Filtre strictement les articles concernés (revalidation de la structure avant traitement)
• Tourne en mode DRY_RUN par défaut : on inspecte le diff avant d’écrire en base
• Pose une sauvegarde dans une post_meta dédiée pour permettre un retour arrière granulaire
• Reste idempotent : relancer le script sur un article déjà traité ne fait rien
• S’exécute sur un seul POST_ID d’abord pour validation visuelle, avant le passage à l’échelle

Ce schéma systématique, DRY_RUN sur 1 post → validation visuelle → LIVE global → audit, c’est la colonne vertébrale du chantier. Pas de magie : de la rigueur d’industriel.

Co-piloter l’IA, pas la subir

C’est ici que l’IA change la donne. Écrire à la main 25 scripts de migration spécialisés, chacun avec sa logique d’analyse DOM, ses utilitaires réutilisés, ses garde-fous, c’est plusieurs semaines de développement.

Avec Claude Code branché sur l’environnement de développement local (DevKinsta + WP-CLI + un adaptateur MCP qui donne à l’agent l’accès direct à WordPress), le rapport de force change :

• Je décris le motif observé sur un article représentatif
• L’agent propose un script complet, avec la signature POST_ID / DRY_RUN / ROLLBACK que j’ai standardisée
• Je valide visuellement sur un post test, je signale les écarts
• L’agent itère sur les cas particuliers : balises <br> à l’intérieur d’un <strong>, <a> wrapper autour d’une <img>, signatures auteur collées en fin de paragraphe…

Le rôle de l’expert WordPress reste central : c’est moi qui détecte un faux positif visuel, qui repère qu’une légende a disparu, qui décide si un article hors-motif doit être traité à la main plutôt que tordre le code pour 1 cas sur 700.

L’IA accélère la production de code de 5 à 10 fois. Elle ne remplace pas l’œil de quelqu’un qui sait à quoi ressemble une migration WordPress réussie.

Exemple concret : Ma Maison Mag, 728 articles, 30 heures

Le site Ma Maison Magazine est un média en ligne dédié à l’habitat, la décoration et l’aménagement intérieur en région toulousaine et tarnaise. Plus de sept cents articles publiés depuis 2016, dont 728 bâtis sur SiteOrigin Page Builder + thème Origamiez à l’origine.

Le passage à Twenty Twenty-Five (TT5) + Spectra Pro a posé les fondations modernes (et notamment introduit le champ ACF chapo pour gérer proprement les chapeaux éditoriaux). Le flux automatisé de migration des contenus, lui, a fait basculer le corpus historique tout entier vers ce nouveau standard.

Bilan chiffré du chantier, extrait du changelog du projet :

• 724 articles sur 728 migrés automatiquement (couverture 99,45 %)
• 4 articles traités manuellement pour cause de mise en page atypique
• ~30 articles supplémentaires déjà convertis à la main par mes soins en amont (les plus récents publiés post-modernisation) et marqués pour exclusion
• Extraction du chapô vers le nouveau champ ACF sur l’ensemble du corpus, avec préservation des liens et de la signature photographe quand pertinent
• 6 294 images normalisées au format Gutenberg moderne (suppression des attributs HTML width/height hérités du pré-WP 6, synchronisation is-resized)
• 9 509 paragraphes vides + 662 titres vides supprimés du corpus
• 14 564 <span> Pinterest parasites nettoyés (séquelle d’une ancienne intégration)
• 4 673 substitutions typographiques françaises (espaces insécables avant : ; ! ? €, guillemets « »)
• 385 images mises en lightbox native WordPress (Interactivity API, WP 6.4+)
• Sauvegardes granulaires posés sur chaque article migré, retour arrière possible à tout moment

Le ROI brut :

• Estimation manuelle : 200 à 250 heures de travail pur
• Temps réel scripté + IA : 30 heures (audit, écriture des motifs, validation, LIVE, audit final), hors les 8 heures de faux départ avec Claude Chat décrites plus haut
• Facteur de gain : entre 7x et 8x
• Économie en temps facturable : 170 à 220 heures, soit l’équivalent de plusieurs semaines libérées pour autre chose.

Et surtout : le chantier est devenu finançable. Sans cette approche, Ma Maison Mag serait probablement resté avec son corpus historique en SiteOrigin pendant encore cinq ans, avec une dette technique qui s’aggrave à chaque nouvelle version de WordPress et de PHP.

Ce que l’IA seule n’aurait pas vu

Même avec la bonne configuration en place, Claude Code, MCP, skills, pipeline DRY_RUN/sauvegarde/idempotence, plusieurs bugs ont nécessité un œil humain expérimenté pour être détectés et corrigés. Voici quatre exemples parmi les plus instructifs :

1 – Le bug de pagination par OFFSET

Premier script de nettoyage, j’enchaîne les batches avec LIMIT 50 OFFSET N. Sauf que le filtre SQL exclut les posts déjà traités. Conséquence : à chaque incrément d’OFFSET, 50 posts sont silencieusement sautés. Sur 317 articles cibles, 150 ont été oubliés. Diagnostic et correction (pagination par ID > last_id au lieu d’OFFSET), puis re-passe.

2 – La lightbox stockée en base vs rendu serveur

Premier script de lightbox : il injectait dans le HTML stocké la classe wp-lightbox-container et un bouton <button class="lightbox-trigger">. Côté front, ça marchait. Mais l’éditeur Gutenberg affichait « Le bloc contient du contenu invalide ou inattendu ». Cause : ces éléments sont injectés au moment du rendu serveur par WordPress quand l’attribut lightbox.enabled est posé. Les stocker en base, c’est du double-emploi qui invalide le bloc. Correction : ne plus toucher au HTML stocké, modifier seulement les attributs.

3 – Le tempered token sur les listes à puces

Conversion des paragraphes commençant par • en bloc core/list. La regex initiale utilisait un quantificateur non-greedy (?:.+?) qui pouvait backtracker à travers </p> et avaler silencieusement les paragraphes intermédiaires non-bullet. J’ai signalé que sur un article précis, « il y a du texte entre les items qui commencent avec une puce » avait disparu. Correction : remplacement du .+? par un tempered token qui interdit explicitement la traversée de </p>.

4 – Désynchronisations média invisibles

Sur un article, les <img src> pointaient vers des fichiers .png alors que les attachments correspondants étaient en .jpg dans la base. Le fichier .png n’existait même pas physiquement. Conséquence : attachment_url_to_postid() retournait 0, le pipeline ne pouvait pas attacher les images. Pas un bug du script, une désynchro héritée probablement d’une ancienne extension de conversion d’images. Décision : traiter cet article manuellement.

Ces quatre cas illustrent une réalité qu’il faut accepter : l’IA est un excellent producteur de code, mais c’est le développeur expérimenté qui valide, qui repère les régressions visuelles, et qui décide quand un cas hors-motif doit basculer en traitement manuel plutôt que de complexifier le code à l’infini.

100son.net : la migration de votre site WordPress, à votre échelle

Si votre site WordPress tourne encore sur SiteOrigin Page Builder, WPBakery (anciennement Visual Composer), Divi en mode legacy ou tout autre constructeur de pages devenu encombrant, je peux vous accompagner sur une migration progressive vers Gutenberg :

• Audit du corpus : profilage des structures, identification des groupes, estimation chiffrée du chantier
• Modernisation du socle : passage à un thème natif moderne, choix d’une extension Gutenberg (Spectra, Kadence, GenerateBlocks…) adaptée à vos besoins
• Pipeline sur-mesure : scripts PHP idempotents¹ avec sauvegarde, retour arrière, validation visuelle
• Co-pilotage IA : Claude Code utilisé comme producteur de code, pas comme décideur
• Validation humaine sur chaque étape : aucun passage à l’échelle sans contrôle qualité
• Préservation SEO : URLs, métadonnées, champs ACF, images attachées, structure éditoriale
• Formation de votre rédaction sur Gutenberg après migration

L’objectif n’est pas de « passer à Gutenberg » parce que c’est tendance. C’est de redonner à votre site une base technique saine, lisible par les éditeurs WordPress de 2030, et performante.

Faites le choix d’une migration maîtrisée

Une migration WordPress d’envergure, c’est trois choses : une méthode rigoureuse, un outil approprié, et une décision claire sur ce qui sera automatisé et ce qui restera manuel. L’IA ne dispense pas de l’expertise : elle la démultiplie.

👉 Contactez-moi pour un audit gratuit de votre site et une estimation chiffrée de votre migration.

Notes de bas de page :

1. idempotents : signifie qu’une opération a le même effet qu’on l’applique une ou plusieurs fois. Ref. ↩︎