Pourquoi je n’enseignerai pas encore Elementor V4 à mes étudiants

Je prépare une séance sur Elementor pour des étudiants en édition. Avant d’écrire le support, j’ai voulu savoir ce qu’ils verraient exactement en installant le plugin. La documentation officielle m’a donné une réponse. Le code source du plugin m’en a donné une autre, plus précise, et c’est celle-là qui a décidé du cours.

Elementor est passé en version 4 fin mars 2026. Nouveau numéro, nouvel éditeur, nouveau vocabulaire : éléments atomiques, classes globales, composants. La FAQ officielle l’annonce : « à partir d’avril 2026, tous les nouveaux sites Elementor tourneront en version 4 par défaut ».

Mes étudiants installent le plugin mercredi prochain. Si mon support décrit une interface et qu’ils en voient une autre, la séance est perdue.

1. La documentation ne répond pas à la bonne question

La FAQ officielle est claire sur le principe : « On every new Elementor installation, atomic features are enabled by default and the new Atomic Elements appear at the top of the Elements panel. »

Mais qu’est-ce qu’une « nouvelle installation » ? Un WordPress neuf ? Ou un plugin installé pour la première fois sur un site existant ? Or les WordPress de mes étudiants ont été montés deux semaines plus tôt, avec déjà des contenus et d’autres extensions.

J’ai donc arrêté de lire la documentation. Avec Claude Code connecté au serveur, j’ai installé le plugin sur mon espace de démonstration et je suis allé lire son code.

2. Trois lignes de PHP qui valent toute la FAQ

Elementor gère ses nouveautés par un système d’expériences. Chacune a un nom, un statut et un état par défaut. Une commande WP-CLI les liste sur une installation réelle :

wp eval '
$m = \Elementor\Plugin::$instance->experiments;
foreach ($m->get_features() as $k => $f) {
  printf("%-34s %-8s defaut=%-8s statut=%s\n",
    $k,
    $m->is_feature_active($k) ? "ACTIF" : "inactif",
    $f["default"] ?? "?",
    $f["release_status"] ?? "?");
}
'

Mon espace de démonstration est un WordPress monté pour le cours dix jours plus tôt, avec ses contenus et ses extensions, mais qui n’avait jamais connu Elementor. Avec la version 4.3.2, la sortie contient ces deux lignes :

e_atomic_elements                  ACTIF    defaut=active   statut=beta
e_opt_in_v4                        ACTIF    defaut=active   statut=alpha

Les deux fonctionnalités de la version 4 sont actives. Mais les statuts annoncent beta et alpha, alors qu’Elementor communique sur une version stable depuis mars. Contradiction apparente. Le fichier qui enregistre cette expérience l’explique :

Plugin::$instance->experiments->add_feature([
    'name'           => 'e_opt_in_v4',
    'title'          => 'Editor V4',
    'hidden'         => true,
    'default'        => Experiments_Manager::STATE_INACTIVE,
    'release_status' => Experiments_Manager::RELEASE_STATUS_ALPHA,
    'new_site'       => [
        'default_active'               => true,
        'minimum_installation_version' => '4.0.0',
    ],
]);

Tout est dans les trois lignes du bloc new_site. Le défaut global est inactif ; ce bloc le renverse pour tout site dont la première installation d’Elementor est en 4.0.0 ou plus. Le drapeau hidden, lui, la retire de l’écran des fonctionnalités expérimentales.

Les statuts alpha et beta sont donc des étiquettes internes du code, pas le statut commercial du produit.

3. Ce que le code appelle un site neuf

Restait à savoir comment Elementor date cette première installation. La fonction qui tranche s’appelle install_compare :

private function install_compare( $version ) {
    $installs_history = Upgrade_Manager::get_installs_history();

    if ( empty( $installs_history ) ) {
        return version_compare( ELEMENTOR_VERSION, $version, '>=' );
    }

    $cleaned_version = preg_replace( '/-(beta|cloud|dev)\d*$/', '', key( $installs_history ) );

    return version_compare( $cleaned_version, $version, '>=' );
}

