Ouvrez une page convertie dans Elementor et vous trouvez parfois des conteneurs dans des conteneurs dans des conteneurs. Ce n’est pas un hasard — cela reflète exactement votre HTML. Une fois la règle comprise, il devient facile de la maîtriser.
La règle de base : un élément de bloc, un conteneur
Le convertisseur parcourt votre DOM. Chaque élément englobant de niveau bloc (<div>, <section>, <article>, <header>, <figure>…) devient un conteneur Elementor, et ses valeurs calculées de padding, d’arrière-plan, de bordure, d’arrondi, d’ombre et de mise en page flex/grid sont reportées sur ce conteneur. Les textes, titres, images et boutons deviennent des widgets à l’intérieur.
Ainsi, une chaîne de balisage comme section > div.wrap > div.row > div.col > h2 produit quatre conteneurs imbriqués avant d’arriver au titre. Rien n’est cassé — mais c’est fastidieux à modifier.
Ce qui est déjà fusionné pour vous
Un élément englobant qui n’a aucun effet visuel ni de mise en page est supprimé automatiquement. Concrètement, un <div> est fusionné lorsqu’il a exactement un élément enfant et aucune des propriétés suivantes : arrière-plan, image d’arrière-plan, bordure, padding, box-shadow, max-width, min-height, ou un affichage flex/grid. Le convertisseur les compte et les indique sous « Conteneurs redondants fusionnés » dans la vue d’ensemble de la carte de structure.
Dès qu’un élément englobant porte ne serait-ce qu’un petit padding ou un arrière-plan, il est conservé — car le supprimer modifierait la mise en page.
Les cartes sont aplaties en un seul widget
Il existe un second aplatissement, plus poussé : lorsqu’une carte n’est en réalité qu’un cadre stylé autour d’un seul contenu, le cadre passe sur le widget lui-même et l’élément englobant disparaît. Deux motifs le déclenchent :
- image + titre + texte court → un seul widget Boîte d’image
- icône + titre + texte court → un seul widget Boîte d’icône
Dans les deux cas, l’arrière-plan, la bordure, l’arrondi, l’ombre et le padding de la carte sont écrits dans les réglages de l’onglet Avancé du widget lui-même ; une rangée de cinq cartes devient donc un conteneur Grille contenant cinq widgets — et non un conteneur Grille contenant cinq conteneurs qui contiennent chacun un widget. C’est exactement ainsi que vous la construiriez à la main.
Comment obtenir un résultat plus plat
- Écrivez un HTML moins profond. Un élément englobant par section suffit généralement. Si vous générez le HTML avec une IA, demandez-le explicitement dans le prompt.
- N’ajoutez pas de div de mise en page inutiles. Un parent grid ou flex peut disposer directement ses enfants ; avec le CSS moderne, un élément englobant
.colsupplémentaire par élément est rarement nécessaire. - Utilisez la racine de copie. Dans la carte de structure, cliquez sur l’icône cible de la ligne que vous voulez réellement. Tout ce qui se trouve au-dessus est ignoré, si bien que les éléments englobants extérieurs de la page n’atteignent jamais Elementor.
- Excluez ce dont vous n’avez pas besoin avec l’icône ✕ d’une ligne.
Le test exact — et pourquoi le seuil de padding est de 2px
Mieux vaut connaître la règle exacte, car elle explique la plupart des surprises. Un élément englobant n’est supprimé que si toutes ces conditions sont réunies : il n’est ni flex ni grid ; il n’est pas positionné (fixed, absolute ou sticky) ; il n’a ni couleur ni image d’arrière-plan ; la largeur totale de bordure est nulle ; le padding total est de 2px ou moins ; il n’y a pas d’ombre portée ; il n’y a pas de max-width ; min-height vaut zéro ; et aucune des marges latérales ne vaut auto.
La tolérance de 2px est volontaire. Les navigateurs renvoient le padding calculé en pixels fractionnaires, et un élément englobant qu’une feuille de style déclare sans padding se calcule couramment à quelque chose comme 0.4px une fois l’arrondi, les bordures et le zoom pris en compte. Exiger une valeur strictement nulle conserverait des centaines d’éléments englobants qui ne servent à rien ; tolérer quelques pixels de bruit permet de les supprimer sans jamais écarter un padding réellement voulu par un designer.
Les conditions sur les marges et sur max-width existent pour un motif précis : la colonne de contenu centrée. Un élément englobant avec max-width: 1100px; margin: 0 auto semble vide — pas d’arrière-plan, pas de padding — mais il assure la tâche de mise en page la plus importante de la page. Le fusionner laisserait le contenu s’étaler d’un bord à l’autre. Il est donc conservé et transformé en conteneur Encadré.
Pourquoi les éléments englobants avec padding ne sont jamais fusionnés avec leur enfant
Une idée en apparence raisonnable consiste à aller plus loin : si un conteneur contient exactement un conteneur, les fusionner et additionner les paddings. C’est la première chose que l’on demande, et l’outil s’en abstient délibérément.
Prenez une carte : un élément englobant extérieur avec 24px de padding, qui crée l’espace entre les cartes, contient une boîte intérieure avec son propre padding de 24px et un arrière-plan blanc, qui crée l’espace entre le bord de la carte et son texte. Ces deux paddings semblent identiques dans les styles calculés mais ont des rôles complètement différents. Fusionnez-les et vous obtenez une seule boîte avec 48px de padding, un arrière-plan qui recouvre désormais ce qui était l’espacement, et une rangée de cartes qui n’a plus d’espace entre elles.
Il n’existe aucun moyen fiable de distinguer les deux à partir des seuls styles calculés, et une erreur casse silencieusement une mise en page, d’une façon dont il est vraiment difficile de remonter à la cause. La passe automatique ne supprime donc que les éléments englobants dont on peut prouver qu’ils ne servent à rien, et tout ce qui est ambigu vous est laissé — c’est à cela que servent les commandes de racine de copie et d’exclusion.
Ce que la profondeur vous coûte réellement
Une imbrication profonde n’est pas un problème d’exactitude. La page s’affiche correctement. Ce qu’elle coûte, c’est tout ce que vous faites ensuite :
- La sélection. Cliquer sur un titre dans le canevas sélectionne l’élément le plus profond ; pour atteindre l’élément englobant de la section, il faut remonter le fil d’Ariane quatre ou cinq fois, à chaque fois.
- Le travail responsive. Un padding sur trois tailles d’appareil à travers cinq niveaux imbriqués représente quinze réglages là où il devrait y en avoir trois.
- Le poids du code. Chaque conteneur est un vrai
<div>avec ses propres règles CSS générées. Une profondeur de huit sur vingt sections, c’est beaucoup de balisage pour une mise en page qui n’a besoin que de deux niveaux. - La passation. Si un client ou un collègue modifie la page plus tard, c’est face à un arbre profond qu’il abandonne et vous demande de le faire.
Un exemple concret
Voici la forme que produisent la plupart des constructeurs de pages et des générateurs IA :
section.features > div.container > div.row > div.col-4 > div.card > div.card-body > h3
Sept niveaux pour atteindre un titre. Après conversion, div.container est conservé s’il porte le centrage par max-width, div.row est fusionné s’il s’agit d’un simple parent flex sans style propre — et si .card contient une icône, un titre et un court paragraphe, toute la branche de la carte s’aplatit en un seul widget Boîte d’icône. Les sept niveaux se réduisent à environ trois, sans que vous touchiez à rien.
Réécrivez la source en section.features > div.grid > div.card > h3 et vous arrivez à deux. Toute l’astuce est là : le convertisseur reproduit fidèlement votre balisage, donc un balisage peu profond est la seule voie fiable vers un arbre Elementor peu profond.
Vérifiez avant d’exporter
La vue d’ensemble de la carte de structure affiche la valeur Profondeur d’imbrication max. Si vous voyez un nombre comme 7 ou 8, c’est le signal qu’il faut placer une racine de copie plus bas dans l’arbre, ou simplifier le balisage source et reconvertir. Une profondeur de 3 à 5 reste confortable à manipuler dans l’éditeur Elementor.