# Pattern ou bloc personnalisé : quand un pattern suffit amplement

> Avant d'ouvrir un nouveau projet npm pour un bloc sur mesure, posez-vous la question du coût réel face à un simple pattern enregistré. Comparatif chiffré.

- Auteur : Clément Hadrot
- Publié le : 2023-06-06
- Mis à jour le : 2023-06-06
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/pattern-ou-bloc-personnalise-quand-choisir/

## L’essentiel

- Un pattern se maintient sans build, un bloc React en a besoin
- Le pattern convient si la structure varie peu d'un usage à l'autre
- Le bloc s'impose dès qu'il faut des réglages ou une logique dynamique

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.

> L'essentiel à retenir : Un pattern se maintient sans build, un bloc React en a besoin ; Le pattern convient si la structure varie peu d'un usage à l'autre ; Le bloc s'impose dès qu'il faut des réglages ou une logique dynamique

## 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é.