Faut-il interroger WPGraphQL pour construire une page de résultats de recherche, ou faut-il tout confier à Algolia dès la première lettre tapée dans la barre de recherche ? La question revient régulièrement sur les projets headless qui combinent les deux outils, et la réponse la plus solide consiste à ne jamais leur faire porter le même rôle.
WPGraphQL excelle à décrire une structure de contenu typée et à en extraire précisément les champs nécessaires au rendu d’une page. Algolia excelle à retrouver rapidement une poignée de résultats pertinents dans un corpus texte, avec tolérance aux fautes de frappe et facettes de filtrage. Les confondre revient à demander à chacun de faire ce que l’autre fait mieux.
Le rôle de WPGraphQL : décrire et servir le contenu
WPGraphQL construit un schéma typé au-dessus des types de contenu WordPress, avec des relations navigables entre eux (un article et ses catégories, une page et ses blocs ACF). Ce schéma est fait pour être interrogé de façon précise : une requête demande exactement les champs nécessaires à l’affichage d’une page, ni plus ni moins, ce qui en fait l’outil naturel pour le rendu d’une fiche produit, d’un article ou d’une page de catalogue paginée classiquement.
Ce que WPGraphQL ne fait pas nativement : une recherche texte tolérante aux fautes de frappe, un classement par pertinence sophistiqué, ou des facettes combinées calculées à la volée sur un grand volume de contenu. Ce sont des besoins pour lesquels un moteur de recherche dédié reste largement supérieur.
Le rôle d’Algolia : retrouver, pas décrire
Algolia reçoit un index construit à partir du contenu WordPress — généralement synchronisé à chaque publication via un plugin ou un appel direct à son API — et se charge exclusivement de la recherche : trouver les éléments les plus pertinents pour une requête texte, avec typo-tolerance, recherche par facettes, et un temps de réponse de l’ordre de quelques dizaines de millisecondes quel que soit le volume indexé.
La répartition concrète sur un projet
Visiteur tape "articl" dans la barre de recherche
│
▼
Requête vers Algolia (recherche floue, facettes)
│
▼
Algolia renvoie une liste d'identifiants + un extrait
│
▼
Le front affiche directement l'extrait Algolia
(pas de second appel WPGraphQL pour l'affichage des résultats)
│
▼
Clic sur un résultat → requête WPGraphQL classique
pour charger la page complète de l'article
Le point clé de cette architecture : les résultats de recherche eux-mêmes ne redemandent jamais une requête WPGraphQL supplémentaire. L’extrait, le titre et les métadonnées nécessaires à l’affichage de la liste de résultats sont déjà présents dans le document indexé côté Algolia — dupliquer cette information via un second appel GraphQL n’apporterait rien, sinon de la latence.
Le piège de la duplication de logique
L’erreur la plus fréquente sur ce type de projet consiste à répliquer, côté Algolia, la même logique de filtrage et de relations que celle déjà exprimée dans le schéma WPGraphQL — par exemple recalculer une hiérarchie de catégories des deux côtés. Cette duplication finit toujours par diverger : une catégorie renommée dans WordPress, remontée dans WPGraphQL, mais oubliée dans la prochaine synchronisation Algolia, et les deux systèmes racontent alors deux histoires différentes du même contenu.
La bonne pratique consiste à ne synchroniser vers Algolia que ce qui sert strictement la recherche — titre, extrait, quelques facettes stables — en laissant WordPress, via WPGraphQL, rester l’unique source de vérité pour tout le reste du contenu.
Ce qui doit toujours transiter par WPGraphQL
- Le contenu complet d’un article ou d’une page, avec ses blocs et ses relations.
- Les données qui changent fréquemment et doivent être toujours à jour à la lecture (stock, disponibilité).
- Toute donnée nécessitant un contrôle d’accès fin, qu’Algolia ne gère pas nativement.
Un moteur de recherche n’a pas vocation à devenir une seconde base de données de contenu : plus l’index qu’on lui confie reste étroit et spécialisé, plus il reste simple à garder synchronisé.
Les pièges à éviter
Au-delà de la duplication de logique, deux erreurs reviennent régulièrement : synchroniser vers Algolia du contenu brouillon non publié par erreur de filtre, et oublier de désindexer un contenu supprimé ou dépublié côté WordPress, ce qui laisse apparaître des résultats de recherche pointant vers des pages qui n’existent plus.
En résumé
WPGraphQL et Algolia ne sont pas deux options concurrentes pour le même besoin : ce sont deux outils complémentaires, chacun cantonné à ce qu’il fait le mieux. Poser cette frontière dès la conception de l’architecture évite la duplication de logique la plus coûteuse à maintenir sur la durée d’un projet headless.
