# Bloc de recherche Algolia : brancher InstantSearch sans plugin de recherche > Un bloc dynamique qui rend un widget Algolia InstantSearch directement dans l'éditeur, sans passer par un plugin de recherche généraliste. - Auteur : WordPress Développement - Publié le : 2020-03-18 - Mis à jour le : 2026-09-30 - Catégorie : Blocs Gutenberg - URL : https://www.wpmoderne.fr/blocs/bloc-recherche-algolia-instantsearch-sans-plugin/ ## L’essentiel - Bloc dynamique avec render_callback dédié - InstantSearch.js chargé uniquement sur les pages qui l'utilisent - Aucune dépendance à un plugin de recherche tiers `npx @wordpress/create-block bloc-recherche-algolia` : c'est la première commande tapée pour ce projet, et elle suffit à poser le squelette du bloc qui va porter toute la recherche instantanée du site. Pas de plugin de recherche à configurer avec quinze réglages inutiles, pas de shortcode à placer à la main dans un widget : un bloc dynamique, un rendu PHP, et le widget Algolia InstantSearch qui prend le relais côté client. Ce choix a du sens dès que le volume de contenu dépasse ce que `WP_Query` peut indexer raisonnablement en LIKE SQL, ou dès que le client veut une recherche à facettes (catégories, prix, disponibilité) sans latence perceptible. Algolia fait tout le travail de pertinence et de vitesse ; le bloc, lui, se contente d'exposer un point d'ancrage propre dans l'éditeur et de charger le strict nécessaire en façade. ## Pourquoi un bloc plutôt qu'un plugin de recherche généraliste Les plugins de recherche généralistes remplacent la recherche native de WordPress partout, y compris là où ce n'est pas souhaité. Un bloc dédié, lui, ne s'active que là où il est inséré : une page d'accueil, une page catalogue, un gabarit spécifique. Cette granularité évite de charger le SDK Algolia sur des pages qui n'en ont pas besoin, ce qui compte pour le poids JavaScript global du site. Autre avantage : un bloc personnalisé expose des réglages dans le panneau latéral (nombre de résultats par page, facettes actives, placeholder du champ) sans dépendre des options d'un plugin tiers qui évoluent au rythme de son éditeur, pas du vôtre. ## Installer InstantSearch.js et déclarer le bloc Le squelette généré par `create-block` contient déjà `block.json`, `index.js`, `edit.js` et `save.js`. Comme le rendu final est piloté en PHP, `save()` ne retourne rien : c'est un bloc dynamique. ``` // block.json (extrait) { "apiVersion": 2, "name": "wpmoderne/recherche-algolia", "title": "Recherche Algolia", "category": "widgets", "attributes": { "indexName": { "type": "string", "default": "produits" }, "hitsPerPage": { "type": "number", "default": 8 } }, "editorScript": "file:./index.js", "render_callback": "wpmoderne_render_recherche_algolia" } ``` Côté npm, on installe la librairie qui va faire tourner l'interface de recherche : ``` npm install algoliasearch instantsearch.js ``` > L'essentiel à retenir : Bloc dynamique avec render_callback dédié ; InstantSearch.js chargé uniquement sur les pages qui l'utilisent ; Aucune dépendance à un plugin de recherche tiers ## Configurer l'index et les identifiants Algolia Les identifiants (Application ID, clé de recherche publique) se déclarent en constantes PHP, jamais dans le JavaScript embarqué en clair au-delà de la clé de recherche, qui est publique par nature chez Algolia : ``` define( 'ALGOLIA_APP_ID', 'A1B2C3D4E5' ); define( 'ALGOLIA_SEARCH_KEY', 'a1b2c3d4e5f6...' ); define( 'ALGOLIA_INDEX_NAME', 'produits' ); ``` La clé d'écriture (Admin API Key), elle, ne doit jamais transiter côté navigateur : elle reste réservée à la tâche d'indexation, exécutée en tâche de fond ou via WP-CLI, ce qui sort du périmètre de cet article. ## Le render_callback : injecter le conteneur et localiser le script Le PHP se charge de deux choses : afficher un conteneur HTML vide que le JavaScript viendra peupler, et transmettre la configuration au script via `wp_localize_script`. ``` function wpmoderne_render_recherche_algolia( $attributes ) { wp_enqueue_script( 'wpmoderne-algolia-front' ); wp_localize_script( 'wpmoderne-algolia-front', 'wpmAlgoliaConfig', array( 'appId' => ALGOLIA_APP_ID, 'searchKey' => ALGOLIA_SEARCH_KEY, 'indexName' => $attributes['indexName'], 'hitsPerPage' => $attributes['hitsPerPage'], ) ); return '
'; } ``` Le script front, lui, instancie InstantSearch avec les widgets standard : champ de recherche, liste de résultats, pagination. Chaque widget reste indépendant, ce qui facilite l'ajout de facettes plus tard sans réécrire le conteneur. ## Build et vérifications avant mise en production Le build passe par `wp-scripts`, déjà présent dans le squelette généré : - Vérifier que le script front n'est enqueue que sur les pages contenant le bloc (via `has_block()`), pas globalement. - Tester la recherche avec un index volontairement vide pour valider le message « aucun résultat ». - Contrôler le temps de première réponse avec les outils réseau du navigateur : au-delà de 150 ms, la configuration de l'index mérite d'être revue. - Vérifier l'accessibilité clavier du champ et de la navigation dans les résultats. ## Ce que ce tutoriel ne couvre pas L'indexation du contenu WooCommerce (produits, variations, stock) suit un cron ou un webhook dédié, avec sa propre logique de synchronisation incrémentale : ce n'est pas le sujet ici, qui se limite au bloc de restitution front. La facturation Algolia (nombre de requêtes, taille de l'index, plan tarifaire) dépend du volume du site et se négocie indépendamment de l'implémentation technique du bloc. ## En résumé Un bloc dynamique dédié à la recherche Algolia reste plus sobre qu'un plugin généraliste : il ne charge son JavaScript que là où il est utilisé, il expose des réglages clairs dans l'éditeur, et il laisse à Algolia la responsabilité de la pertinence. La contrepartie est un peu de PHP et de JavaScript à écrire soi-même, mais c'est un compromis raisonnable pour un site qui a vraiment besoin de vitesse sur sa recherche.