Trente-quatre classes globales pour environ douze besoins de style réellement distincts : c’est le constat dressé sur un projet mené par quatre développeurs différents, chacun ayant contribué au design system atomique d’Elementor sans qu’aucune règle commune n’encadre la création de nouvelles classes. Ce chiffre, loin d’être une exception, illustre une dérive fréquente dès qu’un design system grandit sans gouvernance explicite.
Cette analyse détaille les dérives observées sur ce type de projet, précisément liées à l’éditeur atomique et à ses classes globales. La version précédente d’Elementor, qui ne connaissait pas ce système de classes, n’est volontairement pas traitée ici.
Ce qu’on observe sur le terrain
Le symptôme le plus visible reste la multiplication de classes quasi identiques, créées à des moments différents par des développeurs différents, sans qu’aucun n’ait vérifié si une classe existante répondait déjà au besoin. Un bouton d’appel à l’action se retrouve ainsi décliné en trois ou quatre classes globales aux noms proches mais aux propriétés légèrement différentes, sans qu’aucune raison fonctionnelle ne justifie cette multiplication.
Le nommage constitue le second symptôme majeur : sans convention partagée, certains développeurs nomment leurs classes selon leur fonction visuelle (« bouton-orange »), d’autres selon leur rôle sémantique (« bouton-appel-action »), d’autres encore selon la page où la classe a été créée en premier (« bouton-page-accueil »). Cette incohérence rend le gestionnaire de classes de plus en plus difficile à parcourir au fil des mois, jusqu’à devenir quasiment inutilisable pour quiconque n’a pas participé à sa création.
Pourquoi c’est un problème structurel, pas seulement esthétique
Au-delà de l’aspect purement visuel, cette dérive a un coût de maintenance direct : une modification de charte graphique qui devrait toucher une seule classe globale doit en réalité être répercutée sur plusieurs classes redondantes, avec le risque d’en oublier une au passage. Le design system, censé garantir une cohérence facile à maintenir, finit par produire l’effet inverse de celui recherché à l’origine.
Le second coût, plus insidieux, touche l’onboarding de tout nouveau développeur rejoignant le projet : face à une trentaine de classes au nommage incohérent, il devient quasiment impossible de deviner laquelle réutiliser sans redemander à un collègue déjà présent depuis le début, ce qui ralentit chaque nouvelle intervention sur le projet.
Quoi faire pour éviter cette dérive
- Adopter une convention de nommage sémantique partagée avant même la première classe créée, et la documenter dans un espace accessible à toute l’équipe.
- Désigner une personne référente, chargée de valider ou refuser la création de toute nouvelle classe globale, plutôt que de laisser cette décision à la seule initiative de chaque développeur.
- Mettre en place une revue mensuelle légère du gestionnaire de classes, pour repérer les doublons apparus et les fusionner avant qu’ils ne se propagent davantage sur de nouvelles pages.
- Documenter, pour chaque classe créée, le besoin fonctionnel qu’elle couvre, pas seulement son apparence visuelle : cela facilite grandement la recherche d’une classe existante avant d’en créer une nouvelle.
Un exemple concret de fusion de classes redondantes
Sur le projet observé, la fusion des quatre variantes de bouton d’appel à l’action en une seule classe globale, avec un paramètre de variante géré par un contrôle secondaire plutôt que par une classe séparée, a permis de réduire le nombre total de classes de plus d’un tiers en quelques semaines, sans aucune perte fonctionnelle pour les pages existantes.
Une gouvernance légère ne signifie pas un processus lourd : une simple règle, « on cherche une classe existante avant d’en créer une nouvelle, et on demande validation si on hésite », suffit déjà à limiter la majorité de ces dérives sur un projet à plusieurs développeurs.
En résumé
Un design system atomique bâti sans gouvernance ne s’effondre jamais brutalement : il se dégrade progressivement, classe après classe, jusqu’à devenir aussi difficile à maintenir que l’ancien système de styles qu’il était censé remplacer. Une règle simple de validation avant création suffit, dans la majorité des cas, à éviter cette dérive avant qu’elle ne s’installe durablement.
