Une agence de communication m’a confié l’audit d’un site vitrine repris à un prestataire indépendant parti sans laisser de documentation. Le thème bloc en place fonctionnait, visuellement correct au premier regard, mais chaque tentative de modification révélait un problème structurel différent. Après plusieurs audits de ce type ces dernières années, je retrouve systématiquement les trois mêmes antipatterns, dans des proportions variables mais toujours présents.
Cet article se concentre sur ces trois défauts structurels observés en audit de code. L’audit de performance chiffré du même site, avec ses propres mesures de poids et de temps de chargement, fait l’objet d’un travail séparé.
Ce qu’on voit : des patterns dupliqués plutôt que réutilisés
Le thème contenait sept fichiers de pattern dans patterns/, dont trois portaient des noms différents (section-services-v2.php, section-services-final.php, section-services-final-v2.php) mais un contenu HTML quasiment identique, avec seulement quelques classes CSS qui divergeaient d’une version à l’autre.
Pourquoi c’est un problème
Un pattern est censé être un bloc de structure réutilisable et centralisé : modifier son fichier source devrait répercuter le changement partout où il est inséré sous forme de référence. En pratique, le prestataire précédent copiait-collait le contenu HTML directement dans les pages plutôt que d’insérer une référence au pattern enregistré, ce qui revient à transformer un mécanisme de réutilisation en simple modèle de copie manuelle, sans aucun des bénéfices attendus.
Quoi faire
La correction a consisté à identifier la version la plus aboutie de chaque pattern dupliqué, à la déclarer proprement avec register_block_pattern(), puis à remplacer chaque occurrence copiée-collée dans le contenu par une insertion réelle du pattern enregistré, repérable à sa référence wp:pattern dans le contenu plutôt qu’à un bloc de structure recopié en dur.
register_block_pattern(
'agence/section-services',
array(
'title' => __( 'Section services', 'agence' ),
'categories' => array( 'agence' ),
'content' => file_get_contents( get_theme_file_path( 'patterns/section-services.html' ) ),
)
);
Ce qu’on voit : un theme.json quasi vide
Le fichier theme.json du thème ne déclarait que la version et un unique préréglage de couleur, alors que le site affichait visuellement une charte de cinq couleurs et trois tailles de police distinctes utilisées de façon cohérente sur l’ensemble des pages.
Pourquoi c’est un problème
Un theme.json presque vide signale que le thème a été construit visuellement, page par page, en fixant chaque couleur et taille de police directement dans les blocs plutôt qu’en s’appuyant sur des préréglages déclarés une fois pour toutes. Résultat concret pour l’agence qui reprend le projet : impossible de changer une seule couleur de la charte sans repasser sur chaque page individuellement pour retrouver et corriger chaque occurrence de la valeur fixée en dur.
Quoi faire
La correction, plus lourde que pour les patterns, a consisté à extraire les valeurs de couleur et de typographie réellement utilisées, à les déclarer dans settings.color.palette et settings.typography.fontSizes, puis à reconstruire progressivement chaque page pour qu’elle référence ces préréglages nommés plutôt que des valeurs fixes, un chantier étalé sur plusieurs semaines de maintenance facturée séparément.
Ce qu’on voit : des styles en dur qui survivent à tout changement de charte
Au fil de l’audit, 27 occurrences du même attribut style="color:#3a5a40" ont été retrouvées directement dans le contenu des blocs, appliquées manuellement bloc par bloc plutôt que via un préréglage de couleur nommé, exactement le symptôme concret du problème précédent poussé à l’échelle du contenu déjà publié.
Pourquoi c’est un problème
Ces styles en dur, invisibles dans theme.json puisqu’ils vivent directement dans le contenu de chaque article ou page, survivent à n’importe quelle refonte future de la charte graphique. Un changement de couleur de marque demanderait, en l’état, une recherche-remplacement manuelle dans la base de données, une opération risquée sur du contenu structuré en blocs Gutenberg où la couleur est encodée à deux endroits redondants : l’attribut de style inline et une classe CSS générée.
Quoi faire
Une fois la palette officiellement déclarée dans theme.json, chaque occurrence de couleur fixe a été remplacée manuellement par la classe de préréglage correspondante (has-vert-sapin-color par exemple), en s’appuyant sur une recherche de contenu par expression régulière pour localiser systématiquement chaque occurrence avant correction, plutôt que de se fier à une relecture visuelle forcément incomplète sur un site de plusieurs dizaines de pages.
grep -rn 'style="color:#3a5a40"' wp-content/uploads/ wp-content/themes/
Le fil conducteur des trois antipatterns
Les trois défauts partagent la même cause profonde : un thème construit visuellement, sans jamais remonter la logique de présentation vers une source de vérité centralisée. C’est le signe d’un travail fait dans l’urgence, pas d’un manque de compétence technique du prestataire précédent.
En résumé
Patterns copiés-collés au lieu d’être réutilisés, theme.json presque vide malgré une charte graphique cohérente à l’œil, et styles fixés en dur dans le contenu : ce trio d’antipatterns revient systématiquement dans les audits de reprise de thème bloc. Le corriger demande de remonter méthodiquement chaque valeur codée en dur vers une déclaration centralisée, un travail plus long que la conception initiale mais qui conditionne toute évolution future du site sans reprendre à zéro.
