# Compatibilité Elementor V4 et WPML : ce que cassent les classes globales
> « Les styles ne s'appliquent plus sur cette traduction » : un symptôme précis apparu avec l'architecture atomique d'Elementor V4 et son système de classes globales.
- Auteur : Clément Hadrot
- Publié le : 2026-08-18
- Mis à jour le : 2026-08-18
- Catégorie : Multilingue
- URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/elementor-v4-wpml-classes-globales/
## L’essentiel
- Les classes globales d'Elementor V4 sont stockées indépendamment du contenu traduit
- Une classe modifiée côté langue source ne se répercute pas automatiquement sur les traductions
- Un identifiant de classe globale doit rester strictement identique entre langues
« Les styles ne s'appliquent plus sur cette traduction, alors que la page source reste parfaite. » Ce symptôme est apparu sur plusieurs sites ayant migré vers l'architecture atomique d'Elementor V4, tout en conservant WPML pour la gestion multilingue. Contrairement aux pannes de sélecteur déjà documentées sur les versions précédentes d'Elementor, ce problème ne touche pas la structure des blocs eux-mêmes, mais le système de classes globales introduit par la nouvelle architecture atomique.
## Ce que change l'architecture atomique sur le plan des styles
Elementor V4 introduit un système de classes globales réutilisables, définies une fois puis appliquées à de multiples éléments à travers tout le site, remplaçant en partie les styles inline propres aux versions précédentes de l'éditeur. Ces classes globales sont stockées comme des entités indépendantes des pages qui les utilisent, avec leur propre identifiant interne, distinct du contenu éditorial traduit par WPML.
Sur une page traduite, WPML duplique correctement le contenu et la structure des éléments, mais la référence à une classe globale reste, dans certains cas observés, liée à l'identifiant de la classe telle qu'elle existait au moment de la traduction, sans se synchroniser automatiquement si cette classe est modifiée ultérieurement côté langue source.
## Symptôme : une modification de style invisible sur les traductions
> L'essentiel à retenir : Les classes globales d'Elementor V4 sont stockées indépendamment du contenu traduit ; Une classe modifiée côté langue source ne se répercute pas automatiquement sur les traductions ; Un identifiant de classe globale doit rester strictement identique entre langues
Le cas typique observé se présente ainsi : un designer modifie la couleur d'une classe globale « bouton-principal » sur la page source en français, la vérifie visuellement, et la considère résolue. Quelques jours plus tard, un visiteur signale que le bouton reste dans son ancienne couleur sur la version anglaise de la même page, alors que le contenu textuel de cette traduction affiche pourtant bien le texte à jour.
L'inspection du code source de la page anglaise révèle que l'élément référence toujours un identifiant de classe globale, mais que cet identifiant, dans de rares cas de duplication via WPML, ne correspond plus exactement à celui utilisé sur la page source après une réorganisation antérieure des classes globales dans l'éditeur.
```
```
## Diagnostic : un identifiant de classe globale non partagé entre langues
La cause précise tient à un cas de figure limité mais réel : lorsqu'une classe globale a été créée ou renommée après la première synchronisation d'une page entre langues, WPML duplique la référence à la classe telle qu'elle existait à ce moment-là plutôt que de pointer vers la classe actuelle, provoquant l'apparition d'un identifiant divergent entre la version source et sa traduction.
### Le correctif appliqué
La correction consiste à forcer une resynchronisation manuelle des références de classes globales sur les traductions concernées, via l'outil de synchronisation de WPML dédié aux paramètres Elementor, en sélectionnant explicitement l'option de resynchronisation des styles globaux plutôt que la seule synchronisation du contenu textuel, deux opérations distinctes dans l'interface.
- Vérifier en priorité si le problème touche une classe globale récemment modifiée ou renommée.
- Utiliser la resynchronisation des styles globaux de WPML, distincte de la resynchronisation du contenu.
- Éviter de renommer une classe globale existante ; créer plutôt une nouvelle classe pour limiter ce risque de divergence.
> Sur une architecture par classes globales, un renommage n'est jamais anodin : il crée un point de divergence potentiel entre chaque langue qui référence l'ancienne classe au moment précis du renommage.
## Prévention : une politique de nommage stable des classes globales
Pour éviter la récurrence de ce problème, l'équipe a adopté une règle simple : ne jamais renommer une classe globale existante sur un site multilingue déjà traduit. Toute évolution de style significative passe désormais par la création d'une nouvelle classe globale, avec migration progressive des éléments concernés, plutôt que par la modification d'une classe existante potentiellement référencée différemment selon les langues.
## Ce que cela n'affecte pas
Ce problème reste circonscrit aux classes globales de la nouvelle architecture atomique ; les styles appliqués directement à un élément individuel, sans passer par une classe globale partagée, ne sont pas concernés et se synchronisent normalement entre langues via les mécanismes habituels de WPML.
## Ce qu'il faut retenir
Un style qui disparaît sur une traduction, sans que le contenu textuel ne soit affecté, doit désormais faire suspecter une divergence d'identifiant de classe globale sur les sites utilisant Elementor V4 avec WPML. Une resynchronisation ciblée des styles, distincte de la resynchronisation du contenu, résout la grande majorité des cas observés jusqu'ici.