En 2021, Elementor lançait les Containers Flexbox en version bêta ; cinq ans plus tard, un inventaire du parc de sites suivis par une petite équipe révèle qu’un gabarit sur cinq environ repose encore entièrement sur l’ancien système de Sections et Colonnes. Ce bilan ne porte pas sur la méthode de conversion elle-même, mais sur ce que ces Sections restantes ont concrètement perdu à ne pas avoir basculé.
Le chiffre de départ : un parc encore partiellement en Sections
Sur l’ensemble des gabarits actifs suivis, 18 % reposent encore sur des Sections, une proportion qui diminue chaque année mais reste loin de zéro. Ces gabarits ne sont pas nécessairement anciens au sens du contenu : certains ont été modifiés récemment, simplement sans jamais convertir leur structure de mise en page sous-jacente.
La raison la plus fréquente de cette persistance n’est pas technique mais économique : un gabarit fonctionnel, qui ne pose aucun problème visible, ne justifie pas toujours une intervention dont le bénéfice reste difficile à chiffrer pour le client qui finance le temps passé.
Ce que les Sections ont perdu : la flexibilité de mise en page fine
La perte la plus concrète tient à l’imbrication. Une Section ne peut contenir que des Colonnes, elles-mêmes limitées dans leur capacité à s’imbriquer profondément sans recourir à des astuces de CSS personnalisé. Un Container, à l’inverse, peut contenir d’autres Containers sur plusieurs niveaux, chacun avec sa propre direction (ligne ou colonne), ce qui autorise des mises en page bien plus proches de ce qu’un développeur écrirait directement en CSS flexbox natif.
Sur les gabarits restés en Sections, cette limite se traduit concrètement par un nombre plus élevé de classes CSS personnalisées ajoutées à la main pour compenser ce que la structure native ne permet pas, un surcoût de maintenance qui s’accumule discrètement au fil des modifications successives.
Ce que les Sections ont perdu : le poids de balisage
Une Section génère systématiquement une structure imbriquée de conteneurs et de colonnes, même pour une mise en page simple à un seul bloc de contenu. Un Container équivalent produit un balisage plus direct, avec moins de niveaux d’imbrication pour un même résultat visuel. Sur un gabarit d’article répété plusieurs centaines de fois, cette différence de poids de balisage, bien que modeste à l’unité, finit par représenter un volume non négligeable de HTML transféré à l’échelle du site.
Ce que la conversion a réellement changé, sur le plan visuel
Le constat le plus notable de ce bilan tient justement à ce qui n’a pas changé : sur les gabarits convertis suivis dans le temps, le rendu visuel final est resté identique dans la quasi-totalité des cas, aux ajustements de marge près déjà documentés par ailleurs. La conversion n’a donc pas amélioré l’apparence des pages, elle a surtout allégé leur structure interne et facilité les évolutions futures.
| Aspect observé | Gabarits restés en Sections | Gabarits convertis en Containers |
|---|---|---|
| Niveaux d’imbrication moyens | Plus élevés | Réduits |
| CSS personnalisé de compensation | Plus fréquent | Rare |
| Compatibilité avec les futures classes atomiques | Non prévue | Prévue nativement |
Le point le plus structurant pour l’avenir
Le futur système de classes atomiques d’Elementor cible exclusivement les Containers, jamais les Sections héritées. Un gabarit resté en Sections aujourd’hui ne bénéficiera donc d’aucune des évolutions liées à ce système tant qu’il n’aura pas été converti au préalable, ce qui transforme une question de confort en une question de compatibilité future à moyen terme.
Un gabarit qui fonctionne encore aujourd’hui en Sections n’est pas un gabarit sans problème : c’est un gabarit qui n’a pas encore rencontré la limite qui forcera sa conversion.
En résumé
Cinq ans après leur introduction, les Containers ont largement pris le pas sur les Sections dans le parc suivi, mais une part non négligeable de gabarits reste en retard sans en payer immédiatement le prix. Ce que ces Sections perdent ne se voit pas à l’écran : cela se voit dans la maintenance, dans le poids du balisage, et surtout dans leur incompatibilité avec les évolutions à venir de l’éditeur.
