Fin 2020 marque un moment charnière, encore discret, pour qui suit de près l’évolution du plugin Gutenberg : un simple fichier JSON, nommé theme.json, commence à circuler dans les discussions de développeurs de thèmes. Il ne fait pas encore partie du cœur de WordPress, mais son ambition affichée est claire — centraliser, dans un seul fichier, ce qui était jusque-là dispersé entre CSS, PHP et réglages de blocs.
Ce billet ne traite pas des gabarits par défaut d’un thème classique, qui restent, à cette date, entièrement indépendants de ce nouveau fichier. Il s’agit ici de faire un point d’étape sur ce que theme.json autorise déjà, à ce stade précoce de son existence.
Une intention plus qu’une structure figée
À ce stade, la structure exacte du fichier n’est pas stabilisée : des clés apparaissent, disparaissent, changent de nom d’une version du plugin à l’autre. Ce qui reste constant, en revanche, c’est l’intention : permettre à un thème de déclarer ses réglages visuels de façon déclarative, plutôt que par du code PHP dispersé dans plusieurs fichiers.
{
"version": 1,
"settings": {
"color": {
"palette": [
{ "name": "Bleu nuit", "slug": "bleu-nuit", "color": "#14213d" },
{ "name": "Ambre", "slug": "ambre", "color": "#fca311" }
]
}
}
}Ce qui fonctionne déjà
Malgré son caractère expérimental, plusieurs réglages produisent déjà un effet observable dans l’éditeur de blocs. La palette de couleurs déclarée dans theme.json remplace celle, plus ancienne, enregistrée via add_theme_support( 'editor-color-palette' ). Les tailles de police déclarées de la même façon apparaissent dans le sélecteur de taille des blocs de texte.
Ce recouvrement entre l’ancien mécanisme, basé sur add_theme_support(), et le nouveau, basé sur ce fichier, crée d’ailleurs une source de confusion fréquente chez qui découvre theme.json à cette période : les deux systèmes coexistent, et le second prend le pas sur le premier sans avertissement explicite dans l’interface.
Ce qui reste hors de portée
- La mise en page des gabarits eux-mêmes, qui dépend encore entièrement des fichiers PHP classiques du thème.
- Les styles élément par élément — liens, boutons — qui n’existent pas encore dans ce que le fichier permet de déclarer.
- Toute forme de garantie de rétrocompatibilité : une clé qui fonctionne aujourd’hui peut être renommée la semaine suivante.
Pourquoi s’y intéresser dès maintenant
La question se pose légitimement : pourquoi investir du temps sur un mécanisme aussi instable ? La réponse tient à la direction prise par le projet. Les discussions publiques autour de l’édition complète de site laissent peu de doute sur l’ambition portée par ce fichier : devenir, à terme, le point d’entrée unique pour tout ce qui concerne l’identité visuelle d’un thème.
Observer une fonctionnalité expérimentale ne signifie pas la déployer en production : cela signifie comprendre suffisamment tôt sa logique pour ne pas être pris de court le jour de sa stabilisation.
Une prudence de circonstance
Aucun thème destiné à un usage réel ne devrait, à ce stade, reposer entièrement sur theme.json. Le fichier reste une curiosité de développeur, à tester sur un environnement local avec le plugin Gutenberg activé, pas une fondation pour un projet client livré cette année.
En résumé
Fin 2020, theme.json n’est encore qu’une promesse partiellement tenue : une palette de couleurs, des tailles de police, rien de plus de solide. Mais la direction qu’il dessine — un thème décrit par la donnée plutôt que par du code dispersé — mérite d’être suivie de près, car elle façonnera très probablement la façon dont les thèmes seront écrits dans les années à venir.
