Une charte graphique en PDF et un fichier theme.json partagent, en apparence, le même objectif : garantir une cohérence visuelle. Leur différence tient à un détail décisif — l’un est un document que personne ne consulte plus après la troisième semaine de projet, l’autre est une contrainte que l’outil de production applique sans effort de mémoire de la part de qui l’utilise.
Ce billet s’adresse à un lead technique qui veut que theme.json impose une cohérence visuelle documentée, sur un parc de sites gérés pour plusieurs clients distincts. Il ne traite pas des supports de blocs, un sujet différent qui concerne l’enregistrement de fonctionnalités plutôt que la gouvernance visuelle.
Le problème d’une charte non exécutable
Une charte graphique classique décrit des règles — telle couleur pour tel usage, telle taille de titre pour tel niveau hiérarchique — mais ne les fait respecter par aucun mécanisme technique. Rien n’empêche un intégrateur pressé d’appliquer une couleur hors palette directement sur un bloc, sans que l’outil ne signale l’écart.
theme.json comme source unique exécutable
En centralisant palette de couleurs, tailles de police et espacements dans theme.json, ces règles cessent d’être de simples recommandations pour devenir les seules options disponibles dans l’éditeur. Un intégrateur ne peut plus choisir une couleur hors palette par erreur : elle n’apparaît simplement pas dans le sélecteur.
{
"settings": {
"color": {
"custom": false,
"palette": [
{ "name": "Encre", "slug": "encre", "color": "#1a1a2e" },
{ "name": "Corail", "slug": "corail", "color": "#e94560" }
]
},
"typography": {
"customFontSize": false,
"fontSizes": [
{ "name": "Petit", "slug": "petit", "size": "0.875rem" },
{ "name": "Grand", "slug": "grand", "size": "2rem" }
]
}
}
}Les clés custom et customFontSize, réglées à false, jouent ici un rôle décisif : elles retirent les sélecteurs libres de couleur et de taille, ne laissant que les valeurs définies dans la palette et l’échelle typographique du thème.
Un thème socle partagé plutôt qu’un thème par client
La gouvernance devient plus simple encore lorsque plusieurs sites clients partagent un même thème socle, dont seul theme.json et quelques fragments de gabarit varient d’un client à l’autre. Une agence qui gérait auparavant une douzaine de thèmes indépendants, chacun avec ses propres écarts accumulés au fil des projets, peut ainsi les ramener à un seul thème socle commun, personnalisé par surcharge plutôt que par duplication complète.
- Un seul thème à maintenir et à mettre à jour pour des corrections transversales.
- Une personnalisation par client limitée à son propre fichier
theme.json, jamais au cœur du thème. - Une montée en compétence plus rapide pour tout nouvel intégrateur, qui retrouve la même base d’un projet à l’autre.
Documenter les combinaisons de style autorisées
Au-delà des couleurs et des tailles, les variations de style déclarées dans theme.json permettent de figer des combinaisons entières — un bloc bouton avec une couleur de fond et un rayon de bordure précis, par exemple — plutôt que de laisser chaque intégrateur recomposer ces réglages bloc par bloc.
Une règle de design qui dépend de la mémoire d’un intégrateur finira par être oubliée ; une règle inscrite dans
theme.jsons’applique qu’on s’en souvienne ou non.
Ce que cette gouvernance ne remplace pas
Ce mécanisme encadre les choix disponibles dans l’éditeur, mais ne remplace pas une revue de qualité humaine sur l’agencement global d’une page. Un thème parfaitement cadré en couleurs et en typographies peut malgré tout produire une mise en page maladroite si l’organisation des blocs n’est pas revue par un œil attentif.
En résumé
Porter un design system par theme.json transforme une charte graphique passive en contrainte active, directement appliquée dans l’outil de production. Pour une agence multi-clients, ce choix se traduit par un thème socle partagé, plus simple à maintenir, et par une cohérence visuelle qui ne dépend plus de la vigilance individuelle de chaque intégrateur.
