« make.wordpress.org » le décrit clairement dans son annonce de WordPress 6.5, publiée en avril 2024 : l’Interactivity API fournit « un standard pour créer des expériences interactives basées sur les blocs, avec une empreinte JavaScript minimale ». Une promesse séduisante pour un thème classique. Beaucoup moins évidente à traduire pour un projet où WordPress ne sert jamais directement de HTML au visiteur final.
Sur un projet consommant WordPress via l’API REST ou WPGraphQL, avec un rendu entièrement assuré par un frontend React découplé, la question s’est posée assez vite : l’Interactivity API peut-elle être exploitée pour livrer de l’interactivité déjà prête à l’emploi jusqu’au front, ou reste-t-elle cantonnée aux projets qui rendent leurs blocs directement côté serveur WordPress ?
Comment fonctionne réellement l’Interactivity API
L’Interactivity API repose sur trois éléments : une directive déclarative ajoutée au balisage HTML généré par le bloc (data-wp-interactive, data-wp-on--click, etc.), un magasin d’état JavaScript associé au bloc via store(), et un petit runtime chargé côté navigateur qui interprète ces directives pour activer l’interactivité sans dépendre d’un framework complet comme React.
Ce mécanisme suppose un point essentiel : c’est WordPress lui-même qui génère le balisage HTML du bloc, directives incluses, au moment du rendu de la page. Un site headless, par construction, ne laisse jamais WordPress générer ce HTML final : il ne récupère que le contenu structuré (JSON via REST, ou objet typé via WPGraphQL), à charge pour le front de le transformer lui-même en balisage.
Ce qui ne franchit pas la frontière headless
Un bloc Gutenberg natif utilisant l’Interactivity API, comme le bloc de navigation avec son menu déroulant mobile interactif, expose son contenu via l’API REST sous la forme du HTML rendu de son innerHTML Gutenberg, directives incluses en tant qu’attributs bruts. Mais le petit runtime JavaScript qui interprète ces directives (@wordpress/interactivity) n’est jamais chargé côté headless, puisque WordPress ne sert jamais de page complète au visiteur.
Concrètement, un front React qui affiche ce HTML brut hérite d’attributs data-wp-interactive totalement inertes, sans aucun comportement associé, à moins de recréer soi-même l’équivalent de ce comportement côté React.
Où la duplication devient inévitable
Pour un composant interactif équivalent (un accordéon, un onglet, une navigation mobile), deux options se présentent en architecture headless, sans troisième voie satisfaisante identifiée à ce jour :
- Ignorer entièrement le balisage généré par l’Interactivity API côté WordPress et réécrire le composant équivalent en React, avec sa propre gestion d’état
- Utiliser WordPress uniquement pour la structure de contenu (texte, images), et gérer toute la logique interactive exclusivement côté front, sans lien avec les blocs
Dans les deux cas, la promesse initiale de l’Interactivity API (« empreinte JavaScript minimale, sans devoir écrire de logique React ou Vue ») ne s’applique tout simplement pas au périmètre headless : la logique doit être réécrite, pas réutilisée.
Un pont possible, mais partiel
Un usage plus mesuré reste envisageable pour les portions du site qui ne sont pas rendues par le frontend découplé, mais restent servies directement par WordPress : une page de prévisualisation interne, un back-office enrichi, ou un sous-domaine spécifique non couvert par le frontend principal. Dans ce périmètre restreint, l’Interactivity API fonctionne exactement comme prévu, puisque WordPress y rend directement le HTML final.
Ce que cet article ne couvre pas
Cette analyse porte exclusivement sur la compatibilité architecturale entre l’Interactivity API et un frontend découplé. L’écriture des blocs eux-mêmes, leur enregistrement via block.json ou la structure de leur render.php, relève d’un sujet distinct qui n’est pas traité ici.
Notre verdict
L’Interactivity API est un pont pour les projets qui laissent WordPress rendre au moins une partie de leur HTML final, et un cul-de-sac pur pour une architecture entièrement headless où WordPress ne sert jamais que du contenu structuré. Sur un projet découplé, mieux vaut considérer les blocs Gutenberg comme une source de contenu et de structure, sans attendre de leur comportement JavaScript qu’il franchisse la frontière de l’API pour arriver intact jusqu’au front.
