# Cinq ans de thèmes blocs en production : ce qu’on changerait

> Pas un historique général de la fonctionnalité, mais un bilan personnel d'équipe : les choix techniques qu'on referait, et ceux qu'on éviterait si c'était à refaire.

- Auteur : Clément Hadrot
- Publié le : 2026-08-21
- Mis à jour le : 2026-08-21
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/cinq-ans-themes-blocs-bilan/

## L’essentiel

- Le premier starter thème était trop ambitieux trop tôt
- Sous-estimer la formation de l'équipe rédactionnelle a coûté cher
- Documenter les décisions vaut plus que documenter le code

Cinq ans après avoir livré notre premier projet client entièrement construit en thème bloc, il nous semblait utile de faire un bilan honnête, pas un simple récapitulatif des fonctionnalités apparues au fil des versions de WordPress, déjà largement couvert ailleurs sur ce blog. Ce texte porte sur nos propres décisions d'équipe, celles qu'on assumerait à nouveau et celles qu'on changerait clairement si c'était à refaire.

Le recul de cinq ans donne une perspective différente de celle qu'on avait en cours de route : certains choix qui semblaient anodins sur le moment se sont révélés structurants, dans un sens comme dans l'autre.

## Erreur n°1 : un premier starter thème trop ambitieux

Notre tout premier starter thème bloc interne tentait de couvrir un maximum de cas d'usage dès sa première version : patterns pour six secteurs d'activité différents, système de variations multiples, options de configuration avancées. Résultat, il était devenu, ironiquement, presque aussi lourd à maintenir que les thèmes premium à tiroirs que nous critiquons aujourd'hui ouvertement. Nous l'avons entièrement réécrit deux ans plus tard, avec un périmètre volontairement restreint.

## Erreur n°2 : sous-estimer la formation de l'équipe rédactionnelle

> L'essentiel à retenir : Le premier starter thème était trop ambitieux trop tôt ; Sous-estimer la formation de l'équipe rédactionnelle a coûté cher ; Documenter les décisions vaut plus que documenter le code

Le passage à l'édition par blocs a été traité, au départ, comme un changement principalement technique côté développement. Nous avons largement sous-estimé le temps nécessaire pour que les équipes rédactionnelles de nos clients s'approprient réellement les nouveaux réflexes : verrouillage de patterns, utilisation des styles globaux plutôt que du formatage manuel, compréhension de la différence entre un bloc synchronisé et un bloc classique. Plusieurs projets ont connu des débuts difficiles, non pas à cause du code, mais à cause d'une formation client insuffisante en amont de la mise en production.

- Nous avons depuis systématisé une session de formation dédiée avant chaque mise en production d'un thème bloc, jamais optionnelle.
- Nous verrouillons désormais par défaut la structure des patterns sensibles, pour éviter qu'un rédacteur non formé ne casse involontairement une mise en page.
- Nous fournissons un guide court, propre à chaque projet, plutôt qu'une documentation générique sur l'édition par blocs.

## Ce qu'on referait sans hésiter

Le choix d'investir tôt dans `theme.json` comme source unique de vérité pour les styles, plutôt que de continuer à dupliquer des réglages entre CSS classique et configuration de thème, s'est révélé être la décision la plus rentable sur la durée. Les projets qui ont adopté cette discipline dès le départ ont systématiquement mieux traversé les montées de version successives de WordPress que ceux où des styles CSS parallèles persistaient en dehors de `theme.json`.

## Ce qu'on changerait : la documentation des décisions, pas seulement du code

Notre plus grand regret collectif ne porte pas sur une erreur technique précise, mais sur une habitude qui nous a longtemps manqué : documenter le pourquoi d'une décision d'architecture, pas seulement le comment du code qui en résulte. Reprendre un vieux projet interne, cinq ans après, pour comprendre pourquoi telle échelle d'espacement ou telle structure de patterns avait été choisie ainsi, s'est révélé plus difficile que de comprendre le code lui-même.

> Un code bien écrit explique comment il fonctionne. Il n'explique jamais pourquoi il a été écrit ainsi plutôt qu'autrement, cette partie-là se documente à part, ou elle se perd.

## Ce que l'avenir proche nous fait anticiper

Les évolutions les plus récentes du cœur, notamment l'intégration croissante de l'Interactivity API dans les thèmes par défaut, nous poussent à revoir une nouvelle fois notre starter thème interne, moins pour corriger une erreur passée que pour intégrer nativement des mécanismes qui n'existaient simplement pas lors de sa précédente refonte. Le bilan de ces cinq années n'est donc pas un point final, plutôt une étape dans un processus d'ajustement continu qui, on l'espère, ne s'arrêtera jamais vraiment.

## En résumé

Cinq ans de production en thèmes blocs nous ont appris que les erreurs les plus coûteuses n'étaient pas techniques mais organisationnelles : un starter trop ambitieux dès le départ, une formation client sous-estimée, une documentation des décisions négligée au profit de la seule documentation du code. Les choix techniques structurants, comme l'investissement précoce dans `theme.json`, ont en revanche largement tenu leurs promesses dans la durée.