Trois ans de production avec l’éditeur de site : ce que l’on referait différemment

WordPress 5.9 est sorti en janvier 2022, avec l’éditeur de site complet comme fonctionnalité phare. Quatre ans plus tard, notre agence a livré et maintenu plusieurs dizaines de projets construits autour du Full Site Editing, avec un recul suffisant pour dresser un bilan honnête, loin de l’enthousiasme du lancement comme de la méfiance des débuts.

Ce recul est précieux, car les trois premières années d’un site ne révèlent pas les mêmes problèmes qu’une quatrième ou cinquième année de maintenance. Certains choix qui semblaient anodins en 2022 se sont révélés structurants ; d’autres, qui paraissaient prometteurs sur le papier, ont généré une charge de maintenance que nous n’avions pas anticipée. Voici ce que nous referions différemment si c’était à refaire.

L’évolution du workflow d’agence

Le changement le plus profond n’est pas technique, il est organisationnel. Avec le thème classique et PHP, la frontière entre développeur et intégrateur était nette : le développeur codait la structure, l’intégrateur ajustait le CSS, et le client remplissait le contenu via des champs personnalisés soigneusement cadrés. Avec l’éditeur de site, cette frontière s’est largement estompée : la structure elle‑même (templates, patterns) est désormais éditable visuellement, ce qui a changé la nature du travail de nos développeurs front, davantage centrés sur la conception de systèmes de blocs réutilisables que sur l’écriture de gabarits fermés.

Ce changement a demandé une montée en compétence réelle sur theme.json, sur l’API des blocs et sur la logique des patterns synchronisés, que nous avons sous-estimée au démarrage. Les premiers projets FSE de l’agence, en 2022, ont pris sensiblement plus de temps que prévu, le temps que l’équipe change véritablement de réflexe.

Ce qui a bien vieilli : patterns synchronisés et theme.json

Deux choix se sont révélés particulièrement solides sur la durée. Les patterns synchronisés (anciennement appelés blocs réutilisables) ont tenu leurs promesses : centraliser un bloc « bandeau de contact » ou « bloc newsletter » utilisé sur des dizaines de pages, et pouvoir le modifier une seule fois pour toutes ses occurrences, a considérablement réduit le temps de maintenance sur les sites à fort volume de pages.

theme.json s’est également révélé être une excellente base de travail. Centraliser la palette de couleurs, la typographie et les espacements dans un fichier de configuration unique, plutôt que dans des fichiers CSS épars, a rendu les refontes graphiques partielles beaucoup plus rapides à exécuter : changer une couleur de marque dans theme.json propage le changement à l’ensemble du site en une seule modification, sans chasse aux valeurs codées en dur dans le CSS.

• Patterns synchronisés : gain de temps mesurable sur la maintenance de contenu répété
• theme.json : centralisation efficace des tokens de design, refontes partielles accélérées
• Verrouillage de blocs : réduction nette des tickets de support liés à la casse de structure

Ce qui a posé problème sur la durée

Le point le plus douloureux, sans conteste, a été la maintenance des thèmes-blocs sur mesure. Contrairement à un thème classique où la logique métier vit essentiellement en PHP, un thème-bloc distribue sa logique entre theme.json, les fichiers de templates HTML, et les patterns enregistrés en PHP ou en JSON. Cette dispersion, séduisante au démarrage d’un projet, complique sensiblement la reprise d’un projet par un développeur qui n’en est pas l’auteur initial : il faut naviguer entre plusieurs formats et plusieurs emplacements pour comprendre la construction complète d’une page.

Les migrations entre versions majeures de WordPress ont également demandé plus de vigilance qu’anticipé. Certains changements de structure des templates (le passage de certains formats de balisage de blocs, ou l’évolution des attributs de patterns) ont cassé silencieusement des mises en page sur d’anciens projets lors de montées de version, sans message d’erreur explicite, simplement un rendu visuel dégradé constaté après coup.

Nous imposons désormais un environnement de recette obligatoire avant toute montée de version majeure sur un site FSE en production, avec une checklist visuelle des pages clés. Ce n’était pas systématique en 2022 et 2023 ; cela l’est devenu après plusieurs incidents évitables.

La question de la dette technique des patterns

Un autre point sous-estimé au démarrage : la prolifération de patterns non maîtrisée. Sur plusieurs projets anciens, l’absence de gouvernance claire sur la création de nouveaux patterns a conduit à une bibliothèque encombrée de variantes quasi identiques, créées au fil de l’eau par différents intervenants sans concertation. Nettoyer cette dette, sur un site de plusieurs centaines de pages, représente un chantier non négligeable.

Nous recommandons désormais, sur tout nouveau projet, de documenter dès le départ une nomenclature stricte des patterns et un nombre limité de variantes par type de section, plutôt que de laisser la bibliothèque grossir sans contrôle au fil des demandes clients.

Conseils pour aborder un nouveau projet FSE aujourd’hui

Voici ce que nous appliquons systématiquement sur chaque nouveau projet FSE lancé aujourd’hui, à la lumière de ces quatre années de production :

1. Centraliser tous les tokens de design dans theme.json dès le premier jour, sans exception ni valeur codée en dur dans le CSS.
2. Définir une nomenclature de patterns avant d’en créer le premier, avec un nombre maximal de variantes par type de section.
3. Documenter la structure du thème-bloc (emplacement des templates, des parties, des patterns) dans un fichier accessible à toute l’équipe, pas seulement au développeur initial.
4. Prévoir systématiquement un environnement de recette avant toute montée de version majeure de WordPress.
5. Verrouiller les blocs structurants (header, footer, navigation) avant chaque livraison client.
6. Limiter le rôle des comptes clients non techniques à ce dont ils ont réellement besoin, quitte à masquer l’éditeur de site.

En résumé

Quatre ans après WordPress 5.9, l’éditeur de site a largement fait ses preuves pour la production d’agence, mais il n’a rien d’une baguette magique : sa promesse de simplicité côté client repose sur une discipline accrue côté développeur, en particulier sur la gouvernance des patterns et la rigueur des montées de version. Les fondations — theme.json, patterns synchronisés, verrouillage de blocs — se sont révélées solides sur la durée. La dette technique, elle, ne vient plus du framework, mais de l’absence de méthode autour de son usage. C’est une leçon que nous appliquons désormais dès le premier jour de chaque projet.