Elementor tient un historique de toutes ses versions installées sur le site, dans l’option elementor_install_history. La fonction lit la première entrée de cet historique, et seulement elle. L’âge du WordPress ne compte pas. Ses contenus non plus.

Une lecture de code reste une hypothèse tant qu’on ne l’a pas confrontée au réel. J’avais sous la main le cas contraire parfait : un espace qui portait encore le site d’un étudiant de l’année précédente, avec Elementor et Elementor Pro. J’ai lu l’historique des deux sites :

# Espace de démonstration
elementor_install_history : {"4.3.2":1790355296}
  -> première version : 4.3.2 (25/09/2026)     e_opt_in_v4 : ACTIF

# Site de l'année précédente
elementor_install_history : {"3.32.3":1759232291,"3.32.4":1761045692,
                             "3.33.4":1765227506,"3.35.5":1771358779,
                             "4.2.4":1788420383}
  -> première version : 3.32.3 (30/09/2025)    e_opt_in_v4 : inactif

Le second site tourne en 4.2.4 depuis début septembre. Même version majeure, comportement opposé : ses éléments atomiques sont absents du panneau, parce que sa première version était une 3.32.3. L’hypothèse tient.

4. Compter les briques : mon premier chiffre était faux

Premier comptage : 9 widgets atomiques contre 140 classiques. J’ai failli écrire que la V4 était une coquille presque vide.

Elementor range ses widgets dans un registre, et ses éléments de structure (conteneurs, onglets, boucles) dans un autre. Je n’avais interrogé que le premier. Le compte complet des briques enregistrées, sur la même installation :

La roadmap officielle confirme la mesure : boucle, grille et accordéon atomiques sont sortis en juillet 2026. Il manque encore, côté atomique, deux briques dont un portfolio a besoin : le carrousel, annoncé pour octobre, et la galerie, absente de la roadmap.

Surtout, la V4 ne remplace pas la V3. Les deux coexistent sur la même page, la FAQ le dit en toutes lettres. Deux architectures dans un même écran, jusque dans le code : un titre classique et un titre atomique n’ont ni la même classe PHP, ni le même système de réglages.

5. Le test qui décidait de ma progression

Ma séance suivante porte sur l’affichage de champs personnalisés : un type de contenu sur mesure, des champs ACF, et un modèle de page qui les affiche automatiquement. Sans contenu dynamique, cette séance n’existe pas.

Le contenu dynamique est réservé à Elementor Pro. Sur le site de l’année précédente, qui en dispose, j’ai compté les réglages acceptant une valeur dynamique, puis les balises ACF enregistrées :

heading      : 9 controle(s) acceptent le contenu dynamique
text-editor  : 7 controle(s) acceptent le contenu dynamique
image        : 10 controle(s) acceptent le contenu dynamique

8 balises ACF : acf-text, acf-image, acf-url, acf-gallery,
                acf-file, acf-number, acf-color, acf-date-time

Avec les widgets classiques et Elementor Pro, le chemin existe sur une installation réelle : les balises sont enregistrées et les réglages les acceptent.

Du côté atomique, la réponse est moins nette. Elementor publie une page d’aide dédiée au contenu dynamique en V4 : la fonctionnalité existe. Mais le rapport #35820, intitulé « Atomic elements lose styling when referencing ACF fields », décrit exactement le scénario de ma séance : la valeur du champ s’affiche, la mise en forme réglée disparaît. Ouvert le 11 mai 2026, il n’a plus bougé depuis le 20 mai. Trois versions mineures ont suivi.

Statut réel : indéterminé. Pour un cours, un statut indéterminé sur le chemin critique est une réponse suffisante.

6. L’argument qui a vraiment tranché

