Le 2 juin 2026, Elementor 4.1 a fait entrer Angie dans l’éditeur atomique : à partir de cette version, l’agent sait créer des formulaires, des variables et des classes. La version 4.2, en juillet, a étendu la génération aux sections et aux boucles. Le constat qui en découle pour un intégrateur est simple : ce qui sort de l’IA n’est plus une pile de widgets jetables, c’est de la structure réelle qu’il faudra entretenir. Cet article fait partie de la série « IA et constructeurs de pages » ; il propose une checklist de reprise, sans aborder le CSS personnalisé.
Ce que l’on peut attendre, selon Elementor
Les notes de version de la 4.2 indiquent qu’Angie génère désormais des sections en structure atomique native (vrais conteneurs, classes et variables du système de conception), comme une mise en page faite à la main. Elle peut aussi créer un système de conception à partir d’une capture d’écran, d’une consigne ou d’un CSS existant, générer des boucles (avec réglages de requête, disposition et modèle d’élément) et, pour les utilisateurs Pro, des composants réutilisables. Les formulaires exigent Elementor Pro.
Deux précisions de contexte, vérifiées au moment de la rédaction. L’éditeur atomique n’est pas encore l’éditeur par défaut : on l’active dans les réglages d’Elementor (section Éditeur, option Éditeur atomique), et la version V3 reste la base. Ensuite, la version 4.3 était en bêta à la mi-septembre 2026, avec une sortie annoncée pour le 22 septembre ; vérifiez votre version avant de suivre ces conseils.
Ces annonces décrivent l’intention de l’outil, pas une garantie sur chaque génération. Je n’ai pas mesuré, sur un échantillon de pages, la fréquence des écarts ci-dessous ; la checklist qui suit est donc une liste de points à contrôler, pas un constat chiffré de défauts.
Pourquoi la reprise reste indispensable
Dans l’éditeur atomique, la documentation d’Elementor décrit les styles d’un élément comme des définitions locales attachées à l’élément, avec variantes responsives et états (survol, focus). À côté, les classes globales sont partagées. Une génération peut donc, selon la consigne, placer un même réglage soit dans une classe réutilisable, soit en local sur dix éléments. Les deux rendent bien à l’écran ; seul le second coûte cher à la première modification de charte.
Le retour d’un testeur sur la discussion de la 4.3 illustre un autre point : avec plus de deux cents classes, l’ordre d’application devient difficile à gérer, et un mainteneur explique que les règles de spécificité du CSS empêchent de réordonner par élément. Une génération qui multiplie les classes aggrave ce risque.
La checklist de reprise
- Styles locaux ou classes. Parcourez chaque élément généré : un style répété sur plusieurs éléments doit devenir une classe. Supprimez les styles locaux devenus redondants.
- Variables. Ouvrez le gestionnaire de variables : des variables créées mais jamais appliquées s’accumulent vite, tandis que des couleurs écrites en dur échappent au système. Reliez-les, ou supprimez-les.
- Nommage. Les libellés proposés sont lisibles par l’IA, pas forcément par votre équipe. Renommez selon votre convention.
- Structure. Comptez les niveaux de conteneurs imbriqués : chaque niveau superflu alourdit le code produit. Aplatissez ce qui peut l’être.
- Sémantique. Vérifiez la balise de chaque titre, l’ordre hiérarchique, les textes alternatifs des images et les libellés des liens.
- Responsive. Contrôlez chaque point de rupture, et ce sur le site public : enregistrez la page, puis validez la disposition dans le canevas et côté visiteur, en particulier après l’application de classes à une grille.
- Contenu. Remplacez tout texte fictif, relisez les promesses commerciales, et vérifiez les images.
- Boucles. Le modèle d’élément d’une boucle relève de l’offre Pro ; vérifiez la requête, le nombre d’éléments et l’état vide.
Une mise en page générée est un devis de structure : elle chiffre ce qui est possible, pas ce qui est juste.
Un cas concret : une page de services en six blocs
Demandez à Angie une page de services avec six cartes et un bandeau d’introduction, en précisant : « réutilise nos classes et nos variables existantes ». Sans cette phrase, rien n’oblige l’agent à s’aligner sur votre système ; avec elle, il dispose au moins de l’instruction. Puis appliquez la checklist dans l’ordre : quelques minutes suffisent à voir si les six cartes partagent une classe ou si chacune porte son style local. Si ce n’est pas le cas, regroupez avant toute autre retouche, car la correction est beaucoup plus simple avant l’habillage par les équipes de contenu.
Le cas publié par une agence utilisant le MCP d’Elementor va dans le même sens : l’équipe indique que l’examen humain reste essentiel pour l’accessibilité, le comportement responsive et la cohérence, et que l’éditeur visuel reste plus rapide pour les ajustements fins.
Quand ne pas générer la mise en page
Évitez la génération sur une page à fort enjeu d’accessibilité, quand le système de conception n’est pas encore posé (l’IA en inventera un), ou sur un site en V3 que vous ne comptez pas migrer : l’édition par MCP, elle, ne concerne que les pages atomiques. Et si la page est simple, la composer à la main prendra autant de temps que la relecture.
Conclusion
La génération atomique d’Elementor est crédible parce qu’elle produit des objets que vous pouvez gouverner : classes, variables, conteneurs. La contrepartie est qu’il faut les gouverner. Posez d’abord le système, générez ensuite, puis déroulez la checklist avant toute publication. Les notes de la version 4.2 sont disponibles dans la discussion officielle sur GitHub.
