Arrêtez de reconstruire chaque site WordPress

Résumé

La plupart des agences construisent chaque site WordPress à partir d'un thème vierge, même lorsqu'une base commune permettrait de gagner des semaines sur le calendrier. Cet article soutient que theme.json, les block patterns et les blocs dynamiques permettent de standardiser la couche structurelle tout en préservant le design distinctif de chaque client. Il aborde directement les cinq objections qui empêchent les équipes de changer : « nous avons des clients différents », « les blocs personnalisés sont chers », « l'éditeur est déroutant », « nous allons perdre nos hooks et filtres » et « FSE n'est pas prêt pour la production ». Chaque objection reçoit un contre-argument pratique et un motif concret que vous pouvez adopter progressivement. Le bénéfice est un processus de construction répétable qui honore toujours le travail sur mesure là où il a sa place. Attention : aucun bouton de réinitialisation en un clic n'est promis.

Combien de vos sites clients partagent ne serait-ce qu'une ligne de code ? Pas la ligne de copyright—du vrai code. Si la réponse est « à peine », vous avez déjà ressenti la douleur : la même section héros reconstruite pour la neuvième fois, le même balisage de grille d'équipe copié d'un projet à l'autre, les mêmes ajustements de préprocessus référencés à travers une demi-douzaine de thèmes. Vous avez aussi entendu la défense : « Chaque client a des besoins différents. » Vrai. Mais la conclusion que tout le monde en tire—que chaque site a besoin d'une base sur mesure—est fausse. L'écosystème WordPress vous offre désormais un moyen de standardiser les pièces structurelles sans standardiser le design : theme.json pour les design tokens, les block patterns pour les mises en page répétées, et les blocs dynamiques pour les quelques fonctionnalités qui nécessitent une vraie logique côté serveur. Cet article traite des objections qui empêchent les agences de franchir ce pas, et de ce qui fonctionne réellement lorsqu'on les conteste.

L'objection « mais chaque client est différent »

Le principe sous-jacent : standardiser la fondation, pas la surface. La raison de garder la structure dans une bibliothèque partagée est précisément de laisser la couche visuelle libre. Un fichier theme.json n'est pas un design—c'est un ensemble de design tokens. Les couleurs, l'espacement et la typographie sont des valeurs, pas du balisage. C'est le changement crucial : vous pouvez partager le balisage tandis qu'un theme.json par site rend le site complètement différent pour une marque différente.

Prenons deux clients : un cabinet d'avocats et un détaillant d'équipement de plein air. Leurs langages de design sont à des années-lumière. Mais les deux ont besoin d'une section héros, d'une grille de témoignages, d'une bande d'appel à l'action. Au lieu de reconstruire le balisage pour chacun, maintenez trois block patterns et laissez le theme.json de chaque client définir les couleurs, les polices et l'espacement. La structure reste identique ; les design tokens la transforment d'une marque à l'autre. Lorsque le détaillant changera sa palette de couleurs au printemps prochain, vous modifierez un fichier sur son site—pas le balisage dans six modèles.

Concrètement, cela signifie que votre équipe crée des patterns sous forme de code, les enregistre dans un plugin partagé et laisse theme.json sur chaque site client gérer l'apparence. Les noms de classe des patterns deviennent votre architecture ; les valeurs deviennent les variables. Vous pouvez même aller plus loin et étendre theme.json pour inclure des paramètres personnalisés pour les types de publication ou la sortie de plugin, même si à un moment donné vous construisez une interface de configuration au lieu d'un site—un piège discuté dans notre analyse de l'extension de theme.json. Gardez la couche partagée légère : elle ne doit contenir que ce qui se répète chez les clients. Le moment où vous vous surprenez à ajouter un paramètre « au cas où quelqu'un en voudrait un jour », vous avez créé une abstraction qui coûtera plus à maintenir qu'elle n'en sauve.

