# CSS personnalisé dans Elementor : widget, page ou site, où l’écrire ?

> Elementor propose trois niveaux de Custom CSS. Chacun crée une dette différente si on ne centralise pas cette logique dans le thème enfant.

- Auteur : Clément Hadrot
- Publié le : 2020-12-14
- Mis à jour le : 2020-12-14
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/css-personnalise-elementor-widget-page-site/

## L’essentiel

- Custom CSS widget est le plus facile à écrire et le plus dur à retrouver
- Le CSS de page échappe totalement au versioning Git
- Un thème enfant reste le seul endroit où le CSS est réellement traçable

Six mois après la livraison d'un site, un client nous a demandé de changer la couleur d'un bouton « Demander un devis » qui apparaissait sur douze pages différentes. Ce qui aurait dû prendre trente secondes en a pris deux heures, le temps de retrouver que la couleur était en réalité codée en dur dans le champ Custom CSS de six widgets différents, avec six valeurs légèrement différentes de la même teinte. C'est l'histoire typique de la dette CSS qu'Elementor rend très facile à créer, et tout aussi facile à éviter.

Elementor Pro propose du Custom CSS à trois niveaux : le widget, la page, et le site entier. Chacun a un usage légitime, mais chacun crée un risque de dispersion si on ne réfléchit pas, dès le départ, à une stratégie de centralisation.

## Niveau 1 : Custom CSS au niveau du widget

Disponible dans l'onglet **Advanced** de n'importe quel widget (fonctionnalité Pro), ce champ accepte du CSS brut où le sélecteur `selector` est automatiquement remplacé par la classe unique générée pour ce widget précis :

```
selector .elementor-button {
    border-radius: 0;
    text-transform: uppercase;
}
```

C'est le niveau le plus rapide à utiliser, et le plus dangereux à grande échelle : rien n'indique, en parcourant la liste des pages d'un site, quels widgets contiennent du CSS personnalisé. Il n'existe aucune recherche native pour retrouver « tous les widgets avec du Custom CSS ».

## Niveau 2 : Custom CSS au niveau de la page

Dans **Réglages de la page > Avancé > Custom CSS**, ce champ s'applique à l'ensemble du contenu de la page en cours, sans avoir besoin de cibler un widget précis. Il est enregistré comme métadonnée du post, et injecté dans le fichier CSS généré spécifiquement pour cette page (voir le fonctionnement des fichiers `post-XXX.css`).

- Utile pour un ajustement ponctuel propre à une seule page (une landing page de campagne, par exemple).
- Totalement invisible dans un dépôt Git : ce CSS vit en base de données, pas dans les fichiers du thème.
- Perdu en cas de duplication de page si l'utilisateur ne pense pas à le recopier.

## Niveau 3 : Custom CSS au niveau du site

Dans **Elementor > Réglages généraux > Custom CSS** (fonctionnalité Pro également), ce champ s'applique à toutes les pages construites avec Elementor. C'est le niveau le plus proche, en intention, d'une feuille de style globale de thème — mais il reste stocké en base de données, dans les options d'Elementor, et non dans un fichier versionnable.

> L'essentiel à retenir : Custom CSS widget est le plus facile à écrire et le plus dur à retrouver ; Le CSS de page échappe totalement au versioning Git ; Un thème enfant reste le seul endroit où le CSS est réellement traçable

## La dette que ces trois niveaux créent ensemble

Le vrai problème n'est pas qu'un seul de ces niveaux existe, c'est qu'ils coexistent sans hiérarchie imposée. Rien n'empêche un intégrateur pressé d'ajouter la même règle au niveau du widget sur une page, puis un collègue de l'ajouter à nouveau au niveau du site quelques semaines plus tard parce qu'il ignorait l'existence du premier correctif. Le résultat : des règles redondantes, parfois contradictoires selon l'ordre de chargement, et un debug CSS qui devient une chasse au trésor.

| Niveau | Portée | Traçabilité Git | Risque de dispersion |
| --- | --- | --- | --- |
| Widget | Un seul élément | Aucune | Très élevé |
| Page | Une page entière | Aucune | Élevé |
| Site | Tout le site Elementor | Aucune | Moyen |

## La stratégie de centralisation que nous appliquons

Sur tous nos projets, la règle est simple : aucun Custom CSS au niveau du widget ou de la page ne survit à la recette. Tout ce qui doit persister est déplacé dans la feuille de style du thème enfant, versionnée dans Git, avec des classes explicites plutôt que des sélecteurs générés automatiquement.

1. Le Custom CSS de widget ou de page sert uniquement de brouillon pendant l'intégration.
2. Une fois validé, la règle est recopiée dans `style.css` du thème enfant avec un commentaire expliquant son origine.
3. Le champ Custom CSS d'origine est vidé pour éviter toute redondance.
4. Seul le Custom CSS de site peut rester pour des ajustements très ponctuels documentés dans un fichier de suivi de projet.

> Un CSS qu'on ne trouve pas dans son éditeur de code n'existe pas vraiment pour l'équipe : il finira toujours par être réécrit en double par quelqu'un qui ignorait qu'il était déjà là.

## En résumé

Les trois niveaux de Custom CSS d'Elementor répondent à des besoins réels, mais aucun n'est versionné ni facilement traçable. La discipline qui évite la dette technique consiste à les considérer comme des brouillons de travail, puis à centraliser tout ce qui doit rester dans le CSS du thème enfant, la seule couche réellement maîtrisée par l'équipe de développement.