Le kit de couleurs et de polices d’un site vieux de quatre ans ressemble rarement à un système propre. Sur le projet qui nous occupe cette semaine, le client avait onze couleurs globales nommées « Couleur 1 » à « Couleur 11 », plus une douzième ajoutée récemment et baptisée « Rouge promo ». Aucune de ces entrées ne correspondait à un usage clair, et personne dans l’équipe actuelle n’était présent quand elles ont été créées.
Préparer ce site pour l’éditeur V4 d’Elementor imposait donc un double travail : comprendre ce que chaque couleur et police faisait réellement sur le site avant de la migrer, puis traduire cette compréhension dans le nouveau système de classes et de variables introduit par la V4. Ce deuxième travail est plus mécanique qu’il n’y paraît, à condition de connaître les correspondances exactes.
Ce que devient une Global Color
Dans l’ancien système, une Global Color est une entrée unique référencée par son identifiant interne partout où elle est utilisée : bordures, fonds, textes. Dans la V4, cette notion se rapproche d’une variable de style, consommée par des classes globales qui, elles, portent la sémantique (bouton-primaire, texte-accent) plutôt qu’un simple numéro.
La migration efficace ne consiste donc pas à recréer onze variables nommées à l’identique de l’ancien système, mais à profiter de la bascule pour nommer enfin les couleurs selon leur rôle réel. Sur ce projet, « Couleur 3 » est ainsi devenue la variable couleur-cta après vérification qu’elle n’était utilisée que sur des boutons d’appel à l’action, et « Couleur 7 », qui apparaissait à la fois sur des titres et un fond de section, a dû être scindée en deux variables distinctes une fois les usages différenciés.
Le cas plus délicat des Global Fonts
Les polices globales posent un problème supplémentaire : elles embarquent souvent plusieurs propriétés à la fois (famille, poids, taille, interlignage) dans une seule entrée. Le système V4 sépare davantage ces notions, ce qui oblige à décomposer chaque Global Font historique en plusieurs réglages distincts avant de les regrouper dans une classe globale cohérente.
- Repérer la famille de police réellement chargée (attention aux polices système de secours jamais nettoyées).
- Extraire les valeurs de graisse et de taille utilisées par contexte (titre H1, H2, corps de texte).
- Vérifier si un contrôle de fluid typography avait déjà été ajouté à la main sur certains widgets, auquel cas il faut le fusionner avec la classe globale plutôt que le dupliquer.
- Tester le rendu sur les trois principaux breakpoints avant de considérer la migration terminée.
Une phase de double nommage, provisoire mais nécessaire
Sur un site qui ne peut pas basculer d’un coup vers la V4 (parce que certains templates restent en attente de recette, par exemple), nous recommandons une phase de transition où l’ancienne Global Color et la nouvelle variable coexistent, avec un nommage qui indique clairement laquelle est la source de vérité actuelle. Un simple préfixe suffit : v4-couleur-cta pendant la migration, renommé en couleur-cta une fois l’ancien système officiellement retiré.
Cette étape intermédiaire évite l’erreur classique où deux couleurs très proches mais légèrement différentes cohabitent sur le site final, l’une héritée de l’ancien kit, l’autre issue de la nouvelle variable, sans que personne ne s’en aperçoive avant un audit visuel poussé.
Un tableau de correspondance pour cadrer le travail
| Ancien système | Équivalent V4 | Point d’attention |
|---|---|---|
| Global Color | Variable de couleur | Renommer selon le rôle, pas le rang |
| Global Font | Classe globale de texte | Décomposer avant de regrouper |
| Kit par défaut (Site Settings) | Jeu de variables du thème | Vérifier les surcharges par page |
| Style local sur widget | Classe locale ou variante atomique | Source fréquente de doublons non détectés |
Une migration de couleurs globales est une bonne occasion de nettoyer un système qui n’a jamais été pensé comme un système. Ne recopiez pas l’ancien capharnaüm sous un nouveau nom de variable.
Pour aller plus loin
La migration technique décrite ici ne remplace pas un inventaire complet du site avant projet, sujet que nous avons déjà traité séparément. Elle s’applique une fois cet inventaire fait, quand vient le moment de transformer la connaissance acquise en variables et classes concrètes dans l’éditeur V4. Sur un site avec plus d’une dizaine de couleurs globales historiques, comptez une bonne demi-journée de travail rien que pour cette étape de traduction, en plus des vérifications visuelles page par page.
