Gutenberg, Divi, Elementor : autopsie technique des limites que les éditeurs visuels n'ont jamais résolues — et comment l'IA change la donne

Avant-propos : pourquoi cette analyse existe

Cet article n'est pas un procès. Gutenberg, Divi et Elementor ont chacun résolu un problème réel : permettre à des non-développeurs de créer des pages web sans écrire une ligne de code. C'est un accomplissement technique considérable. Mais chaque solution technique porte en elle les limites de l'architecture qui l'a rendue possible. Et ces limites, documentées depuis des années par la communauté des développeurs, ont des conséquences directes sur la performance, le SEO et l'expérience des utilisateurs finaux.

Chez Claude Web Agency (CWA), nous développons un éditeur visuel de nouvelle génération, dont une première version est déjà disponible dans notre SaaS. Cet article est le résultat d'une analyse approfondie des problèmes de code que nos prédécesseurs ont affrontés — non pas pour les critiquer, mais pour comprendre ce que l'éditeur du futur doit résoudre. Et surtout : en quoi l'expérience utilisateur sera fondamentalement transformée.

Chapitre 1 — Le problème originel : comment représenter une page dans une base de données

Le dilemme de la sérialisation

Le premier problème fondamental auquel tout éditeur visuel WordPress a dû répondre est : comment stocker une mise en page visuelle complexe dans un champ texte de base de données MySQL ? WordPress stocke le contenu dans la table wp_posts, dans une colonne post_content de type longtext. Un seul champ texte pour représenter une page entière avec ses colonnes, ses images, ses boutons, ses animations, ses styles responsive.

Divi a choisi les shortcodes. Chaque module visuel est représenté par un shortcode WordPress : [et_pb_section][et_pb_row][et_pb_column][et_pb_text]Mon texte[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]. Cette approche, techniquement élégante au départ, a engendré un problème majeur : le contenu est prisonnier du format Divi. Désactivez le plugin, et votre page affiche une soupe de shortcodes bruts illisible. Votre contenu n'existe pas en dehors de Divi.

Elementor a choisi le JSON sérialisé dans les post_meta. La structure de page est stockée dans wp_postmeta sous forme de tableaux PHP sérialisés (puis JSON à partir de la version 3.0). Le post_content contient une version HTML simplifiée du contenu, mais la "vraie" page — avec ses styles, ses paramètres d'animation, ses breakpoints responsive — est dans les métadonnées. Résultat : deux sources de vérité distinctes pour un même contenu, avec tous les problèmes de synchronisation que cela implique.

Gutenberg a inventé les blocs commentés. L'approche la plus ingénieuse et la plus controversée : le contenu est stocké en HTML dans post_content, mais enrichi de commentaires HTML spéciaux qui délimitent les blocs : <!-- wp:paragraph --><p>Mon texte</p><!-- /wp:paragraph -->. Le contenu HTML reste lisible sans Gutenberg, mais les métadonnées de mise en page sont dans les commentaires. C'est astucieux, mais fragile : toute modification du HTML par un outil tiers peut casser la structure des blocs.

Pourquoi ce problème n'aurait jamais dû exister

Ces trois approches sont des contournements d'une contrainte héritée : le modèle de données de WordPress, conçu en 2003 pour un blog. Un blog a un titre et un contenu texte. Un site web moderne a une arborescence de composants avec des propriétés, des états, des relations parent-enfant et des variantes responsive. Essayer de faire rentrer le second dans le premier est un compromis architectural dont toutes les conséquences décrites dans cet article découlent directement.

Chapitre 2 — Le fléau du DOM : quand chaque module génère 15 niveaux de div

L'imbrication structurelle de Divi

Inspectez le code HTML d'une page Divi dans votre navigateur. Un simple paragraphe de texte génère au minimum : une div.et_pb_section, une div.et_pb_row, une div.et_pb_column, une div.et_pb_module, une div.et_pb_text_inner, puis enfin le <p> contenant votre texte. Six niveaux d'imbrication pour un paragraphe. Pour une page complète avec 20 modules, le DOM atteint facilement 800 à 1 200 nœuds — pour un contenu qui, en HTML sémantique, en nécessiterait 100 à 200.

