Faire respecter une palette de couleurs imposée via les supports de blocs

Une charte graphique au format PDF impose une palette de douze couleurs précises ; trois semaines plus tard, un rédacteur presse choisit un rouge personnalisé au sélecteur de couleur libre pour un bandeau d’alerte, parce que rien dans l’interface ne l’en empêche techniquement. Comparé à un document de recommandations, aussi bien écrit soit-il, un réglage posé directement dans block.json ne laisse tout simplement pas cette possibilité d’exister.

Où se situe la vraie faille dans l’approche documentaire

Une charte graphique, aussi précise soit-elle, ne s’applique que si chaque personne qui édite du contenu la connaît, s’en souvient et prend le temps de la respecter à chaque bloc inséré. Sur un site à plusieurs contributeurs, avec un turnover de personnel et des urgences éditoriales fréquentes, cette hypothèse ne tient pas dans la durée. Le problème n’est pas la compétence des rédacteurs, mais l’absence de contrainte technique qui rendrait l’écart tout simplement impossible plutôt que simplement déconseillé.

Où placer le verrouillage technique

theme.json (palette autorisée du site)
└── settings.color.palette          → liste fermée de couleurs nommées
    └── settings.color.custom       → false : interdit la couleur libre

block.json (par type de bloc concerné)
└── supports.color
    ├── background : true           → autorise le fond, dans la palette seulement
    ├── text       : true           → autorise le texte, dans la palette seulement
    └── custom     : false          → retire le sélecteur de couleur libre côté bloc

Configurer le thème pour fermer la palette

{
	"version": 2,
	"settings": {
		"color": {
			"custom": false,
			"customGradient": false,
			"palette": [
				{ "slug": "bleu-marque", "color": "#0b2d5c", "name": "Bleu marque" },
				{ "slug": "orange-accent", "color": "#e8590c", "name": "Orange accent" },
				{ "slug": "gris-texte", "color": "#2b2b2b", "name": "Gris texte" }
			]
		}
	}
}

settings.color.custom à false retire, pour l’ensemble des blocs du thème, l’onglet de saisie libre de couleur normalement proposé dans le sélecteur ; seule la palette nommée reste accessible. Ce réglage s’applique globalement, ce qui suffit dans la majorité des cas où l’objectif est un verrouillage total du site.

Renforcer le verrouillage bloc par bloc si nécessaire

Pour un bloc personnalisé développé en interne, le support color déclaré dans son propre block.json peut aller plus loin que le réglage global du thème, par exemple en n’autorisant que la couleur de fond et pas la couleur de texte, si la charte impose un texte toujours noir sur fond de marque :

{
	"supports": {
		"color": {
			"background": true,
			"text": false,
			"custom": false
		}
	}
}

• Le réglage theme.json ferme la porte à l’échelle du site entier.
• Le support déclaré dans un block.json spécifique peut restreindre davantage un bloc précis.
• Un bloc ne peut jamais rouvrir, à lui seul, une liberté que theme.json a fermée globalement.

Ce que ce verrouillage ne couvre pas

Cette approche protège la saisie via les contrôles natifs de couleur de l’éditeur, pas un style CSS personnalisé ajouté par ailleurs (un attribut de classe libre, une feuille de style additionnelle chargée par une extension). Un rédacteur disposant d’un accès au code HTML brut d’un bloc, ou d’une extension tierce injectant ses propres styles, peut toujours contourner cette contrainte par un autre chemin. Le verrouillage des supports de blocs ferme la voie la plus fréquente d’écart, pas toutes les voies possibles.

Un compromis à discuter avec l’équipe éditoriale

Fermer totalement custom à false peut frustrer une équipe habituée à une liberté de teinte pour des cas exceptionnels (un événement ponctuel, une campagne spéciale). Une palette volontairement un peu plus large que le strict minimum, incluant quelques nuances supplémentaires validées à l’avance, évite souvent ce point de friction sans rouvrir la saisie totalement libre.

En résumé

Une palette imposée ne tient dans la durée que si elle est verrouillée techniquement, pas seulement documentée. La combinaison de settings.color.custom à false dans theme.json et d’un réglage plus fin des supports de couleur dans les block.json des blocs sensibles ferme la quasi-totalité des écarts constatés en pratique, sans qu’aucun rappel de charte graphique ne soit nécessaire au quotidien.