Un client m’a demandé un jour de rendre modifiable, en un seul endroit, le bandeau d’alerte qui s’affichait en haut de toutes les pages de son site. Simple en apparence. Sauf qu’il existe deux façons de faire ça dans l’éditeur de site, et qu’elles ne se comportent pas de la même manière dès qu’on sort du cas d’usage le plus simple.
La template part et le pattern synchronisé partagent un même objectif — éviter de recopier un bloc de contenu dix fois — mais divergent sur la portée, les droits d’édition, l’export et la traduction. Ce choix, souvent tranché à la légère, a des conséquences concrètes sur la maintenance d’un site en production.
Deux mécanismes qui se ressemblent en apparence
Une template part s’insère avec le bloc wp:template-part, qui référence un slug (header, footer, cta-newsletter…) déclaré dans theme.json ou détecté automatiquement depuis le dossier parts/ du thème. Un pattern synchronisé (anciennement « bloc réutilisable ») s’insère lui via wp:block, qui référence l’identifiant numérique d’un article du type wp_block.
Dans les deux cas, modifier le contenu à un endroit le modifie partout où il est utilisé. C’est là que s’arrête la ressemblance.
Portée : un slug partagé contre un identifiant unique
La template part existe d’abord comme fichier HTML du thème (parts/header.html). Tant qu’elle n’a jamais été modifiée depuis l’éditeur, WordPress la sert directement depuis ce fichier. Dès qu’un utilisateur la personnalise dans l’éditeur de site, une copie est enregistrée dans le post type wp_template_part, qui prend le pas sur le fichier du thème — sans jamais l’écraser. Ce mécanisme de repli (theme puis base) permet de revenir à l’original en supprimant l’entrée en base.
Le pattern synchronisé, lui, n’a pas d’équivalent fichier natif : il vit uniquement en base, sous forme d’article wp_block. Deux patterns synchronisés distincts peuvent avoir un contenu identique sans jamais partager le moindre lien — contrairement au slug de template part, qui garantit l’unicité au sein du thème actif.
Droits d’édition : qui peut toucher à quoi
Modifier une template part dans l’éditeur de site nécessite la capacité edit_theme_options, réservée par défaut aux administrateurs et éditeurs disposant de droits élevés sur le thème. C’est cohérent : une template part touche à la structure visuelle globale du site.
Un pattern synchronisé, en tant qu’article du type wp_block, suit les capacités classiques de gestion de contenu (edit_posts et assimilées). Un rédacteur habilité à modifier des articles peut donc éditer un pattern synchronisé inséré dans son contenu, sans avoir accès à l’éditeur de site. Pour une équipe où les rédacteurs gèrent un encart promotionnel répété dans plusieurs articles, c’est souvent l’argument décisif en faveur du pattern.
Export et portabilité entre projets
Les template parts personnalisées s’exportent nativement avec le thème : le menu Outils > Exporter de l’éditeur de site (ou l’extension Create Block Theme) régénère les fichiers parts/*.html à partir du contenu en base, prêts à être versionnés dans le dépôt Git du thème.
Les patterns synchronisés n’ont pas cette voie d’export automatique vers des fichiers de thème. Il faut les exporter individuellement en JSON depuis le menu du pattern dans l’éditeur, ou passer par Create Block Theme qui sait aussi convertir un pattern synchronisé en fichier PHP enregistré côté thème — perdant au passage la synchronisation en base au profit d’un enregistrement classique via register_block_pattern().
Ce que ça change en pratique
- Un header ou un footer : template part, pour bénéficier du fallback thème et de l’export propre.
- Un encart promotionnel géré par les rédacteurs dans le corps des articles : pattern synchronisé, pour les droits d’édition adaptés.
- Un élément présent sur cinq sites d’un même réseau avec un thème différent à chaque fois : ni l’un ni l’autre nativement, plutôt un pattern enregistré via PHP et partagé par un plugin mu.
Traduction et sites multilingues
Le contenu d’une template part encore stockée uniquement en fichier thème profite des fonctions de traduction PHP classiques si le développeur les a utilisées (_e(), esc_html_e()) dans un fichier de rendu associé. Mais dès qu’elle est personnalisée depuis l’éditeur et enregistrée en base, son contenu devient un bloc HTML brut, sans mécanisme de traduction natif — chaque site d’un réseau multilingue doit alors porter sa propre version.
Le pattern synchronisé souffre du même problème : son contenu est un post en base, lié à une langue au sens strict d’un plugin multilingue seulement s’il est explicitement dupliqué et traduit par ce plugin. Aucun des deux mécanismes ne résout la traduction par magie.
| Critère | Template part | Pattern synchronisé |
|---|---|---|
| Stockage par défaut | Fichier thème, avec repli base si modifié | Toujours en base (wp_block) |
| Droit d’édition requis | edit_theme_options | edit_posts |
| Export vers le thème | Natif via Outils > Exporter | Manuel, JSON ou via extension |
| Usage typique | En-tête, pied de page, zones structurelles | Encarts insérés dans le contenu éditorial |
Notre verdict
Pour un élément structurel qui appartient au thème — en-tête, pied de page, barre latérale répétée — la template part reste le choix le plus cohérent : elle suit le cycle de vie du thème, s’exporte proprement et respecte la séparation entre configuration du site et contenu éditorial.
Pour un élément que des rédacteurs doivent pouvoir modifier sans toucher à l’éditeur de site, le pattern synchronisé l’emporte grâce à ses droits d’édition plus permissifs. Entre les deux, la question à se poser n’est pas « qu’est-ce qui est techniquement le plus simple à mettre en place », mais « qui, dans l’équipe, doit avoir la main dessus ».