Lorsque vous configurez un nouveau client, les trente premières minutes devraient être : cloner le plugin de patterns partagés, créer un nouveau theme.json avec la palette et l'échelle de police du client, et enregistrer son logo et son pied de page. Ce n'est pas une construction personnalisée ; c'est une tâche de configuration. Le reste du travail spécifique au client va dans le contenu, la structure et toute fonctionnalité véritablement sur mesure. C'est la différence entre construire chaque maison de zéro et avoir un ensemble de plans d'étage préfabriqués que vous pouvez repeindre et retapisser. L'analogie est approximative, mais le principe tient : plus vous poussez dans les valeurs de theme.json, moins vous avez à toucher au balisage.

L'un des gains les plus simples est de regarder comment fonctionnent réellement les block patterns. Un pattern n'est qu'une collection de blocs avec du contenu et un style prédéfinis. Vous pouvez enregistrer n'importe quelle configuration de blocs comme pattern, et ensuite un client peut l'insérer sans avoir besoin de savoir comment elle est construite. Cela signifie que le pattern devient un « point d'entrée » pour les utilisateurs non techniques. Lorsque votre équipe maintient le pattern sous-jacent en code, le client obtient une bibliothèque cohérente sans toucher à une seule balise PHP.

Maintenant, l'avertissement sur lequel je reviens sans cesse : ne surcentralisez pas. Un theme.json avec un paramètre pour chaque nuance imaginable est un marécage de maintenance. Les patterns partagés devraient être affirmés, pas omnipotents. Si un client a besoin d'une mise en page radicalement différente—disons, une page d'accueil de magazine avec une grande grille en vedette—il pourrait ne pas correspondre à votre bibliothèque de patterns standard. Ce n'est pas grave. La standardisation signifie que vous gagnez sur les 80% de projets similaires, pas que vous forcez chaque site dans le même moule.

L'objection « les blocs personnalisés font exploser le budget »

Voici un contre-principe qui semble ennuyeux mais qui fait économiser de l'argent : la plupart des choses que vous pensez nécessiter un bloc personnalisé n'en ont pas besoin. Les blocs de base plus un pattern peuvent couvrir la grande majorité des mises en page. Le bloc personnalisé est le dernier recours, pas la première intention.

L'exemple classique est la grille d'équipe. Si c'est ponctuel, utilisez les blocs de base « colonnes » et « groupe » et laissez le client déposer un avatar à la main. Si trois clients demandent la même grille avec la même structure « liens sociaux sous le nom », vous avez maintenant un candidat pour un block pattern. Lorsque ce pattern commence à accumuler de nouvelles options—effets de survol, tri, étoiles de notation—le pattern devient un fourre-tout ingérable, et il est alors temps d'écrire un bloc personnalisé. L'erreur qui fait mal au budget est de sauter directement au bloc personnalisé dès la première demande.

Un scénario plus insidieux : le client demande un « carrousel d'études de cas ». Le premier réflexe est de penser : « J'ai besoin d'un bloc carrousel. » Mais ont-ils vraiment besoin d'un carrousel ? Peut-être ont-ils besoin d'un groupe de publications défilant horizontalement, ce que les blocs de base peuvent gérer avec un bloc « groupe » et un peu de CSS. Ou peut-être ont-ils besoin d'une liste dynamique d'études de cas récentes, ce qui est un bloc dynamique qui interroge le CPT. La question n'est pas « quelle fonctionnalité le client veut-il ? » mais « de quelles données dépend-elle ? » Si les données sont statiques et modifiables par le client, un pattern suffira. Si les données proviennent d'une requête de base de données, un bloc dynamique est justifié. Si les données doivent être mises à jour en temps réel depuis une API, vous cherchez peut-être plutôt une intégration API REST—cela relève d'un type de construction différent.

Lorsque vous construisez un bloc, block.json est votre ami. C'est la source unique de vérité pour les attributs, les scripts et les styles, ce qui rend le bloc portable à travers les projets. Il vous permet également de déclarer proprement les dépendances et les traductions, ce qui est essentiel lorsque vous distribuez une bibliothèque sur de nombreux sites clients. Pour le contenu qui dépend de données en direct, un bloc dynamique est rendu sur le serveur, vous n'avez donc pas besoin d'envoyer un bundle JavaScript à chaque vue de page. Et si votre bloc évolue, vous pouvez gérer les dépréciations avec élégance pour que le contenu existant ne casse pas—notre guide sur la dépréciation des blocs détaille le schéma exact.

