2026 marque la fin programmée du support étendu d’une version d’Elementor sur laquelle reposait, depuis près de six ans, un réseau multisite de 500 sites vitrines destinés à des indépendants d’un même secteur. La décision de migrer vers un thème bloc natif ne s’est pas prise à la légère : sur un parc de cette taille, une migration ratée aurait un impact direct sur des centaines de clients simultanément.
La méthode retenue ne devait à aucun moment interrompre la disponibilité des sites existants, ni imposer une bascule brutale un jour donné. Voici comment la migration a été construite, cohorte par cohorte, sur un peu plus de trois mois.
Étape préalable : cartographier la diversité réelle du parc
Avant tout script de migration, un audit a classé les 500 sites selon leur complexité de mise en page : structure simple (page d’accueil, contact, prestations), structure intermédiaire (ajout d’une galerie ou d’un blog), structure complexe (mise en page personnalisée avec positionnement libre). Cette cartographie a permis d’estimer, avant de commencer, la proportion de sites migrables automatiquement et celle nécessitant une intervention manuelle.
Étape 1 : construire le thème bloc de destination
Le nouveau thème bloc reprend la structure visuelle du kit Elementor existant : mêmes zones d’en-tête et de pied de page, mêmes gabarits de page type. Les templates front-page.html, page.html et les parties de template correspondantes ont été construits en miroir des sections Elementor les plus utilisées sur le réseau, pour que la conversion automatique dispose d’une cible stable.
Étape 2 : un script de conversion pour les structures simples
Pour les sites classés en structure simple, un script PHP exécuté via wp-cli parcourt le contenu Elementor stocké en métadonnée _elementor_data, en extrait les blocs de texte, titres et images, puis génère le contenu équivalent au format de blocs natifs, inséré directement dans le contenu de la page :
wp eval-file migrer-page.php --url=client042.reseau.example --page_id=12Ce script couvre environ 80 % des pages du réseau, correspondant aux structures simples et à une bonne partie des structures intermédiaires, sans intervention humaine autre qu’une vérification visuelle rapide après conversion.
Étape 3 : traitement manuel des structures complexes
Les 20 % de sites aux mises en page les plus personnalisées ont été confiés à un référent dédié, qui reconstruit manuellement chaque page dans l’éditeur de site, en s’appuyant sur les patterns du nouveau thème plutôt que de tenter une conversion automatique vouée à produire un résultat approximatif. Ce choix a délibérément ralenti le traitement de cette portion du parc, jugé préférable à une automatisation forcée sur des structures trop spécifiques.
Étape 4 : migrer par cohortes, jamais en une seule vague
Le réseau a été découpé en cinquante cohortes de dix sites, migrées à raison de trois à quatre cohortes par semaine. Chaque cohorte suit le même déroulé : génération du contenu converti sur un environnement de recette dédié au site concerné, vérification visuelle par un chargé de compte qui connaît le client, puis bascule du thème actif uniquement pour les sites validés de la cohorte.
Pourquoi ce rythme plutôt qu’une bascule réseau globale
Une bascule de thème au niveau du réseau entier aurait affecté les 500 sites simultanément dès la moindre anomalie non détectée en recette. Le découpage en cohortes limite l’impact d’un problème imprévu à dix sites au maximum, largement gérable en cas de rollback ciblé, sans jamais mettre en péril l’ensemble du parc.
Suivi et ajustements en cours de route
- Un tableau de suivi centralisé trace l’état de chaque site : non migré, en recette, validé, basculé en production.
- Les anomalies récurrentes détectées sur les premières cohortes (mauvaise conversion des colonnes à largeurs personnalisées) ont permis d’affiner le script de conversion avant les cohortes suivantes.
- Un canal de support dédié a été ouvert pour que les chargés de compte signalent rapidement toute régression visuelle constatée par un client.
Sur une migration de cette ampleur, le vrai risque n’est jamais le script de conversion lui-même : c’est la tentation d’aller plus vite que ce que la vérification humaine peut réellement absorber.
En résumé
La migration complète des 500 sites du réseau s’est étalée sur quatorze semaines, un rythme jugé lent au démarrage mais qui a évité tout incident majeur affectant plusieurs sites à la fois. Cette méthode ne couvre pas le cas d’une migration d’un site isolé, sensiblement plus simple, ni la configuration multisite elle-même, restée inchangée tout au long de l’opération.
