WordCamp Nice 2026

Les 4 points clés à retenir

1. Les patterns ne sont pas de simples blocs réutilisables Utilisés correctement, ils deviennent un véritable système de construction de thèmes WordPress structuré et maintenable.

2. Le PHP change totalement leur potentiel Internationalisation, assets dynamiques, boucles et logique conditionnelle permettent de rendre les compositions plus intelligentes et réutilisables.

3. L’organisation des patterns est essentielle Nommage, catégories, entêtes enrichies et gestion programmatique permettent d’industrialiser un projet comportant plusieurs dizaines de patterns.

4. L’expérience éditeur est un levier majeur Avec des outils comme le Block Locking API, on peut offrir une interface simple et sécurisée pour les clients tout en conservant la puissance de Gutenberg.


Le 6 mars dernier, j’étais au WordCamp Nice 2026 pour animer un atelier technique consacré aux Block Patterns WordPress. L’occasion de partager mon approche et de démontrer qu’une composition, c’est bien plus qu’un bout de HTML qu’on duplique d’un projet à l’autre.

Un atelier qui a fait bouger les lignes

L’idée de cet atelier est née d’un constat simple : la plupart des développeurs WordPress, freelances ou agences, utilisent les compositions comme de simples blocs réutilisables. On copie, on colle, on ajuste à la main. Ça fonctionne, mais il est possible de faire bien plus.

Pendant presque 1h, j’ai exploré avec les participants trois axes qui transforment les patterns en un véritable système de développement professionnel.

L’utilisation de PHP

Contrairement aux templates ou templates parts, les compositions sont des fichiers .php, pas .html. Cette différence change tout. Internationalisation native, assets dynamiques liés au thème, approche DRY (Don’t Repeat Yourself) avec l’utilisation des boucles PHP par exemple… Le code devient maintenable, traduisible et portable d’un projet à l’autre.

L’industrialisation du workflow

Conventions de nommage, en-têtes de fichiers complets avec Keywords pour la recherche dans l’inserter, catégories personnalisées, contrôle programmatique via functions.php… Quand on gère 20, 30 ou 50 patterns dans un même thème, l’organisation fait toute la différence.

Amélioration de l’expérience éditeur avec par exemple le Block Locking API

C’est probablement le volet qui a le plus surpris les participants. Avec templateLock: "contentOnly", on offre au client une interface où il ne peut modifier que le texte et les médias. Plus de risque de casser une mise en page, plus de panneau latéral intimidant. Le back-office devient un outil agréable, pas un champ de mines.

Des retours qui font plaisir

Je ne m’y attendais pas à ce point : les retours ont été unanimement positifs. Y compris de la part de personnes qui estimaient avoir déjà un bon niveau sur Gutenberg et le Full Site Editing.

Plusieurs participants m’ont confié avoir découvert des possibilités qu’ils n’imaginaient pas. En particulier sur la puissance des entêtes, la Block Locking API, ou les possibilités offertes par l’utilisation du PHP. Pouvoir livrer un site adapté et personnalisé, où le client ne voit que ce qu’il doit voir, sans sacrifier la puissance de l’éditeur de blocs, ça change la donne.

Ce qui est revenu le plus souvent dans les échanges ? La qualité de l’expérience back-office. C’est un aspect trop souvent négligé dans les projets WordPress. On soigne le front, on optimise les performances, on peaufine le responsive… mais côté administration, le webmaster se retrouve face à un éditeur générique, parfois confus, rarement adapté à son contexte. C’est précisément là que je fais la différence avec WeAre[WP]. Un site bien construit, c’est un site agréable à utiliser pour tout le monde, visiteurs comme gestionnaires de contenu.

Des compositions puissantes, mais pas magiques

Bien entendu, les compositions ne font pas tout. Elles participent à une expérience globale, celle d’un thème bien pensé, d’une architecture cohérente, d’un back-office adapté à celui qui l’utilise, mais elles ont leurs limites. Et quelques participants ont d’ailleurs eu du mal à saisir certaines frontières imposées par WordPress sur ce sujet.

J’aime bien utiliser l’analogie du carrelage pour expliquer ça.

Imaginez que vous êtes carreleur. Les compositions, ce sont vos carreaux : vous pouvez en créer/utiliser avec différentes couleurs, formes, motifs. Grâce au PHP, vous pouvez même proposer des carreaux adaptés au profil du webmaster, à son métier, ou pourquoi pas à la période de l’année. Sur un même site, un éditeur du contenu éditorial n’aura pas les mêmes compositions qu’un responsable RH, ou qu’un responsable achat, et c’est exactement le but.