Avant de construire quoi que ce soit, passez la décision au crible de cette grille :

Approche	Idéal pour	Éviter quand
Bloc de base	Contenu ponctuel, pages simples	La mise en page est répétée chez de nombreux clients et nécessite des options riches
Block pattern	Mises en page répétables sans logique	La mise en page nécessite des conditionnels, des données dynamiques ou des interactions complexes
Bloc personnalisé	Comportement répété, piloté par les données ou très spécifique	La seule raison est une section ponctuelle qui peut être traitée avec une classe

Vous voudrez aussi réfléchir au nommage des blocs dès le premier jour. Un nom de bloc est essentiellement un contrat avec votre contenu. Si vous l'appelez wagent/team-grid et que vous le renommez plus tard en wagent/team-carousel, vous casserez le contenu existant à moins de fournir un chemin de dépréciation. Choisissez des noms génériques et basés sur l'objectif qui ne deviendront pas une fausse publicité à mesure que le bloc évolue. C'est une variante de la discipline de nommage que nous avons tous apprise des préfixes de plugins, et elle s'applique tout autant aux noms de blocs.

Le point de vue à contre-courant ici est la chose la plus utile que je puisse dire : le bloc personnalisé que vous construisez parce qu'un client a demandé « juste une pièce » est presque toujours une erreur. Dites non poliment, livrez un bloc de base avec une classe, et mettez les heures de côté. Vous gagnerez plus de respect de la part du client—et une ligne plus petite dans le budget de maintenance.

L'objection « les clients vont casser l'éditeur »

Cette objection n'a qu'à moitié raison. L'éditeur de blocs en lui-même n'est pas le problème ; le problème est de donner trop de corde aux clients. theme.json peut verrouiller ce qui est modifiable : désactiver l'éditeur de modèles, restreindre les blocs autorisés et définir des styles par défaut pour qu'une colonne mal placée fasse moins de dégâts. Certains clients arriveront encore à casser des choses, mais vous pouvez rétablir une page à un pattern enregistré en un clic—ce que l'éditeur classique ne pouvait pas offrir.

Laissez-moi vous peindre un scénario. Un client appelle et dit : « J'ai déplacé une section et maintenant toute la page a l'air fausse. » Avec un thème classique, vous vous connecteriez, inspecteriez le CSS et passeriez probablement une heure à réparer la mise en page. Avec une configuration en blocs, vous pouvez ouvrir la page, sélectionner la zone de contenu et la réinitialiser au pattern enregistré. Le pattern est la ligne de base ; les modifications du client sont la surcouche. Lorsque la surcouche ne va pas, vous la retirez. Ce n'est pas seulement un flux de travail plus agréable ; c'est un éditeur fondamentalement plus indulgent.

Maintenant la nuance : la plupart des clients ne veulent pas éditer grand-chose. Ils veulent changer le texte, remplacer des photos et peut-être réorganiser une section. Le block pattern vous donne exactement cela sans exposer toute la structure du site. En ce sens, l'éditeur n'est pas un jouet ; c'est un viseur. Votre travail est de calibrer ce que les clients peuvent voir. Cela signifie que vous pourriez désactiver les paramètres « Templates », limiter l'insertion de blocs à une liste organisée et même préremplir les patterns vides avec du travail d'espace réservé. L'éditeur devient un formulaire de saisie de contenu plutôt qu'une toile de conception web.

Côté accessibilité, la gestion du focus et la prise en charge du clavier de l'éditeur de blocs sont généralement meilleures que les champs de modèle d'un éditeur classique. Mais vous devez toujours vous assurer que les patterns ont une hiérarchie de titres correcte et des noms accessibles. Comme le pattern est partagé entre les clients, vous ne corrigez ces problèmes qu'une fois, ce qui est un autre avantage caché de la standardisation.

La partie vraiment difficile est interne. Pour votre équipe, apprendre à prototyper avec des blocs exige de désapprendre l'habitude de « le faire en PHP ». C'est un coût réel, mais c'est un coût unique par personne. Ce n'est pas une raison pour éviter l'approche ; c'est une raison pour commencer avec une bibliothèque de patterns et un client indulgent avant de déployer partout. Ne laissez pas le refrain « mes clients ne peuvent pas gérer les blocs » cacher le fait que vous n'avez pas encore configuré un environnement de blocs pour aller à leur rencontre.

