Une agence de développement avait reçu, à quelques semaines d’intervalle, trois demandes clients qui se ressemblaient sur le papier : « je voudrais une version différente de ce bloc ». La première portait sur un bloc Bouton, où seule la couleur de fond changeait selon le contexte. La deuxième portait sur un bloc Galerie, où le nombre de colonnes par défaut devait changer selon la page d’atterrissage utilisée pour une campagne publicitaire. La troisième portait sur un bloc Témoignage, où la version « premium » affichait en plus une note en étoiles absente de la version standard. Trois demandes qui semblaient identiques, mais qui appelaient en réalité trois solutions techniques totalement différentes.
Confondre ces trois mécanismes, ou choisir systématiquement le même par habitude, mène presque toujours à une impasse au moment de la première évolution demandée par le client, quelques mois plus tard. Une grille de décision simple permet d’éviter ce piège dès la conception initiale.
Le style de bloc : une alternative purement visuelle
Un style de bloc, enregistré via registerBlockStyle, ajoute une classe CSS alternative appliquée au même balisage, sans toucher aux attributs ni à la structure du bloc. C’est le mécanisme adapté à la première demande de l’exemple : une variation purement esthétique, sans logique métier, qui reste réversible en un clic depuis le panneau de style de l’éditeur.
wp.blocks.registerBlockStyle( 'core/button', {
name: 'accent-vif',
label: 'Accent vif',
} );La variation de bloc : des attributs préréglés à l’insertion
Une variation, déclarée via la propriété variations de block.json ou enregistrée dynamiquement avec registerBlockVariation, propose une entrée distincte dans l’inserteur qui pré-remplit certains attributs dès l’insertion, sans créer de nouveau type de bloc. C’est le mécanisme adapté à la deuxième demande : le bloc Galerie reste fondamentalement le même, seul son attribut columns diffère à l’insertion initiale, librement modifiable ensuite par le rédacteur.
{
"name": "core/gallery",
"variations": [
{
"name": "galerie-campagne",
"title": "Galerie campagne (4 colonnes)",
"attributes": { "columns": 4 }
}
]
}
Le bloc dédié : quand la structure elle-même diverge
Un bloc entièrement distinct se justifie quand la divergence dépasse une simple valeur d’attribut ou une classe CSS : un champ supplémentaire dans le formulaire d’édition, un comportement de rendu différent, ou une logique métier propre qui n’a pas de sens pour la version standard du bloc. C’est le cas de la troisième demande : la note en étoiles n’existe tout simplement pas dans le bloc Témoignage standard, elle nécessite un attribut, un contrôle d’édition et un rendu qui lui sont propres.
La grille de décision en pratique
| Question posée | Réponse oui |
|---|---|
| Le balisage HTML final reste-t-il identique, seule la classe change ? | Style de bloc |
| Un attribut existant suffit-il, seule sa valeur par défaut change ? | Variation de bloc |
| Un nouveau champ, un nouveau comportement ou une logique propre sont-ils nécessaires ? | Bloc dédié |
Le coût d’un mauvais choix initial
Choisir un style de bloc pour un besoin qui, en réalité, nécessite un nouvel attribut oblige tôt ou tard à migrer vers une variation, avec les complications de rétrocompatibilité que cela implique pour le contenu déjà publié avec l’ancienne classe CSS. À l’inverse, créer un bloc dédié pour un besoin qui aurait suffi avec une simple variation multiplie inutilement la surface de maintenance : plus de code à tester, plus de documentation à tenir à jour, plus de confusion pour les rédacteurs face à deux blocs qui se ressemblent trop.
- Un style de bloc se change après coup sans perte de données.
- Une variation reste un simple point de départ, jamais une contrainte définitive.
- Un bloc dédié engage une maintenance à part entière, distincte du bloc dont il s’inspire.
Avant de coder quoi que ce soit, formulez la demande du client sous la forme « est-ce que je peux obtenir ça avec une classe CSS, avec un attribut préréglé, ou est-ce que j’ai besoin d’un champ qui n’existe pas encore ». La réponse indique directement le bon mécanisme.
Notre verdict
Ces trois mécanismes ne sont pas interchangeables ni redondants : ils répondent chacun à un niveau de divergence différent entre deux usages d’un même bloc. Prendre cinq minutes pour situer une demande client sur cette échelle, avant d’ouvrir un éditeur de code, évite la grande majorité des refontes précipitées observées quelques mois après la livraison initiale d’un projet.