Ce n'est pas de la négligence de la part d'Elegant Themes (l'éditeur de Divi). Chaque div wrapper a une raison technique d'exister : gestion du padding section, alignement flex des colonnes, isolation des styles de module, conteneur d'animation. Le problème est que cette architecture a été conçue à une époque (2013) où la performance du DOM n'était pas un critère SEO. En 2026, Google mesure le Total Blocking Time et l'Interaction to Next Paint — deux métriques directement impactées par la profondeur et la taille du DOM.

Elementor et le problème des widgets

Elementor adopte une structure similaire. Chaque widget est enveloppé dans div.elementor-element, div.elementor-widget-wrap, div.elementor-widget, div.elementor-widget-container. À cela s'ajoutent les wrappers de section et de colonne. L'équipe d'Elementor a tenté de réduire ce nesting avec la fonctionnalité "Flexbox Container" introduite en 2022, qui remplace l'ancienne structure section/colonne par un système plus plat. Mais la rétrocompatibilité avec les millions de sites existants impose de maintenir l'ancien système en parallèle — ajoutant de la complexité au code plutôt que d'en retirer.

Gutenberg : plus léger, mais pas exempt

Gutenberg produit un HTML plus propre que Divi ou Elementor. Les blocs natifs génèrent un markup sémantique minimal. Mais dès qu'on utilise le système de colonnes, les groupes de blocs ou les blocs tiers, le nesting revient. Le Core Web Vitals d'une page Gutenberg dépend fortement du nombre et du type de blocs utilisés — et surtout de la qualité du code des blocs tiers, sur laquelle l'éditeur de WordPress n'a aucun contrôle.

Chapitre 3 — La guerre du CSS : spécificité, inline styles et feuilles de 400 ko

Le cauchemar de la spécificité CSS

CSS a un système de priorité appelé "spécificité" : un style défini avec un ID (#monElement) surpasse un style défini avec une classe (.maClasse), qui surpasse un style défini avec un sélecteur d'élément (p). Les éditeurs visuels doivent garantir que les styles que l'utilisateur définit dans le panneau de propriétés s'appliquent réellement sur la page, quel que soit le thème WordPress installé.

La solution de Divi : des sélecteurs CSS extrêmement longs et spécifiques. .et_pb_section .et_pb_row .et_pb_column .et_pb_module .et_pb_text_inner p { ... } — cinq niveaux de classe pour cibler un paragraphe. Cette surenchère de spécificité résout le conflit avec le thème, mais crée un nouveau problème : il devient presque impossible de surcharger les styles Divi avec du CSS personnalisé sans utiliser !important en cascade — une pratique que tout développeur CSS considère comme un dernier recours.

Le problème des styles inline d'Elementor

Elementor a fait un choix différent : générer une grande partie des styles en inline directement dans le HTML (style="color: #333; font-size: 16px; margin-top: 20px;"). L'avantage : aucun conflit de spécificité possible, le style inline a la priorité maximale. L'inconvénient : le HTML de la page est gonflé de centaines de déclarations de style répétées, les styles ne sont pas mutualisés (le même color: #333 est répété sur chaque élément au lieu d'être défini une fois dans une classe), et les styles inline sont invisibles pour le cache CSS du navigateur.

De plus, Elementor génère un fichier CSS par page. Pour un site de 50 pages, cela signifie 50 fichiers CSS distincts, chacun contenant l'intégralité des styles de la page. Certains atteignent 200 à 400 ko — pour des styles dont 60 à 80 % sont redondants avec ceux des autres pages. Ce mécanisme a un impact direct et mesurable sur le Largest Contentful Paint.

Gutenberg et les styles JSON

Gutenberg a introduit le theme.json en 2021 pour centraliser la gestion des styles. C'est architecturalement plus propre : les styles sont définis une fois et appliqués via des custom properties CSS (variables). Mais l'implémentation est encore incomplète : les blocs tiers n'utilisent pas toujours theme.json, créant des incohérences, et le système de style global de WordPress (global styles) entre parfois en conflit avec les styles de blocs individuels.

Chapitre 4 — Le mur de JavaScript : quand le frontend paie le prix du backend

Le double chargement de frameworks

Elementor charge, sur le frontend de chaque page visitée par un internaute, entre 300 et 500 ko de JavaScript — dont une portion significative est du code d'éditeur qui n'a aucune utilité côté visiteur. Les scripts de elementor-frontend.js et elementor-waypoints.js incluent des fonctionnalités (drag-and-drop, panneau de propriétés, mode responsive) qui ne servent qu'en mode édition. Leur chargement en frontend est le résultat d'une architecture qui n'a pas suffisamment séparé le code d'édition du code de rendu.

Divi fait de même avec et-builder-modules-script.js (environ 150 ko minifié) chargé systématiquement. Les animations CSS suffiraient pour la plupart des effets visuels de Divi, mais le JavaScript est nécessaire pour la comptabilité avec les anciens navigateurs et la rétrocompatibilité avec les fonctionnalités historiques.

Le problème du rendu côté serveur

WordPress génère le HTML côté serveur (Server-Side Rendering). Les éditeurs visuels ajoutent une couche de rendu côté client (Client-Side Rendering) pour les animations, le lazy loading et les interactions. Ce double rendu crée des problèmes de "flash" au chargement : le HTML serveur s'affiche, puis le JavaScript client le modifie, provoquant des sauts de mise en page (CLS) visibles par l'utilisateur et mesurés par Google.

Chapitre 5 — L'éditeur visuel du futur : ce que l'IA rend possible

Repenser l'architecture depuis zéro

L'éditeur du futur ne corrige pas les problèmes de Divi ou d'Elementor — il les élimine en partant d'une architecture fondamentalement différente. Chez CWA, l'éditeur que nous développons repose sur trois piliers architecturaux qui n'existaient pas quand ces éditeurs ont été conçus.

Premier pilier : un modèle de données natif, pas un hack sur WordPress. Chaque élément de la page est un objet structuré avec un type, un contenu, des propriétés de style, des animations et des variantes responsive — le tout stocké dans une base de données pensée pour cette structure. Pas de shortcodes, pas de JSON sérialisé dans un champ texte, pas de commentaires HTML. L'objet de données est la page. Le rendu HTML est un produit dérivé, généré à partir de cette source de vérité unique.

Deuxième pilier : la séparation totale édition/rendu. Le code de l'éditeur visuel (canvas, panneaux, outils de sélection) ne se retrouve jamais dans le site publié. Le site exporté est du HTML/CSS propre, optimisé, sans aucune trace du builder. Ce n'est pas un objectif aspirationnel — c'est une contrainte architecturale imposée dès la conception. Résultat : les pages publiées n'ont aucun JavaScript de builder à charger, aucun CSS de framework superflu, aucun wrapper div inutile.

Troisième pilier : l'IA comme co-éditeur, pas comme gadget. Ce pilier est le vrai changement de paradigme. L'IA n'est pas ajoutée par-dessus un éditeur existant — elle est intégrée dans l'architecture même de l'éditeur.

Ce que l'IA change concrètement pour l'utilisateur

Dans un éditeur classique, l'utilisateur manipule des propriétés CSS une par une : taille de police, couleur, espacement, alignement. C'est un processus technique qui requiert une compréhension du design et du CSS. Dans notre éditeur, l'utilisateur peut simplement dire : "Rends ce titre plus impactant" ou "Adapte cette section pour un public B2B" — et l'IA modifie les propriétés pertinentes en fonction du contexte sémantique de l'instruction.

Notre barre de commande IA (AICommandBar) permet d'éditer n'importe quel élément du canvas par instruction en langage naturel. L'IA reçoit le contexte complet de l'élément — son type, sa position, ses styles actuels, son contenu — et retourne un patch JSON validé qui modifie uniquement les propriétés pertinentes. Des gardes de sécurité empêchent la modification de l'identifiant ou du type de l'élément, garantissant l'intégrité structurelle de la page.

Le panneau SEO Agent va plus loin : il analyse la page en temps réel et suggère des optimisations de contenu, de métadonnées et de structure — directement dans l'éditeur, sans sortir du contexte de travail. L'utilisateur n'a plus besoin de comprendre le SEO technique pour produire une page bien référencée.

Le système de design tokens : la fin du CSS inline

Au lieu de définir des couleurs, tailles et espacements en valeurs absolues pour chaque élément (la cause du CSS bloat de Divi et Elementor), notre éditeur utilise un système de design tokens. Un token est une variable sémantique : color-primary, spacing-section, font-heading. L'utilisateur ne choisit pas #2563eb — il choisit "couleur primaire". Modifier un token met à jour instantanément tous les éléments qui l'utilisent.

Ce système résout simultanément trois problèmes : la cohérence visuelle (impossible d'avoir 15 nuances de bleu légèrement différentes), la maintenabilité (changement de charte graphique en un clic) et la performance (les tokens sont compilés en custom properties CSS, soit quelques lignes au lieu de centaines de déclarations inline).

Le responsive natif, pas adaptatif

Divi et Elementor traitent le responsive comme une couche ajoutée après coup : "voici vos styles desktop, maintenant masquez cet élément sur mobile et réduisez cette police". Notre éditeur utilise un système de breakpoints avec override par propriété : chaque élément a ses propriétés par défaut, et chaque breakpoint (tablette, mobile) peut surcharger uniquement les propriétés qui doivent changer. C'est la même logique que les media queries CSS, mais exposée visuellement dans un panneau dédié plutôt que dans du code.

L'utilisateur bascule entre les vues desktop, tablette et mobile dans l'éditeur et ajuste directement ce qu'il voit — sans jamais écrire une media query. Les propriétés non modifiées héritent automatiquement du breakpoint parent.

Les animations sans JavaScript

Notre système d'animation (onScroll, onHover, onLoad) couvre les cas d'usage les plus courants : fade-in au scroll, scale au hover, parallaxe, typewriter, blur-in. Ces animations sont définies dans les propriétés de l'élément et compilées en animations CSS natives — pas en JavaScript. Là où Elementor charge un fichier JS de 50 ko pour ses animations, notre éditeur produit quelques lignes de CSS pur qui s'exécutent sur le GPU du navigateur.

Chapitre 6 — Ce que tout cela change pour l'utilisateur final

L'utilisateur d'un éditeur classique doit penser en termes de modules, colonnes, sections, padding, margin, breakpoints. C'est du vocabulaire technique, pas du vocabulaire de design ou de business. L'éditeur du futur permet à l'utilisateur de penser en termes de message, hiérarchie visuelle, intention de conversion, expérience mobile — l'IA traduit ces intentions en propriétés techniques.

Concrètement, pour l'utilisateur de notre SaaS chez CWA :

• Il ne manipule plus du CSS — il décrit ce qu'il veut, et l'IA ajuste les propriétés.
• Il ne gère plus les conflits de responsive — le système de breakpoints hérités s'en charge.
• Il ne subit plus les temps de chargement de l'éditeur — l'architecture canvas est légère par conception.
• Il ne sacrifie plus la performance pour le design — l'export produit du code propre, sans vestige du builder.
• Il ne part plus d'une page blanche — l'IA génère une maquette initiale qu'il affine ensuite visuellement et par instructions naturelles.

Ce n'est pas un éditeur visuel amélioré. C'est un outil de création web d'une nature différente — rendu possible par la convergence de frameworks modernes (Next.js, React), d'architectures de données natives (Zustand, Supabase) et de modèles de langage capables de comprendre des instructions de design en langage naturel (Claude). Les limitations de Gutenberg, Divi et Elementor n'étaient pas des erreurs — c'étaient les conséquences inévitables des technologies de leur époque. L'époque a changé.