# Préparer un site Elementor V3 à l’éditeur V4 : inventaire et stratégie

> Recenser widgets, addons et styles locaux avant de migrer vers les éléments atomiques V4, et décider méthodiquement quoi migrer et quoi laisser tel quel.

- Auteur : Clément Hadrot
- Publié le : 2025-09-19
- Mis à jour le : 2025-09-19
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/preparer-site-elementor-v3-editeur-v4-inventaire/

## L’essentiel

- L'inventaire précède toujours la décision de migrer ou non
- Les widgets d'addons tiers ne sont pas tous prêts pour le modèle atomique
- Migrer par lot de pages limite le risque plutôt qu'une bascule totale

Avec l'arrivée de l'éditeur V4 et des éléments atomiques, la question qui revient chez la plupart des clients gérant un site Elementor construit sur plusieurs années n'est pas « faut-il migrer », mais « que faut-il migrer, et dans quel ordre ». Se lancer directement dans la bascule sans inventaire préalable revient à découvrir les incompatibilités une par une en production, ce qui est exactement l'inverse de ce qu'un projet de cette ampleur mérite.

Cette checklist détaille les cinq catégories de contenu à recenser avant toute décision, et la façon de prioriser une migration progressive plutôt qu'une bascule totale risquée.

## 1. Les widgets natifs réellement utilisés

Première étape : lister les widgets Elementor natifs effectivement posés sur les pages du site, pas seulement ceux disponibles dans la bibliothèque. Un export de la liste des types de widgets utilisés par page, via une requête directe sur le contenu sérialisé `_elementor_data` des pages, donne une vision précise bien plus rapide qu'un parcours manuel page par page sur un site de grande taille.

```
wp post list --post_type=page --field=ID | while read id; do
  wp post meta get "$id" _elementor_data | grep -o '"widgetType":"[a-z_-]*"'
done | sort -u
```

## 2. Les widgets d'addons tiers

Deuxième catégorie à recenser séparément : les widgets issus d'extensions tierces (Essential Addons, Crocoblock ou autres), dont la compatibilité avec le modèle atomique dépend entièrement du rythme de mise à jour de chaque éditeur d'extension. Un widget tiers non mis à jour pour l'éditeur V4 continuera de fonctionner en mode classique, mais ne bénéficiera d'aucune des nouvelles fonctionnalités de style atomique tant que son éditeur ne l'aura pas adapté.

> L'essentiel à retenir : L'inventaire précède toujours la décision de migrer ou non ; Les widgets d'addons tiers ne sont pas tous prêts pour le modèle atomique ; Migrer par lot de pages limite le risque plutôt qu'une bascule totale

## 3. Les styles locaux versus les styles globaux

Troisième point de contrôle : la proportion de widgets qui utilisent des couleurs et polices globales définies dans Site Settings, par rapport à ceux qui définissent des styles entièrement locaux, en dur, sur chaque widget. Un site où les styles globaux sont largement utilisés migre plus facilement vers les classes globales et variables introduites par l'éditeur V4, puisque cette architecture reprend en partie la même logique de valeurs centralisées, avec un mécanisme de conversion plus direct.

## 4. Les widgets HTML et le CSS personnalisé

Les widgets HTML bricolés et les champs CSS personnalisé disséminés sur les widgets constituent le point de friction le plus sérieux, car ils échappent par nature à toute analyse automatisée du schéma de propriétés. Chaque occurrence doit être recensée manuellement pour évaluer si le résultat visuel obtenu peut être reproduit avec les nouveaux outils de style atomique, ou s'il doit rester en l'état, hors du périmètre de migration dans un premier temps.

### 5. Les templates du Theme Builder

Header, footer et templates d'archive construits avec le Theme Builder méritent un recensement à part, car ils sont partagés par de nombreuses pages : une incompatibilité découverte sur un header affecte immédiatement l'ensemble du site, contrairement à un problème localisé sur une seule page de contenu.

## Construire la stratégie de migration

| Constat de l'inventaire | Stratégie recommandée |
| --- | --- |
| Widgets natifs majoritaires, peu d'addons tiers | Migration progressive envisageable à court terme |
| Dépendance forte à des addons non encore compatibles | Attendre la mise à jour des extensions avant de migrer les pages concernées |
| Nombreux widgets HTML et CSS personnalisé disséminés | Traiter en priorité le nettoyage de ces widgets avant d'envisager la migration |
| Styles globaux déjà bien utilisés | Migrer en premier les templates de Theme Builder, qui bénéficieront le plus vite des classes globales V4 |

## Découper la migration en lots

- Commencer par un gabarit de page unique et représentatif, pas par la page d'accueil qui concentre souvent le plus de widgets complexes.
- Migrer les templates du Theme Builder en second, une fois la méthode validée sur du contenu de page classique.
- Réserver les pages dépendantes d'addons tiers non compatibles pour une phase ultérieure, une fois ces extensions mises à jour.

## En résumé

Un inventaire rigoureux avant toute migration vers l'éditeur V4 n'est pas une précaution excessive : c'est ce qui permet de transformer un projet risqué et anxiogène en une suite d'étapes maîtrisées, chacune validée avant de passer à la suivante. Les sites qui se lancent sans cet inventaire découvrent leurs incompatibilités les unes après les autres, souvent au pire moment, sur une page en production plutôt qu'en environnement de test.