L'objection « nous avons déjà des hooks et des filtres »

Le principe ici est : vous ne jetez pas les hooks ; vous ajoutez une couche par-dessus. Les blocs sont la frontière de présentation ; les hooks sont toujours la façon dont vous injectez la logique. Le callback de rendu d'un bloc dynamique s'exécute en PHP, ce qui signifie que vous pouvez appeler les mêmes fonctions et appliquer les mêmes filtres que vous utilisez déjà en toute confiance.

Imaginez un plugin qui vous permet d'ajouter un champ « produit en vedette » à n'importe quelle publication à l'aide d'un filtre. Avec un bloc dynamique, vous pouvez inclure un bloc rendu côté serveur qui exécute ce filtre et affiche la sortie à l'intérieur du conteneur du bloc. Le client insère le bloc ; la logique PHP existante fait le gros du travail. Rien n'est jeté. Pour un exemple encore plus concret, considérez un bloc personnalisé qui liste les publications de projets récentes. Dans son callback de rendu, vous appelez get_posts(), puis bouclez et appliquez the_title() et the_permalink()—les mêmes balises de modèle que vous utilisez depuis des années.

C'est aussi l'endroit où être honnête sur ce qui ne se transpose pas. Certains anciens thèmes astucieux utilisent template-parts avec des conditionnels complexes qui prennent des arguments en fonction du contexte de la page. Recréer cela comme un bloc peut être compliqué. Mais vous n'avez pas à tout recréer d'un coup. La voie incrémentale est de garder la logique PHP, de l'envelopper dans un bloc dynamique et de déplacer le balisage dans le modèle de bloc. Vous constaterez souvent que vos modèles de filtres existants peuvent gérer la nouvelle sortie. Et si la logique est étroitement couplée à une hiérarchie de modèles (par exemple, « sur les résultats de recherche, affichez ceci différemment »), vous pouvez toujours utiliser le modèle classique pour ces vues spécifiques tout en utilisant des blocs pour les pages régulières.

L'API REST ouvre également une autre porte : vous pouvez construire des blocs qui extraient des données d'autres sites WordPress ou de services tiers. Un bloc dynamique peut appeler wp_remote_get() pour récupérer du JSON et le rendre sur le front-end. C'est un modèle puissant pour les créations d'agence où les clients veulent afficher des flux sociaux, des listes de produits ou des données internes sans gérer une intégration séparée. Le compromis est la mise en cache et la gestion des erreurs—si l'API distante est lente, votre page est lente. Gardez les blocs basés sur l'API hors du contenu critique au-dessus de la ligne de flottaison, ou utilisez le rendu côté client avec un état de chargement approprié.

Les actions et les filtres s'exécutent toujours autour de l'enregistrement et du rendu ; l'architecture des hooks ne disparaît pas lorsque vous adoptez les blocs, elle se déplace simplement vers un nouveau contexte. Si vous avez besoin de rafraîchir votre compréhension de là où les actions et les filtres rencontrent ce nouveau monde de blocs, notre plongée en profondeur sur les hooks est un rafraîchissement utile.

L'objection « FSE n'est pas prêt pour la production »

D'accord, mais demandez ce que « risqué » signifie réellement. L'édition complète du site (Full Site Editing) a traversé plusieurs versions, et theme.json s'est installé dans un schéma stable. Le risque n'est pas que l'éditeur « casse soudainement »—le risque est que le code personnalisé de votre équipe repose sur d'anciens modèles PHP qui cohabitent mal avec les modèles de blocs. De plus, certains plugins tiers supposent toujours l'éditeur classique ou le personnalisateur. C'est une décision de compatibilité, pas une raison pour jeter tout le modèle.

Une façon utile d'y penser : les sites simples et répétables avec du contenu écrit en blocs sont les moins risqués. Les clients à haut risque sont ceux qui ont des thèmes classiques profondément personnalisés ou des plugins propriétaires qui rendent leur propre front-end. C'est une raison légitime de s'en tenir aux thèmes classiques pour cette petite niche. L'erreur est de prétendre que « prêt pour la production » est un interrupteur unique qui est soit allumé, soit éteint.