Mais une fois le carreau posé, il est figé. Il n’y a plus de lien avec le moule d’origine.

Concrètement : si j’utilise du PHP dans une composition pour afficher la date du jour, cette date sera correcte au moment où le webmaster insère la composition dans sa page. Mais elle ne se mettra pas à jour toute seule le lendemain. Le PHP s’exécute à l’enregistrement du pattern, pas au chargement de la page. Le carreau est posé, point final.

C’est un facteur limitant qu’il faut avoir en tête. La bonne nouvelle, c’est que WordPress évolue, et que l’API Block Bindings vient en partie combler ce manque en permettant de connecter des blocs à des sources de données dynamiques, champs personnalisés, métadonnées, et bien d’autres. Le carreau reste posé, mais on peut maintenant y incruster un petit « écran » qui, lui, se met à jour en temps réel. C’est un sujet passionnant qui mériterait un atelier à part entière.

Mon expertise, votre avantage

Cet atelier est le reflet de ce que je mets en pratique au quotidien dans les projets de l’agence :

  • Gutenberg et Full Site Editing : nous concevons des thèmes sur mesure qui exploitent pleinement l’éditeur de blocs, avec des compositions structurées, documentés et maintenables.
  • Performance : un code propre et des patterns bien architecturés, c’est aussi un site plus rapide. Pas de surcharge de plugins, pas de shortcodes imbriqués, pas de constructeurs de page superflus.
  • UX / UI / AX : nous pensons l’expérience utilisateur du visiteur, mais aussi celle de l’éditeur. L’administrator experience (AX) est intégrée dès la conception, pas ajoutée en fin de projet.
  • Accompagnement : nous livrons des sites que nos clients savent utiliser en autonomie, parce que l’interface a été pensée avec eux, pour eux.

Ressources en libre accès

Parce que le partage fait partie de l’ADN de la communauté WordPress et de l’Open Source, je mets à disposition les ressources de l’atelier :

  • Un thème de démonstration complet est disponible sur GitHub : github.com/thierrypigot/wc-nice. Il contient plus de 40 patterns couvrant tous les cas abordés pendant l’atelier : internationalisation, assets dynamiques, boucles PHP, verrouillage par niveaux, starter pages et patterns de templates…
  • Le support de présentation utilisé pendant l’atelier est également téléchargeable en PDF : Télécharger le support (PDF).

N’hésitez pas à explorer, forker et adapter ces ressources à vos propres projets.

Merci à ceux qui rendent tout ça possible

Un WordCamp, ça ne se fait pas tout seul. Avant de parler technique, il faut des gens qui bossent dans l’ombre pendant des mois pour que tout roule le jour J. Un grand merci à toute l’équipe d’organisation du WordCamp Nice 2026, ainsi qu’aux bénévoles qui étaient sur tous les fronts. Et merci aux sponsors, sans qui ces événements n’existeraient tout simplement pas.

Et puis il y a ce truc un peu particulier dans la communauté WordPress francophone : des gens qui traversent la France entière, l’Europe, pour le plaisir de se retrouver, d’échanger sur des sujets qui nous passionnent, de découvrir les projets des uns et des autres… et de finir la journée autour « d’un verre ». On appelle ça des collègues, même si on ne partage pas le même bureau. C’est toujours un plaisir de vous retrouver, et c’est aussi pour ça qu’on revient à chaque fois.

Envie d’aller plus loin ?

Si vous souhaitez un site WordPress conçu avec ce niveau d’exigence, ou si vous avez un projet qui mérite une expérience éditeur à la hauteur de son front-office, parlons-en. C’est exactement ce que nous faisons chez WeAre[WP], et visiblement, ça se voit.

Nous contacter


Thierry Pigot – Fondateur de WeAre[WP], consultant WordPress depuis plus de 15 ans, membre actif de la communauté WordPress francophone depuis 2005.

A propos de Thierry

Thierry Pigot est fondateur de WeAre[WP] et de WP Assistance. Expert WordPress depuis 2005, co-fondateur de l’association WP Paris et WP Laval, speaker aux WordCamps. Il accompagne les entreprises dans leur migration de page builders vers WordPress natif.