Faut-il un seul index de recherche filtré par langue, ou un index distinct par langue ? Cette question revient sur presque tous les projets d’annuaire multilingue, et la réponse dépend moins de préférences techniques que d’un arbitrage clair entre performance, pertinence et coût de maintenance.
Prenons le cas d’un annuaire de restaurants disponible en français, anglais et allemand, avec plusieurs milliers de fiches, chacune décrivant une cuisine, une ambiance et des avis en texte libre. C’est un cas représentatif pour poser l’arbitrage.
Option A : un index unique avec un filtre de langue
La première approche consiste à indexer toutes les fiches, toutes langues confondues, dans un seul index de recherche (Relevanssi, ElasticPress ou une solution équivalente), puis à ajouter un filtre sur le champ de langue Polylang à chaque requête. Cette approche a un avantage réel : elle simplifie l’architecture, un seul index à gérer, un seul schéma de champs.
Elle a en revanche un coût de pertinence souvent sous-estimé : un moteur de recherche doit appliquer une analyse linguistique (racinisation, gestion des accents, mots vides) adaptée à une langue précise. Avec un index unique multilingue, cette analyse doit soit se limiter à un plus petit dénominateur commun peu satisfaisant pour chaque langue, soit se complexifier fortement pour appliquer un analyseur différent selon la valeur du champ langue de chaque document, ce que peu de configurations gèrent bien nativement.
Option B : un index distinct par langue
La seconde approche crée un index de recherche séparé par langue, chacun configuré avec l’analyseur linguistique adapté (racinisation française pour l’index français, allemande pour l’index allemand). La requête de recherche interroge uniquement l’index correspondant à la langue courante du visiteur, déterminée via pll_current_language().
$langue = pll_current_language();
$index_cible = "annuaire_recherche_{$langue}";
$resultats = interroger_index( $index_cible, $terme_recherche );Schéma d’architecture retenu
Recherche visiteur
|
+-- langue = fr --> index_annuaire_fr (analyseur français)
+-- langue = en --> index_annuaire_en (analyseur anglais)
+-- langue = de --> index_annuaire_de (analyseur allemand)
|
+-- Ré-indexation déclenchée par langue à chaque publication/traductionCette structure a un coût : trois index à maintenir, trois schémas à faire évoluer en parallèle si un nouveau champ de recherche est ajouté. Mais chaque index reste plus petit, plus rapide à requêter, et surtout plus pertinent, chaque analyseur linguistique travaillant sur un corpus homogène.
Arbitrage : quand choisir quoi
| Critère | Index unique filtré | Index par langue |
|---|---|---|
| Volume de fiches par langue | Faible (quelques centaines) | Élevé (plusieurs milliers) |
| Exigence de pertinence linguistique | Basique | Fine (racinisation, synonymes) |
| Effort de maintenance accepté | Faible | Moyen à élevé |
| Fréquence des recherches | Occasionnelle | Intensive |
Le cas de l’annuaire de restaurants
Avec plusieurs milliers de fiches par langue et des recherches en texte libre sur les avis clients, l’index par langue s’est imposé : le gain de pertinence sur les recherches en allemand, langue à forte composition de mots, a justifié le coût de maintenance supplémentaire. Un annuaire plus modeste, avec quelques centaines de fiches et des recherches essentiellement par filtre de catégorie plutôt que par texte libre, aurait probablement pu se contenter d’un index unique filtré.
La question à se poser n’est jamais « combien d’index puis-je maintenir », mais « quelle pertinence mes visiteurs attendent-ils réellement de la recherche ».
En résumé
L’index par langue n’est pas systématiquement la solution supérieure : c’est un compromis qui se justifie à partir d’un certain volume de contenu et d’une exigence réelle de pertinence linguistique. En dessous de ce seuil, la simplicité d’un index unique filtré reste un choix parfaitement défendable.
