e-atomic-btn-primary-v2-final : ce genre de nom de classe, retrouvé sur un projet en cours de test avec la version bêta de l’éditeur atomique d’Elementor, résume à lui seul le problème. Trois développeurs, trois façons différentes de nommer une classe pour un bouton principal, et déjà des doublons qui se chevauchent sur le même gabarit.
L’éditeur atomique introduit des classes de style réutilisables entre éléments, une bonne nouvelle pour le poids du CSS généré, mais un risque nouveau pour une petite équipe sans convention écrite : sans règle commune, chaque développeur recrée sa propre classe plutôt que de réutiliser celle d’un collègue, ce qui annule une bonne partie du bénéfice recherché.
Le constat sur un projet à trois développeurs
Sur un gabarit de test comportant une dizaine de composants, l’absence de convention a produit quatre classes distinctes pour un seul et même style de bouton principal, chacune créée par un développeur différent à quelques jours d’intervalle, sans qu’aucun ne sache que les autres avaient déjà résolu le même besoin.
Le problème ne vient pas d’un manque de rigueur individuelle : chaque développeur a suivi une logique cohérente à son échelle, simplement différente de celle des deux autres. C’est précisément le rôle d’une convention écrite que d’aligner ces logiques individuelles avant qu’elles ne divergent.
La structure minimale suffisante
Pour une équipe de trois personnes, une convention trop détaillée devient vite plus contraignante que l’absence de règle elle-même. La structure retenue tient en trois segments, séparés par un tiret double, dans un ordre fixe :
[prefixe]--[role]--[variante]
- Préfixe : toujours
proj, identifiant fixe du projet, pour éviter tout conflit avec les classes internes générées par Elementor. - Rôle : le type de composant concerné, en un seul mot descriptif (
btn,card,badge,nav). - Variante : l’état ou la déclinaison visuelle du composant (
primaire,secondaire,compact), jamais un numéro de version ni le mot « final ».
Arborescence de référence partagée
Au-delà du nom lui-même, la convention n’a de valeur que si elle s’accompagne d’un endroit unique où consulter les classes déjà créées. Sur ce projet, un simple fichier texte versionné avec le code, à la racine du thème, joue ce rôle :
theme/
├── style-tokens/
│ ├── classes-atomiques.md (registre des classes existantes)
│ ├── couleurs.md
│ └── typographies.md
└── functions.php
Avant de créer une nouvelle classe atomique, la règle d’équipe impose de consulter ce registre. Si un composant équivalent existe déjà, même sous un nom légèrement différent, il est réutilisé ou renommé d’un commun accord, jamais dupliqué silencieusement.
Ce que la convention n’essaie pas de résoudre
Cette structure minimale ne cherche pas à couvrir tous les cas d’un futur design system complet à dix développeurs : elle vise seulement à empêcher la dérive la plus fréquente sur une petite équipe, celle des doublons créés par ignorance de l’existant. Une équipe qui grandirait au-delà de quatre ou cinq développeurs gagnerait sans doute à formaliser davantage cette convention, avec une revue systématique avant fusion du code.
Un point mérite d’être tranché dès le départ, avant même le premier composant créé : que faire d’une variante qui ne rentre dans aucune des catégories prévues ? Sur ce projet, la règle retenue autorise un quatrième segment optionnel, réservé aux cas réellement particuliers, mais impose que ce segment soit discuté entre les trois développeurs avant sa création, jamais ajouté seul dans l’urgence d’une livraison.
Un exemple concret de nommage appliqué
| Besoin | Ancien nommage (avant convention) | Nommage après convention |
|---|---|---|
| Bouton principal | e-atomic-btn-primary-v2-final | proj--btn--primaire |
| Carte compacte | card-small-new | proj--card--compact |
| Badge de statut | badge2 | proj--badge--statut |
Une convention de nommage qui tient sur une page se respecte. Une convention qui en demande dix se contourne, faute de temps pour la lire.
En résumé
À trois développeurs, la meilleure convention n’est pas la plus exhaustive mais la plus simple à retenir sans relire la documentation à chaque création de classe. Un préfixe fixe, un rôle, une variante, et un registre partagé consulté avant toute nouvelle classe suffisent à éviter la dérive constatée sur ce projet, sans ralentir le rythme de production.
