vendredi 25 septembre 2026

À propos

Contact

IA & MCP

Recherche sémantique et embeddings : une autre façon d’indexer un site WordPress

La recherche native de WordPress compare des mots. La recherche par embeddings compare des sens. Voici comment fonctionne cette approche et comment l'intégrer sans tout reconstruire.

Par Clément Hadrot • 14 novembre 2023 • 4 min de lecture • Aucun commentaire
Recherche sémantique et embeddings : une autre façon d'indexer un site WordPress

La recherche intégrée à WordPress, basée sur la fonction WP_Query et une correspondance de type LIKE en SQL, trouve ses limites dès qu’un visiteur formule sa requête différemment du vocabulaire utilisé dans les articles. Chercher « comment accélérer mon site » ne renverra rien si l’article concerné parle uniquement de « performance » et d’« optimisation », alors que le sens recherché est exactement le même. C’est précisément le problème que la recherche sémantique, basée sur les embeddings, vient résoudre.

Cet article explique le principe de fonctionnement de cette approche et la façon de l’intégrer à un site WordPress sans repartir de zéro sur le moteur de recherche existant.

Ce qu’est un embedding

Un embedding est une représentation numérique d’un texte sous la forme d’un vecteur, c’est-à-dire une liste de plusieurs centaines ou milliers de nombres décimaux. Cette représentation est produite par un modèle spécialisé, distinct des modèles de génération de texte, entraîné pour placer les textes de sens proche à des positions proches dans cet espace numérique. Concrètement, « accélérer un site » et « optimiser les performances » produiront deux vecteurs mathématiquement proches, même si aucun mot n’est commun aux deux expressions.

La recherche sémantique consiste alors à transformer la requête de l’utilisateur en vecteur, puis à chercher dans la base de contenu les vecteurs les plus proches selon une mesure de distance (le plus souvent la similarité cosinus), plutôt que de comparer des chaînes de caractères.

Pourquoi WordPress seul ne suffit pas

MySQL, le moteur de base de données historique de WordPress, n’est pas conçu pour ce type de recherche par proximité vectorielle à grande échelle. Chercher les vecteurs les plus proches parmi plusieurs milliers d’articles nécessite un index spécialisé, que les extensions MySQL classiques ne fournissent pas nativement sur les versions utilisées majoritairement par les hébergements mutualisés en 2023. En pratique, la plupart des intégrations combinent WordPress avec un service externe dédié : une base de données vectorielle indépendante, interrogée via une API REST depuis l’extension WordPress.

L'essentiel à retenir : La recherche WordPress native repose sur une correspondance de mots-clés en SQL ; Les embeddings représentent le sens d'un texte sous forme de vecteur numérique ; Une base vectorielle externe est presque toujours nécessaire en complément

Ce service externe stocke les vecteurs générés pour chaque article, avec l’identifiant du contenu correspondant en métadonnée, et répond à une requête de recherche en renvoyant la liste des identifiants les plus pertinents. WordPress se charge ensuite d’aller chercher les articles correspondants via WP_Query avec un tableau d’identifiants (post__in), en respectant l’ordre de pertinence renvoyé par le service vectoriel.

Construire l’index initial

La mise en place démarre par la génération des embeddings pour l’ensemble du contenu existant. Ce traitement s’effectue idéalement via WP-CLI, dans une commande personnalisée qui parcourt les articles et appelle l’API d’embeddings pour chacun :

wp mon-extension indexer-embeddings --post_type=post --batch-size=20

Ce script parcourt les articles par lots, envoie le contenu de chacun à l’API d’embeddings, puis transmet le vecteur obtenu à la base vectorielle avec l’identifiant WordPress associé. Traiter par lots limite le risque de dépassement de délai d’exécution PHP sur un catalogue de plusieurs centaines d’articles, un piège fréquent si l’indexation est lancée en une seule requête via l’interface d’administration.

Maintenir l’index à jour

Une fois l’index initial construit, il faut le maintenir synchronisé avec les publications et modifications ultérieures. Le hook save_post est le point d’entrée naturel pour déclencher une réindexation, mais il ne doit surtout pas appeler l’API d’embeddings de façon synchrone à chaque enregistrement, sous peine de ralentir l’expérience d’édition. La bonne pratique consiste à planifier la réindexation via wp_schedule_single_event(), pour un traitement en arrière-plan quelques secondes après la sauvegarde.

  • Déclencher la réindexation sur save_post, uniquement pour les statuts publiés
  • Différer le traitement réel via une tâche planifiée asynchrone
  • Supprimer l’entrée correspondante côté base vectorielle sur le hook before_delete_post

Une recherche sémantique mal maintenue devient vite pire qu’une recherche classique : elle renvoie du contenu qui n’existe plus.

En résumé

La recherche par embeddings apporte une amélioration nette pour les visiteurs qui ne formulent pas leur requête avec le vocabulaire exact du site, un cas fréquent sur les blogs à forte volumétrie de contenu. Sa mise en œuvre sur WordPress passe presque toujours par un service vectoriel externe, interrogé en complément du moteur de recherche natif, avec une attention particulière portée à la synchronisation entre le contenu WordPress et son index vectoriel dans la durée.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi