Difficile de se souvenir, sept ans après l’arrivée de Gutenberg dans le cœur de WordPress, à quel point développer un bloc relevait alors du bricolage. Pas de fichier de déclaration unifié, un outillage de build à assembler soi-même, aucune API standard pour l’interactivité front. Le chemin parcouru depuis mérite un vrai temps d’arrêt, avec le recul suffisant pour distinguer les évolutions qui ont réellement changé la pratique quotidienne de celles restées plus anecdotiques.
Cet article propose un bilan de cette évolution, des premières années de registerBlockType écrit à la main jusqu’à l’écosystème actuel, avec l’Interactivity API et les block bindings solidement établis, et un regard sur ce que laisse entrevoir la feuille de route vers WordPress 7.0.
Les débuts : un outillage à construire soi-même
Dans les premières années de Gutenberg, chaque équipe de développement configurait son propre pipeline de build, généralement autour de webpack et de Babel, pour transformer du JSX en JavaScript compatible. La déclaration d’un bloc se répartissait entre un fichier JS pour la partie éditeur et un enregistrement PHP séparé pour la partie serveur, sans lien formel entre les deux, ce qui rendait la maintenance fastidieuse dès que le nombre de blocs augmentait.
L’arrivée de @wordpress/scripts a rapidement changé la donne en fournissant un outillage prêt à l’emploi, sans configuration à écrire pour démarrer. Mais c’est surtout la généralisation de block.json qui a structuré durablement la façon de déclarer un bloc, en centralisant en un seul fichier des informations jusque-là dispersées.
block.json : la vraie bascule structurelle
Avec le recul, block.json reste probablement l’évolution la plus structurante de toute l’histoire des blocs Gutenberg, davantage encore que certaines fonctionnalités plus spectaculaires. Elle a permis à l’écosystème tout entier, des outils de scaffolding aux validateurs du répertoire WordPress.org, de s’appuyer sur un format commun et prévisible. Le passage progressif de l’apiVersion 2 à 3, avec l’éditeur iframé, a prolongé cette logique de standardisation sans jamais casser la compatibilité ascendante, un choix qui a permis une adoption progressive plutôt que forcée.
Cette stabilité contractuelle a aussi rendu possible l’essor des blocs bindings et de l’Interactivity API sans réécriture de l’existant : les nouvelles fonctionnalités s’ajoutent comme des propriétés supplémentaires dans un format déjà connu, plutôt que comme une rupture de paradigme.
De l’interactivité artisanale à un modèle unifié
Le second grand tournant concerne le JavaScript côté front. Pendant des années, chaque plugin réinventait sa propre façon de rendre un bloc interactif : jQuery pour les uns, vanilla JS pour les autres, parfois un mini-framework maison. L’Interactivity API, stabilisée avec WordPress 6.5, a offert un vocabulaire commun, avec des directives déclaratives et un store partagé, qui réduit considérablement la quantité de code à écrire pour des interactions courantes comme un accordéon ou un système de filtres.
En parallèle, la Block Bindings API a comblé un vide resté longtemps ouvert : connecter un bloc natif à une donnée dynamique sans écrire de bloc dynamique complet. Ces deux évolutions, arrivées la même année, ont sensiblement réduit le volume de code sur mesure nécessaire pour des besoins qui, auparavant, justifiaient systématiquement un nouveau bloc dynamique from scratch.
Ce qui a le moins changé
Certains fondamentaux, eux, sont restés remarquablement stables : le cycle edit()/save(), la logique des attributs typés, ou encore le mécanisme de déprécation pour gérer les migrations de markup. Ce socle conçu tôt dans le projet a résisté à sept ans d’évolutions, preuve d’une architecture initiale plutôt solide, même si son adoption a pris du temps du côté des développeurs les plus habitués aux anciennes pratiques.
Un écosystème d’outils tiers qui a mûri en parallèle
Les solutions tierces ont accompagné ce mouvement plutôt que de le freiner. Advanced Custom Fields a intégré très tôt ses propres blocs, offrant une voie d’entrée accessible aux développeurs venus du PHP classique. Le répertoire officiel de blocs s’est étoffé, avec un processus de revue devenu plus rigoureux au fil des années, en particulier sur les questions de sécurité et d’accessibilité.
- L’outillage de test (Jest, Playwright via e2e-test-utils) est devenu un standard de fait sur les projets sérieux, alors qu’il restait marginal les premières années.
- Les patterns de blocs, généralisés depuis plusieurs versions, ont réduit le besoin de créer un nouveau bloc pour de simples variations de mise en page.
- L’accessibilité des blocs, longtemps secondaire dans les priorités, fait désormais partie des critères examinés lors de la revue du répertoire officiel.
Ce que laisse entrevoir WordPress 7.0
Avec l’Abilities API introduite fin d’année dernière, WordPress pose les bases d’une exposition structurée de fonctionnalités du site à des agents externes, y compris des agents d’intelligence artificielle capables d’interagir avec le contenu via des protocoles comme MCP. Il est encore tôt pour savoir précisément comment cette API influencera le développement de blocs au quotidien, mais la direction est cohérente avec l’évolution générale observée ces dernières années : donner aux blocs des points d’interaction standardisés, plutôt que de laisser chaque plugin inventer sa propre convention.
Ce qui frappe le plus avec le recul, ce n’est pas telle ou telle fonctionnalité isolée, mais la constance de la direction prise : moins de code à écrire pour les cas courants, davantage de standards partagés pour les cas avancés.
Notre verdict
Sept ans après ses débuts hésitants, le développement de blocs Gutenberg a atteint une maturité que peu auraient anticipée au lancement du projet. block.json a apporté la structure, l’Interactivity API et les block bindings ont réduit le besoin de code sur mesure pour des besoins courants, et l’écosystème d’outils de test et de publication s’est professionnalisé. Reste à voir comment l’Abilities API et les futures versions de WordPress redéfiniront, une nouvelle fois, ce que signifie « développer un bloc » dans les années à venir.