Avant de proposer un thème de blocs à un client, passez en revue une liste de contrôle rapide :

• Le client a-t-il un thème fortement personnalisé qui nécessiterait une migration ?
• Les plugins indispensables prennent-ils en charge l'éditeur de site et l'API REST ?
• L'environnement d'hébergement permet-il l'accès aux fichiers attendu par le thème de blocs ?
• Avez-vous prévu du temps pour la conception des patterns, et pas seulement l'enregistrement des blocs ?
• L'équipe du client tolérera-t-elle les changements de l'éditeur, ou a-t-elle besoin d'un modèle verrouillé ?

Si une réponse est non, ajustez le périmètre ou utilisez une approche hybride. Ce n'est pas un compromis ; c'est un jugement d'ingénieur. Et si vous construisez un hybride, souvenez-vous de l'histoire des hooks et des filtres ci-dessus—vous pouvez toujours envelopper l'ancienne logique dans des blocs dynamiques pendant que theme.json gère l'apparence globale.

Versionner votre theme.json n'est pas seulement une préoccupation théorique. J'ai vu la bibliothèque de blocs personnalisés d'une agence se casser lorsque le client a mis à jour WordPress et que le fichier style du bloc, enregistré avec wp_register_style(), avait un identifiant modifié. La correction a été facile, mais la panique était réelle. Un simple processus de test—exécuter la mise à jour sur une copie de staging du site, cliquer sur les pages clés, puis publier—résout la plupart de ces surprises.

L'objection que vous ne vous êtes pas encore faite

Voici la méta-objection qui empêche les agences de standardiser : « C'est un gros changement, et il n'y a pas le temps de le faire pendant le travail client. » C'est vrai—alors ne le faites pas pendant le travail client. Choisissez un projet interne ou un petit client et construisez une bibliothèque de patterns. Utilisez theme.json comme système de design tokens. Ajoutez un bloc personnalisé uniquement lorsque c'est justifié. Enveloppez les anciens hooks là où ils aident. Itérez.

Voici une première approximation des 30 premiers jours :

1. Auditez vos cinq dernières créations client et listez les dix éléments de mise en page les plus répétés.
2. Transformez ces dix éléments en block patterns, avec un petit ensemble de classes CSS.
3. Construisez un plugin partagé (ou mu-plugin) qui enregistre ces patterns. Si vous n'avez pas réfléchi à l'organisation des plugins pour cela, parcourez d'abord ce guide sur la création de plugins WordPress robustes.
4. Créez un theme.json qui correspond à votre design de base ; ajoutez des valeurs spécifiques au client au fur et à mesure que vous lancez des projets.
5. Choisissez un petit projet interne ou un client sympathique et migrez-le vers la pile.
6. Documentez une histoire héroïque d'un client qui a modifié sa page d'accueil sans vous appeler.

À la fin de cette expérience, vous n'aurez pas un badge « block-first » à accrocher au mur. Vous aurez une équipe capable de lancer un nouveau site client à partir d'une base partagée sans s'excuser pour le calendrier. Vous serez également mieux placé pour dire non à la demande du client pour un 42e bloc personnalisé—parce que vous savez exactement ce que les blocs de base peuvent faire, ou parce que vous pouvez montrer pourquoi un bloc dynamique serait vraiment plus rapide.

Construirez-vous encore des sites sur mesure ? Oui. Certains clients auront toujours besoin d'un modèle personnalisé, d'une page sur mesure ou d'une intégration propriétaire qui ne vaut pas la peine d'être forcée dans le modèle partagé. L'objectif n'est pas d'éliminer le travail sur mesure—c'est d'en faire l'exception plutôt que la règle.

La répétabilité vient des parties ennuyeuses : un schéma theme.json solide, une bibliothèque de patterns claire et la discipline de garder la couche partagée légère. Ce n'est pas la version brillante que vous entendez dans les webinaires. C'est celle qui dissipe le blues du lundi matin face au thème vierge.