L'éditeur de site à l'épreuve des clients : un guide theme.json

Résumé

Lorsqu'un client ouvre l'éditeur de site WordPress pour la première fois, la possibilité de modifier chaque bloc, couleur et mise en page peut sembler être une fonctionnalité pour lui — et une menace pour vous. Cet article explique comment utiliser theme.json pour tracer une ligne claire entre la modification du contenu et le contrôle du design. Au lieu de lutter contre l'éditeur de site, vous configurez des préréglages, des valeurs par défaut et des limites qui permettent à des clients non techniques de mettre à jour leur propre site en toute sécurité. Nous verrons ce qu'il faut verrouiller, ce qu'il faut laisser ouvert, et pourquoi le sur-verrouillage est un vrai risque. L'approche repose sur des jetons de design et des contraintes au niveau des modèles, de sorte qu'elle fonctionne de manière cohérente sur chaque site client que vous gérez. À la fin, vous disposerez d'un processus réutilisable pour confier l'éditeur de site sans confier les clés de votre système de design.

Quelle est la première chose que vous faites lorsqu'un client vous envoie un e-mail pour dire qu'il « a simplement essayé de mettre à jour le titre » et que tout l'espacement du site s'est effondré ?

Si vous gérez plus d'un site WordPress, vous avez probablement reçu ce message sous une forme ou une autre. L'éditeur de site a donné à votre client les clés d'une voiture avec cinq vitesses et pas de frein. Ils pensent faire un simple changement de texte, et soudain la typographie globale est déréglée, le héros de la page d'accueil a une couleur néon que vous n'avez pas choisie, et deux blocs sont maintenant empilés au lieu d'être côte à côte.

Pendant ce temps, vous pensez aux six autres sites clients que vous gérez, et la dernière chose dont vous avez besoin est un piège de maintenance où chaque modification client « utile » nécessite une restauration à partir d'une sauvegarde.

La réponse n'est pas de retirer l'éditeur de site. Il s'agit de définir des limites à l'intérieur de celui-ci en utilisant theme.json. Selon les ressources pour développeurs WordPress, theme.json est la source de vérité centrale pour les réglages et les styles de l'éditeur de blocs — il définit les palettes de couleurs, la typographie et les options de mise en page qui apparaissent au client. Cela signifie que le même fichier qui contrôle votre design peut aussi contrôler ce que votre client peut et ne peut pas modifier.

Voyons comment réfléchir à cela, car la plupart des tutoriels se concentrent sur ce que theme.json peut faire pour les développeurs. La question pour une agence est différente : comment l'utiliser pour rendre les clients en sécurité sans qu'ils se sentent enfermés ?

Pourquoi l'éditeur de site semble-t-il si dangereux ?

Votre client n'essaie pas de casser le site. Il essaie de faire ce que vous l'avez formé à faire pendant des années dans l'ancien éditeur : changer un titre, remplacer une image, peut-être ajouter un paragraphe. Le danger n'est pas son intention — c'est que l'éditeur de site affiche les contrôles globaux au même endroit que les contrôles de contenu.

Voici un scénario courant. Un client ouvre un modèle dans l'éditeur de site et voit un bloc de titre. Il change sa couleur pour correspondre au nouvel échantillon de la marque. Mais parce que ce titre est dans un modèle, le changement s'applique partout où ce modèle est utilisé. Pour le client, cela ressemblait à une modification. Pour le site, c'était un changement global.

Le principe général : lorsque vous donnez à quelqu'un un constructeur de pages, il finira par trouver les « réglages avec garde-fous » et les désactivera. Mais avec theme.json, vous pouvez masquer les garde-fous eux-mêmes. Au lieu de dire au client « ne touchez pas aux styles globaux », vous ne lui montrez tout simplement pas une palette de couleurs qui peut produire un mauvais résultat. Vous définissez une palette de couleurs approuvées, une échelle de tailles de police et un ensemble de préréglages d'espacement — et le client choisit parmi ceux-ci, pas parmi tout le spectre du CSS.

