Un développeur junior de l’équipe m’a demandé, un peu gêné, s’il « avait le droit » de faire un simple pattern pour un bandeau d’appel à l’action répété sur douze pages, plutôt que de développer un bloc personnalisé complet avec block.json, build wp-scripts et tout l’attirail. La réponse est oui, et c’est même le bon choix dans neuf cas sur dix pour ce genre de composant.
Cette hésitation revient souvent chez les développeurs qui viennent du monde des composants React classiques, où chaque élément réutilisable mérite son propre fichier. Dans l’écosystème des blocs WordPress, un pattern (bloc réutilisable enregistré via PHP, disponible depuis WordPress 5.5 sous le nom de blocs réutilisables puis généralisé comme Block Patterns) est souvent suffisant, et bien moins coûteux à maintenir.
Ce qu’est réellement un pattern
Un pattern (au sens Block Patterns, enregistré avec register_block_pattern()) est un gabarit de blocs natifs déjà assemblés — colonnes, titre, bouton, image — que l’éditeur insère et que l’utilisateur peut ensuite modifier librement, bloc par bloc. Contrairement à un bloc réutilisable synchronisé, un pattern classique se détache dès l’insertion : chaque instance est indépendante des autres.
Un bloc personnalisé, lui, est un composant à part entière avec son propre nom d’espace de noms, son edit(), son save() ou son rendu serveur, ses attributs typés, et généralement un processus de build via @wordpress/scripts.
Le tableau des critères
| Critère | Pattern suffit | Bloc personnalisé nécessaire |
|---|---|---|
| Structure | Fixe, faite de blocs natifs | Doit varier selon des réglages complexes |
| Logique | Aucune, juste de la mise en page | Calculs, appels API, état interne |
| Réglages exposés | Ceux des blocs natifs (couleur, texte) | Champs personnalisés (sélecteur de CPT, date, relation) |
| Maintenance | Un fichier PHP, pas de build | Build wp-scripts, tests, versioning des attributs |
| Rendu identique partout | Non garanti (chacun peut le modifier) | Garanti par le rendu du bloc |
Exemples concrets tranchés
Sur nos projets récents, voici comment les choix se sont faits, et pourquoi :
- Bandeau CTA « Réserver un appel » : pattern. Structure fixe (colonne texte + colonne bouton), aucune logique, l’équipe éditoriale change juste le texte et la couleur du bouton.
- Bloc « Avis clients » avec notation par étoiles et lien vers une source externe : bloc personnalisé. Il fallait un attribut numérique borné de 1 à 5, un rendu spécifique des étoiles en SVG, et une validation qu’un simple champ texte de pattern ne permet pas.
- Bloc « Carte produit » qui va chercher automatiquement le prix et le stock via une requête : bloc dynamique obligatoire. Impossible de faire ça avec un pattern statique, la donnée doit être calculée au rendu.
- Grille de logos partenaires : pattern avec un bloc Galerie natif préconfiguré. Pas besoin de logique, juste d’un point de départ pratique pour l’éditeur de contenu.
Le vrai coût caché d’un bloc inutile
Développer un bloc personnalisé pour un simple bandeau engage bien plus que le temps de codage initial : un fichier block.json, un edit.js, un save.js, un style.scss, une configuration webpack héritée de wp-scripts, et surtout un processus de mise à jour des attributs si la structure change un jour (voir les dépréciations de blocs, un sujet à part entière). Chaque bloc supplémentaire dans une extension, c’est aussi un candidat de plus à tester après chaque montée de version de WordPress.
À l’inverse, un pattern mal choisi a son propre coût : s’il doit rester identique partout et que l’éditeur de contenu le modifie par erreur sur une page, rien ne l’empêche. Pour ce cas précis — une structure qui doit rester strictement identique partout tout en étant simple — le bloc réutilisable synchronisé (introduit sous ce nom depuis la fusion des anciens « blocs réutilisables » dans l’inserteur moderne) est un compromis intéressant : pas de build, mais une seule source de vérité modifiable depuis n’importe quelle instance.
Le cas intermédiaire : la variation de bloc
Entre le pattern et le bloc personnalisé complet, il existe une troisième option trop souvent oubliée : la variation de bloc, déclarée via registerBlockVariation(). Elle permet de préconfigurer un bloc natif existant (par exemple une Galerie en mode « mosaïque trois colonnes ») avec des attributs par défaut et une icône dédiée, sans écrire de nouveau composant de rendu. C’est la bonne réponse quand on veut simplement proposer un préréglage d’un bloc qui existe déjà.
Notre grille de décision
Avant de lancer un nouveau projet de bloc, on pose systématiquement trois questions à l’équipe : le composant a-t-il besoin d’un état ou d’un calcul au rendu ? A-t-il besoin d’un réglage qu’aucun bloc natif ne propose déjà ? Doit-il rester rigoureusement identique à chaque insertion sans que l’éditeur puisse le casser ? Si la réponse est non aux trois, un pattern (ou une variation de bloc natif) suffit très largement, et l’équipe gagne un cycle de développement entier.
Un conseil qu’on répète à chaque nouvelle recrue : commencez toujours par un pattern. S’il montre ses limites — parce qu’un client casse systématiquement la structure, ou parce qu’une logique dynamique devient indispensable — on migre vers un bloc à ce moment-là, pas avant.
Notre verdict
Un pattern coûte un fichier PHP et zéro dépendance de build ; un bloc personnalisé coûte un projet à part entière avec sa propre maintenance dans la durée. Le bon réflexe consiste à partir du besoin réel — logique, réglages, garantie de structure — plutôt que de l’habitude ou du prestige technique. Sur le bandeau CTA de cet article, le passage prévu d’un bloc à un pattern a fait disparaître six fichiers du dépôt sans rien retirer côté fonctionnalité.
