Douze mille, cinquante mille, deux cent mille : le nombre d’enregistrements indexés est souvent le seul chiffre qu’on regarde avant de brancher Algolia sur un site WordPress multilingue. C’est une erreur. La vraie question à se poser dès le premier jour, c’est la forme de l’index, pas sa taille. Une fois que des dizaines de milliers d’objets ont été poussés dans une structure donnée, la reconstruire dans l’autre sens devient un chantier à part entière, avec ré-indexation complète, changement de code côté front et parfois interruption de la recherche pendant plusieurs heures.
Deux approches dominent : un index distinct par langue (produits_fr, produits_en, produits_de…) ou un index unique contenant tous les enregistrements, avec un attribut lang filtré à la requête. Les deux fonctionnent très bien en production. Elles ne se comportent pas du tout de la même façon dès que le site grandit, change de structure tarifaire ou ajoute une langue.
Ce que change un index par langue
Avec un index séparé par langue, chaque langue a son propre classement (ranking), ses propres règles de synonymes, ses propres stop words et sa propre configuration de searchableAttributes. C’est précieux dès qu’une langue a des besoins linguistiques différents : le japonais ne segmente pas les mots comme le français, l’allemand compose des mots longs qu’il faut découper autrement pour l’auto-complétion. Séparer les index permet d’ajuster ces réglages sans jamais risquer de casser une autre langue.
La contrepartie est le coût et la maintenance : chaque index consomme un quota de configuration (règles, synonymes, A/B tests) séparé, et toute évolution de schéma — ajouter un attribut, changer une règle de tri — doit être répliquée sur chaque index, langue par langue. Sur un site à six langues, une modification de configuration devient une opération à exécuter six fois, avec le risque d’oublier une langue ou de désynchroniser les réglages.
Ce que change un index unique avec filtre
L’index unique, lui, stocke tous les enregistrements toutes langues confondues, avec un attribut facetté lang appliqué en filters à chaque requête (filters: "lang:fr"). La configuration — synonymes, règles, ranking — est unique et partagée. Ajouter une langue ne demande pas de nouvel index : il suffit d’indexer les objets avec le bon attribut lang. C’est nettement plus simple à opérer et moins coûteux en nombre d’index actifs, un critère qui compte directement sur la facture Algolia au-delà d’un certain palier.
Le revers de la médaille apparaît dès qu’une langue a besoin d’un comportement de recherche différent. Impossible d’avoir des synonymes propres au français et d’autres propres à l’anglais dans le même jeu de règles sans complexité supplémentaire (via des règles conditionnées par contexte, ce qu’Algolia permet mais qui multiplie la charge de maintenance). Le tri par pertinence linguistique — un mot composé allemand mal segmenté, par exemple — devient plus difficile à corriger sans affecter les autres langues.
Le tableau de décision
| Critère | Index par langue | Index unique filtré |
|---|---|---|
| Nombre d’index à maintenir | Un par langue | Un seul |
| Personnalisation linguistique | Totale et indépendante | Limitée, via règles conditionnelles |
| Coût de configuration | Multiplié par le nombre de langues | Fixe |
| Ajout d’une langue | Nouvel index à créer et configurer | Simple ajout d’un attribut |
| Recherche multi-langue simultanée | Nécessite une fédération de requêtes | Native, il suffit de retirer le filtre |
Le seuil qui doit trancher
Sur les projets accompagnés ces deux dernières années, le repère qui fonctionne le mieux n’est pas un volume de données mais un nombre de comportements de recherche distincts par langue. En dessous de trois langues aux besoins linguistiques proches (français, anglais, espagnol par exemple), l’index unique filtré est presque toujours le bon choix : la simplicité opérationnelle l’emporte largement. Au-delà, ou dès qu’une langue à écriture ou segmentation très différente entre en jeu (japonais, arabe, allemand avec ses mots composés), l’index par langue devient rentable malgré son coût de maintenance plus élevé.
Un cas fréquent : la migration en cours de route
Le scénario le plus coûteux reste celui d’un site qui a démarré avec un index unique, sans jamais anticiper l’ajout d’une langue à comportement différent. Ajouter le japonais à un index pensé pour le français et l’anglais oblige souvent à tout reconstruire : nouvel index, nouveau code d’appel côté React ou InstantSearch.js, nouvelle stratégie de synchronisation depuis WordPress (webhook ou tâche planifiée). Le travail de migration prend en général plus de temps que la mise en place initiale, simplement parce qu’il faut faire cohabiter l’ancien système avec le nouveau pendant la bascule.
Sur ce type de décision, mieux vaut perdre une demi-journée à lister les besoins linguistiques réels de chaque langue avant le premier index, plutôt que de découvrir le mur trois ans plus tard avec deux cent mille produits à ré-indexer.
- Lister les langues déjà prévues à moyen terme, pas seulement celles en ligne aujourd’hui
- Identifier les langues à segmentation ou écriture atypique (CJK, arabe, langues à mots composés)
- Chiffrer le coût réel des index supplémentaires dans le plan Algolia retenu
- Prototyper la recherche multi-langue simultanée si elle est un jour envisagée
En résumé
Il n’existe pas de bonne architecture Algolia multilingue dans l’absolu, seulement une architecture cohérente avec les besoins linguistiques réels du site. L’index unique filtré convainc par sa simplicité et son coût maîtrisé tant que les langues restent proches dans leur comportement de recherche. L’index par langue, plus lourd à opérer, devient indispensable dès qu’une langue exige un traitement à part. Le vrai risque n’est pas de choisir l’un ou l’autre : c’est de ne jamais se poser la question avant que le volume ne rende le changement de cap trop coûteux.