C'est le premier changement : arrêtez de penser en termes de règles et commencez à penser en termes d'usines. theme.json est votre chaîne de production. Vous configurez les options que le client voit, et les contraintes sont appliquées par l'interface elle-même, et non par un ensemble d'instructions dans un document de transmission.

Que devriez-vous réellement verrouiller ?

Pas tout. Si vous verrouillez trop étroitement la zone de contenu, le client vous appellera soit à chaque fois qu'il aura besoin d'ajouter un paragraphe, soit il trouvera un moyen de contourner — souvent en ajoutant un plugin ponctuel ou en copiant le HTML de son ancien site.

Voici un tableau pratique de ce qu'il faut verrouiller, de ce qu'il faut laisser, et pourquoi :

Surface d'édition	Verrouiller ?	Pourquoi
Structure du modèle et mises en page des blocs	Verrouiller	Empêche la suppression ou la réorganisation accidentelle des blocs de mise en page principaux
Styles globaux (couleurs, polices, préréglages d'espacement)	Verrouiller avec préréglages	Les clients choisissent parmi un ensemble approuvé, pas des valeurs arbitraires
Texte et images du contenu	Laisser ouvert	C'est leur travail ; laissez-les faire sans demander la permission
Espacement entre les blocs	Verrouiller partiellement	Fournissez des préréglages d'espacement pour qu'ils puissent ajuster le rythme sans casser l'alignement
Motifs de blocs sélectionnés	Laisser ouvert si vous les avez validés	Un moyen sûr pour les clients d'ajouter de nouvelles sections sans tout construire de zéro

La nuance importante est « verrouiller avec préréglages », pas « verrouiller complètement ». Pour les styles globaux, vous ne cachez pas le panneau de réglages ; vous réduisez le nombre de choix à un ensemble sélectionné. Pour la structure du modèle, vous pouvez verrouiller certains blocs afin qu'ils ne puissent pas être supprimés, mais toujours permettre aux clients de modifier le texte à l'intérieur.

Un mot de prudence : verrouiller un bloc dans un modèle est différent de le verrouiller dans une page spécifique. Les verrous de modèle affectent tout le contenu qui utilise le modèle. Si vous avez besoin de différents niveaux de verrouillage sur différentes pages, vous devrez travailler au niveau du bloc dans l'éditeur, ce qui est plus fragile. Pour un travail d'agence répétable, concevez vos modèles pour que les zones verrouillées soient cohérentes.

Comment définir des limites sans donner l'impression que l'éditeur est un piège ?

La technique consiste à définir vos jetons de design dans theme.json, puis à résister à l'envie de faire quoi que ce soit d'autre en CSS.

Par exemple, au lieu de laisser le client définir une couleur arbitraire sur un bouton, vous définissez un style de bouton dans theme.json qui utilise une couleur spécifique de votre palette. Le client peut toujours sélectionner le bouton et modifier son texte, mais le sélecteur de couleurs n'affiche que vos échantillons approuvés. Il en va de même pour les tailles de police, les hauteurs de ligne et l'espacement.

Le même principe s'applique aux modèles. Vous pouvez utiliser la fonctionnalité « verrouiller » sur des blocs spécifiques d'un modèle — par exemple, verrouiller la structure en colonnes d'un bloc de témoignage pour que le client puisse modifier le texte de la citation mais pas transformer trois colonnes en deux. Si vous n'avez pas encore utilisé le verrouillage de blocs, il est disponible dans la barre d'outils de l'éditeur ; lorsque vous verrouillez un bloc, vous pouvez choisir si le client peut modifier le contenu, le déplacer, ou les deux. Vous pouvez même appliquer cela dans theme.json pour les valeurs par défaut au niveau du bloc.

Ce que vous visez, c'est un éditeur où le client ne voit jamais un contrôle qui peut casser le design. Cela ne signifie pas qu'il ne peut rien faire de mal ; cela signifie que la pire chose qu'il puisse faire est de changer le libellé d'un titre, pas l'apparence de tout le site.

Si vous utilisez des types de publication personnalisés, les mêmes principes s'appliquent au-delà des modèles par défaut — consultez notre guide sur l'extension de theme.json aux types de publication personnalisés et aux sorties de plugins.

Que se passe-t-il lorsque vous verrouillez trop ?

Voici le point provocateur : le sur-verrouillage est tout aussi nocif que le sous-verrouillage. Un client qui ne peut pas redimensionner un titre ou ajouter un espace entre les sections finira par vous demander de « faire en sorte que cela ait l'air bien » — et puis vous reviendrez à faire de petites modifications gratuitement. Pire, ils pourraient décider que l'éditeur de site est inutile et revenir à un constructeur de pages tiers, ce qui leur redonne trop de contrôle.

Le compromis est réel. Les éditeurs verrouillés produisent moins d'appels d'urgence, mais aussi plus de demandes du type « pouvez-vous juste remonter ce bouton de cinq pixels ». Les éditeurs ouverts produisent l'inverse. Votre travail est de trouver le point d'équilibre pour chaque client, pas d'appliquer une configuration universellement.

Une bonne heuristique de départ : verrouillez tout ce qui affecte toutes les instances de quelque chose (styles globaux, structure du modèle), et laissez ouvert tout ce qui affecte une seule instance (le texte et les images d'une page unique). Si un client casse une seule page, c'est une réparation de 5 minutes. S'il casse un style global, c'est une réparation de 20 minutes et un problème de sécurité.

Comment rendre cela réutilisable d'un client à l'autre ?

C'est là qu'intervient le flux de travail de l'agence. Vous devriez avoir un theme.json de base qui définit vos jetons de design — la palette de couleurs, l'échelle typographique et les préréglages d'espacement — puis un fichier de remplacement par client qui étend ou modifie des valeurs spécifiques.

Commencez par créer un thème de blocs « starter ». Voici comment créer un thème de blocs personnalisé avec theme.json — une fois que vous l'avez développé et documenté, le copier pour un nouveau client consiste à remplacer les couleurs et les polices de la marque. Vous ne réinventez pas la roue ; vous remplacez des jetons. C'est exactement la mentalité arrêter de reconstruire chaque site WordPress, mais appliquée à l'éditeur plutôt qu'au backend.

Parce que theme.json est un fichier unique, il est également facile à versionner et à déployer sur plusieurs environnements. Vous pouvez examiner les modifications, voir ce qu'un client a modifié dans les styles globaux et comparer ces modifications à votre fichier de base. Cela vous donne une piste d'audit solide pour les demandes de support.

Si vous gérez plusieurs sites et que vous n'avez pas encore configuré de thème de base, c'est votre chance. C'est le morceau de travail WordPress personnalisé qui se rentabilise à chaque fois qu'un client ouvre l'éditeur.

Et les clients qui n'arrêtent pas de demander « une couleur de plus » ?

Votre palette est une promesse. Si vous définissez cinq couleurs de marque et qu'un client en demande une sixième, la réponse n'est pas « non » — c'est « oui, mais elle arrive comme un ajout délibéré à la palette, pas comme un code hexadécimal ponctuel dans un titre. » Lorsque vous ajoutez une couleur à theme.json, elle devient disponible de manière cohérente sur tout le site. C'est la bonne façon de gérer ces demandes.

C'est aussi là que vous devez communiquer avec le client. Expliquez que l'éditeur de site ne leur montre que les couleurs et les polices qui correspondent à leur charte de marque. S'ils veulent élargir ces normes, vous vous en occuperez dans le système de design, puis chaque nouvelle couleur sera disponible partout — y compris sur les futures pages qu'ils n'ont pas encore construites. C'est une bien meilleure réponse que « nous ne faisons pas cela ».

En même temps, n'accumulez pas une palette de quarante couleurs. Revisitez-la trimestriellement et supprimez tout ce qui était un accident ponctuel. L'objectif est un petit ensemble d'options intentionnel.

Si vous verrouillez la mise en page mais laissez le contenu, et que vous faites de la palette une partie vivante de votre relation client, l'éditeur de site cesse d'être une menace. Il devient un moyen de donner à vos clients une véritable autonomie sans sacrifier les normes de design que vous êtes payé pour protéger.