60 millisecondes : c’est à peu près le temps de réponse observé sur un index Typesense de deux mille offres d’emploi hébergé sur un petit serveur, contre plusieurs centaines de millisecondes pour une requête WP_Query équivalente avec des méta-requêtes imbriquées. Pour une agence de recrutement dont le catalogue d’offres change plusieurs fois par jour, cet écart se voit tout de suite.
Ce billet explique comment brancher un bloc Gutenberg personnalisé sur une instance Typesense plutôt que sur la recherche native de WordPress, pour un champ de recherche d’offres tolérant aux fautes de frappe. L’indexation des candidatures reçues via un formulaire reste hors sujet ici : seule la recherche d’offres est traitée.
Pourquoi la recherche native montre ses limites
La recherche native de WordPress s’appuie sur une comparaison LIKE dans la table wp_posts. Elle ne gère ni la tolérance aux fautes, ni le tri par pertinence fine, ni le filtrage combiné par lieu et type de contrat sans complexifier fortement la requête. Sur un catalogue d’offres qui change au quotidien, les résultats deviennent vite approximatifs, et chaque filtre supplémentaire alourdit la requête SQL générée.
Typesense, moteur de recherche open source pensé pour la tolérance aux fautes de frappe et la vitesse, se présente comme une alternative légère à des solutions plus lourdes à opérer. Il s’installe sur un petit serveur dédié ou via un conteneur, et expose une API REST simple à interroger.
Indexer les offres depuis WordPress
La première étape consiste à pousser chaque offre publiée vers la collection Typesense, via le hook save_post :
add_action( 'save_post_offre', function( $post_id ) {
if ( wp_is_post_revision( $post_id ) ) {
return;
}
$document = array(
'id' => (string) $post_id,
'titre' => get_the_title( $post_id ),
'lieu' => get_post_meta( $post_id, 'lieu', true ),
'contrat' => get_post_meta( $post_id, 'contrat', true ),
);
wp_remote_post( 'http://localhost:8108/collections/offres/documents', array(
'headers' => array(
'X-TYPESENSE-API-KEY' => TYPESENSE_API_KEY,
'Content-Type' => 'application/json',
),
'body' => wp_json_encode( $document ),
) );
} );
Un bloc de recherche qui interroge Typesense
Le bloc lui-même reste volontairement simple : un champ de saisie et une zone de résultats, tous deux gérés côté client. Dès que l’utilisateur tape, un script front interroge directement l’API de recherche Typesense, sans passer par une route REST WordPress intermédiaire :
const reponse = await fetch(
'http://localhost:8108/collections/offres/documents/search?q=' + terme + '&query;_by=titre,lieu',
{ headers: { 'X-TYPESENSE-API-KEY': cleRecherche } }
);
const resultats = await reponse.json();La clé utilisée côté navigateur doit être une clé de recherche à droits restreints, générée séparément de la clé d’administration utilisée pour l’indexation côté serveur. C’est un point de sécurité à ne jamais négliger : une clé complète exposée dans le JavaScript public permettrait de modifier l’index depuis n’importe quel navigateur.
Ce que ce choix apporte vraiment
- Une tolérance native aux fautes de frappe, sans configuration supplémentaire
- Un temps de réponse mesuré autour de 60 millisecondes sur un index de deux mille offres
- Un filtrage combiné par lieu et type de contrat sans complexifier la requête
Les limites à connaître avant de se lancer
Installer et maintenir une instance Typesense ajoute un service à surveiller, avec ses propres sauvegardes et sa propre supervision. Pour une agence avec deux cents offres et peu de trafic, la recherche native suffit largement. La bascule vers Typesense se justifie surtout quand le volume d’offres et la fréquence de mise à jour rendent la recherche native visiblement lente ou imprécise.
Sur ce type de projet, on ne branche jamais la clé d’administration côté navigateur : une clé de recherche dédiée, généré avec des droits limités, évite bien des mauvaises surprises.
Notre verdict
Pour un catalogue d’offres de plusieurs centaines d’entrées mis à jour en continu, Typesense apporte une recherche nettement plus rapide et plus tolérante que la recherche native, au prix d’un service supplémentaire à opérer. Le bloc de recherche reste léger côté WordPress : toute la charge de calcul repose sur Typesense, ce qui laisse l’éditeur et le front WordPress inchangés par ailleurs.
