L’Interactivity API, introduite avec WordPress 6.5, a suscité une question récurrente dès son annonce dans les cercles de développeurs travaillant en headless : puisque WordPress fournit désormais un mécanisme natif pour gérer de l’état interactif côté client, sans dépendre de React ni de Vue, peut-on le récupérer pour un front totalement découplé qui n’utilise ni le thème PHP, ni le rendu de blocs natif de WordPress ?
La réponse mérite d’être posée avec précision, car la tentation de « profiter » d’une fonctionnalité native de WordPress dans un contexte où elle n’a pas été conçue pour s’appliquer peut mener à des heures perdues. Voici ce qui a été testé, ce qui fonctionne réellement, et ce qui relève du cul-de-sac.
Ce que fait concrètement l’Interactivity API
L’Interactivity API fonctionne par des directives ajoutées directement dans le balisage HTML des blocs, comme data-wp-interactive, data-wp-on--click ou data-wp-bind--hidden. Ces directives sont lues à l’exécution, dans le navigateur, par un petit moteur JavaScript fourni par WordPress lui-même (le module @wordpress/interactivity), chargé automatiquement dès qu’un bloc utilisant ces directives est présent sur la page. L’état associé à chaque bloc est initialisé côté serveur PHP via la fonction wp_interactivity_state(), puis sérialisé dans un script type="application/json" intégré à la page, que le moteur client va lire au chargement.
Ce mécanisme repose donc sur deux éléments indissociables : un balisage HTML porteur de directives, et un moteur client qui sait interpréter ces directives. Sans les deux, l’Interactivity API ne fait rien du tout.
Ce qui casse en headless pur
Sur un site headless classique (front React ou Vue consommant l’API REST WordPress), le contenu récupéré via content.rendered contient bien, techniquement, les attributs data-wp-* si le bloc source les utilise. Mais ce contenu HTML est en général réinjecté tel quel dans une page qui ne charge jamais le module @wordpress/interactivity, puisque ce module fait partie de l’écosystème du thème PHP WordPress, chargé via le système de scripts natif (wp_enqueue_script), absent d’un front headless qui ne sert jamais de page PHP au visiteur final.
Résultat testé en conditions réelles sur un projet pilote : un bloc « Accordéon » natif de WordPress, dont l’ouverture et la fermeture reposent entièrement sur l’Interactivity API, s’affichait bien en HTML statique une fois injecté dans le front React, mais restait totalement inerte au clic. Les directives data-wp-on--click étaient présentes dans le DOM, visibles dans l’inspecteur, mais aucun code ne les interprétait côté client.
Charger le moteur manuellement : une fausse bonne idée
Une tentative a consisté à importer directement le module @wordpress/interactivity depuis son paquet npm public et à l’initialiser manuellement dans le front React, en espérant reproduire le comportement natif sans dépendre du thème PHP. Le module a bien pu être chargé, mais il attend une structure précise de balisage et un enregistrement explicite, côté serveur, des « stores » associés à chaque bloc via wp_interactivity_state(), une étape qui ne se produit que dans le rendu PHP natif de WordPress. Reproduire cette étape en dehors du rendu PHP demanderait de réimplémenter une bonne partie de la logique interne de rendu de blocs, ce qui annule l’intérêt principal du headless : ne pas dépendre du rendu PHP de WordPress.
Ce qui fonctionne réellement : l’état initial en JSON
Le seul pont exploitable de façon fiable a été de récupérer, via l’API REST, non pas le comportement interactif lui-même, mais l’état initial que WordPress aurait sérialisé pour ce bloc. En exposant cet état via un champ personnalisé register_rest_field, un front headless peut réimplémenter sa propre logique d’interactivité (avec React ou Vue) en utilisant les mêmes données de départ que celles que WordPress aurait utilisées nativement.
register_rest_field('page', 'etat_accordeon', [
'get_callback' => function ($post) {
// Extraction de l'état initial défini côté bloc
return get_post_meta($post['id'], '_etat_accordeon_initial', true);
},
]);Cette approche fonctionne, mais elle abandonne totalement l’idée de « réutiliser » l’Interactivity API : elle ne fait que récupérer une donnée d’état, exactement comme on l’aurait fait avant même l’existence de cette API, via un champ ACF ou une métadonnée classique.
Verdict après plusieurs semaines de test
- L’Interactivity API n’est pas conçue pour être consommée par un front totalement découplé ; elle est un mécanisme de rendu côté client couplé au thème PHP WordPress.
- Tenter de charger son moteur client en dehors du contexte WordPress natif demande un effort d’ingénierie disproportionné par rapport au bénéfice obtenu.
- Le seul apport réel pour un projet headless est indirect : les blocs qui migrent vers l’Interactivity API exposent souvent un état initial plus structuré et plus facile à extraire via l’API REST qu’auparavant, ce qui simplifie la réimplémentation côté React ou Vue, sans jamais réutiliser le mécanisme lui-même.
Une fonctionnalité native de WordPress n’est jamais « gratuite » à récupérer en headless simplement parce qu’elle existe ; il faut toujours vérifier de quel rendu elle dépend réellement avant de l’envisager.
Notre verdict
Sur ce point précis, l’Interactivity API reste un cul-de-sac pour un site totalement découplé, et non un pont. Elle peut en revanche simplifier indirectement le travail d’un front headless, en poussant les auteurs de blocs à exposer un état initial plus propre et plus prévisible. Les équipes qui envisagent un tel projet gagneront du temps à accepter cette limite dès le départ plutôt qu’à chercher à la contourner.