Ce n’est pas le bug ACF. C’est une famille de rapports plus ennuyeuse : des styles atomiques qui ne s’appliquent pas, ou ne se chargent pas, une fois la page affichée.

Au 25 septembre 2026, je compte sept rapports ouverts sur ce thème dans le dépôt public d’Elementor. Le plus ancien date d’avril, le plus récent, #37385, du 22 septembre. Cinq attendent encore leur premier tri ; un seul est marqué comme corrigé dans la 4.1, sans avoir jamais été refermé. Leurs titres suffisent à dessiner le symptôme : styles perdus dans un modèle, perdus dans une boucle, styles globaux ignorés, fichiers CSS qui répondent par intermittence (#37299). Dans l’éditeur, la page est juste. Publiée, elle peut ne plus l’être.

Le rythme de publication finit de convaincre. Trois versions en trois jours, d’après le journal des modifications embarqué dans le plugin : 4.3.0 le 22 septembre, 4.3.1 le 23, 4.3.2 le 24. La 4.3.1 levait une exception en présence d’Elementor Pro 3.29.2 (#37443) ; Elementor a fermé le rapport le jour même, sans correctif, en demandant de mettre Pro à jour. Sur un quadrimestre, c’est une surface de risque que je ne contrôle pas.

7. Deux pages officielles qui se contredisent

La FAQ officielle affirme que les éléments Grid et Loop « sont déjà en développement ». La roadmap officielle les donne pour sortis en juillet 2026. Et mon propre comptage les trouve bien installés.

Vérifiées le même jour, les deux pages se contredisent. Ce n’est pas un scandale : une FAQ vieillit plus vite qu’une roadmap.

J’apprends à mes étudiants qu’une extension se juge sur quatre critères : nombre d’installations, date de dernière mise à jour, compatibilité annoncée, qualité des avis. Ce cas en ajoute un cinquième, qui vaut pour toute la veille technique : une documentation officielle n’est pas une vérité. Elle a une date, un auteur, et parfois un contradicteur dans la pièce d’à côté.

8. Ce que je prévois pour la classe

Cette année, j’enseigne les widgets classiques. Le reste est un plan de travail, pas encore une règle :

• Ne rien désactiver - les deux familles cohabitent dans le même éditeur, et chaque réglage manuel fait diverger les postes.
• Nommer ce qu’ils voient - la section atomique saute aux yeux en premier. Cinq minutes d’explication évitent une rafale de questions.
• Figer une version pour toute la classe - de la 4.0 à la 4.3 en six mois, des postes désynchronisés finissent par afficher des interfaces différentes.
• Écrire « version 4.x » dans les supports - tout numéro précis sera périmé en janvier.

Et une note pour l’an prochain. Le modèle atomique repose sur des classes réutilisables plutôt que sur du style appliqué élément par élément. C’est ce qu’on enseigne en CSS. Quand le carrousel sera là et les rapports sur les styles refermés, la V4 deviendra probablement un meilleur support pédagogique que la V3.

Ce que j’en retiens

• Le code source répond aux questions que la documentation reformule. Une fonction d’une dizaine de lignes m’a donné la règle exacte là où la FAQ restait approximative.
• Une hypothèse de lecture se vérifie par le cas contraire. Le site qui n’avait pas la V4 prouvait ma lecture mieux que celui qui l’avait.
• Un chiffre brut induit en erreur sans son modèle. Mon « 9 contre 140 » était faux deux fois : la V4 ne remplace pas la V3, et je n’avais interrogé qu’un registre sur deux.
• En formation, le coût d’un outil instable n’est pas la panne. C’est l’apprenant qui se croit responsable d’un défaut qui ne lui appartient pas.
• Une contradiction entre deux pages officielles vaut mieux qu’un bon cours sur la veille. Elle est datée, vérifiable, et elle enseigne le doute à ma place.

Je n’enseignerai pas la version 4 cette année. Peut-être l’an prochain, après avoir refait exactement les mêmes tests.