# Le CSS additionnel des styles globaux de WordPress 6.2 : usages et limites

> WordPress 6.2 ajoute un champ de CSS personnalisé directement dans le panneau Styles. Où il stocke ce code, comment il se priorise, et pourquoi il ne doit rester qu'un dernier recours.

- Auteur : Clément Hadrot
- Publié le : 2023-07-17
- Mis à jour le : 2023-07-17
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/css-additionnel-styles-globaux-wordpress-62/

## L’essentiel

- Le CSS additionnel se saisit depuis le panneau Styles sans fichier séparé
- Il se charge après les styles générés par theme.json
- Utile pour un ajustement ponctuel, pas comme feuille de style principale

Depuis la sortie de WordPress 6.2 en mars dernier, l'éditeur de site propose un nouvel emplacement, un peu caché au fond du panneau Styles : un champ de CSS personnalisé, accessible sans ouvrir le moindre fichier du thème. Sur un projet où le client souhaitait ajuster lui-même un détail visuel récurrent, cette fonctionnalité a évité un aller-retour avec le développeur, tout en soulevant une question légitime : jusqu'où peut-on s'appuyer dessus ?

Voici ce que l'on a observé en l'utilisant sur plusieurs projets ces derniers mois.

## Où trouver ce champ et comment il fonctionne

Depuis **Apparence > Éditeur > Styles > (icône crayon) > CSS additionnel**, un éditeur de code s'ouvre, permettant de saisir des règles CSS classiques. Contrairement à un fichier `style.css` traditionnel, ce code n'est pas stocké dans un fichier du thème, mais directement en base de données, associé aux styles globaux du site.

```
.site-header .wp-block-search__button {
    border-radius: 999px;
    text-transform: uppercase;
}
```

## Où se situe ce CSS dans l'ordre de priorité

> L'essentiel à retenir : Le CSS additionnel se saisit depuis le panneau Styles sans fichier séparé ; Il se charge après les styles générés par theme.json ; Utile pour un ajustement ponctuel, pas comme feuille de style principale

Ce CSS personnalisé se charge après les styles générés automatiquement à partir de `theme.json` et après les styles de blocs individuels appliqués depuis l'éditeur. Il bénéficie donc, en pratique, d'une priorité assez confortable, ce qui explique en partie pourquoi il est tentant de l'utiliser pour forcer un rendu récalcitrant plutôt que de comprendre pourquoi le style attendu ne s'applique pas par les voies habituelles.

## Un outil pratique, pas une feuille de style de substitution

C'est précisément là que réside le principal piège observé sur le terrain : un client, une fois ce champ découvert, a tendance à y accumuler des règles CSS au fil des besoins, jusqu'à transformer ce qui devait rester un ajustement ponctuel en une véritable feuille de style parallèle, non versionnée dans Git et invisible pour l'équipe de développement.

- Ce CSS vit en base de données, pas dans le dépôt du thème : aucune trace dans l'historique Git.
- Un changement de thème n'emporte pas ce CSS avec lui, ce qui peut casser silencieusement l'apparence attendue.
- Il n'existe aucune validation syntaxique poussée : une règle mal écrite ne provoque ni erreur ni avertissement visible.

## Une règle simple adoptée sur nos projets

> Sur nos projets, ce champ reste réservé à des ajustements que le client peut faire lui-même en autonomie, jamais aux styles structurants du site : ces derniers doivent toujours vivre dans le thème, versionnés et documentés.

## Récupérer ce CSS pour l'intégrer proprement au thème

Lorsqu'une règle ajoutée via ce champ s'avère en réalité structurante, la bonne pratique consiste à la retirer du champ CSS additionnel et à la réintégrer dans le thème, soit via `theme.json` si elle correspond à un style de bloc standard, soit via la feuille de style du thème pour un cas plus spécifique. Ce nettoyage périodique évite que le CSS additionnel ne devienne une dette technique invisible.

## Un audit régulier pour éviter la dérive

Sur les sites où ce champ est activement utilisé par le client, on a pris l'habitude d'exporter périodiquement son contenu pour le relire en équipe, un peu comme on relirait une pull request. Cette revue régulière permet de repérer les règles devenues inutiles, celles qui contredisent silencieusement un style défini dans `theme.json`, et celles qui, à l'inverse, méritent réellement d'être intégrées durablement au thème.

## Notre verdict

Le CSS additionnel des styles globaux comble un vrai besoin d'autonomie pour des ajustements mineurs, sans nécessiter l'intervention d'un développeur. Mais son confort d'accès en fait aussi un piège classique : sans discipline d'équipe, il finit par accumuler des règles qui auraient dû vivre dans le thème lui-même, avec tous les problèmes de maintenance que cela implique à moyen terme.