WordPress a longtemps rimé avec jQuery puis React, mais le vent tourne : la réactivité native dans le navigateur progresse, et WordPress l’a bien compris. Avec l’Interactivity API introduite en WP 6.5, on peut désormais créer des interfaces dynamiques sans embarquer un framework JavaScript entier — et c’est là que la Signals API entre en scène. Dans cet article, on va voir concrètement ce que sont les signals, comment WordPress les exploite déjà, et si vous devriez (ou non) les adopter dès maintenant dans vos projets.
Signals API : c’est quoi exactement ?
Avant de plonger dans l’intégration avec WordPress, il faut poser les bases. La Signals API JavaScript, c’est un concept qui circule depuis un moment dans la communauté frontend — mais qui prend aujourd’hui une forme plus concrète et standardisée. Alors, de quoi parle-t-on vraiment ?
La réactivité côté navigateur, un vieux problème
Gérer l’état d’une interface dans le DOM natif, c’est historiquement… fastidieux. Sans framework, dès qu’une donnée change, c’est à vous de tout orchestrer manuellement : sélectionner le bon élément, mettre à jour son contenu, déclencher les effets secondaires associés. Le moindre oubli, et votre interface se désynchronise silencieusement.
// L'ancienne façon : tout à la main
let count = 0;
document.getElementById('btn').addEventListener('click', () => {
count++;
document.getElementById('display').textContent = count; // oubliez cette ligne... et c'est le bug
});
C’est verbeux, fragile, et difficile à maintenir dès que l’application grossit. C’est précisément pour résoudre ce problème que des frameworks comme React, Vue ou Svelte ont émergé — chacun avec sa propre approche de la réactivité.
Le concept de Signal : un état observable
Un Signal, c’est un peu comme un interrupteur connecté dans une maison domotique : quand vous l’actionnez, toutes les ampoules qui en dépendent se mettent à jour automatiquement, sans que vous ayez à les appeler une par une. C’est exactement ça, l’idée centrale.
Techniquement, un Signal encapsule une valeur et notifie automatiquement tous ses « abonnés » (effets, calculs dérivés) dès qu’elle change. Si vous avez déjà utilisé useState en React, ref() en Vue, ou les stores de Svelte, vous connaissez déjà ce paradigme sous une autre forme.
La différence avec la Signals API JavaScript native, c’est que ça ne dépendrait d’aucun framework. L’état observable serait directement géré par le navigateur, de façon standardisée. Voilà pourquoi ça intéresse beaucoup de monde, y compris dans l’écosystème WordPress.
Où en est la spécification aujourd’hui ?
La Signals API est portée par le groupe TC39 — le comité qui standardise JavaScript. Au printemps 2026, la proposition est active et a franchi les premières étapes du processus de standardisation. Il faut cependant être clair : ce n’est pas encore un standard figé. La spécification continue d’évoluer, et les implémentations natives dans les navigateurs ne sont pas encore disponibles de façon généralisée.
Du côté des navigateurs, la position est celle de l’observation attentive : Chrome, Firefox et Safari suivent les travaux du TC39, mais aucun n’a déployé d’implémentation stable en production à ce stade. Des polyfills existent déjà (notamment le paquet signal-polyfill) pour tester le concept dès maintenant.
Bref : c’est une proposition sérieuse, avec une vraie dynamique, mais il faudra encore un peu de patience avant de la retrouver nativement dans tous les navigateurs.
WordPress et la Signals API : quel intérêt concret ?
On a vu dans la section précédente ce qu’est la Signals API et pourquoi elle intéresse autant la communauté JavaScript. Mais concrètement, qu’est-ce que ça change pour WordPress ? Beaucoup plus qu’on ne le pense au premier abord.
Interactivity API de WordPress et les signals
Depuis WordPress 6.5, une nouvelle API fait son entrée dans le cœur de WordPress : l’Interactivity API. L’idée, c’est de permettre des interactions frontend légères directement dans les blocs, sans avoir à charger un framework complet.
Ce qui est intéressant — et peu de gens le savent — c’est que cette API s’appuie en coulisses sur @preact/signals-core. Autrement dit, WordPress utilise déjà une implémentation des signals. La réactivité déclarative est donc bel et bien présente dans l’écosystème WordPress aujourd’hui, même si elle reste encapsulée derrière l’abstraction de l’Interactivity API.
C’est un signal fort (sans jeu de mots) : l’équipe Core a misé sur ce paradigme. Et si la proposition TC39 aboutit à une standardisation native dans les navigateurs, WordPress sera en excellente position pour en tirer parti directement.
Réduire la dépendance à React dans les blocs Gutenberg
Gutenberg, c’est fantastique pour l’expérience éditeur… mais côté frontend, on traîne souvent un bundle JavaScript assez lourd. React est chargé pour des interactions parfois très simples : un accordéon, un filtre de liste, un compteur. C’est un peu comme utiliser un marteau-piqueur pour planter un clou.
Avec une approche basée sur les signals, on peut gérer ces états réactifs simples sans charger React du tout. L’Interactivity API va exactement dans ce sens : elle offre une alternative légère pour les blocs qui n’ont pas besoin de toute la puissance de React côté client.
Résultat : moins de JavaScript à parser, moins de travail pour le navigateur, et des métriques Core Web Vitals qui s’améliorent — notamment l’INP (Interaction to Next Paint), qui mesure la réactivité de la page aux actions utilisateur.
Un exemple pratique : un compteur réactif sans framework
Voici un exemple concret d’un bloc Gutenberg utilisant l’Interactivity API avec une logique de type signal pour un simple compteur de clics :
// Dans render.php du bloc
<div
data-wp-interactive="mon-bloc"
data-wp-context='{ "count": 0 }'
>
<p data-wp-text="context.count">0</p>
<button data-wp-on--click="actions.increment">
Cliquer ici
</button>
</div>
// Dans view.js du bloc
import { store } from '@wordpress/interactivity';
store( 'mon-bloc', {
actions: {
// L'état réactif est géré automatiquement via le contexte
increment() {
const { count } = this.context; // lecture de l'état
this.context.count = count + 1; // mise à jour → re-render automatique
},
},
} );
Pas de useState, pas de ReactDOM.render. L’état (count) est observé automatiquement, et le DOM se met à jour en conséquence. C’est exactement le principe des signals, appliqué à WordPress. Le code est lisible, maintenable, et le bundle final est nettement plus léger qu’avec un composant React équivalent.
Performances et compatibilité : ce qu’il faut surveiller
Les avantages sont réels : bundle plus léger, moins de JavaScript à exécuter côté client, meilleur score LCP et surtout INP dans les Core Web Vitals. Pour un site qui cherche à optimiser ses performances frontend, c’est un argument sérieux.
Mais attention, il y a des points à surveiller. La Signals API native (la proposition TC39) n’est pas encore standardisée, et le support navigateur est pour l’instant inexistant sans polyfill. L’Interactivity API de WordPress contourne ce problème en embarquant @preact/signals-core directement — donc pas de dépendance au navigateur pour l’instant.
Autre limitation : les thèmes classiques (non-block themes) ne bénéficient pas naturellement de tout cela. L’Interactivity API est pensée pour l’écosystème des blocs. Si votre site tourne encore sur un thème classique avec un page builder, vous n’êtes pas encore dans ce paradigme.
Donc, oui, c’est prometteur. Mais comme souvent en développement WordPress, il faut bien évaluer son contexte avant de foncer.
Faut-il adopter les Signals dès maintenant dans ses projets WordPress ?
Bon, on arrive au moment où il faut trancher. Est-ce que vous devriez intégrer les Signals dans vos projets WordPress aujourd’hui ? Ma réponse courte : ça dépend vraiment de votre contexte. Mais si vous voulez une réponse honnête et un peu plus nuancée, voilà ce que j’en pense après avoir creusé le sujet.
Les cas où vous devriez explorer ça dès maintenant
Si vous travaillez déjà avec l’Interactivity API ou le Full Site Editing, vous êtes en terrain favorable. Les Signals font déjà partie de la stack via @preact/signals-core — donc vous ne partez pas de zéro, vous exploitez simplement mieux ce qui existe.
Concrètement, les cas d’usage où ça vaut clairement le coup dès aujourd’hui :
- Blocs Gutenberg interactifs : carrousels, accordéons, onglets — tout ce qui nécessite un état local sans sortir l’artillerie lourde React
- Filtres AJAX : affichage dynamique de produits WooCommerce ou de posts sans rechargement de page
- Interfaces légères : formulaires multi-étapes, toggles, compteurs — des interactions simples où charger un framework complet serait disproportionné
Dans ces cas, les Signals permettent d’obtenir de la réactivité native avec un impact minimal sur les performances (LCP, INP). C’est exactement le genre de situation où cette approche brille.
Les cas où il vaut mieux attendre
Par contre, si vous maintenez un thème classique (sans FSE), ou si votre projet est en production critique avec des milliers de visites par jour, la prudence s’impose. La proposition TC39 n’est pas encore standardisée — elle est au stade 1. Ça peut évoluer, être amendée, voire être retirée (même si c’est peu probable vu l’adoption déjà en cours).
De même, si votre équipe n’est pas encore à l’aise avec l’Interactivity API, empiler les Signals par-dessus risque de créer plus de confusion que de valeur. Mieux vaut maîtriser les fondations avant d’explorer les couches supérieures.
Pour aller plus loin
Si vous voulez creuser le sujet, voici les ressources que je recommande :
- 📦 Repo GitHub TC39 : tc39/proposal-signals — la proposition officielle, avec les discussions et l’état d’avancement
- 📖 Documentation WordPress : developer.wordpress.org/block-editor/reference-guides/interactivity-api/ — la référence pour l’Interactivity API
- 📝 Make WordPress Core : les articles de l’équipe core sur make.wordpress.org/core expliquent les choix d’architecture et les roadmap prévues — indispensable pour suivre l’évolution
Une direction qui fait du bien
Ce qui me réjouit dans tout ça, c’est la direction que prend WordPress. Moins de JavaScript superflu, des interactions natives plus performantes, une meilleure expérience utilisateur sans sacrifier la DX (Developer Experience). La standardisation JavaScript avance, WordPress s’y adapte intelligemment plutôt que de tout miser sur un framework propriétaire.
Ce n’est pas une révolution du jour au lendemain — mais c’est un signal clair (sans mauvais jeu de mots) que l’écosystème mûrit. Et franchement, pour les développeurs WordPress qui ont souffert du « tout React » imposé lors de l’arrivée de Gutenberg, c’est une très bonne nouvelle.