Reprendre un thème bloc écrit par une autre agence, ou par nous-mêmes six mois plus tôt sous la pression d’un délai serré, est devenu un exercice régulier. À chaque reprise, les mêmes travers reviennent, avec des conséquences très concrètes sur le budget de maintenance du client. Ce n’est pas une critique du modèle des thèmes blocs en lui-même : c’est un rappel de ce que le format autorise, sans jamais l’imposer.
Voici quatre anti-patterns que nous avons rencontrés sur des projets récents, avec à chaque fois ce qui les rend problématiques et la façon dont nous les corrigeons.
Des styles inline figés dans les templates
Premier travers : des blocs avec des styles inline codés en dur directement dans le fichier HTML du template, plutôt que puisés dans la palette du thème.
<!-- wp:paragraph {"style":{"color":{"text":"#3a3a3a"}}} -->
<p style="color:#3a3a3a">Texte du pied de page</p>
<!-- /wp:paragraph -->Pourquoi c’est un problème : la couleur #3a3a3a n’existe dans aucun preset de theme.json. Le jour où le client demande d’assombrir légèrement sa charte, il faut rouvrir chaque template pour traquer les couleurs codées en dur, avec le risque d’en oublier une. Le système de design perd tout son intérêt : autant revenir à un thème classique avec une feuille CSS unique.
Quoi faire : déclarer systématiquement la couleur en preset dans theme.json, puis référencer la classe générée (has-pied-de-page-color par exemple) plutôt que la valeur brute. Un script de recherche sur style="color: dans le dossier templates permet de faire le ménage sur un thème existant.
Des templates dupliqués au lieu de template parts
Second travers, très fréquent sur les sites avec plusieurs types de contenus : un template single-evenement.html et un template single-formation.html qui partagent 90 % de leur structure, mais ont été créés en dupliquant l’un depuis l’autre plutôt qu’en factorisant les blocs communs.
Pourquoi c’est un problème : chaque correctif — un changement de mise en page dans l’en-tête d’article, un ajustement du fil d’Ariane — doit être répété dans chaque fichier dupliqué. Sur un projet avec cinq types de contenus proches, nous avons vu des templates diverger silencieusement au fil des interventions, jusqu’à ce que deux pages du même site n’affichent plus la même structure sans que personne ne l’ait décidé.
Quoi faire : extraire la structure commune dans un template-part dédié (via register_block_template ou simplement un fichier dans parts/), et ne garder dans chaque template spécifique que ce qui diffère réellement — souvent une simple requête de champs personnalisés.
theme.json surchargé de CSS brut
Troisième travers : un fichier theme.json qui ne contient presque aucun preset, mais renvoie l’essentiel du style vers une feuille style.css classique bourrée de sélecteurs très spécifiques, du type .wp-block-group.is-style-carte > .wp-block-heading.
| Approche | Conséquence |
|---|---|
| Presets dans theme.json | Valeurs disponibles dans l’éditeur, cohérentes, faciles à faire évoluer globalement |
| CSS brut avec sélecteurs spécifiques | Valeurs invisibles pour l’éditeur, risque de conflits de spécificité, maintenance dispersée entre deux fichiers |
Ce n’est pas que le CSS classique soit interdit dans un thème bloc : certains ajustements fins (grilles complexes, animations) n’ont pas d’équivalent dans theme.json. Le problème survient quand le CSS reprend la main sur des décisions qui relèvent du design system — couleurs, espacements, typographie — et que ces décisions deviennent invisibles pour l’éditeur de site.
Des patterns non traduisibles
Dernier travers, plus discret mais coûteux sur les sites multilingues : des patterns enregistrés en PHP avec du texte codé en dur, sans passer par les fonctions de traduction de WordPress.
register_block_pattern( 'mon-theme/hero-accueil', array(
'title' => 'Bloc héros accueil',
'content' => '<!-- wp:paragraph --><p>Bienvenue chez nous</p><!-- /wp:paragraph -->',
) );Pourquoi c’est un problème : le texte « Bienvenue chez nous » est figé dans le code PHP. Sur un site utilisant Polylang ou WPML, ce pattern ne sera jamais traduit automatiquement, contrairement au contenu saisi directement dans l’éditeur. Le client se retrouve avec un pattern qu’il doit modifier manuellement à la main dans chaque langue, ou pire, qu’il n’ose pas toucher de peur de casser la mise en forme.
Quoi faire : entourer chaque chaîne de esc_html__() ou __() avec le bon domaine de texte, y compris dans le contenu HTML injecté par le pattern. Le titre et la description du pattern lui-même, affichés dans l’inserteur de blocs, doivent aussi passer par ces fonctions.
En résumé
Ces quatre anti-patterns partagent un point commun : ils apparaissent presque toujours sous la pression du délai, quand il est plus rapide de coder en dur une valeur que de la déclarer proprement dans le système de design. Le coût se paie ensuite, en maintenance, souvent par une autre personne que celle qui a écrit le code initial. Un audit rapide en fin de projet — recherche de styles inline, de templates trop proches, de CSS non justifié et de chaînes non traduites — suffit à repérer l’essentiel avant la livraison.
